Agent 协作最佳实践

AI 编程工具越来越强，但单个 Agent 仍然容易受到上下文、思考路径和自我确认偏差的限制。我的实践是让两个 Agent 承担不同角色，再由人负责关键决策，形成一套“方案—实施—检视—修正”的闭环。

这套流程的核心不是让 AI 完全接管开发，而是：

Agent 负责提高产出和检查效率，人负责目标、取舍与最终判断。

我的配置

主 Agent：ChatGPT（Codex），Plus 会员，负责制定计划、编写代码和落实修改。
副 Agent：Qoder，Team 会员，负责读取飞书文档、生成技术方案，以及独立检视代码 Diff。

这种组合的重点并不在具体产品，而在于明确分工：一个 Agent 主导实施，另一个 Agent 提供独立视角，避免“自己写、自己审”带来的盲区。

完整开发流程

1. Qoder 读取飞书文档，生成技术方案

先让 Qoder 读取需求文档，并输出结构化技术方案。方案至少应覆盖：

目标与非目标
现有实现和影响范围
技术选型与关键决策
实施步骤
风险、边界条件和验收标准

这一步的产物不是最终答案，而是提供给主 Agent 的高质量上下文。

2. 将技术方案交给 Codex，开启 Plan mode

把需求背景和技术方案一起发给 Codex，并开启 Plan mode。让 Codex 在修改代码之前先检查仓库、理解现状，再给出可执行的实施计划。

技术方案描述“准备怎么做”，Plan 则需要结合真实代码回答“具体改哪里、按什么顺序改、如何验证”。

3. 人工审视 Plan

不要看到计划后立刻开始执行。重点检查：

是否准确理解需求
是否遗漏关键模块或兼容场景
是否出现过度设计
是否包含明确的测试与验收方式
每一步是否足够小，能够独立验证

如果计划存在偏差，直接指出问题并要求 Codex 修正，直到计划与预期一致。

4. Codex 分步实施

确认 Plan 后，让 Codex 按步骤修改代码。复杂任务应尽量保持小步提交、小步验证，避免一次生成大量改动后才发现方向错误。

实施过程中，人仍然需要关注 Agent 暴露出的假设、阻塞和范围变化。遇到会改变产品行为或架构方向的选择，应由人做决定。

5. Codex 输出自我检视结果

代码完成后，不要只要一句“已完成”。要求 Codex 对本次改动进行自我检视，并说明：

修改了什么
为什么这样实现
执行了哪些测试和检查
是否存在未覆盖的边界情况
当前仍有哪些风险或限制

自我检视可以提前发现低级问题，也能为下一轮独立审查提供清晰背景。

6. 使用 Qoder 直接检视 Diff

让 Qoder 基于实际 Git Diff 进行独立 Code Review，而不是只阅读 Codex 的总结。

检视时重点关注：

正确性和需求覆盖度
回归风险
异常处理与边界条件
类型安全、并发和状态一致性
安全与性能问题
测试是否有效，而不只是“存在测试”

独立审查的价值在于，Qoder 没有参与实现，更容易质疑实现阶段已经形成的思维定式。

7. 将 Qoder 的检视意见发给 Codex

把检视意见原样交给 Codex，并要求它逐条评估。最好让每条意见都包含文件位置、问题原因、影响程度和建议修改方向，减少来回确认的成本。

8. Codex 与人工共同评估检视意见

Code Review 意见并不天然正确。Codex 负责结合代码上下文分析技术合理性，人负责判断它是否符合真实业务目标。

对每条意见可以给出三种结论：

采纳：问题成立，按建议或更合适的方式修改。
部分采纳：风险成立，但建议方案不够准确，需要调整实现方式。
不采纳：说明意见为何不适用于当前场景，并给出代码或测试依据。

这个阶段尤其要避免两个极端：盲目接受所有 AI 意见，或者因为代码已经能运行就拒绝修改。

9. 修改后让 Qoder 复检

Codex 完成修改后，再让 Qoder 检查：

原有问题是否真正解决
修改是否引入新的问题
是否存在只绕过表象、没有解决根因的情况
新增或更新的测试能否覆盖问题

复检应以最新 Diff 和上一轮意见为依据，逐条关闭问题。

10. 达成一致后 Commit 入库

当 Codex 和 Qoder 对改动没有未解决的实质性问题，人工也完成最终确认后，再进行 Commit。

提交前最后检查：

工作区只包含本次任务相关改动
格式化、类型检查和测试通过
文档或配置已同步更新
Commit message 能准确描述改动目的

至此，一个完整的双 Agent 开发闭环结束。

角色分工

角色	主要职责	不应完全交给它的事情
Codex	计划、实现、自检、修复	独自决定产品目标和重大取舍
Qoder	方案整理、独立审查、复检	在不了解业务背景时直接决定实现方案
人	明确目标、纠偏、判断意见、最终验收	逐行完成所有机械性工作

这套流程为什么有效

关注点分离

主 Agent 专注于把功能做出来，副 Agent 专注于寻找问题。不同目标会带来不同的观察角度。

降低确认偏差

实现者很容易默认自己的设计前提成立。引入没有参与实现的 Agent，可以重新挑战这些前提。

保留人的最终判断

两个 Agent 达成一致不代表结果一定正确。它们可能基于相同的错误上下文得出相同结论，因此需求解释、业务取舍和最终验收仍然必须由人负责。

让问题真正闭环

Review 不是把意见列出来就结束，而是要经过评估、修改和复检，直到每条有效意见都有明确结论。

实践中的注意事项

给两个 Agent 同一份需求基线。 如果上下文不同，争议可能只是信息不对称。
让审查针对 Diff，而不是针对总结。 总结会过滤细节，Diff 才是实际入库内容。
要求意见提供证据。 没有文件位置、触发条件或影响分析的意见，优先级应降低。
控制每轮改动规模。 Diff 越大，Agent 越容易遗漏跨模块影响。
测试结果优先于口头判断。 能通过自动化测试验证的问题，不要只靠 Agent 互相说服。
明确停止条件。 没有未解决的高风险问题、测试通过、人工验收完成，即可结束循环，避免无休止优化。

总结

我的开发链路可以概括为：

飞书需求
  → Qoder 技术方案
  → Codex Plan
  → 人工确认
  → Codex 实施与自检
  → Qoder Review
  → Codex + 人工评估并修改
  → Qoder 复检
  → 最终确认
  → Commit

双 Agent 协作的价值，不是简单地“多用一个 AI”，而是建立相互制衡的工作机制：用独立审查提升代码质量，用人工判断守住需求方向，用复检确保问题闭环。