2.5 多智能体协作团队

2.5 多智能体协作团队

本节摘要：单个智能体能力有限，把任务拆开交给多个"术业有专攻"的智能体分工协作，是复杂任务的标准解法。本节用 Team 搭建"网络搜索 + 金融分析"双成员团队，讲清成员职责、协作流程与结果汇总，并给出团队设计的原则。

本节导读

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

1. 说出多智能体协作解决什么问题
2. 用 Team 组建多成员协作单元
3. 为每个成员设置清晰的职责边界
4. 理解协作流程与结果汇总机制
5. 判断什么任务适合用团队而非单个智能体

一、问题与直觉

让一个智能体"既要会搜新闻，又要会算财务，还要会写报告"——提示词会越来越长，每个环节都做得不深。人的组织方式是分工：记者查资料、分析师算数、编辑写稿。多智能体团队复制这套逻辑：每个 Agent 只做自己最擅长的一件事，Team 负责协调与汇总。任务越复杂，分工的价值越大。

二、核心原理

2.1 团队协作的模式

Team 中有一个协调者负责理解任务、分派给合适成员、收集结果；成员各司其职。用户只跟 Team 打交道，不必关心内部谁干了什么。

2.2 协作流程

三、工程实践要点

3.1 搭建双成员团队

from agno.agent import Agent
from agno.team import Team
from agno.tools.duckduckgo import DuckDuckGoTools
from agno.tools.yfinance import YFinanceTools

# 成员一：查资料
web_agent = Agent(
    name="web_searcher",
    role="负责搜索最新的公开信息",
    tools=[DuckDuckGoTools()],
)

# 成员二：算数据
finance_agent = Agent(
    name="finance_analyst",
    role="负责获取行情与财务数据",
    tools=[YFinanceTools(stock_price=True)],
)

# 组装团队
team = Team(
    name="research_team",
    members=[web_agent, finance_agent],
    instructions=["先搜索背景信息，再补充财务数据，最后综合回答"],
)

team.print_response("某科技龙头最近有什么大新闻？估值水平如何？")
​

三个要点：role 定义成员职责（分派依据）、members 列出成员、instructions 定义协作顺序。

💡 关键直觉：成员的 role 是协调者分派任务的依据。role 写得越具体，分派越准——"负责搜索最新公开信息"比"搜索"好得多。

3.3 什么时候用团队

⚠️ 常见坑：任务简单也硬上团队，反而引入协调开销——分派、上下文传递都可能出错。一个智能体能干好的事，别组队。

3.4 团队设计的三个原则

• 成员职责不重叠：两个成员都"查资料"会互相抢活，职责要正交
• 协调指令明确：告诉 Team"先做什么、再做什么、最后怎么汇总"
• 结果可追溯：开 show_tool_calls 观察每个成员的执行过程

3.5 团队的调试

四、两个团队蓝本：从分析型到服务型

原始资料给了两个很有代表性的团队蓝本。第一个是分析型：新闻搜集智能体负责搜信息，情感分析智能体负责判断舆情倾向，队长把两路结果合成一份带观点的简报。这类团队的成员是"工序关系"——前一个的产出是后一个的输入，队长负责串线。

第二个是服务型智能客服团队，结构更立体：快速回复智能体处理简单高频问题（成本低、响应快）；高级客服智能体处理复杂投诉（推理强）；知识库专家智能体应对产品细节咨询（挂向量库查文档）。队长按问题难度与类型分流，活脱脱一个"分级接诊"体系。

            用户咨询
               │
         ┌─────▼─────┐
         │  队长 分流  │
         └──┬───┬───┬┘
   简单高频  复杂投诉  产品细节
            │   │   │
        快速回复  高级客服  知识库专家
        低成本   强推理   检索增强
            └───┼───┘
             汇总回复用户
​

两个蓝本教会同一课：团队设计就是组织设计。先想清楚"这件事一个人干为什么费劲"（要么能力太杂，要么负载太高），再决定按工序拆还是按专长拆。

五、成员设计与队长指令

成员智能体的设计要点是"专且窄"：每个成员一个清晰角色、一组对口工具、一份聚焦的指令。角色名和职能描述要写得让队长好判断——它就是靠这些信息做派单决策的。

队长的指令是团队的运行章程，值得花心思打磨。原始示例给团队写的指令包含"结果必须带信息来源""数据用表格展示"这类全局规则，比给每个成员重复写一遍更干净。队长层面还要定优先级：意见冲突听谁的、时间不够先保哪个、什么情况直接升级人工。

⚠️ 常见坑：成员越多越强的错觉。每加一个成员，队长的调度复杂度、通信开销、出错面都在涨。三个精干成员往往胜过七个定位模糊的成员——先用最小团队跑通，有真实瓶颈再加人。

团队的失败模式与预案

团队跑起来之后，故障的样子和单智能体完全不同，认识几种典型失败模式，出了事才不慌。

派单漂移：问题明明该给知识库专家，队长却派给了快速回复。病因多是角色描述含糊或成员职责重叠。预案：给每个成员写"典型问题示例"进描述，并留一批分流测试题定期回归。

口径打架：两个成员对同一事实给出不同数字，队长随机采信。预案：指令里定证据优先级（实时工具数据高于模型记忆），冲突时显式呈现而非硬选边。

链条断裂：上游成员的产出格式变了，下游解析失败整条流水线停摆。预案：成员间传递一律走结构化格式（字段清单写进两边指令），格式即契约。

成本失控：每个问题都被拆给全部成员，简单问题也走全团队。预案：队长指令里加分级规则——能单点解决的不过团队，并监控每问的成员调用数。

这些预案的共同思路是：团队的可靠性不靠祈祷模型发挥，靠把协作规则写死在指令与格式契约里。设计阶段多写十条规则，运行阶段就少十个深夜告警。

六、常见问题

队长和成员必须用同一个模型吗？

不必，而且经常不该。队长要做任务分解与结果裁决，用推理强的模型；成员干的是检索、格式化这类活，够用的便宜模型即可。按角色配模型，是团队控成本的主要手段。

成员之间能直接对话吗？

取决于编排模式。教程示例走的是"经队长中转"的模式，信息汇拢、责任清晰；更松散的成员直连模式沟通路径短，但容易失控。初学建议从队长中转开始，摸熟后再放开。

怎么调试一个行为古怪的团队？

打开工具调用与成员响应的展示开关，先看队长的派单是否符合预期，再逐个查成员的输入输出。多数"团队变笨"的问题出在角色描述含糊，导致派单错位，而不是模型能力不足。

团队的成本账与规模感

组团队之前算一笔账，能避免大量过度设计。一个三成员团队处理一个典型请求，粗略是：队长一次理解与派单、三个成员各自一到两次推理（含工具调用）、队长一次整合——模型调用量是单智能体的四到六倍，延迟叠加，账单线性上涨。这笔钱买回来的是质量与稳定性：专业分工让每步更准，出错时可以局部重试而不是整轮重来。

值不值，取决于任务的"单价"。每天跑一次的深度研报，质量优先，团队的钱花得值；每分钟几十次的在线问答，单智能体加分级路由才是正解。规模感还可以这样建立：先量化单智能体在你的任务上的错误率，如果它已经能做到九成五，团队带来的边际收益有限；如果只有七成且错误集中在某类子问题上，拆出专门成员攻克它，性价比立刻显现。

另一个常被低估的选项是"伪团队"：把多个智能体按固定流程串行调用，中间没有动态调度。没有派单决策就没有队长开销，行为也更可预测。很多所谓的团队需求，其实一条写死的流水线就够——动态编排留给真正动态的任务。

队长指令的打磨实例

给一段队长指令的打磨过程，感受"指令即制度"的含金量。初版写"请协调成员完成任务"——结果是队长把任务原文转发给所有人，人人都在干重复活。第二版加上"先判断问题类型再派单，每次只派给最合适的一名成员"——分流正确了，但复杂问题没人拆解。第三版补上"复杂任务先分解为子任务列表再逐一派发，简单任务直接处理不过团队"——终于像样了。三轮打磨，每一轮都是被真实失败案例逼出来的规则。

这个过程揭示了团队开发的真实节奏：指令不是设计出来的，是运维出来的。上线初期密集观察派单日志，把每类失败翻译成一条新规则，两周后队长的行为就基本稳定。反之，指望第一版指令就完美、写完就不再看日志的团队，一个月后会发现自己养了一个行为乖张的黑盒。

收尾强调一个心态：团队的复杂度是借来的债，借之前想清楚收益。每当你想加一个成员，先写下"它独有、其他成员给不了的能力"——写得出来再动手，写不出来就先缓缓。这条朴素的纪律，能帮你避开多智能体开发里最常见的那类陷阱：为了架构的完整感，支付真实的性能与维护成本。

温故知新

• 要点一：Team = 协调者 + 专业成员，用户只与 Team 交互
• 要点二：role 是分派依据，写得越具体分派越准
• 要点三：简单任务别组队，团队适合"多能力、强独立"场景
• 要点四：成员职责要正交，避免互相抢活
• 要点五：协调指令明确"先搜后算最后汇总"
• 要点六：show_tool_calls 观察成员执行，便于排查

团队会搭了，下一节把流式输出、会话持久化、结构化响应等高级功能综合实战一次。