Agno 多 Agent 团队模式
Agno 多 Agent 团队模式
学习目标
本章将分析 Agno 的多 Agent 团队系统:
- Team 类的三种协作模式(路由/并行/协作)
- 嵌套团队(Team 中包含 Team)
- 独立的 session、存储和记忆管理
- 父/子团队层级关系
前置知识
建议先阅读:
- 多 Agent 路由与隔离 — Agent 隔离与消息路由
- 编排器模式 — 多 Agent 编排模式
下文假设你已理解上述概念,直接聚焦 Agno 的具体实现。
项目实践
Team 类与三种模式
Agno 的 Team 类管理一组 Agent 或嵌套 Team 的协作:
# 伪代码:Team 定义team = Team( members=[agent1, agent2, agent3], model=OpenAIResponses(id="gpt-4o"), mode="route", # 或 "parallel" / "collaborate" name="research_team",)三种 TeamMode:
| 模式 | 行为 | 适用场景 |
|---|---|---|
| route | Team 路由 Agent 分析输入,选择最合适的成员执行 | 多领域专家,需要智能路由 |
| parallel | 所有成员并行执行,结果合并 | 多视角分析、并行搜索 |
| collaborate | 成员按顺序协作,每个成员的结果传递给下一个 | 流水线处理、多步推理 |
嵌套团队
Team 的成员可以是其他 Team,实现层级编排:
# 伪代码:嵌套团队research_team = Team(members=[researcher, analyst], mode="collaborate")review_team = Team(members=[reviewer1, reviewer2], mode="parallel")
super_team = Team( members=[research_team, review_team, writer], mode="route",)层级关系:
- 子 Team 的
parent_team_id自动设置为父 Team 的 ID - 子 Team 有独立的 session、存储和记忆
- 父 Team 的路由决策可以路由到子 Team 或平级 Agent
独立 Session 管理
每个 Team 和每个 Agent 都有独立的 session:
# Team session 与成员 session 的关系TeamSession( team_id="team_123", member_sessions={ "agent_1": AgentSession(agent_id="agent_1", ...), "agent_2": AgentSession(agent_id="agent_2", ...), },)为什么独立?
- 每个成员的对话历史和状态不同
- 团队成员可以在不同的 session_id 下复用
- 便于调试——可以单独查看某个成员的 session 历史
Team 的配置继承
Team 的配置会传递给成员:
# 伪代码:配置继承team = Team( members=[agent1, agent2], model=OpenAIResponses(id="gpt-4o"), # 成员共享默认模型 db=PostgresDb(db_url="..."), # 成员共享数据库 instructions="你是研究团队的成员。", # 追加到成员的系统提示)成员可以覆盖团队级别的设置(如使用不同的模型)。
问题与规避
1. 嵌套团队的调试困难
多层嵌套 Team 的执行流程难以追踪。
规避:
- 每个 Team 和 Agent 有独立的
id,日志中可追溯 store_events=True持久化事件流,可以重放执行过程- Team 的
parent_team_id提供层级关系
2. 并行模式的结果合并
parallel 模式下多个 Agent 的结果如何合并?
规避:Team 的路由 Agent(或合并逻辑)负责将并行结果整合为统一输出。合并策略取决于具体实现。
3. 团队成员之间的通信
collaborate 模式下,成员之间如何传递中间结果?
规避:通过 Team 级别的 session 和消息传递。每个成员的结果作为下一条消息的上下文传递给下一个成员。
设计取舍
为什么 Team 有自己的模型?
优势:Team 级别的路由决策需要模型(决定路由到哪个成员),独立于成员的模型 代价:增加一次额外的 LLM 调用(route 模式) 替代方案:使用规则路由(而非 LLM)——更快但不够灵活
为什么支持嵌套团队?
优势:可以构建复杂的多层级编排(研究团队 → 审核团队 → 写作) 代价:调试困难,执行流程不直观 替代方案:扁平团队 + Workflow 编排——更透明但需要更多手动配置