Anthropic 发布 AI Agent 架构指南：先问三个问题，再决定要不要上多智能体
多智能体系统效果能提 90.2%，但 token 成本也贵 10-15 倍，这套三问框架帮你先想清楚要不要上复杂架构。
- Anthropic 发布一份企业级 AI Agent 架构指南，基于 Coinbase、Intercom、Thomson Reuters 等客户的真实落地案例，整理出架构模式与选型方法。
- 全文给出六种核心架构：单智能体、分层监督式、协作式、顺序工作流、并行工作流、评估器-优化器工作流。
- Anthropic 内部研究显示，面对需要同时探索多条独立路径的复杂任务，多智能体系统效果比单智能体高出 90.2%，但 token 消耗是单智能体的 10-15 倍。
- 指南给出一套三问决策框架（要多高的可控性、问题跨几个领域、资源预算多少），帮你判断该用哪种架构，而不是一味追最复杂的方案。
- 核心方法是「从简单开始、逐步演进」：先用单智能体验证价值，再按业务需求和数据反馈升级，而非一开始就搭复杂系统。
一份来自 Anthropic 的企业级 agent 架构手册
Anthropic 最近发布了一份面向企业的 AI Agent 架构指南，汇总了 Coinbase、Intercom、Thomson Reuters 等客户的真实落地案例，给出六种架构模式和一套选型决策框架。
白皮书开篇第一句话就把定位挑明了：生成式 AI 回答问题，AI agent 解决问题。而这份手册要回答的，是下一个更实的问题：同一个业务，到底该用一个 AI 智能体单干，还是搭一整套多智能体系统。它把这个选择拆成可操作的判断框架，每种架构都配上真实客户的量化数据。
为什么值得看：指南给出一个关键量化权衡，面对需要同时探索多条独立方向的复杂任务，多智能体系统效果比单智能体高出 90.2%；但它消耗的 token 量是单智能体的 10-15 倍。这一升一降，就是全文所有选型判断的地基。
先说清楚一件事：AI 智能体（agent）和普通自动化脚本，运作方式差别很大。传统自动化要把每一步都提前写死，流程照着脚本一步步走，遇到没预设过的情况就卡住。agent 的做法是评估任务、挑合适的工具、试一种做法、看结果好不好、再调整策略，跑一个循环直到把事办成。
每一步都要预先写好。流程固定，能追溯，但只会走事先铺好的那条路，碰到边界情况就断。
拿到任务后自己规划：读问题、查账户历史、翻知识库、起草回复、必要时拉人工介入，全程根据中间结果动态调整。
指南开头列了一批客户成绩单，用来说明这些系统在真实生产环境里跑出了什么。
这四块数字看的不是大小，是覆盖面：客服、安全运营、欺诈审核、跨行业解决率，四种完全不同的活都有 agent 在生产环境里扛住了。它们证明的是「值得投入」，还回答不了「该选哪种架构」。指南还给了一个更贴近日常运营的例子：某零售银行用 agent 处理信贷风险备忘录，过去关系经理要花好几周手动核对十个数据源，现在带来 20% 到 60% 的生产力提升，信贷周转时间缩短 30%。这些数字建立了一个前提，agent 值得投入，但用哪种架构去实现，才是这份指南真正要教的。它一共讲六种架构，其实分三家：让 AI 自己拿主意的（单智能体、分层监督式、协作式），流程由人预先写死的（顺序、并行工作流），外加一个专管质检的（评估器-优化器）。下面按从简单到复杂的顺序一个个看。
第一步：先看单智能体够不够用
指南反复强调的第一原则是「从简单开始」。别一上来就搭复杂系统，先看单智能体能不能解决问题，它更便宜、更好排查、指标也更能对上业务结果。
单智能体系统就是一个 AI 智能体在跑一个连续循环：感知环境、决定下一步、动手执行，直到任务完成或者撞上「暂停等人工复核」这样的停止条件。它的核心由几个组件搭起来。
图里三个组件里有两个专门术语，这里先说明白。
一套让 agent 连外部系统（数据库、网页搜索、内部工具）的标准接口。agent 靠它才能真正动手查数据、调工具，而不是只会聊天。像给 AI 装了一套万能转接头，不管连数据库还是搜索引擎，接口标准统一，不用每次单独开发对接代码。
把某个领域的专业知识、标准流程、工具用法打包成一个模块，agent 需要时调用，不用把所有专业知识都塞进提示词里。像给 agent 配一套专业工具箱，遇到法律问题掏法律工具箱，遇到财务问题换一套，一个 agent 脑子里不用装满所有领域。
适合：面对开放式问题，一开始看不清路怎么走，不知道要几步、会碰到什么障碍，让 agent 自己边走边调整。
别用：需要第一次就 100% 拿到完美答案的场景。这时单智能体力不从心，要么加专门的 Skills 提升准确率，要么才考虑上多智能体。升级前先想清楚：给单智能体加技能，是不是就够了。
展开看：一个研究 agent 怎么用 8 步走完一次复杂查询
员工问：「研究工程团队正在采用的远程办公效率工具，看看有没有跟我们内部生产力指标相关的。」这个 agent 配了 MCP 连到内容库、业务工具和开发环境，它这样处理：
- ① 接收问题 → ② 初步分析：判断出这需要两个数据源，外部工具研究和内部公司指标，且外部研究一开始不依赖内部数据，可以拆成并行搜索，最后再做关联。
- ③ 激活技能：调用研究方法、数据关联、商业洞察三类技能，套用成熟框架而不是从零推理。
- ④ 任务拆解与规划：定下外部网页搜索、内部数据库查询、并行执行、关联综合的方案。
- ⑤ 并行调工具：同时跑网页搜索（找效率工具趋势）和 SQL 数据库（查内部生产力指标），两个工具并发，大幅缩短总耗时。
- ⑥ 迭代精修：看完初步结果，发现需要更具体的工程团队数据，据此追加更精准的二次查询。
- ⑦ 综合关联 → ⑧ 生成结果：把外部趋势和内部指标交叉比对，产出整合结论。
撑不住了：什么信号说明该上多智能体
当单智能体撞上根本性的天花板，才轮到多智能体登场。指南给了明确的三类触发信号，但也把代价摆到了台面上。
多智能体的意思是：把任务拆开、分给多个各有专长的智能体，各自干完再把结果综合成一个连贯回答。Anthropic 内部研究给出的核心数字是，面对需要同时探索多条独立方向的复杂任务，多智能体系统效果比单智能体高出 90.2%。它的判断是，智能到了某个临界点，「多智能体系统成为扩展性能的关键路径」，因为一群智能体能完成的事，远超单个，就像人类组织一样。
这两根条子放一起，就是全文的定盘星：效果确实能大幅往上，但成本也成倍往上翻。另外盯紧 90.2% 的适用范围，这是全书最容易被断章取义的数字：它只在「需要同时探索多条独立方向」的复杂任务上测出来，拿去给所有场景背书就是移花接木。所以告诫也很直接：简单查询不该触发昂贵的多智能体流程，系统要能按任务价值动态调配投入。
① 开放式问题：很难预判需要几步，需要在调查过程中随时转向、探索岔路。
② 任务横跨多个不相干的领域：研究显示，一件任务里混进两个以上互不相干的专业领域（比如又要审法律条款、又要算财务模型），单智能体就会顾此失彼，表现急剧下滑。
③ 广域并行：问题需要同时追多个独立方向，并行处理能带来实质性能收益。
代价还不止 token：多智能体让排查问题变难了。传统调试办法在这里失效，因为智能体是动态决策、每次运行都不确定的。当决策成倍增加，必须做能捕捉智能体之间怎么沟通、怎么分派、怎么综合结果的追踪，否则协调一出岔子就几乎无从排查。
分层监督式：一个总管带几个专家
决定上多智能体之后，第一个要回答的问题是怎么组织这群智能体：有人管，还是没人管。有人管的版本叫分层监督式，也是最常见的多智能体模式：一个中央监督者分析请求、把任务派给合适的专家智能体、再把结果综合起来，形成一条清晰的责任链。
关键机制是：在分层系统里，每个专家子智能体被当成一个「工具」，监督者用工具调用的方式决定该唤起哪个专家。这跟高效人类团队的运作一样，专家专注自己的领域，协调者负责分派和整合。子智能体自己还能带子智能体，这些下层被对上层监督者屏蔽，监督者只跟子团队的组长打交道，不知道下面还有几层。
拿一个营销团队的例子把流程走一遍。
这套模式最要命的坑叫上下文管理，值得单独拎出来讲。
系统跑久了，对话历史和中间结果会把 AI 的「脑容量」（上下文窗口）塞满，表现为窗口溢出、推理能力下降、智能体之间协调失灵。解法有三条：
- 上下文编辑（context editing）：快到 token 上限时，自动清理过时的工具调用记录和结果，同时保持对话流不断。
- 记忆工具（memory tools）：把信息存到上下文窗口外的文件系统里，需要时再读取，还能跨会话保留。
- 工具自带节流：给工具加分页、范围选择、过滤、截断，用合理默认值把单次响应封顶在可控大小（比如 2.5 万 token 左右），防止上下文被撑爆。
指南也承认这套模式 token 用量更高，但它的判断是账算得过来：对那些需要专门知识、或超出单智能体上下文极限的高价值复杂任务，性能收益撑得起这笔成本。
协作式：智能体之间互相对话解决问题
这就是「没人管」的那个版本，也是最容易和分层监督式搞混的一种。它和分层监督的本质差别就一条：没有谁管谁。协调是从智能体的互动里自己长出来的，不是被一个中央权威强加的。
在协作式系统里，智能体是平级的自主个体，直接点对点沟通、动态商量各自的角色、一起把复杂问题解决掉。它靠三种机制达成共识。
群聊式讨论：多个智能体拉一个共享对话线程，边聊边解决问题、做决策、互相验证，像拉了个项目群。
事件驱动协调：用「事件」当共享语言，每个动作都广播成一条结构化更新，其他智能体据此接活、同步上下文。
黑板式共享知识库：立一块所有智能体都能读写的中央「黑板」，谁有发现就写上去，当作集体记忆。
协作式的风险恰恰长在它的自由度上。智能体之间频繁通信会推高计算成本和复杂度；更麻烦的是会冒出「涌现行为」，也就是没人专门编程、却自己冒出来的行为，一个小改动可能不可预测地影响整个系统怎么动。应对的思路不是下死命令，而是立好协作框架：定义分工、解决问题的方式、投入预算，同时防止智能体把任务无限踢皮球，并配好冲突解决机制。
把这两种多智能体模式并排放，差别一眼就能看清。点下面的标签切换看两种结构。
树状指挥链。一个监督者在顶端，专家在下层，任务自上而下派、结果自下而上汇。
- 有清晰责任链，可审计、可追溯
- 监督者能强制执行业务规则，保留把关
- 适合客服、内容创作、数据分析这类需要灵活又要监督的中等可控场景
网状对等连接。智能体全平级，谁都能直接跟谁对话，靠讨论自己达成共识。
- 无中心决策，协调从互动里涌现
- 行为更难预测，这在探索性场景里是特性不是缺陷
- 适合研究、头脑风暴、复杂分析这类低可控要求的场景
顺序 vs 并行：任务到底该排队还是同时冲
前面几种是智能体动态决策，接下来两种是预先写死、静态的工作流编排（agentic workflows），它定义了智能体按什么顺序、在什么条件下执行任务。核心区别就一个：任务排队走，还是同时冲。
| 顺序工作流 | 并行工作流 | |
|---|---|---|
| 怎么跑 | 一条线依次执行，每一步的产出是下一步的输入 | 多条线同时执行，各自独立出结果，最后汇总 |
| 核心价值 | 用等待换准确率：多花一点时间，换每次 AI 调用都变成更聚焦、更不容易错的简单任务；流程可预测、可估成本、可按阶段排查 | 要的是快和多视角：几路同时开工，从不同角度把问题覆盖住，结论更有底 |
| 什么时候用 | 任务能干净拆成固定子任务、有明确线性依赖、需要审计追溯（合规检查、审批链、草稿→审核→发布） | 子任务互相独立能同时跑、多视角能提质、速度比协调开销更重要（风险评估要多视角、护栏审查：一个模型干活另一个专门筛不当内容、多路并行评测） |
| 什么时候别用 | 只有几步单智能体就能搞定、智能体需要协作而非交接、流程需要回溯迭代 | 智能体要在彼此成果上叠加、需要特定执行顺序、要改共享状态却没有冲突解决策略、结果聚合逻辑太复杂反而降质 |
两种流程各配了一个真实案例。顺序的是数据科学洞察：分析请求先走界定 agent（判断分析类型、路由），再到数据工程 agent（抽取清洗数据），再到分析 agent（跑统计建模，或标记复杂请求转人工），最后进人工复核。并行的是金融风险评估。
评估器-优化器：让 AI 自己改自己的作业
这是最后一种工作流，用两个 AI 分工，在反复循环里把质量磨到达标。
一个 AI 负责生成内容，另一个专门挑毛病、给可执行的反馈，来回改直到达标，不是一次性生成就完事。像一个写手配一个编辑，编辑不断打回重写，直到点头通过才发表。
API 文档生成的案例是这样跑的：生成 agent 分析代码库、写出初稿（端点说明、参数、示例、认证要求），技术评估 agent 对着真实代码实现逐条核对（参数类型对不对、端点覆盖全不全、示例能不能跑），把问题打回去，生成 agent 吸收反馈再改。
适合：有明确评估标准、迭代打磨能带来可见价值的场景，比如文学翻译、带安全要求的代码生成、语气拿捏严格的专业文书、需要多步推理加验证的研究任务。
别用：第一次出稿就已达标、评估标准主观模糊、时间成本压过质量收益的场景；也别用于要即时响应的实时应用、基础分类这类简单任务、token 预算吃紧的环境，以及评估器本身缺乏领域专业度、给不出有意义反馈的情况。
三问框架 + 一条真实演进路线
先把前面走过的链条拉直：单智能体够用就别加人；撞上三类信号（开放式、跨领域、广域并行）才上多智能体；上了多智能体，先选有人管还是没人管；流程能预先写死的交给工作流，写不死的才留给智能体自己决策。这条链收敛下来，就是全书最值钱的部分：三个必答问题。先想清楚这三点，再对号入座选架构，而不是照着技术复杂度往上堆。下面这个选择器，按你自己的情况点一下，看它指向哪种架构。
指南还补了第四问，你需不需要深度领域专业？单一领域有成熟流程，用配了专门 Skills 的单智能体就行；多个不同领域必须协同（比如法律审查要跟财务分析配合），才上带专门 Skills 的多智能体。下面是这套三问清单的完整中文版，条目和原文一一对应，拿去照着套。
1. 你需要多高的可控性？ 高可控要求（合规监管、金融交易、安全攸关操作）→ 从单智能体或顺序工作流起步 中等可控要求（客服、内容创作、数据分析）→ 考虑分层多智能体系统 低可控要求（研究、头脑风暴、复杂分析）→ 协作式多智能体也可行 2. 你的问题领域有多复杂？ 单一领域问题（答产品问题、处理退货、出报告）→ 单智能体就能高效搞定 多领域但流程可预测（员工入职、合规流程、标准分析任务）→ 顺序或并行工作流 复杂开放式问题（战略分析、研究项目、系统排障）→ 多智能体架构 3. 你的资源约束是什么？ 预算/token 有限 → 单智能体，或精心设计的并行工作流 上市时间紧 → 先用单智能体，规划好演进路径 长期战略投入 → 一开始就为模块化演进设计 4. 你需不需要深度领域专业？ 单一领域、有成熟流程 → 单智能体，配专门 Skills 多个不同领域必须协同 → 多智能体系统，各自配专门 Skills
各模式适用场景速查表
上面的约束翻译成一张明确的对号入座表，判断具体业务归哪一类时直接查。
单智能体最适合： - 品类边界清晰的客服流程 - 业务规则明确的文档处理 - 代码审查和基础开发任务 - 例行分析和报表 顺序工作流最适合： - 多步审批流程 - 内容生产管线（草稿 → 审核 → 发布） - 数据转换与校验 - 按多项标准做合规检查 并行工作流最适合： - 多视角能提升质量的场景 - 各项分析相互独立、可同时跑 - 速度比协调开销更重要的场景 - 需要多元视角的风险评估 多智能体系统最适合： - 需要多领域专业的复杂问题 - 研究和分析类项目 - 跨多个系统的动态客户交互 - 战略规划与决策支持
英文原文对照（三问清单 / 速查表 / 演进模板）
1. What level of control do you need? High control requirements (regulatory compliance, financial transactions, safety-critical operations) → Start with single agents or sequential workflows Moderate control requirements (customer support, content creation, data analysis) → Consider hierarchical multi-agent systems Low control requirements (research, brainstorming, complex analysis) → Collaborative multi-agent systems become viable 2. How complex is your problem domain? Single domain problems (answering product questions, processing returns, generating reports) → Single agents handle these efficiently Multi-domain but predictable problems (employee onboarding, compliance workflows, standard analysis tasks) → Sequential or parallel workflows Complex, open-ended problems (strategic analysis, research projects, system troubleshooting) → Multi-agent architectures 3. What are your resource constraints? Limited budget/tokens → Single agents or carefully designed parallel workflows Time-to-market pressure → Start with single agents, plan an evolution path Long-term strategic initiative → Design for modular evolution 4. Do you need deep domain expertise? Single domain with established workflows → Single agent with specialized Skills Multiple distinct domains requiring coordination → Multi-agent systems with specialized Skills Single agents work best for: customer service / document processing / code review / routine analysis and reporting Sequential workflows work best for: multi-step approvals / content pipelines (draft → review → publish) / data transformation / compliance checking Parallel workflows work best for: multiple perspectives / independent analyses / speed over coordination / diverse-viewpoint risk assessment Multi-Agent systems work best for: complex problem-solving / research and analysis / dynamic multi-system interactions / strategic planning Phase 1: Single agent for customer inquiries (proving value) Phase 2: Routing pattern separating order status, product questions, complaints Phase 3: Specialized agents for each category with shared context Phase 4: Multi-agent system with inventory, payment, and shipping coordination Phase 5: Evaluator agents for quality assurance and continuous improvement
一条真实演进路线：某电商平台的五个阶段
收尾是一条真实路径：一个电商平台从单智能体走到多智能体的五个阶段。它不是一步到位搭复杂系统，而是每一阶段等到有了可衡量的价值再加复杂度。
生产系统还常常演化成混合架构：分层监督里套并行处理、顺序工作流里带动态路由、单智能体碰到边界情况时自动触发多智能体系统。业务价值撑得起复杂度时，这些组合能解锁单一模式做不到的能力。
落脚点始终是那一条：架构跟着需求演进，从简单开始，度量一切，只在复杂度能带来可衡量价值时才加。今天最好的架构，是既满足当下要求、又给明天留好路径的那个最简方案。 Building Effective AI Agents · Anthropic