我的Agents-Concerto实战

最怕那种AI Agent：代码写完、自检通过、自我表扬，然后扔给我一个巨大的PR。我盯着那些绿色的测试用例，心里却在打鼓——因为它写的是那种毫无意义的Mock测试，只要代码能跑通就给绿灯，根本没验证业务逻辑。这种“盲签”代码的恐惧，是我折腾 agents-concerto 的动力。

简单说，这就是一套基于 Claude Code 的多 Agent 编排方案。我给它起名 Concerto（协奏曲），因为这里必须有一个“指挥家”和一群“演奏者”。指挥家只管调度，绝不写代码；而且最后的 Merge 权限死死攥在人类手里。

这套工作流的核心是四个角色，分工极其死板（这也是它高效的原因）：

• Orchestrator (指挥)：负责拆解任务和跑修复循环，绝对禁止写一行应用代码。
• Classifier (分类器)：只负责判断任务难度。复杂逻辑给 Opus，简单任务给 Sonnet。
• Implementer (执行者)：唯一能写代码的，但它在独立的 git worktree 里工作，且必须遵循“先重构、后实现”的 Tidy First 原则。
• Reviewer (评审员)：权限极低，只有读权限，没有写权限。它只能告诉你哪里错了，不能帮你改。

为了杜绝 AI 乱写测试，我强制要求验收标准必须符合 Given-When-Then 格式。这种方式把“需求”直接变成了“测试用例”，而且必须验证可观测的行为（比如 HTTP 响应、UI 渲染），严禁断言内部私有字段。

在实际部署中，我定了几条死规矩：
1. 权限隔离：写代码的 Agent 绝对不能审核自己的代码。
2. 环境隔离：所有操作在独立 worktree 进行，不污染本地开发分支。
3. 拒绝自动合并：AI 只能把 PR 提交到“Ready for review”状态，最后一步必须是人点 Merge。

目前在公司内部推行这套 AI Agent 工作流后，最明显的体感是 PR 评审压力减轻了。因为 Reviewer 已经过滤掉了一波低级错误，而 Implementer 必须通过可观测的测试才能过关，不再是那种“看起来跑通了”的虚假繁荣。

如果你也想尝试这种编排，可以参考这个结构：

# 核心逻辑配置示例
agents:
  - role: orchestrator
    model: claude-3-opus
    capabilities: [plan, dispatch]
  - role: implementer
    model: dynamic # 根据 Classifier 结果动态选择
    capabilities: [write, test]
  - role: reviewer
    model: claude-3-opus
    capabilities: [read, verify]