大多数多智能体设置让一个智能体包办一切——撰写建议、判定结果、路由输出。当我将它们拆分开来，情况发生了变化。

我一直在构建多智能体系统——在真实产品中运维一个40智能体的团队。我反复看到失败的模式正是多数公开方案使用的那个：一个智能体审查代码、判断是否合格、路由结果。三项工作，同一个智能体。它只会走过场。同一视角写建议并判定结果——循环中没有任何张力。我从开发者做起，转任PM，后来又回到工程。经历两端让我明白真实团队的实际做法——并不是一个人掌控所有决策。审查者不决定什么发布。PM不写安全审查。PO负责综合——他们自己不产出发现。专业化加上交接，才是冲刺真正有效的原因。所以我提取了这个模式并开源了。**agile-team-skill — Claude Code 内的7个智能体，每个专职一项：** * **QA** — 测试 + 验收标准。硬否决。若失败则链条停止。 * **PR审查者** — 正确性、模式、死代码。 * **安全** — OWASP、机密、CVE、认证、输入验证。 * **技术主管** — 架构、技术债、复杂度。 * **PO** — 将所有信息综合成一个判定：立即修复 / 待办 / 不修复。PO从不审查。审查者从不判定结果。QA在其他三个运行之前就拦截一切。我没有预料到的是：持久化和分离同样重要。没有跨会话持久的 NEXT.md、STATE.md、BACKLOG.md，每次站会只是没有记忆的聊天。一旦状态持久化，团队就拥有了机构知识。今早我的站会标记了 Sprint 3 为“有风险——与 Sprint 1 和 2 相同关卡。”它识别了跨越三个冲刺的模式。单会话智能体做不到这一点。你还获得了真实的开发容量承诺的冲刺规划、产出待办项的回顾、以及一旦引入就变成故事的技术债。每个仪式一个斜杠命令。没有仪表盘，没有设置负担。真诚好奇其他人如何实现生产者/综合者的分离——以及是否有人找到了保持审查有效运行数百次的良好模式。