阅读时间约 14 分钟前置知识理解 Agent 决策循环P01、上下文管理P03、重试与错误处理P04P05 让 Agent 有了记忆。但架构上还有一个选择一个 Agent 干到底还是拆成多个你会听到两种声音“别拆单 Agent 够用和拆了效果好 90%”。谁对前言一场没有标准答案的论战CognitionDevin 母公司的主张不要建 Multi-Agent 系统。多 Agent 编排增加复杂度、毁掉可调试性、把上下文工程就能解决的问题变成了架构问题。Anthropic 的反证用 Opus 4 协调多个 Sonnet 4 子 Agent在复杂研究任务上比单 Agent Opus 4 提升了 90.2%。两家都做生产级 Agent都拿得出数据。而且两家都是对的因为他们在解决不同的问题。Multi-Agent 不是更好的架构。它是一种特定场景下的工具。用对了收益巨大用错了烧 token 还降低质量。本章核心Multi-Agent 的决策依据是三个信号上下文污染、并行探索、工具过多。大多数场景先优化单 Agent 更划算。否强依赖是不会会否是否是新任务子任务是否独立单 Agent上下文会污染吗需要并行执行任务价值 协调成本Multi-Agent优化 Prompt/上下文/工具Coordinator Sub-Agent第一部分单 Agent 为什么对大多数场景够了Google Research 发现在严格顺序推理任务上Multi-Agent 比单 Agent 性能下降 39% 到 70%。原因很简单每多一层 Agent 间信息传递就多一层压缩。压缩就是丢东西。Anthropic 自己也说大多数团队不需要 Multi-Agent 系统单个 Agent 改进 prompt 效果就能匹配复杂多 Agent 架构代价更低。80% 的企业场景单 Agent 就够了。单 Agent 的三大优势共享上下文是资产。读过的文件、看到过的错误、试过的方案全在一个上下文窗口里。拆成多个 Agent协调者看到的是摘要而不是原始数据摘要是带损耗的。调试是可控的。一个上下文窗口 一条可追踪的链路。多 Agent 的失败会跨边界级联B 失败了因为 A 的摘要漏了关键细节。排查 B 找不到问题几小时后才发现是 A 的压缩出错。延迟可预测。每步一次模型调用。多 Agent 每次交接增加 2-10 秒延迟。本章要点单 Agent 对 80% 场景够用。共享上下文 信息不丢、调试 一条链路、延迟 可预测。第二部分三种真正需要 Multi-Agent 的场景场景一上下文污染一个上下文窗口里同时分析两家竞争公司的数据模型的心理模型会混在一起。为什么 Multi-Agent 能解决两个子 Agent 分别在独立上下文里各自分析协调者收到两份干净的独立报告再做对比。信息从未混合。defanalyze_competitors(report_a,report_b):agent_aSubAgent(分析师-A)agent_bSubAgent(分析师-B)result_aagent_a.run(f分析这份年报{report_a})result_bagent_b.run(f分析这份年报{report_b})returnCoordinator().run(f对比\nA:{result_a}\nB:{result_b})场景二并行探索需要同时研究 20 篇论文、同时调 8 个 API、同时查 5 个数据库。单 Agent 只能串行。5 个子 Agent 同时跑总时间是一个 Agent 的五分之一。场景三工具过多注册了 50 个工具模型选错的概率显著增加工具描述本身占几千 token。按功能拆成专门子 Agent每个只暴露 3-5 个工具。混合模式最实用的折中Anthropic 自己的数据Multi-Agent token 消耗是单 Agent 的 10-15 倍。大部分生产环境用混合模式一个主 Agent 按需启动一次性子 Agent。classHybridAgent:def__init__(self):self.coordinatorCoordinator()defsolve(self,task):planself.coordinator.plan(task)results{}forstepinplan:ifstep.requires_isolation:subSubAgent(step.context)results[step.id]sub.run(step.prompt)# 子 Agent 跑完即弃else:results[step.id]self.coordinator.execute(step)returnself.coordinator.synthesize(results)本章要点三种适用场景上下文污染、并行探索、工具过多。混合模式主 Agent 按需子 Agent最实用。第三部分四种不该用 Multi-Agent 的反模式反模式为什么错拟人化角色分工角色名称不等于能力边界。同一模型换 system prompt 不算真正的拆分简单查询也拆 Agent查天气一次工具调用就能完成拆三个 Agent 烧 15 倍 token顺序依赖硬拆并行A 的输出是 B 的输入拆开后在传递中丢失信息为了好看上架构每多一层协调多一层调试难度、多 10 倍成本总结什么时候坚决不拆大多数编码任务单仓库简单查询查天气、问价格顺序依赖的任务拟人化角色没有真正的能力域差异Token 预算紧张本章要点简单查询、低价值任务、顺序依赖、单仓库编码先优化单 Agent 更划算。Multi-Agent 不是默认选项。第四部分通信模式指挥链就够了Multi-Agent 之间怎么通信两种方案指挥链Coordinator → Sub-Agent所有通信经过协调者。可追踪、可调试、协议简单。适合内部系统。A2A 协议Agent 之间自由互发消息。Google 2025 年提出适合跨组织场景。但日常开发基本用不到Coordinator 知道全局任务目标直接指挥比让 Agent 自己协商效率高得多。CoordinatorSub-Agent ASub-Agent BSub-Agent C本章要点内部系统用指挥链就够了。A2A 留给跨组织场景。实战正确 Multi-Agent 的三个关键细节classSubAgent:独立上下文完成单一分析def__init__(self,name,system_prompt):self.namename self.messages[]# 独立上下文空间defrun(self,task):self.messages[{role:system,content:self.system_prompt},{role:user,content:task}]return{agent:self.name,result:call_llm(self.messages)}classCoordinator:汇总子 Agent 结果综合判断defsynthesize(self,sub_results):results_text\n\n.join(f[{r[agent]}]:{r[result]}forrinsub_results)returncall_llm([{role:user,content:f基于以下独立分析给出综合对比\n{results_text}}])三个关键细节独立上下文、明确职责边界子 Agent 不做对比、结构化输出传递不传原始数据。本章要点正确的 Multi-Agent 关键在三点独立上下文、明确职责边界、结构化传递。总结Multi-Agent 不是升级是取舍。解决三个特定问题上下文污染、并行探索、工具过多。先优化单 Agent。改进 Prompt、优化上下文、精简工具集比上 Multi-Agent 更有效更便宜。混合模式最实用。主 Agent 按需子 Agent用完即弃。通信用指挥链就够了。A2A 留给跨组织场景。思考一下你的项目里哪些任务的真正瓶颈是上下文污染或工具太多而不是Agent 不够多下一篇预告P07. 评测怎么判断你的 Agent 好不好用架构搭完了但现在的问题变成了Agent 到底做得好不好怎么测看任务完成率看 token 消耗看用户打分一套实用的 Agent 评测框架从单元测试到端到端评估。思考一下你现在的 Agent 有没有评测标准还是靠看起来好像对了来判断