智能体该搭成什么结构：Anthropic 总结的五种工作流，多智能体什么时候值得，并行的 Claude 怎么分工

这篇解决一个问题：自己做智能体时，该搭成什么结构：一次调用、固定的几步流程，还是让模型自己决定；一个智能体还是好几个。

Anthropic 工程博客上有三篇文章回答这个问题，本文按顺序整理：

《Building effective agents》（2024 年 12 月）：Anthropic 被引用最多的一篇，总结了五种常见的工作流和什么时候该用真正的智能体。2026 年 8 月文章开头加了一句说明：文中讲的工具和框架变化很大，现在的做法见托管智能体的文档。但它的核心观点没有过时：先找最简单的办法，只在确实需要时才加复杂度。
多智能体研究系统（2025 年 6 月）：Claude 的“研究”功能怎么用一个主智能体带一群子智能体，效果和代价各是多少，什么样的任务适合。
16 个 Claude 并行写 C 编译器（2026 年 2 月）：一个研究员让一组 Claude 在同一个代码库上并行工作两周，写出一个能编译 Linux 内核的编译器。重点是怎么分工、怎么设计测试。

三篇都是整理，本站没有实测。每种结构对应到 Claude Code 和 Agent SDK 里的哪个功能，是本站加的，文中标明了。

工作流和智能体，先分清

Anthropic 把这类系统统称为“智能体系统”，但分成两种：

	是什么	适合
工作流	模型和工具按事先写好的代码路径来编排	定义清楚的任务，要的是可预期、稳定
智能体	模型自己决定怎么做、用哪些工具、做几步	步骤数没法预先知道、不能写死路径的开放问题

很多应用两种都不需要。 文章的原话大意是：智能体系统通常用延迟和成本换效果，要想清楚值不值；对很多应用，把一次模型调用加上检索和几个示例调好，通常就够了。

框架要用得明白。 文章列了几个框架（包括 Claude Agent SDK），说它们让起步容易，但多出来的抽象层会把底层的提示词和响应藏起来，难调试，也容易让人在简单方案就够的时候加复杂度。建议先直接调接口，很多模式几行代码就能写出来；用框架的话，要搞清楚它底下做了什么，对底层的错误假设是客户最常见的错误来源之一。

基础构件：增强过的模型

所有结构的基础，是一个接上了检索、工具和记忆的模型。现在的模型会自己生成搜索词、挑工具、决定记住什么。文章强调两点：按你的场景定制这些能力，以及给模型一个简单、写清楚了的接口。MCP 是接工具的一种办法。

五种工作流

工作流	怎么做	什么时候用	文章的例子
链式	把任务拆成固定的几步，每一步处理上一步的输出，中间可以加代码检查（“关卡”）	任务能干净地拆成固定的子任务；用延迟换准确，每次调用都更简单	先写营销文案再翻译；先写大纲、检查大纲合不合要求、再按大纲写全文
路由	先把输入分类，再交给专门的后续流程	有界限分明的几类输入，分开处理更好，而且分类能做准	客服的一般问题、退款、技术支持走不同流程；简单常见的问题给小模型，难的给大模型
并行	几个调用同时做，结果用代码汇总。分两种：分段（拆成独立子任务）和投票（同一任务做几次）	子任务能并行以求快；或者需要多个视角、多次尝试来提高把握	一个调用回答用户，另一个专门审查内容；几个不同的提示词分别审一段代码的漏洞
编排者和工作者	一个中心模型动态拆分任务，派给几个工作者，再汇总结果	复杂任务，事先不知道要拆成哪些子任务。和并行的区别是子任务不是预先定好的	每次要改多个文件的编程产品；要从多个来源收集和分析信息的搜索
评估者和优化者	一个调用生成，另一个评价和反馈，循环	有清楚的评价标准，而且反复修改有可衡量的价值	文学翻译；要多轮搜索的复杂研究，由评估者决定要不要再搜

判断评估者和优化者合不合适，文章给了两个信号：人说出反馈之后，模型的回答能明显变好；模型自己也能给出这样的反馈。

对应到 Claude Code 和 Agent SDK（本站的对应，不是原文）：

工作流	Claude Code 和 Agent SDK 里可以用的
链式	脚本里串几次 `claude -p`，见《把 Claude Code 接进脚本和 CI》；skill 里写好固定的步骤
路由	按难度选模型，见《Claude Code 的模型怎么设》
并行	同时派几个子代理，见《子代理实战》
编排者和工作者	动态工作流、代理团队、托管智能体的多智能体协作
评估者和优化者	build-eval 和 hillclimb；长任务 harness 里单独的评审代理，见《让 Claude 连续干几个小时》

真正的智能体

当模型在理解复杂输入、推理规划、可靠地用工具、从错误里恢复这几方面成熟以后，智能体开始进入生产。它从用户的一个命令或一段讨论开始，任务明确后自己规划、自己干，必要时回来问人。关键是每一步都要从环境里拿到“真实情况”，比如工具调用的结果、代码运行的结果，用来判断进展；遇到卡点或者到了检查点，可以停下来等人的反馈。通常还要设停止条件，比如最多跑多少轮。

文章说，智能体能做复杂的事，实现却往往很简单：通常就是一个模型在循环里，根据环境的反馈调用工具。 所以工具和工具的文档要认真设计。它的自主性意味着成本更高、错误会累积，建议在沙箱里充分测试，并加上合适的护栏。

三条原则

保持设计简单。
重视透明，把智能体的规划步骤明确展示出来。
认真设计智能体和计算机之间的接口（文章叫它 ACI，对应人机界面 HCI）：把工具的文档写清楚，充分测试。

工具格式要照顾模型

文章附录专门讲了工具，和后来那篇写工具的文章一脉相承（见《给智能体写工具》）。几个具体的点：

同一个动作有好几种表达方式，对程序没区别，对模型难度差很多。写 diff 要先知道这一块改几行；把代码放进 JSON 要处理换行和引号的转义，都比直接写完整文件、放进 Markdown 难。
给模型足够的 token 先“想”，别让它写着写着把自己逼进死角；格式尽量接近网上自然出现的文本；不要让它数几千行代码，也不要让它转义自己写的代码。
防呆设计。 改参数让它更难出错。他们做 SWE-bench 的智能体时，花在优化工具上的时间比整体提示词还多。比如发现智能体离开根目录后，用相对路径的工具常出错，就把工具改成必须传绝对路径，之后模型用得一点没错。

多智能体什么时候值得

Claude 的“研究”功能用的是编排者和工作者的结构：主智能体分析问题、定策略，同时派出几个子智能体从不同方向去搜，各自在自己的上下文里查，压缩出最重要的内容交回来，主智能体再汇总。

效果和代价都很明显：

内部的研究评测里，Opus 4 当主智能体、Sonnet 4 当子智能体的组合，比单个 Opus 4 好 90.2%。例子是“找出标普 500 信息技术板块所有公司的董事会成员”：多智能体拆给子智能体，找到了；单智能体一条条按顺序搜，没找到。
他们分析 BrowseComp 评测发现，三个因素解释了 95% 的成绩差异，其中 token 用量一项就占 80%，另外两项是工具调用次数和模型。多智能体管用，主要是因为它能花足够多的 token。
代价：智能体一般比聊天多用约 4 倍的 token，多智能体比聊天多用约 15 倍。

什么样的任务适合： 价值高到付得起这些 token；能大量并行；信息量超过一个上下文窗口；要接很多复杂的工具。不适合的： 所有智能体需要共享同一份上下文的，或者智能体之间依赖很多的。文章特别点名：大多数写代码的任务，能真正并行的部分比研究少，而且现在的智能体还不擅长实时地互相协调和委派。

给主智能体写提示词的几条经验

早期的系统犯过这些错：一个简单问题派出 50 个子智能体；没完没了地搜根本不存在的来源；互相发太多更新、彼此干扰。他们靠改提示词解决：

经验	做法
站在智能体的角度看	用完全相同的提示词和工具做模拟，一步步看它怎么干，马上能看出问题：结果已经够了还在继续、搜索词太长、选错工具
教主智能体怎么派活	每个子任务都要写清楚：目标、输出格式、用哪些工具和来源、任务边界。只说一句“研究一下芯片短缺”，几个子智能体会做重复的事
按难度定投入	写进提示词：简单的事实查询 1 个智能体、3 到 10 次工具调用；直接比较 2 到 4 个子智能体，每个 10 到 15 次；复杂研究 10 个以上，分工明确
工具的选择和设计	先看一遍所有可用的工具；按用户意图选；专用工具优先于通用工具。工具描述写得差，智能体会走上完全错误的路
让智能体改进自己	他们做了一个“测工具的智能体”：给它一个有毛病的 MCP 工具，它反复试用几十次，再重写工具描述。之后的智能体用新描述，完成任务的时间少了 40%
先宽后窄	先用短而宽的搜索看看有什么，再逐步收窄。智能体默认爱用又长又具体的查询，结果很少
并行	主智能体同时派 3 到 5 个子智能体，子智能体同时调 3 个以上的工具，复杂问题的研究时间最多少了 90%

评测上，他们的经验是：多智能体每次走的路径都不一样，所以评的是结果对不对、过程合不合理，不去检查是不是按某个固定的步骤做的。

并行的 Claude 怎么分工：C 编译器的例子

Anthropic 安全防护团队的研究员 Nicholas Carlini 做了一个实验：让 16 个 Claude 在同一个代码库上并行工作，没有人实时干预，从零用 Rust 写一个 C 编译器。两周、将近 2,000 个 Claude Code 会话、约 2 万美元的 API 费用（Opus 4.6，20 亿输入 token、1.4 亿输出 token），写出一个 10 万行的编译器，能在 x86、ARM 和 RISC-V 上编译出可以启动的 Linux 6.9，还能编译 QEMU、FFmpeg、SQLite、Postgres、Redis，能跑 Doom。

搭法很简单。 每个 Claude 跑在自己的容器里，在一个无限循环里反复启动 claude -p，做完一件就接着做下一件。共用一个 git 仓库，各自克隆、各自推送。为了不让两个 Claude 同时做同一件事，用了最朴素的“锁”：开始做某个任务前，往 current_tasks/ 里写一个文本文件占位；两个人抢同一个，git 的同步会让后来的那个换一个。做完拉取、合并、推送、删掉锁。合并冲突很多，但 Claude 自己处理得了。没有主智能体，每个 Claude 自己决定干什么，大多数时候挑“下一个最明显的问题”。

他的大部分精力花在测试和环境上，而不是循环本身：

测试要近乎完美。 Claude 会自主地解决你给它的问题，验证器有漏洞，它就会解决错的问题。后期 Claude 经常加一个功能就弄坏已有的功能，他加了持续集成和更严格的检查，新提交不能破坏已有的代码。
站在 Claude 的角度设计测试的输出。 每个 Claude 进的是一个没有上下文的新容器，要花不少时间摸清情况，所以要求它们勤更新 README 和进度文件。测试别打几千行没用的输出，最多几行，重要的写进日志；出错时在同一行写 ERROR 和原因，方便 grep。
Claude 没有时间概念。 放着不管，它会花几个小时跑测试而不干正事。所以测试默认带一个快速模式，只随机跑 1% 或 10% 的用例：每个 Claude 固定抽同一批，能准确发现回归；不同容器抽的不一样，合起来仍然覆盖全部。

并行在什么时候失灵。 失败的测试很多、彼此独立时，并行很容易，每个 Claude 挑一个不同的就行。但编译 Linux 内核是一个整体的大任务，16 个 Claude 撞上同一个 bug，修完又互相覆盖。他的办法是拿 GCC 当一个已知正确的参照：内核的大部分文件用 GCC 编译，只有一小部分随机的文件用 Claude 的编译器，内核能跑就说明问题不在这批文件里，不能跑就继续缩小范围。这样每个 Claude 可以并行地修不同文件里的不同 bug。

并行也让分工成为可能。 他让一个 Claude 专门合并重复的代码（模型写的代码常常重新实现已有的功能），一个负责编译器本身的性能，一个负责生成代码的效率，一个从 Rust 开发者的角度挑设计的毛病并做结构调整，一个写文档。

他也写了局限：生成的代码效率不高，开了全部优化还不如 GCC 不开优化；Rust 代码质量合理，但远不到专家水平；汇编器和链接器还有 bug；这个编译器已经接近 Opus 能力的上限，他使劲修了几处局限也没修好。

怎么选

把三篇文章合起来，本站的理解是：

你的情况	从哪开始
一次调用加检索、几个示例就能做好	不要搭智能体系统
步骤固定、能拆开	链式或路由，用代码串起来
要多个视角或要快	并行（分段或投票）
事先不知道要拆成哪些子任务	编排者和工作者
有清楚的评价标准，反复改有价值	评估者和优化者
步骤数没法预知的开放问题	智能体：一个模型在循环里用工具，加停止条件，在沙箱里跑
价值高、能大量并行、信息超过一个上下文	多智能体，但先算一下 15 倍的 token 付不付得起
很多彼此独立的小任务（比如一堆失败的测试）	几个并行的 Claude，配一套近乎完美的测试

不管哪种，都要先有评测，才知道加上去的复杂度有没有用，见《给智能体建评测》。

参考

Erik S.、Barry Zhang：Building effective agents（Anthropic 工程博客，2024-12-19，2026 年 8 月加了说明）
Jeremy Hadfield 等：How we built our multi-agent research system（Anthropic 工程博客，2025-06-13）
Nicholas Carlini：Building a C compiler with a team of parallel Claudes（Anthropic 工程博客，2026-02-05）