smolagents managed_agents，多个小 Agent 怎么分工

01反共识：不是越多 Agent 越好

很多人做多 Agent 系统第一反应是"分得越细越好"——一个 Agent 调研、一个写、一个审、一个发。结果协调成本爆炸，主 Agent 大部分时间在转发消息。

多 Agent 的代价：每多一层 Agent，多一次 LLM 调用、多一轮上下文传递、多一个出错点。协调成本随 Agent 数线性涨，收益却边际递减。所以分多少 Agent，要看任务能不能真的并行——能并行才分，强串行就别硬分。

smolagents 的 managed_agents 给了优雅方案：主 Agent 像调用工具一样调用子 Agent，子 Agent 有自己的工具和上下文，干完返回结果。主 Agent 上下文不被子 Agent 的中间步骤污染——隔离上下文是多 Agent 的核心价值，不是"分工"本身。

02多 Agent 拓扑演示：选任务看该用哪种

选任务类型，看该用 串行 / 并行 / 层级 哪种拓扑。

03三种拓扑的适用边界

• 串行：A 的输出是 B 的输入，必须按顺序。如"调研→写→审"。优点简单可调试，缺点慢、一步错全错。能用单 Agent 就别拆串行。
• 并行：子任务独立，可同时跑。如"同时查三个数据源"。优点快，缺点要等最慢的、结果要合并。适合 IO 密集的独立查询。
• 层级：主 Agent 调度专家子 Agent。如"主 Agent 分配给代码/数据/文档专家"。优点专家上下文隔离、工具专一，缺点主 Agent 调度要准。这是 managed_agents 的主战场。

一个常见坑：把强串行任务硬拆成并行，结果子 Agent 拿不到前置信息瞎猜。先画任务依赖图：能并行的才并行，强串行就老老实实串行或单 Agent。

04带走这套分工清单