GPT88 / API Docs
返回博客

Agentic Engineering 实战配置：2000 小时 AI 编程经验总结

技术教程2026-09-02约 15 分钟Agentic EngineeringAI 编程Agent HarnessCloud AgentSkillsWorktreesCodexClaude CodeGPT88

如果你只把 AI 当成一个“会补全代码的聊天窗口”，很难真正获得数量级的效率提升。更完整的 Agentic Engineering，关注的是一整套围绕 Agent 运行的工作系统：界面、模型、订阅、云端环境、Harness、Skills、权限、工作区、审查和生产力度量。

本文整理 David Ondrej 在 X 上发布的《Agentic Engineering Setup（after 2,000+ hours）》并做了中文结构化改写。原文记录的是作者截至 2026 年第三季度的个人配置，其中软件、价格、模型名称和服务能力都可能快速变化；本文重点提炼可复用的方法，不把个人推荐当作永久结论。

先看结论：你的目标不是“装更多工具”

一套成熟的 Agentic Engineering 环境，应该帮助你完成下面这条链路：

统一入口 → 选择合适模型 → 隔离运行环境 → Agent 执行
        → 自动验证 → 多模型审查 → 记录决策 → 持续度量

核心原则有四个：

  • 让不同 Agent 和模型可以在同一工作流中协作；
  • 让长任务在云端持续运行，不依赖笔记本和网络连接；
  • 让 Agent 的权限、状态和失败恢复可控；
  • 把高频操作抽象成别名、Snippet、Skill 和自动化流程。

适合谁，以及什么算完成

这套方法尤其适合：

  • 同时使用多个编程 Agent 或模型的开发者；
  • 需要并行处理多个仓库、分支或长任务的团队；
  • 希望 Agent 在夜间、远程服务器或云端持续运行的人；
  • 正在从“个人 AI 工具”升级到“Agent 工作系统”的团队。

完成本文后，你不需要复制作者的全部工具清单，但应该能够回答：

  • 我从哪里启动和管理多个 Agent？
  • 哪类任务用哪个模型？
  • Agent 中断后如何恢复？
  • 哪些操作可以自动化，哪些必须人工确认？
  • 如何知道效率提升来自系统，而不是来自短期兴奋？

一、Interface：先统一 Agent 的入口

1. 多 Agent 统一界面

作者使用一个统一的开源界面，把 Codex、Claude Code、Pi、Cursor CLI、OpenCode、Grok Build 等 Agent 放在同一个入口中。这个思路的价值不在于某个具体应用，而在于减少工具切换：你可以根据任务选择模型和订阅，而不必为每个模型维护一套完全不同的操作习惯。

选择统一界面时，可以重点检查：

能力为什么重要
支持多个 Agent 和 Provider避免被单一生态锁定
会话状态可见能快速发现完成、阻塞和运行中的任务
支持预发送消息可以提前排队下一步动作
支持工作树多任务并行时避免互相覆盖
配置可导出方便迁移和恢复

2. 终端、分屏和浏览器

作者还使用 cmux 一类的分屏工作区，将终端、多个 Agent 和内置浏览器组合在一起。这种方式适合少量并行任务：左侧运行 Agent，右侧运行命令、日志或开发服务器。

但分屏不是无限扩展的管理方式。当 Agent 和工作区达到较大规模，侧边栏会变成新的瓶颈。此时需要从“窗口管理”升级到“任务调度”：每个 Agent 都应该有优先级、状态和明确的下一步。

3. Agent 状态追踪

作者使用 Herdr 这类轻量运行时追踪 Agent 状态，并把会话分为 running、idle、done、blocked 等状态。

这是多 Agent 工作流的基础设施，而不是装饰功能。未来当一个管理 Agent 调度多个 Worker Agent 时，你真正需要观察的是：

  • 哪些任务正在运行；
  • 哪些任务已完成但还没审查；
  • 哪些任务被阻塞，需要补充输入；
  • 哪些任务失败并正在重试；
  • 哪些高优先级任务被低优先级输出淹没。

作者自建的 Corral 进一步给 Agent 增加 P1、P2、P3、P4 等优先级：高优先级 Agent 完成后应该优先处理，而不是按照“哪个通知先到就处理哪个”。

二、Models and Subscriptions：模型选择是预算问题，也是路由问题

作者给出的第一原则是：在满足质量的前提下，获得尽可能多的可用 Token 和计算量。

但模型订阅变化很快，某个月的性价比不能当作长期事实。更稳妥的做法是把模型选择拆为三个维度：

维度需要考虑的问题
能力复杂推理、规划、前端、修 Bug、长上下文分别谁更强？
速度首 Token 延迟、持续输出速度和并发限制如何？
成本订阅额度、API 计费、缓存和重试成本如何？

作者的配置思路是使用一个低价多模型订阅作为基础，再叠加 ChatGPT、Claude Code 或 Cursor 等较强模型订阅，形成“便宜模型处理常规任务、强模型处理关键任务”的组合。

推荐的任务路由方式

  • 新项目规划、产品方向和架构发散：使用最擅长提出新思路的模型；
  • 深层 Bug、复杂重构和高风险修复：使用推理能力更强、可投入更高预算的模型；
  • 日常问答、简单改动和解释代码：使用速度快、成本低的模型；
  • 前端视觉、交互和样式迭代：使用对界面代码和视觉反馈更有优势的模型；
  • 独立审查：尽量使用与实现模型不同的模型，降低同源错误。

不要只问“哪个模型最强”，而要问：

任务风险 × 复杂度 × 反馈成本 × 可接受延迟 = 合适的模型预算

不要把 API 单价当作全部成本

作者倾向于使用订阅而不是直接承担高额 API 价格。对于个人开发者，这可能更容易控制预算；对于团队和产品，则必须同时考虑合规、并发、可观测性、数据隔离和供应商锁定。

GPT88 的实践建议是：先建立任务类型与模型路由表，再对订阅和 API 做真实用量统计。不要因为一次调用便宜，就把所有任务默认路由到同一个模型。

三、Cloud Agents：长任务最终会离开你的笔记本

本地 Agent 的问题不是不能用，而是很难规模化：

  • 设备算力和磁盘有限；
  • 多个 Agent 同时运行测试会争抢资源；
  • 电脑休眠、关机或网络中断会导致任务停止；
  • 凭据、端口、开发服务和工作区管理会越来越复杂。

云端 Agent 的价值在于提供：

  • 隔离环境；
  • 持久会话；
  • 持续的网络和电力；
  • 可远程接入的终端；
  • 适合并行运行的资源。

但托管式云 Agent 也有生态锁定：环境、密钥、会话和历史数据都沉淀在供应商平台中，迁移成本可能很高。

自建 VPS 的 80/20 方案

作者的建议是准备一台自己的 VPS，在服务器上运行 Agent Runtime，再通过 SSH 从笔记本、手机或其它设备接入。

典型流程：

VPS
 ├─ SSH
 ├─ Agent Runtime / Herdr
 ├─ Node.js / Python / Git
 ├─ Pi、Codex、Claude Code 等 Harness
 └─ 独立工作区和会话

这种方式保留了云端持久运行的优点，同时减少了对某一家云 Agent 产品的锁定。代价是你需要自行负责系统更新、密钥保护、网络安全、备份和资源预算。

用自然语言配置服务器，但不要放弃安全边界

作者展示的流程是：SSH 登录新 VPS，然后直接告诉 Agent 学习服务器环境并安装 Node.js、Python、Git、Herdr 和目标 Harness。

这说明 Agent 很适合承担环境侦察和重复安装工作，但生产环境不要把“能执行”理解成“应该拥有 root 权限”。更安全的做法是：

  • 为 Agent 创建独立系统用户；
  • 使用最小权限和隔离工作目录；
  • 只在初始化阶段临时提升权限；
  • 将 API Key 放入受保护的 Secret 机制；
  • 对安装脚本和网络下载进行审查；
  • 保留服务器命令与文件变更日志。

四、Harness：模型之外的运行时才决定可控性

Harness 是连接模型和真实工作环境的运行层。它决定 Agent 能看什么、能调用什么、如何执行命令、如何获得反馈，以及如何保存会话。

Pi Agent：极简、开放、适合自定义

作者把 Pi Agent 作为 VPS 上的基础 Harness，原因是它的工具数量少、配置灵活、支持多模型和多 Provider，并且容易在上面构建新的工作流。

极简 Harness 的优点是透明：你知道 Agent 能做什么，也更容易替换模型、添加 Skill 和控制权限。缺点是许多能力需要自己搭建，团队需要具备一定的工程能力。

Cursor CLI：多模型和预发送

Cursor CLI 的价值在于可以访问多种模型，并支持 Skills、预发送消息等能力。对于熟悉 Cursor 生态、又希望使用不同模型的人，它可以作为统一入口的一部分。

自我改进型 Harness

作者将 Hermes Agent、Prime Agent 等归入“自我改进型” Harness：当任务不确定性高、需要持续探索时，这类系统可以在过程中创建或改进 Skill。

它们适合：

  • 对陌生代码库进行探索；
  • 反复出现但流程尚未固化的问题；
  • 需要积累领域知识的长期项目。

它们不适合无条件自动化。自我改进必须有审查、版本控制和回滚，否则 Agent 可能把一次错误判断固化成长期规则。

给高频命令建立别名

作者把长命令配置成 cc、cx 等别名，以减少重复输入。这个原则非常值得保留：高频单步操作用 Shell alias、Raycast Snippet 或命令模板；多步骤流程再抽象成 Skill。

例如：

cc  → 启动带固定权限策略的 Claude Code
cx  → 启动指定模式的 Codex
review → 运行多模型审查
ship   → 检查、提交、推送并触发 CI

别名不应该隐藏危险行为。对于删除、生产写入、推送和部署，建议让别名显示将要执行的目标，并保留最终确认或审计记录。

五、Skills：把重复经验变成可复用能力

作者的 Skills 分为几类。

多模型总审查

/total-review 的思路是让多个不同模型分别审查变更，再合并和去重问题，只把真正重要的风险交给开发者。

这种做法适合中大型改动，尤其适合“实现模型和审查模型不同”的情况。它的重点不是审查数量，而是增加观点差异，减少同一个模型重复确认自己的判断。

Ask then build

在开始实现前，先通过几个关键问题确定目标、平台、兼容性、约束和架构选择。AI 模型擅长实现，但不一定擅长替你做产品判断。涉及 Windows 兼容、数据迁移、权限模型、接口契约等问题时，应该先把选择摆到台面上。

Deep research

深度研究、网页抓取、资料对比和外部信息核验适合独立的研究 Skill。它应该输出来源、证据、冲突和不确定性，而不是只给一段看似确定的结论。

Guardrails 和 Push Lock

全局 Agent Guardrails 可以在工具调用前拦截高风险动作，例如擦除磁盘、覆盖 Git 历史、读取密码管理器等。Push Lock 则用于多个 Agent 并行时，串行化合并、验证、推送、CI 和部署流程。

这类硬约束不应只写在 Prompt 中。Prompt 会被忽略、截断或误解；权限、Hook、沙箱和 CI 才能提供确定性边界。

六、Worktrees：并行 Agent 的隔离基础

Git worktree 可以为不同 Agent 创建独立目录和分支，让多个任务同时运行而不互相覆盖。

项目规模建议
小型项目、单一任务单分支工作更快，避免不必要的管理成本
中型项目、多个独立任务为高风险或长任务建立 worktree
大型项目、20 个以上并行 Agent将 worktree、任务所有权和合并队列作为基础设施

Worktree 不是越多越好。每个工作区都会带来依赖安装、端口、数据库、缓存和最终合并成本。使用前先定义：Agent 负责哪些文件、完成标准是什么、谁负责集成、如何处理冲突。

七、语音输入与预发送：减少人类等待时间

作者使用语音转文字工具，通过口述提高输入速度。对需要频繁描述上下文、复述错误和下达多步指令的人，语音输入确实可以减少键盘输入成本。

更重要的技巧是预发送：如果你已经知道 Agent 下一步要做什么，可以提前排队“执行计划”“运行审查”“修复问题”等消息。

但预发送的前提是任务边界清楚。对于涉及删除、推送、部署、数据迁移的动作，不应盲目排队执行，应在每个高风险阶段设置验证和人工门。

八、什么时候审查，什么时候直接交付

不是每个改动都值得启动完整多模型审查。可以使用风险分级：

改动建议流程
文案、样式、小型 UI 调整运行基础检查后快速交付
单文件功能、普通 Bug测试 + Diff 审查
跨模块重构、权限、支付、数据独立模型审查 + 完整测试
生产事故、数据库、部署流程人工负责决策，Agent 辅助分析和验证

不要递归审查。若不断要求模型继续寻找“更多问题”，它很可能为了满足数量而制造低价值甚至虚构的问题。审查应该有明确范围、停止条件和优先级。

九、ADR：把架构决策留给未来的 Agent 和人

作者建议在项目早期创建 /docs/adr，用短文记录每个核心架构决定：

  • 当时遇到的问题；
  • 选择了什么方案；
  • 为什么这样选择；
  • 哪些替代方案被放弃；
  • 这个决定依赖哪些上下文；
  • 什么情况下需要重新评估。

代码能告诉 Agent“现在是什么”，ADR 才能告诉它“为什么是这样”。没有这些记录，未来的 Agent 很容易把有意的约束误判成历史遗留问题，然后在重构时重新引入旧问题。

十、生产数据库：只读访问比完全隔离更有用

没有任何生产数据，Agent 很难判断功能是否真的被使用、某个异常是否真实发生、某个查询是否符合现实分布。

但直接给 Agent 写权限风险极高。更合理的方案是：

  • 创建只读数据库角色；
  • 只开放必要的表或视图；
  • 对敏感字段脱敏；
  • 限制查询耗时和返回行数；
  • 记录每次查询；
  • 将写入、迁移和删除交给独立流程。

“不给任何访问”会让 Agent 失去现实依据；“给完整写权限”则可能造成不可逆损失。只读、最小范围、可审计是更好的中间路径。

十一、如何衡量自己的 Agentic Productivity

单看提交次数、Agent 会话数或 Prompt 数量都很容易误导：

  • 提交多，可能意味着返工多；
  • 会话多，可能意味着上下文管理差；
  • Prompt 多，可能意味着任务拆分不清。

可以把三类信号结合起来观察长期趋势：

  1. Git 提交及其被接受、回滚、返工的情况；
  2. Agent 会话的持续时间、阻塞次数和模型消耗；
  3. 用户 Prompt 的数量、长度、重试和人工改写比例。

再加上交付质量指标：测试通过率、缺陷逃逸、审查等待时间、上线失败率和恢复时间。真正的生产力是“可靠结果 / 总投入”，不是“生成内容 / 时间”。

十二、推荐的落地顺序

不要一次安装作者的全部工具。可以按以下顺序逐步搭建：

阶段 1：单 Agent 稳定工作

  • 选一个主要 Harness；
  • 建立项目规则文件；
  • 配置 build、test、lint 和 typecheck；
  • 给高频命令设置安全别名；
  • 每次修改后阅读 Diff。

阶段 2：多模型和独立审查

  • 为规划、实现、修复和审查定义模型路由；
  • 让审查模型与实现模型适当错开；
  • 建立中大型改动的审查 Skill；
  • 记录 Token、延迟和返工成本。

阶段 3：持久化云环境

  • 准备独立 VPS 或受控云环境；
  • 使用非 root 用户和最小权限；
  • 配置 SSH、会话持久化、日志和备份；
  • 将长任务从笔记本迁移到服务器。

阶段 4：并行和规模化

  • 引入 worktree；
  • 给任务设置优先级和状态；
  • 建立合并、验证和推送锁；
  • 让高风险动作经过人工门；
  • 用指标验证并行是否真的提高了吞吐量。

最终检查清单

  • 我能在一个入口看到多个 Agent 的状态；
  • 每类任务都有默认模型和升级模型；
  • 长任务不会因为笔记本关闭而丢失；
  • Agent 工作目录、凭据和数据库权限是最小化的；
  • 高频单步操作已经抽象为别名或 Snippet；
  • 高频多步流程已经抽象为 Skill；
  • 中大型改动有独立审查和验证证据；
  • 多 Agent 并行时有 worktree 和合并规则；
  • 生产数据库默认只读并且可审计；
  • ADR 记录了关键架构决策；
  • 我跟踪的是可靠交付，而不是代码行数和 Prompt 数量。

结语：Agentic Engineering 是系统设计，不是工具收藏

这份配置清单最有价值的部分，不是某个具体产品，而是背后的工作方式：统一入口、按任务路由模型、把长任务放到持久环境、用 Harness 控制执行、用 Skill 固化经验、用 Worktree 隔离并行、用权限和审查限制风险，最后用数据判断系统是否真的变快。

当 Agent 数量从一个变成十个、几十个时，最先失效的往往不是模型，而是状态管理、任务优先级、权限边界和合并流程。越早把这些问题当作工程基础设施，越容易从“会用 AI 编程工具”进阶到“能够运营 Agent 软件生产系统”。

来源与说明

本文为基于公开 X 长文的中文结构化整理与方法论扩展。原文中关于订阅价格、模型名称、服务能力和作者个人工具选择均属于特定时间点的经验，不代表 GPT88 的价格、性能或官方推荐，也不应替代上线前的安全评估。

相关指南

AI Native SDLC 深度解读：从 Vibe Coding 到 Agentic Engineering