当编码代理第一次真正为您修复错误时，反应几乎总是相同的：热情和怀疑的混合体。很好，当然。但然后你查看差异并问自己：“好吧，但是他到底碰了什么？我可以相信他吗？明天他会以同样的方式再次这样做吗？”。

我认为这就是有趣的部分开始的地方。不是当代理编写一个函数时，而是当它有足够的能力来承担整个工作时：读取存储库、创建补丁、运行测试、打开 PR、在审阅评论后返回。 Codex 正是朝着这个方向发展：后台工作、单独的工作树、集成浏览器、自动化、插件、内存和更明确的权限控制。

重点不是想象一个不再有人阅读代码的未来。这将是一个可怕的未来，而且非常天真。关键是要弄清楚如何与可以做很多事情的代理合作，而不是让他们做所有事情。

习惯的改变

使用传统的自动完成功能，您始终处于驾驶状态。 AI 建议一条线，你决定。然而，对于代理人来说，关系发生了变化：你给他一个目标，他自己完成多个步骤。

这很强大，但它转移了问题。问题不再只是“模型能编程吗？”。问题变成：

• 我给他的范围够小吗？
• 你知道如何检查结果吗？
• 我是否在一个孤立的环境中工作？
• 最后的审核还是否人性化、细心？

健康的工作流程看起来更像是这样，而不是一根魔杖：

这听起来不像“代理构建一切”那么浪漫，但效果要好得多。这也是善于与人相处的团队的工作方式：明确的任务、快速的反馈、明确的责任。

好的提示几乎就是一张好票

最危险的提示是模糊但自信的提示：“修复发票页面”、“改进架构”、“清理身份验证模块”。这些请求听起来很有成效，但会产生巨大的差异。但后来你发现自己在从事考古工作。

有用的提示会更无聊。例如：为发票页面实现 CSV 导出，知道表位于 app/(dashboard)/invoices/page.tsx 中，查询位于 src/server/invoices.ts 中，并且 app/(dashboard)/reports 中已经存在类似的模式。

然后添加明确的约束：不要更改数据库架构，如果一个小实用程序就足够了，就不要添加依赖项，保持现有的 UI 风格。并以验证结束：npm test -- invoices 和 npm run build。

这种类型的简报并不是为了“更好地向人工智能解释”。它最重要的是让您更清楚您所委托的内容。如果您无法具体写下来，则可能该任务还没有为代理做好准备。

我愿意委派的三项工作

第一个是重复但可验证的工作：添加测试、将调用迁移到新的内部 API、更新导入、替换已弃用的组件、修复 TypeScript 错误。在这里代理可以节省时间并且风险可控。

第二个是探索性工作：“找到这个总数的计算位置”，“向我解释为什么这个测试很脆弱”，“重现错误并告诉我哪些文件似乎受到影响”。即使它没有立即生成补丁，它也可以进行有用的侦察。

第三个是经常性的维护工作：小的依赖更新、旧功能标志的清理、被阻止的 PR 的总结、检查被遗忘的 TODO。这并不光鲜亮丽，但正是那种容易堆积起来的工作。

我保持人性的三份工作

产品决策仍然是人性化的。如果更改改变了用户支付、删除数据、查看价格或理解权限的方式，我需要一个负责人。

安全边界也值得人们关注：身份验证、角色、令牌、敏感数据记录、数据库迁移。代理人可以帮助实施，但不一定是唯一的决策者。

最后，我保留了一切需要建筑品味的人性化。代理可以提出重构，但了解抽象是否确实必要或者我们是否只是在完善一个不存在的问题仍然是一项工作。

审查不是可选的

当代理优秀时，人们会倾向于相信 CI 的绿色。这是可以理解的。这也是问题开始出现的时候。

我总是至少关注五件事：

1. 该补丁仅解决所请求的任务吗？
2. 他是否接触过与此无关的文件？
3. 测试涵盖的是新颖的行为还是只是偶然的机会？
4. 代码是否遵循本地模式？
5. 错误是否像项目的其余部分一样处理？

当出现问题时，反馈需要具体。 “修复它”是懒惰的行为。更好：该实用程序将 parseMoney 复制到 src/lib/money.ts 中；重用该函数，添加针对欧元情况的测试，并且不要更改计费模块的公共 API。

代理对小的、可验证的评论反应更好。奇怪的是，人们也是如此。

护栏值得努力

如果代理可以读取文件、编写代码和执行命令，那么它应该被视为一个强大的进程。不需要偏执，你需要的是卫生。

使用单独的工作树或分支。因此，您可以比较差异，丢弃失败的实验，并且不要将代理的工作与您正在做的事情混合在一起。

限制权限。像 rg、git diff、npm test 和 npm run build 这样的命令可以是相当自由的。部署、数据库迁移、机密访问和破坏性命令必须保持明确。

不需要时减少网络访问。对于许多任务来说，官方文档、包注册表和特定的内部服务就足够了。表面积越小，惊喜就越少。

跟踪行动。当补丁进入审查时，您应该能够重建提示、执行的命令、通过的测试和修改的文件。不是为了制造官僚主义，而是为了能够理解如果出现问题会发生什么。

以团队形式开始的简单方法

如果我要在一个小团队中引入代理，我会在没有重大变革的情况下开始。

我会为范围明确的问题创建一个 agent-ready 标签。我将添加一个包含上下文、约束和验证命令的模板。我会要求小的 PR，最好在几百行以下。我需要测试或屏幕截图来查看可见的更改。最重要的是，我会让一个人负责合并。

两周后，我会查看数据：哪些任务确实加快了，哪些审查繁重，哪些提示令人困惑，代码库的哪些部分太脆弱而无法委托。

与“从今天开始我们将与代理商一起做所有事情”相比，这是一种不太引人注目的方法，但它可以让你毫无遗憾地进入第三周。

最人性化的部分

有趣的是，代理变得越自治，经典技能再次变得越重要：写一张好票、进行小削减、创建测试、阅读差异、沟通权衡。该代理可以加速那些已经知道如何良好工作的人。它还加剧了那些糟糕的授权者的混乱。

所以不，我不认为多代理工作流程是停止工程的捷径。我认为它们是一种将更多精力转移到重要部分的方法：决定构建什么、确保它有效、保持系统易于理解。

代理可以成为出色的异步同事。但异步同事要想发挥作用，就需要背景、界限和审查。就像其他人一样。

有用的来源

• （几乎）一切的 Codex - OpenAI
• 在 OpenAI 上安全运行 Codex
• Codex 简介 - OpenAI
• GitHub Copilot 编码代理的新增功能