一、从一组公开数据开始Anthropic 在 2025 年公开的多 Agent Research 系统里给过一组数字单 Agent 在 BrowseComp 这类长链研究任务上只能解出约 16% 的题目多 Agent 协作版本做到约 46.2%——相对提升接近 90%。但同一篇报告也写得很清楚token 消耗大约是单 Agent 的 15 倍。15 倍成本换 3 倍效果。这不是免费午餐。社区里讲多 Agent 的文章一半在喊未来已来另一半在贴 LangGraph 拓扑图。但工程上的真问题只有两个你的任务是不是真撑爆了单 Agent多 Agent 的 15 倍成本你扛不扛得住下面按这两个问题展开。二、单 Agent 的天花板长什么样把单 Agent 撑爆的瓶颈通常就三种1. 上下文过载研究类任务平均要查 20 个网页每页几千 token搜索结果原文塞进上下文很快爆。Claude 的 200K 窗口看着大但工具返回 历史对话 中间推理一加5-6 轮就开始挤。2. 工具切换的认知税同一个 Agent 既要规划搜索路径、又要写代码过滤结果、又要归纳结论。每一步切换都要重新对齐目标。提示词写得再好工具超过 5-6 个就开始互相干扰。3. 错误无法隔离一个搜索分支走错了整个上下文被污染——后续所有决策都建立在错误假设上。而且这个错误会一直留在 context 里反复污染。多 Agent 不是多开几个 prompt。是把这三个问题拓扑化每个 Agent 拥有独立的上下文窗口、独立的工具集、独立的失败边界。三、多 Agent 解决什么、不解决什么解决上下文隔离A Agent 失败不会污染 B Agent 的工作记忆。并行加速互不依赖的子任务同时跑。专业化一个 Agent 调代码工具一个只做网页抓取——各管一摊。错误恢复某个分支挂了单独重试它主线不受影响。不解决提示词写得烂Agent 多了只会放大烂 prompt 的问题。工具选错给写报告的 Agent 配搜索引擎它还是乱跑。业务逻辑没想清楚3 个 Agent 协调一个没说清楚的状态机比 1 个 Agent 还乱。上下文工程把所有上下文塞给 Supervisor Agent照样 token 爆炸。一个粗略的判定标准如果你的单 Agent 主要问题是上下文窗口不够长多 Agent 基本没用。你需要的是 RAG、摘要策略、长上下文模型而不是更多 Agent。四、三种主流拓扑4.1 Supervisor 模式编排者一个中央 Supervisor 接收任务、拆解、调度 Worker、汇总结果。┌──→ Researcher Agent │ User → Supervisor ──→ Coder Agent │ └──→ Writer AgentAnthropic 的多 Agent Research 系统就是这个结构。适合研究、报告生成、复杂多步查询。代价Supervisor 是单点瓶颈和故障源。它的上下文必须能容纳所有子任务的摘要否则它自己会先爆。4.2 Peer-to-Peer 模式对等没有中心Agent 之间直接对话、互相同步状态。A Agent ←→ B Agent ↕ ↕ C Agent ←→ D Agent适合协商、辩论、协作设计。两个 Agent 互 review 代码、一组 Agent 投票决策。代价通信成本高、容易陷入死循环、需要明确的终止条件最大轮次、一致性阈值、token 上限。4.3 Hierarchical 模式层级多层 Supervisor上层做战略决策下层做执行。Meta Supervisor / \ Domain Supervisor Domain Supervisor / | \ / | \ W1 W2 W3 W4 W5 W6适合超大型任务、企业级流水线、跨域协作。代价调试地狱。一个错误可能跨三层传播日志追踪不做好基本等于盲飞。五、一个能跑的最小例子LangGraph下面这段代码展示三 Agent 串行协作Search → Write → Review。每个 Agent 独立的 state互不污染。fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDfromlangchain_openaiimportChatOpenAIimportoperatorclassResearchState(TypedDict):topic:strsearch_results:Annotated[list,operator.add]draft:strfinal_report:strllmChatOpenAI(modelgpt-4o)defsearch_agent(state:ResearchState):# 搜索 Agent用自己的工具和上下文resultssearch_web(state[topic])return{search_results:[results]}defwrite_agent(state:ResearchState):# 写稿 Agent只看搜索结果不知道用户原始 querydraftllm.invoke(f基于以下资料写一篇文章\n{state[search_results]})return{draft:draft.content}defreview_agent(state:ResearchState):# 审稿 Agent只看 draft不知道搜过什么reviewedllm.invoke(f审校并改进以下文章\n{state[draft]})return{final_report:reviewed.content}graphStateGraph(ResearchState)graph.add_node(search,search_agent)graph.add_node(write,write_agent)graph.add_node(review,review_agent)graph.add_edge(search,write)graph.add_edge(write,review)graph.add_edge(review,END)graph.set_entry_point(search)appgraph.compile()resultapp.invoke({topic:2026 年 AI Agent 框架对比})三个 Agent三个独立的上下文窗口。Search Agent 失败可以单独重试不会影响 Write Agent。Annotated[list, operator.add]这个 reducer 让多个 search 结果能自动合并进 state。并行版本也很简单——加一个Send或者Map-Reduce节点fan out 多个 search worker 就行fromlanggraph.constantsimportSenddefdispatch_searches(state:ResearchState):# 拆分成多个子任务并行分发return[Send(search,{topic:f{state[topic]}- 角度{i}})foriinrange(3)]graph.add_conditional_edges(__start__,dispatch_searches)六、多 Agent 的真实代价把上一节的优势看完这节是冷水。6.1 成本放大Anthropic 的数据多 Agent Research 系统 token 消耗是单 Agent 的15 倍。3 倍效果换 15 倍成本单位 ROI 远不如想象中漂亮。如果你的产品是 B2C 高频场景单次任务成本压到几美分是关键——多 Agent 直接吃掉利润。6.2 调试地狱Agent A 说任务完成Agent B 说我没收到这个任务Supervisor 说我以为它做了。这种沟通偏差在多 Agent 系统里是常态。LangSmith、LangGraph Studio、AgentOps、Langfuse 这类 tracing 工具不是可选项——不接就别上生产。每一步的 input、output、token 消耗、耗时、工具调用必须可查。6.3 延迟串行编排3 个 Agent 各 2 秒 6 秒。并行编排最长那条路径决定总时长max 而不是 sum但调度本身有 overhead。如果产品对延迟敏感 1 秒响应多 Agent 不合适。6.4 评估复杂度单 Agent 你只需要评估输入 → 输出。多 Agent 你要评估每个 Agent 单独的成功率Agent 之间的交接质量handoff 是否带够了上下文整体任务完成率单点失败的恢复率成本 vs 效果比的 Pareto 边界没有这套评估体系多 Agent 就是黑盒跑分——上线即事故。七、何时不要用多 Agent清单式列出任务能在单次 LLM 调用内完成分类、抽取、简单问答——单 Agent 足够。上下文长度是核心瓶颈用 RAG、摘要、长上下文模型而不是堆 Agent。业务逻辑还没稳定先把单 Agent 跑通再考虑拆分。预算敏感高频 C 端场景15 倍成本直接击穿毛利。团队没准备好工程化没有 tracing、没有 eval、没有 prompt 版本管理——多 Agent 上线就是事故。反过来什么时候应该用任务天然多阶段、阶段间可并行每个阶段需要的工具和上下文差别大单点失败要可重试不能拖垮整体有 15 倍成本的预算空间八、落地清单如果你决定上多 Agent过这 10 条明确拆分边界每个 Agent 拥有独立的上下文、工具、失败边界。通信协议定死用什么格式传消息——JSON Schema结构化字段自然语言前后端契约要清晰。终止条件明确每个 Agent 何时算完成何时放弃。错误隔离子 Agent 失败不能拖垮整个流水线。可观测性每个 Agent 的输入、输出、耗时、token 消耗都要可查。评估体系先有单 Agent eval再做多 Agent eval。成本预算单任务最大 token 消耗上限超了降级到单 Agent 或人工。回退路径多 Agent 跑不通时自动回退到单 Agent 或人工介入。状态持久化长任务要支持断点续跑Agent 状态可序列化。人机协同点关键决策允许人类介入不要全自动黑盒。九、写在最后多 Agent 不是高级版单 Agent它是一套分布式系统。分布式系统的所有坑——单点故障、调试困难、成本放大、状态一致性——多 Agent 全有只是换了个名字叫Agent 协作。不要为了看起来高级上多 Agent。先把单 Agent 跑到性能瓶颈的边界看清楚瓶颈是什么——是上下文是工具切换是错误恢复——再决定拆不拆。我自己的经验90% 的场景单 Agent 好的上下文工程 好的工具设计就够了。剩下 10%多 Agent 才是真正的杠杆。但前提是——你得有那 15 倍成本的预算、那套 tracing 体系、那个对多 Agent 调试有耐心的团队。三者缺一多 Agent 就是技术债不是技术升级。参考Anthropic Engineering,How we built our multi-agent research system, 2025-06来源LangGraph 多 Agent 文档LangGraph Multi-AgentLangSmith tracingLangSmith