一个 AI 助理从早上陪你做到下午,早上交代的“正式资料不要动”,到了傍晚它可能已经忘了。任务越长、越杂,一个 AI 越容易漏东漏西。多代理协作框架就是为这种状况设计的。
多代理协作框架(multi-agent harness)是什么? Harness 指模型外面那一整套装备:让它反复行动的循环、能调用的工具、context(模型当下看得到的全部内容)的管理,还有护栏。有了这套装备,模型才成为 agent,能自己决定下一步、自己用工具把事情做完。多代理协作框架是它的多人版:一个指挥者(orchestrator)把大工作拆给好几个 agent,每个 agent 用自己独立的 context 做一小块,只交回精简的结果。指挥者可以是一个 AI,也可以是一段写好的程序。
这篇用白话整理 Anthropic、OpenAI、Google、Microsoft 官方文档里反复出现的做法,再加上小企鹅的 AI 团队实际跑一次的实战记录。
一个 AI 为什么不够?
Anthropic 给单一 agent 做长任务时的毛病取了三个名字:
- Agentic laziness(做到一半说做完):Anthropic 举的例子是一份 50 项的安全检查,只处理了 35 项就宣布完成。
- Self-preferential bias(自己改自己的考卷):叫它检查自己的成果,它会偏向自己。
- Goal drift(聊久了忘了原本要什么):对话变长、旧内容被压成摘要,每压一次都可能漏掉细节,“不要做 X”这类限制就可能这样丢掉。
另外还有 context 污染:前一个子任务留下的数据,一直干扰下一个。解法是把工作拆给几个各有干净 context、只盯一个目标的 agent。负责检查的 agent 如果只拿到结果和标准,看不到做事那方的推理,也比较不会帮它圆场,这一点需要刻意安排。
计划拿在谁手上?
Claude Code 的文档用一句话区分各种做法:“差别在于谁拿着计划。”计划可以在指挥的 AI 手上,由它每一轮决定下一步,弹性大,但所有结果都会回到它的 context,做久了越塞越满。计划也可以写成程序,由脚本保管步骤和中间结果,指挥的 AI 只需要看最终答案。前者像主管边做边想,后者像照一张写好的流程表走。不管哪一种,重点都是让指挥者的 context 保持干净。
六种常见组法
Anthropic 整理了六种组法,实务上会混着用:
- Classify-and-act(先分类,再派工):先判断任务类型,再交给对应的 agent。像是分流客服邮件。
- Fan-out-and-synthesize(拆开并行做,再汇总):切成小块同时做,全部完成才汇总。像是多方向的调查。
- Adversarial verification(对抗式验证):另派 agent 拿标准挑毛病。用在出错代价高的产出。
- Generate-and-filter(大量发想,再筛选):产生很多点子,用标准或实际验证筛选、去除重复,只留最好的。像是发想标题。
- Tournament(淘汰赛):各做一版,两两比较选出最好的。Anthropic 认为两两比较比打绝对分数可靠。
- Loop until done(直到没有新发现为止):持续派 agent 去找,直到停止条件成立,例如 log 里不再出现新错误。

图一:六种组法。图片来源:Anthropic(claude.dev)
Agent 会读网页、邮件、留言这类外来内容时,还有一种组法叫隔离区(quarantine):负责读取的 agent 不做高权限动作,真正动手的 agent 只看它们交出的摘要,不碰原文。这类风险可以看 AI Agent 的安全风险。

图二:读取外来内容的 agent 待在隔离区,有权限的 agent 只看摘要。图片来源:Anthropic(claude.dev)
实战:一篇文章,九个 AI
2026 年 9 月,小企鹅的 AI 团队用这套方法写了一篇新产品解析。分工是:一个指挥的 AI(订计划、写任务简报、决定收或退,自己不写文章)、六个调查 agent(一人一题、各交一个证据文件,其中一个专门核对别人的说法;同一时间最多跑三个,其余排队)、一个只能用证据文件的写稿 agent,还有一个另一家模型的审稿 agent。中途有几个位置换过替补:一家模型的调查额度用完,经小企鹅同意,剩下的调查改由另一家模型的 agent 接手;审稿也换过人,下面会讲。小企鹅本人负责文章角度、封面和按下发布。
从“开始”到拿到指挥者对照证据检查过的稿子,大约一个半小时;最后的审稿又多花了一个多小时,原因在下表最后一列。
| 出了什么错 | 谁抓到 | 学到什么 |
|---|---|---|
| 任务简报的前提错了:把产品名当成一个模型系列,其实同名的也是一个给普通用户的 agent App | 调查 agent 回报,指挥者亲自抽查一手资料确认 | 任务简报发出前,先验证最关键的前提 |
| 指挥者自己说错:看完官方页面,就说“应该没有候补名单” | 社区调查 agent 找到用户回报在 App 里看到候补画面;小企鹅本人一开始就是对的 | 官方页面没写,不代表不存在 |
| 写稿 agent 把媒体报道的“人类拨打电话”写成“人类接听电话” | 指挥者拿证据文件逐段对稿,连同其他问题共退回 12 处 | 读稿要对照原始证据 |
| 指挥者对过稿之后仍留下的错:常见问答和开头跟修正后的正文矛盾、只有一家媒体报道的细节被写成两家 | 另一家模型的审稿 agent 直接读证据,抓出 8 个必须修的问题;指挥者也拿审稿者没看过的视频画面,驳回其中一条 | 最后一关放不同家;审稿意见也要拿证据检验 |
| 审稿 agent 额度用完,替补的两次只交回进度消息、没有结论 | 指挥者直接打开产出检查,没有只看“执行完毕” | “跑完了”不等于“做完了” |
前提写错,agent 只会照着错的前提认真做完。表上五个问题,有两个跟指挥者自己有关。这几层各自抓到不同的错,没有哪一层可以单独信任,指挥者自己也一样。
什么时候不该用?
OpenAI、Microsoft、Anthropic 的文档都建议先把单一 agent 做好,简单的方法能解决就别加 agent。多 agent 适合宽而并行、互不依赖的工作,例如多方向的调查、把一条条说法拆开核对;同一份文件要多人改、每一步都依赖上一步的工作,交给一个 agent 比较好。
一个简单的判断法:这件工作能不能拆给几个人各查各的、互不干扰?能,才值得找一群 AI;不能,就先把一个 AI 的任务简报写好。
成本也会成倍增加:每个 agent 各自消耗 token(模型处理文字、计算费用的单位),交接和协调还要再算一份。研究也提醒要保守:Cemri 等人 2025 年的论文分析 7 个开源多 agent 系统,失败率在 41% 到 86.7% 之间。
五条设计原则
- 照信息的边界切工作。 先想哪些信息要放在一起,再分工。Anthropic 做过实验,照职称分工(规划、实现、测试、审查)的 agent,花在协调上的 token 比实际做事还多。比较好的切法是互不相干的调查方向,或只看结果的独立检查。
- 任务简报写清楚。 Subagent 看不到你跟指挥者聊过什么。目标、输出格式、该用的来源、任务边界都要写,路怎么走交给执行的人。Anthropic 也发现,规划时把技术细节写太细、又写错,错误会一路传到下游。
- 做事的和检查的分开。 检查要有具体标准,也要防反方向的问题:叫审查 agent 找缺点,就算作品没问题,它通常也会找出一些。Anthropic 的做法是一条规则配一个检查者,再由一个“怀疑派”agent 过滤误报。
- 用文件交接。 成果写成文件,只回传很短的参照(文件在哪),避免一路转述、一路失真。同一份东西,同一时间只让一个 agent 改。
- 设停止条件,人守关键关卡。 重试和迭代要有上限,碰到上限怎么办也要先想好,Microsoft 举的例子是转给人处理。敏感、不可逆的动作,留给人确认。
审稿要不要换一家模型?
小企鹅的团队让另一家模型把守最后一关。研究确实发现,模型给答案打分时会偏好自己的产出;也有研究发现,越强的模型犯错越相似,就算来自不同厂商也一样。我们读过的 Anthropic、OpenAI、Google、Microsoft 官方文档,都没有要求换一家来审,Anthropic 要的是新的模型实例,加上干净的 context。所以小企鹅把换一家当成便宜的保险,实际抓到的例子就是上面表格第四列。撑起质量的,是审稿者有干净的 context、直接读原始证据、手上有具体的检查标准。
小企鹅的总结
- 写任务简报像交接给新同事。 对方没听过你们之前聊了什么。最关键的前提,发出前先自己验一次。
- 检查的跟做事的分开。 不会写程序也能套用:打开两个对话,一个写,一个只拿原始数据逐条挑错。小企鹅团队实际的做法是写稿只准用证据文件,最后一关换另一家模型审。
- 一个 AI 做得好,就别叫一群。 多 agent 留给范围大、能并行、做错代价高的工作。
- 品味、授权、不可逆的决定留给人。 文章角度、封面、按下发布,在小企鹅的团队里都还是小企鹅自己来。
Anthropic 的工程团队写过:harness 里的每个零件,都藏着一个“模型自己做不到什么”的假设。模型变强以后哪些零件可以拆掉,小企鹅的团队还在一个一个试。
更多基础观念可以从 AI Agent 专区 开始看;context 怎么运作,可以看 AI Agent 的记忆机制。
参考资料
封面图片来源:Anthropic(claude.dev)
官方文档会持续更新,内容以 2026-09-23 读取为准。
- Anthropic(claude.dev):A harness for every task: dynamic workflows in Claude Code,https://claude.dev/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code/
- Anthropic:Building multi-agent systems: when and how to use them,https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
- Anthropic:Harnessing Claude’s intelligence,https://claude.com/blog/harnessing-claudes-intelligence
- Claude Code 文档:Workflows,https://code.claude.com/docs/en/workflows
- Claude Code 文档:Glossary,https://code.claude.com/docs/en/glossary
- Claude Code 文档:Subagents,https://code.claude.com/docs/en/sub-agents
- Claude Code 文档:Agent teams,https://code.claude.com/docs/en/agent-teams
- Claude Code 文档:Best practices,https://code.claude.com/docs/en/best-practices
- Anthropic Engineering:Building effective agents,https://www.anthropic.com/engineering/building-effective-agents
- Anthropic Engineering:How we built our multi-agent research system,https://www.anthropic.com/engineering/multi-agent-research-system
- Anthropic Engineering:Harness design for long-running application development,https://www.anthropic.com/engineering/harness-design-long-running-apps
- OpenAI:A practical guide to building agents,https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- Google Agent Development Kit:Workflows,https://google.github.io/adk-docs/workflows/
- Microsoft Azure Architecture Center:AI agent orchestration patterns,https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
- Microsoft Agent Framework:Overview,https://learn.microsoft.com/en-us/agent-framework/overview/
- Cognition:Multi-Agents: What’s Actually Working(2026),https://cognition.com/blog/multi-agents-working
- Cemri et al.(2025)Why Do Multi-Agent LLM Systems Fail?,https://arxiv.org/abs/2503.13657
- Kim et al.(2025)Towards a Science of Scaling Agent Systems,https://arxiv.org/abs/2512.08296
- Wang et al.(2024)Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key?,https://arxiv.org/abs/2402.18272
- Panickssery et al.(2024)LLM Evaluators Recognize and Favor Their Own Generations,https://arxiv.org/abs/2404.13076
- Wataoka et al.(2024)Self-Preference Bias in LLM-as-a-Judge,https://arxiv.org/abs/2410.21819
- Verga et al.(2024)Replacing Judges with Juries,https://arxiv.org/abs/2404.18796
- Kim et al.(2025)Correlated Errors in Large Language Models,https://arxiv.org/abs/2506.07962