让 AI 自己批改作业，它永远给你打 A

一个人写代码，然后自己验收，说自己写得没问题。你信吗？

换成 AI agent 也一样。CyrilXBT 发过一篇文章，讲怎么用 Claude Code 搭一个 AI agent 团队，开头就把这个问题点破了：让一个 agent 负责整个项目，是在玩火。它规划、写代码、跑测试、给自己打分。结果它当然说全部通过。

他的判断很直接：写代码的 agent，不该是批准代码的那个 agent。

单 agent 会遇到的四个问题

CyrilXBT 列了四个问题。

上下文会污染。你让同一个 agent 连着做五件事，它会带着前四件的记忆去干第五件。研究笔记、失败的代码、你一小时前的三条修改意见，全堆在上下文里。到第五步，模型读到的是一本无关历史的小说，质量自然下滑。

自己检查不了自己。在同一个对话里让模型写完再审查，它倾向于同意自己。因为它在写的时候已经认定那个答案是对的。让另一个 agent 拿着不同的任务说明、对写的过程毫无记忆去审，才能发现作者看不见的问题。

通才等于没有专长。一句“你是世界级研究员、文案、工程师和编辑”的提示词，不是四个专家，是一个装成四个人的通才。只做一件事、只有一套规则、只有一个完成标准的 agent，表现会好得多。

串行做事效率低。一个 agent 只能一步一步来，研究完再规划，规划完再写。团队可以拆开工件并行跑。

团队怎么拆

CyrilXBT 的架构不复杂：一个 Lead 负责理解目标、拆任务、做最终决定；几个 specialists 各管一件事；一个共享工作区用来交接文件；一套所有人都要遵守的规则。

具体到他那支叫 Launch Team 的队伍，四个角色分工很硬：

• Lead（主会话，跑最强模型）写 brief、派活、拍板。
• Scout 只查资料，找事实、竞品、定价、用户痛点，每条信息都要有来源，绝不写文案。
• Maker 只写交付物，根据 brief 和 research 写落地页、帖子、邮件，绝不自己查资料。
• Critic 只评审，冷着读 Maker 的稿子，对照 brief 和 research 找问题，只标记，不改稿。

分工的关键在于边界。Scout 不写，Maker 不查，Critic 不修。任何一个 agent 开始干别人的活，团队就退化成一个过载的大脑。

Critic 是多数人会跳过的角色

CyrilXBT 说，Critic 是他认为最值得加的 agent。他甚至给 Critic 的系统提示词里写了一句话：你没写这份稿子，你没有理由替它辩护。

但评论区里 @Wukoayos 的补充比原文更狠。他的做法是：在代码还不存在的时候，先把评审标准写进一个 Markdown 文件，让评审 agent 对着这个文件评分，而不是听写代码的人说自己做了什么。他还提了一个验收评审者的方法：先给评审 agent 一个你确定有问题的版本。如果它让这个版本通过了，那它根本没在评审。

这个测试很实用。很多人搭完评审 agent 就默认它能用，从来不验证它是不是真的会挑毛病。

互相点头的团队等于没有团队

@E1ev3n 在评论区提了一个更根本的问题：agent 团队只有在对某件真实的事情上产生分歧时才有用。他见过太多配置，几个 agent 只是互相附和。

这确实是这类方案最大的软肋。四个 agent 如果用的是同一个模型家族、同一套倾向、同一份模糊的 brief，它们很可能集体给出一个平庸但自洽的结果。表面上过了四道关，实际上只是同一个声音重复了四遍。

@Shivanath 给了一个数据点：他把评审者换成不同模型家族后，在一次测试里，两个家族在 200 个判断中有 194 个一致，所有错误都落在那 6 个不一致的意见里。换句话说，跨模型家族的评审不是为了找更多问题，是为了在那 6 个关键分歧上不被同一个偏见带着走。

另一位 @Aleksandar Janca 的角度更底层：能让真正跑起来的测试先判，就别让评审模型先判。能执行代码的检查没法被说服通过。

这三个评论放在一起，其实给 CyrilXBT 的方案补了重要的一课：多 agent 不等于多视角。要让团队真的有用，得让分歧有地方发生。

成本怎么控制

四个 agent 意味着四份上下文，加上评审循环，消耗会翻倍。CyrilXBT 的原则是：把强模型放在需要判断力的位置。Lead、Maker、Critic 跑 Opus，因为规划、写作、评审需要品味和推理。Scout 跑 Sonnet，因为查资料、汇总、格式化属于量大但判断要求低的工作。纯体力活比如重排文件，Haiku 就够。

循环也要设上限。他的命令里写死了“最多把 Scout 打回一次”“Critic 最多再审一轮”。不设上限，Lead 会为了追求完美一直循环下去。

这套东西的核心

CyrilXBT 在文末说了一句挺准的话：搭完第一个团队之后，你不再问“我该让 AI 做什么”，而是开始问“我团队里谁来处理这个”。这是管理者的思路，不是用户的思路。

但我觉得更值得记住的是评论区的那些反驳。团队的价值不在于人多，在于有没有一个独立的判断者，拿着事先写好的标准，对着一个自己没参与过的作品，敢说不行。

如果几个 agent 只是换了个头像互相点头，那还不如一个人干。至少你知道问题出在哪。