为什么要多 Agent，以及为什么别急着上框架

你写了一个能干活的 Agent，它会查资料、会写文件、会调几个工具，本地跑得挺好。然后你给它加了第三类任务、第八个工具，某天它开始抽风：该查资料的时候去写文件，工具选错了还死活不认错，你翻日志想知道它哪一步走偏了，结果是一坨几万 token 的对话历史，根本读不下去。这一节讲的就是这个坎——什么时候一个 Agent 不够用了，得拆成多个；以及一个反直觉的建议：别急着上框架。

这篇适合谁：已经写过单体 Agent（最好读过 AI Agent 是什么 和 文件即记忆），正在纠结「要不要拆多 Agent、要不要上 LangGraph 这类编排框架」的人。读完你能自己判断该不该拆，以及该用多重的工具拆。本篇偏概念和判断，代码不多，图和清单管够。

---

单体 Agent 在生产里为什么脆

本地能跑和能上生产，中间隔着三道坎。单体 Agent（一个大 prompt、一堆工具、一个 loop 全包圆）几乎一定会撞上其中至少一道。

第一，上下文爆掉。 Agent 的每一步都把之前所有的对话、工具调用、工具返回塞回上下文里再问模型。任务一长，工具返回一大（想想一次网页抓取返回的几千字），上下文就像雪球一样滚大。结果是两头受罪：贵（每一步都为越来越长的历史付费），笨（关键信息淹没在一堆陈旧的工具输出里，模型开始抓不住重点）。这不是你 prompt 写得不好，是单体结构的物理上限。

第二，职责纠缠。 你想让它「先调研、再写报告、顺便核对数据」，于是把三件事的指令全写进一个系统提示词。模型在一个上下文里同时背着调研员、写手、审核员三套要求，难免串味——用写报告的语气去做调研，或者调研做一半就开始写。指令越多越互相打架，这是把多个角色硬塞进一个脑子的代价。

第三，难调试。 出了问题你想定位「它在哪一步、为什么这么决定」，但单体 Agent 的全过程是一条没有分段的长流水。没有清晰的边界，你只能在几万 token 里大海捞针。生产环境里，不能快速定位错误 = 不能维护。

这三道坎，本质都是同一个问题：一个 Agent 扛了太多它扛不动的东西。 解法的方向，和软件工程二十年前学到的东西一样——拆。

---

多 Agent = 微服务化的思路

把单体 Agent 拆成多个各管一摊的小 Agent，和把单体应用拆成微服务，是同一套智慧。这个类比能帮你快速理解多 Agent 好在哪：

单体的毛病	微服务怎么解	多 Agent 怎么解
上下文/代码全堆一起	每个服务只管自己那块	每个子 Agent 只带自己任务相关的上下文
一处改动牵动全身	服务间靠接口解耦	子 Agent 之间只传「最终结果」，不共享一脑子历史
难定位问题	每个服务独立日志/监控	每个子 Agent 独立会话，能单独看它干了啥
一个角色背太多职责	单一职责原则	一个子 Agent 一个专门指令（调研员就只当调研员）

最关键的一条是上下文隔离：让一个「调研子 Agent」去抓十个网页、读完、汇总，它自己的上下文塞满了那十个网页的原文——但它只把一段三百字的汇总交回给主 Agent。那十个网页的原文，主 Agent 永远不会看到。 主 Agent 的上下文因此始终干净。这一招直接解掉了「上下文爆掉」。

但类比也有边界，别把它神化。微服务有个著名的反面教训：很多团队拆早了、拆碎了，落得一个分布式的烂摊子，比单体还难维护。 多 Agent 同样如此。拆得对是解药，拆得过头是新的病。这就引出了下一节最重要的判断。

---

判断清单：该拆多 Agent，还是单 Agent 就够

不是任务一复杂就该拆。拆 Agent 有实打实的成本（多一次甚至多轮模型调用、要设计 Agent 之间怎么传话、调试面变大）。先用这张清单判断，满足越多条，越该拆：

该拆多 Agent 的信号：

• ✅ 任务能切成边界清楚的几块，块和块之间不怎么来回（调研 → 写作 → 审核，是单向流水）。
• ✅ 某一块会产生大量中间上下文，但只需要把结论交出去（典型：调研、读长文档、跑批量检索）——这是上下文隔离最值钱的场景。
• ✅ 不同块需要明显不同的「人设」或工具集（调研员要联网搜索，写手要文风指令且不该碰删除工具）。
• ✅ 有几块天然可以并行（同时调研三个竞品），并行能省墙钟时间。
• ✅ 你需要能单独观测/重试某一块（调研挂了只重跑调研，不用整条链推倒重来）。

单 Agent 就够、别拆的信号：

• ❌ 任务步骤少、上下文短，一个 loop 跑完也就几千 token。
• ❌ 各步骤强耦合、要频繁来回对话（拆开反而要不停跨 Agent 传话，更贵更乱）。
• ❌ 你只是「觉得多 Agent 高级」——这不是技术理由。
• ❌ 还没把单体调通就想拆——先让单体能跑，再谈拆分，否则你是在调试一个你还不理解的系统。

一句口诀：拆 Agent 是为了隔离上下文、分清职责、能并行能观测；不是为了显得复杂。 如果你说不清拆开能解决上面哪个具体问题，那就别拆。

---

关键建议：别急着上重框架

假设你判断完，确实该拆多 Agent 了。下一个问题几乎所有人都会问：「那我上 LangGraph / 某编排框架吧？」

慢着。2026 的主流做法是「延迟框架承诺」（delay the framework commitment）。 意思是：先用裸 SDK（比如 Claude Agent SDK、OpenAI 的 Agents 工具）的原生原语手搓编排，把「Agent 之间怎么协调」这件事真正学会、跑通；等你确实需要显式状态机、检查点、复杂拓扑了，再上重框架。

为什么是这个顺序？

第一，多数多 Agent 场景，裸 SDK 的「子代理委派」就够了。 主 Agent 把一块活委派给一个子 Agent，子 Agent 在独立会话里干完、只回结果——这个「子代理」原语，现代 Agent SDK 都直接内置了（Claude Agent SDK 里通过把一个 coordinator 的 multiagent 角色配上一组可委派的子 Agent 来实现，具体字段名以官方文档为准）。你不需要一个图编排框架来做「派活 → 收结果」这么直接的事。

第二，框架是有成本的「承诺」。 一旦你把编排逻辑写进某个框架的 DSL/图节点里，你就和它的抽象、它的版本、它的心智模型绑死了。框架变了你得跟着改，框架的 bug 你得绕着走，新人得先学框架再看你的业务。这笔账，在你还没搞清自己到底需要什么编排拓扑之前付，太亏。

第三，code-first 让你真正理解编排在干嘛。 你亲手写过「主 Agent 调一个子 Agent、拿到结果、再决定下一步」的 loop，你才懂编排的成本结构、懂为什么对话式多 Agent 那么贵、懂检查点到底解决什么问题。先用裸 SDK 把肌肉练出来，再看框架，你会一眼看穿框架在帮你省哪部分、又锁住了你哪部分。 反过来，一上来就抱框架，你学到的是框架，不是编排。

那什么时候确实该上重框架？当你撞到这些裸 SDK 写起来很痛的需求时：

• 需要显式的、可持久化的状态机（流程能在某一步暂停、落盘、隔天恢复）。
• 需要检查点 / 断点续跑（长流程跑到一半挂了，从检查点继续而不是从头来）。
• 需要复杂拓扑（条件分支、循环、扇出扇入交织成图，手写 loop 已经绕不清楚）。
• 多人协作，需要一套统一的、可视化的编排规范让团队都看得懂。

撞到这些，框架帮你省的远多于它锁住的，该上就上。没撞到，裸 SDK 更轻、更透、更好调。

---

反面教训：一上来就上 LangGraph 把简单事搞复杂

讲个典型翻车现场（细节做了脱敏，但模式很常见）。

有个团队要做一个「客服问答 + 查订单」的 Agent。本来：一个 Agent，挂两个工具（知识库检索、订单查询），一个 loop，搞定。这是教科书级的「单 Agent 就够」场景——步骤少、上下文短、不需要隔离。

但他们一开始就决定「要做就做得专业」，直接上了图编排框架，把它拆成「意图识别节点 → 路由节点 → 知识库子图 → 订单子图 → 汇总节点」一张图。结果：

• 本来三行的 loop，变成了几百行图定义。 加一个新意图，要动好几个节点和边。
• 调试更难了，不是更简单。 出问题得在图的执行轨迹里找,比单体的长流水还绕。
• 没解决任何真问题。 上下文没爆（任务本来就短）、职责没纠缠（本来就两件事）、并行用不上（用户一次就问一件事）。框架带来的全是成本，没有收益。
• 新人接手先学框架两周。 而这套业务逻辑，用裸 SDK 一下午能看懂。

教训很清楚：框架不是成熟度的勋章，是针对特定复杂度的工具。 在不需要它的复杂度上用它，你买的不是能力，是负担。先问「我撞到上一节那些『确实该上框架』的信号了吗」，没撞到，就别上。

---

小结 · 你现在掌握了什么

• 你看懂了单体 Agent 在生产里的三道坎：上下文爆、职责纠缠、难调试，本质是一个 Agent 扛太多。
• 你理解了「多 Agent = 微服务化」的类比——靠上下文隔离、单一职责、并行、可观测解题；但也记住了它和微服务一样会被拆过头。
• 你拿到了一张该拆 / 不该拆的判断清单，核心是：说不清拆开解决哪个具体问题，就别拆。
• 你接受了 2026 的主流姿势——延迟框架承诺：先用裸 SDK 手搓编排把协调学会，撞到显式状态机/检查点/复杂拓扑了再上重框架，否则框架只是负担。

下一节我们把「编排到底贵在哪」算清楚：子代理 vs 对话式 vs handoff 三种编排的成本心智，让你按成本选模式，而不是凭感觉。

下一步：理解了「要不要拆、要不要上框架」，接着学「怎么拆最省」。看 AI Agent 智能体阶梯 的 L5 后续；想看全貌就对照三支柱路线图。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。