Agentic Coding 工作流设计：从单 Agent 到 Coder、Reviewer、Tester 多角色协作

很多团队第一次把 AI 接进研发流程时，做法都很直接：给一个 Agent 仓库权限，让它读需求、改代码、跑测试，然后交付结果。

这个模式能解决小任务，但一旦需求涉及跨模块改动、线上状态、历史约束和回归风险，单 Agent 很快会暴露三个问题：

1. 它会把“能跑通”误认为“能上线”。
2. 它容易在自己刚写的代码上产生确认偏误。
3. 它很难同时保持产品意图、代码质量、测试覆盖和部署安全。

更可靠的 Agentic Coding 工作流，不是让一个 Agent 变得更“聪明”，而是把研发流程拆成几个互相制衡的角色：Coder 负责实现，Reviewer 负责找风险，Tester 负责复现和验证，Operator 负责部署边界。

---

一、单 Agent 模式适合什么

单 Agent 最适合低风险、边界清晰的任务：

• 改一个组件的样式。
• 修一个明确的类型错误。
• 补一段文档。
• 为已有函数增加一个小测试。

这类任务有一个共同点：成功标准容易定义，失败影响范围有限。

但如果任务是“重构支付流程”“修复交易机器人风控”“恢复内容流水线”，单 Agent 就不够了。它不仅要理解代码，还要理解运行态、数据状态、业务风险和回滚策略。

这时需要多角色协作。

---

二、四角色模型

1. Planner：把需求变成可验证任务

Planner 不写代码。它的职责是把模糊需求拆成可执行任务，并明确每一步的验收标准。

一个好的 Planner 输出应该包含：

• 要改哪些文件。
• 不改哪些文件。
• 哪些行为必须保持不变。
• 哪些测试必须通过。
• 哪些操作禁止自动执行，例如生产部署、密钥轮换、交易服务重启。

如果没有 Planner，Coder 往往会过早进入实现，把问题改成自己熟悉的形状。

2. Coder：最小可行实现

Coder 只负责实现，不负责给自己盖章。

Coder 的关键约束是“最小改动”：

• 优先沿用现有框架和 helper。
• 不引入无关抽象。
• 不顺手重构旁边的代码。
• 改动后立刻运行最相关的验证。

在 Cursor Rules 或 Codex 指令里，可以把这些约束写成硬规则，避免 Agent 为了追求漂亮结构而扩大改动范围。

3. Reviewer：从失败路径看代码

Reviewer 不问“这段代码看起来对不对”，而问：

• 输入为空会怎样？
• 旧数据格式会怎样？
• 并发调用会怎样？
• 网络超时会怎样？
• 用户权限不足会怎样？
• 线上服务重启后状态能不能恢复？

这和人类 code review 的重点一样：不是重写实现，而是找行为回归、数据损坏、安全漏洞和测试缺口。

4. Tester：把验证从“跑过”变成“有证据”

Tester 的价值在于把抽象通过变成证据：

• 单元测试输出。
• 构建日志。
• Playwright 截图。
• API 响应样本。
• 线上只读探针。

对前端项目，Tester 不应该只看 npm run build。还要打开真实页面，确认文本没有重叠、交互可用、移动端没有横向溢出。

对后端或自动化服务，Tester 不应该只看进程 active。还要检查端口、日志、健康检查和真实请求路径。

---

三、一次可复现的 Agentic Coding 流程

下面是一套适合中小团队落地的流程：

1. Planner 读取需求和代码，输出任务卡。
2. Coder 按任务卡实现，提交本地 diff。
3. Tester 运行最小验证集，记录命令和结果。
4. Reviewer 审查 diff、验证证据和未覆盖风险。
5. Coder 修复 Reviewer 指出的 P0/P1 问题。
6. Operator 处理部署、重启、密钥、数据库迁移等需要人工窗口的动作。

关键点是：每个角色的输出都要可检查。

Coder 不能只说“已修复”，要列出改了哪些文件。Tester 不能只说“测试通过”，要给出具体命令。Reviewer 不能只说“有风险”，要指向具体代码路径和触发条件。

---

四、Cursor Rules / Codex 指令应该怎么写

规则不要写成泛泛的价值观，而要写成可执行边界。

例如：

改代码前先读取相邻实现。
优先使用已有 helper 和测试模式。
不要自动部署生产环境。
遇到密钥、交易、支付、数据库迁移时，只生成审查包。
最终回答必须包含改动文件、验证命令和未处理风险。

这类规则比“请写高质量代码”有效得多。

如果团队有多个 Agent，还应该明确文件所有权。例如：

Coder A 只改 src/api/。
Coder B 只改 src/components/。
Reviewer 只能评论，不直接重写实现。
Tester 只添加或运行测试，不改业务逻辑。

这样可以减少并行工作时的冲突。

---

五、常见失败模式

失败模式一：让 Reviewer 也顺手写代码

Reviewer 一旦开始大改实现，就会失去独立性。更好的方式是让 Reviewer 输出问题清单，再由 Coder 修。

失败模式二：没有部署边界

Agent 很容易把“代码已修复”说成“问题已解决”。但很多线上问题还需要重启服务、迁移数据或轮换密钥。

所以必须区分：

• 本地代码已改。
• 测试已过。
• 审查包已准备。
• 生产已部署。
• 运行态已验证。

这五件事不能混在一起。

失败模式三：测试只覆盖快乐路径

Agent 写测试时倾向于验证自己刚实现的路径。Tester 角色要专门补异常路径：空数据、旧配置、超时、权限、重复提交、并发更新。

---

六、落地建议

如果你现在只有一个 Agent，不需要马上搭一套复杂平台。可以先把流程拆成三段：

1. 让 Agent 先写计划和验收标准。
2. 让 Agent 实现并跑测试。
3. 让同一个 Agent 切换到 review 模式，按失败路径审查自己的 diff。

这不是完美的多 Agent，但已经能显著减少盲改。

当任务开始涉及多人协作、线上状态和定时任务，再引入真正的多角色 Agent：一个负责实现，一个负责审查，一个负责验证，一个负责运维边界。

Agentic Coding 的核心不是让 AI 代替工程流程，而是把工程流程显式化，让 AI 在清晰边界里工作。