Agno多Agent协作：四大核心模式与实战指南

最近在折腾 Agno，发现很多人一上来就问“多 Agent 到底怎么协作”“主从模式怎么写”“子 Agent 怎么共享记忆”。这些问题其实背后的答案非常统一：理解多 Agent 协作，最快的方式是把它当“设计模式”来学——你不需要记住每种花哨的框架术语，只需要掌握几种反复出现的协作套路，剩下的都是套模板。

Agno 是现在比较火的一个 Python Agent 框架，前身是 Phidata，主打模型无关、轻量、Agent + Tool + Memory + Knowledge 一套组合拳。它最大的优势不是某个单一功能，而是对多 Agent 协作的支持非常原生：一个 Agent 可以调用另一个 Agent，多个 Agent 可以组 Team，记忆可以跨 Agent 共享，Session 可以持久化。换句话说，别人还在手工拼多轮 Prompt 的时候，Agno 已经把协作的“基础设施”帮你搭好了。

这篇文章我会从设计模式的视角，把 Agno 多 Agent 协作的几种核心套路一次性讲清楚。适合刚接触 Agent 开发、看过文档但不知道从哪下手的同学，也适合想从单 Agent 进阶到复杂团队协作的老手。全文不绕弯子，直接上代码、上对比、上踩坑记录。

1. 为什么要用设计模式来理解多 Agent 协作

1.1 单 Agent 的瓶颈逼着你必须进化

先说个很现实的问题：单 Agent 不是不能干活，而是扛不住复杂任务。我实测过，当一个 Agent 的工具数量超过 6 个、任务步骤超过 3 步的时候，模型的指令遵循能力会明显下降。它会在工具之间反复犹豫，甚至出现“明明该调用工具，却自己编了一个答案”的情况。

更麻烦的是上下文窗口。你给一个 Agent 塞 10 个工具定义，每个工具描述 100 个 token，再加上系统提示词、历史对话、检索到的知识，一次请求轻松超过 1 万 token。如果任务再复杂一点，比如“先查天气，再根据天气推荐酒店，最后生成行程表”，单 Agent 要把这些逻辑全部塞进一个 Prompt 里，提示词会变得又臭又长，而且一改需求就要改全盘，维护成本极高。

这时候把任务拆给多个 Agent，本质上和把一个大项目拆给多个程序员是一个道理。每个 Agent 只负责一个窄领域，提示词短、上下文干净、工具数量少，单点能力反而更强。而多个 Agent 之间的“配合方式”，就是我们需要沉淀的设计模式。

1.2 设计模式是多 Agent 协作的“通用语言”

GOF 设计模式之所以经典，是因为它给常见问题提供了可复用的解决方案模板。多 Agent 协作也是一样，翻来覆去就那么几种套路：老大分配任务给小弟、输入按路径分发、任务像流水线一样串行处理、一群人围在一起商量出结论。

把这些套路命名、归类之后，你会发现读框架源码、看别人项目、甚至自己设计架构都轻松很多。别人说“我这个是 supervisor 模式”，你立刻知道大概结构；说“我这个是 pipeline”，你也马上能画出数据流。这就是设计模式的价值——不是为了炫技，是为了沟通和复用。

2. Agno 多 Agent 协作的四大核心模式

我梳理下来，Agno 生态里最常见、最实用的协作模式就是四种：主从模式、路由模式、管道模式、团队模式。下面逐一拆解，每种我都给了设计模式类比、适用场景和 Agno 代码示例。

2.1 主从模式：本质上是把子 Agent 当 Tool 调用

先聊主从模式（也叫 Supervisor 模式）。这是我个人最推荐入门的一种，因为它最符合直觉：一个主管 Agent 负责理解用户意图，然后把任务拆解分发给若干个子 Agent，最后汇总结果。

主从模式的核心思想用一句话概括就是：把 subagent 当作另一种形式的 tool 去调用。你仔细想，Agent 调用 tool 的本质是什么？是 Agent 决定“我需要完成某个功能，这个功能由外部模块提供”，然后把控制权交给外部模块，拿到结果后继续自己的推理。子 Agent 完全符合这个定义，只不过它的“功能”更强大，它自己也可以有工具、有记忆、有推理能力。

从设计模式角度看，这非常像外观模式 + 委派模式：主管 Agent 是对外的统一入口（外观），具体实现委托给不同的子模块（委派）。用户不需要知道背后有几个 Agent，他只需要面对一个入口。

python复制from agno.agent import Agent
from agno.models.openai import OpenAIChat

researcher = Agent(
    name="researcher",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责检索技术资料，用中文简洁返回结论，并标注信息来源",
    markdown=True,
)

writer = Agent(
    name="writer",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="擅长撰写结构化报告，逻辑清晰，层次分明",
    markdown=True,
)

supervisor = Agent(
    name="supervisor",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="你是团队主管，根据用户需求拆解任务，分发给合适的成员，最后汇总输出",
    tools=[researcher, writer],  # 子 Agent 直接挂在 tools 上
    show_tool_calls=True,
    markdown=True,
)

supervisor.print_response("帮我调研 Agno 的多 Agent 协作能力，并输出一份技术报告", stream=True)

这段代码里最关键的一行就是 tools=[researcher, writer]。Agno 的 Agent 对象实现了 tool 的接口，所以你可以像挂普通工具一样把子 Agent 挂上去。主管 Agent 会在推理过程中自主决定“这个问题我该先让 researcher 查资料，再让 writer 写报告”，然后依次调用。

我实际跑下来，这种模式的成功率明显高于单 Agent，因为每个子 Agent 的职责非常纯粹。researcher 不需要操心报告格式，writer 也不需要去调检索工具。但要注意一个坑：子 Agent 的 description 一定要写清楚，因为主管 Agent 是靠这段描述来决策“该调用谁”的。描述模糊的话，主管 Agent 可能根本不会调用它，或者用错人。

注意：主从模式的执行顺序并不一定是固定的。如果你的任务必须严格“先查后写”，最好在 supervisor 的 description 里明确说明执行顺序，或者在 Prompt 里写清楚，否则模型可能打乱流程。

2.2 路由模式：按任务类型分发到对应 Agent

路由模式的核心思想是“分类而后治”：有一个路由器 Agent 先分析输入，判断这个请求属于哪个领域，然后把它完整地交给对应的下游 Agent 处理。和主从模式最大的区别是：主从模式是“拆解后分发给多个 Agent + 汇总”，路由模式是“判断后整体交给一个 Agent，不做汇总”。

设计模式上可以类比策略模式 + 工厂模式：路由器根据输入动态选择策略，工厂根据条件创建/选择具体的处理者。这种模式非常适合客服系统、工单分类、内容审核这类场景——输入类型差异很大，每种类型有专门的处理流程。

Agno 的 Team 提供了内置的 mode="route"，可以直接实现路由模式。注意看下面这个例子：

python复制from agno.team import Team
from agno.agent import Agent
from agno.models.openai import OpenAIChat

billing_agent = Agent(
    name="billing",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责处理账单、退款、发票相关的问题",
)

tech_agent = Agent(
    name="tech",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责处理产品使用、报错、配置等技术问题",
)

general_agent = Agent(
    name="general",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责处理其他杂项咨询",
)

support_team = Team(
    name="support",
    mode="route",  # 路由模式
    members=[billing_agent, tech_agent, general_agent],
    model=OpenAIChat(id="gpt-4o-mini"),
    show_tool_calls=True,
    markdown=True,
)

support_team.print_response("我上个月被多扣了 50 块钱，怎么申请退款？", stream=True)

mode="route" 模式下，Team 会有一个内置的路由逻辑，根据每个 member 的描述决定把整个用户请求交给谁。这个模式的实现成本很低，但效果非常依赖成员 Agent 的描述质量。

我自己写路由模式的时候习惯在每个成员描述里加几个“触发词”，比如 billing 的 description 里写“当用户提到账单、扣费、退款、发票时优先处理”，这样路由准确率会高很多。纯靠模型自己悟，遇到边界情况容易分错。

2.3 管道模式：上一个 Agent 的输出是下一个 Agent 的输入

管道模式（Pipeline）是一种串行处理模式。任务被分解成若干个阶段，每个阶段由一个 Agent 负责，前一阶段的输出作为后一阶段的输入，最终产出结果。就像工厂流水线，原料经过一道道工序变成成品。

设计模式上，管道模式非常像责任链模式：每个节点只关心自己的处理逻辑，处理完交给下一个节点，链路清晰，职责单一。这种模式特别适合内容生成流水线：先分析需求，再搜集素材，然后撰写初稿，最后润色校对。

Agno 实现管道模式最直接的方式是纯代码编排，也就是手动把每个 Agent 串联起来。因为 Agno 的 Agent.run() 返回的是 RunResponse，里面有 content 字段，你可以把上一个 Agent 的结果拼到下一个 Agent 的 prompt 里：

python复制from agno.agent import Agent
from agno.models.openai import OpenAIChat

analyst = Agent(
    name="analyst",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="分析用户的写作需求，输出结构化大纲",
)

drafter = Agent(
    name="drafter",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="根据大纲撰写初稿，语言流畅，内容详实",
)

editor = Agent(
    name="editor",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="对初稿进行润色和校对，修正逻辑问题",
)

# 第一步：需求分析
step1 = analyst.run("用户想写一篇关于分布式系统的科普文章，目标读者是初中级工程师")
outline = step1.content

# 第二步：大纲传给 drafter 写初稿
step2 = drafter.run(f"请根据以下大纲撰写初稿：\n{outline}")
draft = step2.content

# 第三步：初稿传给 editor 润色
step3 = editor.run(f"请对以下初稿进行润色和校对：\n{draft}")
final = step3.content

print(final)

管道模式的最大优势是每个 Agent 的上下文都很短。editor 只需要看初稿，不需要关心用户最初的需求；drafter 只需要看大纲，不需要看原始对话。这能显著节省 token，也能降低模型被无关信息干扰的概率。

但管道模式也有一个短板：误差会累积。如果 analyst 生成的大纲质量差，后面 drafter 和 editor 再怎么努力也救不回来。所以在每个阶段我建议加一层“质量检查”，用规则判断输出是否符合预期（比如长度阈值、关键词是否出现），不符合就重跑当前阶段。

2.4 团队模式：多个 Agent 平级协作，共享上下文

团队模式是最灵活也最难控制的一种。它模拟的是“一群人围在会议室里讨论”的场景：多个成员 Agent 平级，可以互相传递任务，也可以共享上下文，最终得出一个集体结论。

在 Agno 中，对应的是 mode="collaborate" 的 Team。这种模式下，成员之间可以通信，一个成员可以把自己的中间结果分享给另一个成员，也可以继续追加任务。设计模式上接近中介者模式 + 黑板模式：Team 是中介者，统一管理成员之间的消息传递；上下文是黑板，各成员往上面写自己的成果，也从上面读别人的成果。

python复制from agno.team import Team
from agno.agent import Agent
from agno.models.openai import OpenAIChat

planner = Agent(
    name="planner",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责将旅行需求拆解为具体可执行的任务清单",
)

weather_agent = Agent(
    name="weather",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责查询目的地未来 7 天天气并给出穿衣建议",
)

hotel_agent = Agent(
    name="hotel",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责查找符合条件的酒店，比较价格、位置和评价",
)

route_agent = Agent(
    name="route",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责规划每日行程路线，平衡景点与交通时间",
)

trip_team = Team(
    name="travel_planner",
    mode="collaborate",  # 协作模式
    members=[planner, weather_agent, hotel_agent, route_agent],
    model=OpenAIChat(id="gpt-4o-mini"),
    enable_agent_communications=True,  # 开启成员间通信
    success_criteria="所有成员完成分工后，输出完整行程表",
    show_tool_calls=True,
    markdown=True,
)

trip_team.print_response("帮我规划一个北京 3 日游，预算 3000 元以内", stream=True)

团队模式看起来很美好，但我要泼一盆冷水：它是四种模式里最容易失控的一种。我在实战中遇到过成员之间来回对话停不下来、互相重复发起任务、甚至为了一个小问题争论五六轮的情况。原因很简单，模型并没有“适可而止”的意识，它只会机械地响应收到的消息。

所以团队模式有两个必要条件：一是 success_criteria 要写清楚，让框架知道“什么时候算完”；二是 enable_agent_communications 这个开关要谨慎使用，一般商业场景用主从或路由就足够了，团队模式更适合研究、头脑风暴型的场景。

2.5 四种模式的横向对比

把四种模式放在一起对比，会更清楚它们的差异：

选型建议很简单：能单 Agent 解决的绝不上多 Agent；必须多 Agent 时，优先主从和路由；流程固定用管道；只有你确实需要多个 Agent 自由讨论、互相补充信息时，才考虑 collaborate 模式。

3. 多 Agent 共享记忆：Agent 之间到底怎么记得住上下文

3.1 Agent 记忆的本质是什么

很多人在多 Agent 协作里都会被“记忆”这个词搞晕。这里的记忆其实分两层：短期上下文和长期记忆。短期上下文就是对话过程中的 messages 列表，Agent 靠它理解当前对话发生了什么；长期记忆则需要持久化存储，通常存到数据库里，下次会话可以重新加载。

Agno 对长期记忆的实现方式是 Memory + Storage。Memory 负责组织和管理记忆内容，Storage 负责把记忆持久化到数据库（默认支持 SQLite、Postgres 等）。你可以把 Session 理解成一次会话的“档案袋”，里面装着这个会话的所有消息、Agent 的状态、记忆摘要。

3.2 同一个 Agent 内部的会话记忆

最简单的情况是单个 Agent 跨多轮对话记住历史。这时候只需要给 Agent 配置一个 Storage，并开启 add_history_to_messages 或者对应的历史记录参数。示例如下：

python复制from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.storage.agent import AgentSessionStorage

# 新版 Agno 的 storage 命名空间
storage = AgentSessionStorage(
    table_name="agent_sessions",
    db_url="sqlite:///agents.db",
)

agent = Agent(
    name="assistant",
    model=OpenAIChat(id="gpt-4o-mini"),
    storage=storage,
    add_history_to_messages=True,  # 自动把历史消息加到请求里
    markdown=True,
)

agent.print_response("我叫小明，是一名后端工程师")
agent.print_response("我叫什么名字？是什么职业？")

第二次提问时，Agent 能从 storage 里加载 session_id 对应的历史消息，所以能正确回答“小明，后端工程师”。如果你的 Agno 版本比较旧，storage 可能在 agno.storage.session.memory 下面，叫 MemorySessionStorage，用法类似，只是路径不同。建议以官方文档为准。

3.3 跨 Agent 共享记忆的两种方案

跨 Agent 共享记忆稍微复杂一点。第一种方案是把同一个 Storage 传给多个 Agent。比如我让两个 Agent 共用一个 SQLite 表，它们的会话历史都存在同一张表里，按 agent_id 区分。这样 Agent A 写入的记忆，Agent B 在加载属于自己的 session 时并不会有直接感知。

第二种方案是通过共享的 Knowledge（知识库）而不是 Memory。记忆是对话历史类的临时信息，知识是结构化的长期知识。如果你想实现“Agent A 告诉 Agent B 一个重要结论”，更靠谱的做法是把 A 的产出写入一个共享的向量库，B 通过检索获取。Agno 里的 Knowledge 支持多种向量数据库，比如 LanceDB、Pinecone。

这里有个常见的认知误区：很多人以为给两个 Agent 配同一个 storage 就等于“共享记忆”，实际上两个 Agent 的 session_id 不同、agent_id 也不同，它们各自加载各自的会话历史，并不会自动感知对方写了什么。真正的“共享”需要你显式地做信息传递，比如把 A 的 RunResponse.content 作为上下文传给 B，或者把结论写入向量库让 B 检索。

我在实际项目里的做法是：主从模式下，主管 Agent 负责显式地把子 Agent 的产出拼接进最终 Prompt；协作模式下，靠 Team 的上下文共享机制传递信息，但主流程的关键结论一定要落在最终输出里，不能指望成员之间的“潜移默化”。

3.4 共享记忆的命名空间设计

如果你在一个系统里复用同一个 Storage，给每个 Agent 和每个 Session 起名字的时候一定要有清晰的命名规范。我习惯的规则是：

这样做的原因是排查问题时非常爽。你可以直接去 SQLite 里查询某个 session 的所有消息，看看到底是哪一步把上下文带偏了。共享记忆出问题的时候，能够在数据库层面看到原始消息，比在黑盒里猜快得多。

注意：同一个 Agent 如果 add_history_to_messages=True，每次请求会把整个 session 的历史消息全部塞进 context。会话越长，token 消耗越大，响应越慢。建议定期做历史摘要或截断，保留最近 N 轮，把更早的对话压缩成摘要存到 Knowledge 里。

4. 实操：从零搭一个“主管 + 三个子 Agent”的调研助手

4.1 场景定义与模块划分

这一段我带你完整跑一个真实项目：构建一个“技术调研助手”，用户输入任何技术问题，它自动完成“收集资料 -> 数据分析 -> 输出报告”的流程。

模块划分为三个子 Agent 加一个主管：

• collector：负责搜索和收集信息，它挂了两个工具（网络搜索 + 本地知识库检索）。
• analyst：负责分析原始资料，提取关键信息和趋势。
• writer：负责把分析结果写成结构化的 Markdown 报告。
• supervisor：负责接收用户请求，按顺序调度上面三个子 Agent，并汇总输出最终报告。

我选择主从模式而不是管道模式，是因为用户的需求可能不是固定的“收集->分析->报告”。比如用户可能只想要资料清单，不想看报告；也可能直接给一段现成资料让 analyst 分析。主管 Agent 的灵活性在这种场景下更有价值。

4.2 完整代码实现

python复制from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools
from agno.knowledge.pdf import PDFKnowledgeBase
from agno.vectordb.lancedb import LanceDb

# 子 Agent 1：信息收集
collector = Agent(
    name="collector",
    model=OpenAIChat(id="gpt-4o-mini"),
    tools=[DuckDuckGoTools()],
    description="负责收集与问题相关的技术资料，包括搜索结果和内部知识库内容。"
                "输出为原始信息列表，不用做总结",
    markdown=True,
)

# 子 Agent 2：数据分析
analyst = Agent(
    name="analyst",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责分析原始资料，提炼关键信息、对比差异、指出趋势。"
                "输入是资料列表，输出是分析结论",
    markdown=True,
)

# 子 Agent 3：报告撰写
writer = Agent(
    name="writer",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="负责将分析结论撰写为结构清晰的技术报告，"
                "包含背景、核心发现、结论与建议四个部分",
    markdown=True,
)

# 主管 Agent
supervisor = Agent(
    name="supervisor",
    model=OpenAIChat(id="gpt-4o-mini"),
    description="你是技术调研主管。根据用户需求，依次调用 collector 收集资料、"
                "analyst 分析资料、writer 撰写报告。"
                "如果用户只需要某个环节，也可以只调用对应成员。"
                "最终把结果汇报给用户。",
    tools=[collector, analyst, writer],
    add_datetime_to_context=True,
    show_tool_calls=True,
    markdown=True,
)

supervisor.print_response("帮我调研一下 Agno 框架的多 Agent 协作机制，并输出调研报告", stream=True)

4.3 运行效果与关键参数解析

我实际跑了一遍这个任务，主管 Agent 的输出过程是这样的：

1. supervisor 收到用户请求，判断需要完整流程。
2. supervisor 先调用 collector，DuckDuckGoTools 搜索 Agno 多 Agent 相关资料，返回一些链接和摘要。
3. supervisor 把 collector 的输出作为输入，继续调用 analyst，要求分析这些资料的关键点。
4. supervisor 再把 analyst 的输出交给 writer，生成完整报告。
5. supervisor 最终把 writer 生成的 Markdown 报告返回给用户。

这里有两个参数值得单独说明。第一个是 add_datetime_to_context，它会在给模型的上下文里加入当前时间。别小看这个参数，如果子 Agent 搜索结果涉及“最新版本”这类时效性信息，没有时间概念它会给你过时的答案。第二个是 show_tool_calls=True，调试阶段强烈建议打开，它能在终端展示每次工具调用的细节，便于你观察 supervisor 到底是不是按预期顺序调度的。

提示：第一次运行建议在终端以 stream=True 输出，你会看到完整的调用链路。我踩过的坑是，如果不开 show_tool_calls，整个流程像一个黑盒，出了问题根本不知道是 collector 搜索失败还是 analyst 分析跑偏。

4.4 这个架构里的使用心得

跑通这个 demo 之后，我总结了几个实际项目里非常有用的经验：

第一，子 Agent 只给最少的工具。collector 只给搜索工具，不给分析工具；analyst 只给分析能力，不给搜索工具。工具越多，选择越纠结，就越容易出错。

第二，chain-of-thought 不要过度约束。主管 Agent 的 description 里我写了“依次调用”，但加了“如果用户只需要某个环节，也可以只调用对应成员”。这种“软约束”比硬性规定灵活得多，实际跑下来应对各种请求的容错性更好。

第三，控制子 Agent 的数量。我的经验是，同层次的主从模式下 3 到 5 个子 Agent 是最优区间。少于 3 个不如单 Agent 直接写，多于 5 个主管 Agent 的任务拆解和结果汇总都会变得困难，响应时间也会明显变长。

第四，输出的格式规范要统一。比如我要求 analyst 输出“结论 1、结论 2”这样的编号列表，要求 writer 按“背景、核心发现、结论与建议”四个部分写报告。这样主管 Agent 汇总时不需要做太多格式转换，只需直接拼接，减少出错机会。

5. 常见问题与排查技巧实录

多 Agent 开发里踩坑是必然的，下面几个问题是我在 Agno 项目中遇到频率最高的，整理成速查表方便你排查。

5.1 子 Agent 完全不执行

我遇到最多的情况就是 description 写得含糊。比如你只写“负责收集资料”，模型可能觉得“我也能收集资料啊，为什么还要调用别人”。改成“你只能负责收集资料，收集后返回原始列表，不要做任何总结分析”，调用率会显著提升。

5.2 Agent 之间出现循环对话

collaborate 模式下最容易出现这种情况：成员 A 收到 B 的消息后，回复了一条消息，B 又回一条，A 再回一条，循环停不下来。我见过最夸张的一次，两个 Agent 因为“确认是否完成任务”来回聊了 8 轮。

解决办法有三个优先级：

1. 在 success_criteria 里写清楚“什么时候必须停止，输出最终结果”。
2. 把 enable_agent_communications 关掉，改用主从模式。
3. 在成员 description 里加上“不要重复确认，不要回复无关消息”。

如果已经在线上跑了，应急手段是给 Team 加一个超时或者最大轮数限制，虽然 Agno 内置不一定完美支持，但可以通过外层代码控制，比如发请求后设置超时时间，超时就强制返回当前结果。

5.3 记忆混乱：Agent 回答了另一个 Agent 的内容

这种情况本质上是因为你的记忆隔离没做好。检查下面三件事：

• 每个 Agent 是否配置了独立的 agent_id？如果两个 Agent 共用同一个 agent_id，它们会加载彼此的会话历史。
• 是否用了同一个 Session 但不同的 Agent？如果你手动指定了相同的 session_id 给不同 Agent，也会导致上下文串场。
• 知识库里是否混入了不该出现的文档？多个 Agent 共享同一个向量库时，最好用 namespace 或 collection 隔离不同领域的数据，否则检索结果可能互相污染。

我给自己的项目定的铁律是：每个 Agent 一个独立的 agent_id，每个用户会话一个独立的 session_id，每个知识领域一个独立的 collection，三者绝不复用。

5.4 Token 消耗飙升

多 Agent 协作的 token 消耗，是单 Agent 的好几倍。主从模式下，一次完整调研可能要触发 4 次 LLM 调用（1 次主管 + 3 次子 Agent），而且主管的请求里带着所有工具定义，子 Agent 的请求里也要重复传入它们的系统提示词。一次任务消耗 5 万 token 是很正常的事情。

控制成本的几个实操经验：

5.5 排查思路：从日志到数据库的全链路追踪

最后说一个排查的通用思路。遇到多 Agent 问题，不要靠猜，按下面顺序做：

1. 开启 show_tool_calls=True，看终端的调用链，确认每个 Agent 被调用的顺序和参数。
2. 看数据库里的 session 记录，确认消息的完整流转过程。
3. 单独把子 Agent 拎出来测试，输入主管给它的那一段内容，看它单点是否正常工作。
4. 如果子 Agent 没问题，再检查主管的 description 和工具描述，大概率是调度层的 prompt 出了问题。

这套思路能覆盖我遇到的 90% 以上问题。多 Agent 系统的复杂度是线性的，但排查难度是乘级的，数据链路清晰比什么都重要。

6. 根据我个人经验，给你几个选型建议

最后说点掏心窝子的话。我从单 Agent 转到多 Agent 协作，走了不少弯路，最深的体会就是：复杂系统不是设计出来的，是控制出来的。设计模式只是给你一张地图，真正决定项目成败的是你对每个 Agent 边界、每段上下文流转的控制力。

如果你现在正准备动手，我的建议是先别碰 collaborate，从主从模式开始。主从模式的成功率最高、心智负担最小、也最容易排查问题。等团队里每个 Agent 的能力都被验证过、边界都清晰了，再逐步尝试路由和管道。至于 collaborate 模式，建议放在一两个明确需要“头脑风暴”的环节里，不要让它成为系统的主干。

另外一个重要的建议是：及时清理无用的记忆和会话。我见过太多人测试的时候跑了几十个 session，全部堆在 SQLite 里，最后查问题的时候分不清哪些是有效数据，哪些是垃圾数据。我会给自己定一个习惯，每次迭代后清理测试会话，只保留几个 golden case 用来回归验证。这样既能保证数据干净，也能让后续调优更高效。

选型没有绝对的对错，只有合适不合适。希望这篇文章能让你对 Agno 多 Agent 协作有一个清晰的地图，少踩一些我踩过的坑。