3.3 多智能体协作机制详解

3.3 多智能体协作机制详解

本节摘要：2.5 教你搭 Team，本节讲清楚协作背后的机制：任务怎么拆、上下文怎么传、三种协作模式各适合什么。理解机制后，你就能按任务形态设计团队结构，而不是套模板。

你能学到什么

阅读完本节，你应当能够：

1. 说出多智能体协作解决的核心问题
2. 理解任务拆解与上下文传递的机制
3. 区分三种协作模式并选择适用场景
4. 设计合理的团队结构与成员边界
5. 规避多智能体协作的常见失败模式

一、问题与直觉

单智能体像一个人单干：全能但每样都不精，上下文一长就乱。多智能体协作像开公司：CEO 拆任务，专家各管一摊，最后整合。但"开公司"也有成本——任务拆不好、上下文传错、结果合不上，协作就失败。本节把协作的底层机制讲透，让你能设计出真正高效的团队。

二、核心原理

2.1 协作机制的两块基石

• 任务拆解：把大任务按"能力域"切成子任务，分配给对应专家。拆得好，每个成员做自己最擅长的；拆得差，任务边界模糊，成员互相等
• 上下文传递：把必要的信息传给成员——用户需求、上游结果。传太多，上下文膨胀、成本上升；传太少，成员信息不足、答非所问

2.2 三种协作模式

三、工程实践要点

3.1 顺序流水线示例

from agno.agent import Agent
from agno.team import Team

# 三阶段：查资料 → 分析 → 写报告
researcher = Agent(name="researcher", role="搜集资料")
analyst = Agent(name="analyst", role="分析数据")
writer = Agent(name="writer", role="撰写报告")

team = Team(
    name="report_team",
    members=[researcher, analyst, writer],
    instructions=["先让研究员查资料，再让分析师解读，最后由撰写员成文"],
)
​

3.2 并行扇出示例

# 同一需求分发给多个独立专家，各自处理后汇总
searcher = Agent(name="searcher", role="搜索公开信息")
db_agent = Agent(name="db_agent", role="查询内部数据")

team = Team(
    name="parallel_team",
    members=[searcher, db_agent],
    instructions=["两个成员同时工作：一个搜公开信息，一个查内部数据，最后汇总"],
)
​

💡 关键直觉：能并行就别串行。多个成员处理互不依赖的子任务时，并行能把耗时从"总和"压到"最慢的那个"。但并行会各自消耗上下文，别盲目并行。

3.3 协作失败的三个模式

3.4 团队规模的经验法则

团队成员不是越多越好：每多一个成员，协调开销与上下文成本都上升。经验法则——能 2 个解决的不上 3 个；确实需要细分才加成员；大规模任务用分层而非平铺。

⚠️ 常见坑：成员之间互相"转发"任务而不干活——A 把任务抛给 B，B 又抛回 A，形成死循环。指令里明确"每个成员必须独立完成任务并输出结果，不得把任务转交给其他成员"，能有效避免协作空转。

四、三个来自原始资料的进阶剧本

资料里给了三个超出"搜索 + 财务"套路的协作剧本，各自演示一种编排形态。

会议时间协商：项目经理、技术主管、市场经理三个智能体各有日程约束，一个会议协调智能体居中收集各方空闲时段、找出交集、提议方案。这是"协商型"编排——成员有利益立场，队长做中间人。

市场竞争模拟：电商平台甲、电商平台乙、市场环境三个智能体互为对手盘，模拟定价与反应的动态博弈，用于策略推演。这是"对抗型"编排——成员之间不共享目标，观察涌现行为本身就是产出。

应急救援演练：信息收集、救援协调、医疗救助、物资运输、灾情演化五个智能体协作，其中灾情演化智能体持续制造新情况，考验其余四者的响应。这是"动态环境型"编排——引入一个"世界"角色不断施加变化。

五、机制内核：队长怎么想、成员怎么答

剥开剧本看机制，协作循环只有三问：任务给谁（路由）、成员怎么干活（执行）、结果怎么合（整合）。队长拿到任务先做分解与路由决策，依据是各成员的角色描述与历史表现；成员执行时带各自的工具与知识库，产出结构化结果；整合阶段队长核对完整性，缺了就追单，齐了就合成最终答复。

把这个循环与单智能体对比，差异在"责任分离"：单智能体一件事干到底，错了整轮重来；团队里某成员出错，队长可以只重派那个子任务。这也是团队在长任务上更稳的结构性原因。

💡 关键直觉：团队不是"更多智能体"，而是"更多角色"。判断该不该上团队的标准，是任务里是否存在天然可分的职责边界——没有边界的任务硬拆，只会制造协调成本。

⚠️ 常见坑：角色描述写得像职位口号（"负责市场分析的市场分析师"），队长无从判断派单。要把"输入什么、产出什么、擅长什么边界"写具体，路由质量立刻不同。

状态与上下文：团队的信息经济学

多智能体系统里，信息在成员之间怎么流动，直接决定系统的智力上限与账单下限。两个极端都有害：完全共享（每个成员都看到全量上下文）智力冗余但 token 成本平方级膨胀；完全隔离（成员只拿自己那份数学题）成本低但协作变盲人摸象。实践中的甜点位在中间——共享"任务目标与关键结论"，隔离"各自的原始过程数据"。

队长在这个设计里扮演信息枢纽：它维护一份精炼的任务黑板（目标、已完成的结论、待办），成员读取黑板获取全局视野，写回自己的结论而不写过程。黑板内容控制在一两百词内，成员间不需要互相读取大段原文。这套模式跟人类团队的协作常识惊人一致——周会同步结论，而不是互相直播工位屏幕。

会话记忆在团队语境下也要重新考虑：记什么？记用户的原始需求与最终答复足矣，成员间的中间过程不必长留。过程数据有价值的话（比如调研素材），沉淀到知识库而不是记忆里，前者是共享资产，后者是会话负担。分清这两者的去向，团队跑一个月后数据库才不会变成沼泽。

六、常见问题

成员数量有没有经验上限？

以队长能清晰调度的范围为限，实践中三到五个成员是舒适区。更多成员建议分层组织：队长管几个小队长，小队长管成员——本质上是人类组织的科层制。

对抗型编排会不会失控？

会，所以要设边界：限定轮次上限、每轮动作合法性校验、队长保留终止权。模拟类应用里"失控"有时正是观察对象，但生产系统里必须圈住。

成员产出的质量怎么管？

给每个成员的产出定义结构（字段、格式、必填项），队长整合时校验，不合格打回重做。用结构换质量，比祈祷模型发挥稳定可靠得多。

从机制到制度：团队的可观测性

团队比单智能体更需要可观测性，因为它多了一层"调度黑盒"——队长为什么这么派单，不打开日志永远是个谜。最小的观测配置是三份记录：派单日志（每个子任务派给了谁、依据的角色匹配）、成员日志（各自的输入摘要、工具调用、输出）、整合日志（队长如何合并、有无冲突及裁决）。三份日志在手，任何一次"团队答错了"都能回放定位到具体环节。

有了日志，接着建团队的"例会机制"：每周抽样回放几条失败案例，归因到派单、成员能力或整合规则，对应修角色描述、成员配置或队长指令。这套机制跑起来后，团队的行为会持续收敛——不是模型变聪明了，是你的协作规则在被真实案例不断打磨。多智能体系统的成熟度曲线，本质上就是这套反馈回路转动的圈数。

规模再往上长，就要考虑给成员加"绩效档案"了：统计各成员的成功率、平均耗时、token 消耗，低绩效成员或降级模型或收窄职责。听起来不像"人工智能"，倒像中层管理——没错，多智能体系统的尽头确实是管理学，只不过被管理的是模型。

团队设计的反模式清单

再补三个一望即知的反模式，自查用。反模式一"全能队长"：队长自己带一堆工具亲自干活，成员沦为摆设——这说明你需要的其实是单智能体，删掉团队层反而干净。反模式二"复述型成员"：成员的产出只是把输入换个说法，没有信息增量——这个环节应该被合并，纯转发的节点是延迟与误差的放大器。反模式三"沉默升级"：成员失败后队长直接放弃并返回模糊错误——应该在队长指令里明确失败处理协议，重试、换人、或如实上报卡点。三条共同指向一个检查动作：逐个成员问"删掉它会损失什么"，答不出损失的就是下一个优化对象。

把机制讲透之后，剩下的是审美问题：好的多智能体系统读起来像一份清晰的组织架构图，每个成员一句话说得清职责；糟糕的则像一张缠满电线的桌子，没人敢碰。定期用"新同事视角"审视你的团队配置——如果他看不懂谁负责什么，说明该重构的不是代码，是分工。

机制的讨论到此告一段落。下一节暂时离开协作话题，转向每个生产系统都绕不开的另一场战役——性能与成本优化，看看轻快的设计在账单面前还剩下哪些硬仗要打。

本节速览

• 要点一：协作机制两块基石——任务拆解与上下文传递
• 要点二：三种模式——顺序流水线、并行扇出、分层团队
• 要点三：步骤依赖选顺序、任务独立选并行、规模超大选分层
• 要点四：能并行就别串行，但并行有上下文成本
• 要点五：失败三模式——职责重叠、上下文爆炸、结果冲突
• 要点六：成员宁少勿多，复杂任务分层而非平铺

团队机制清楚了，下一节让整套系统跑得快、跑得省——性能优化最佳实践。