马蕾医生先聊一个比较反直觉的认知：在 Multi-Agent 系统里，SubAgent 并不是和主 Agent 平起平坐的“同事”，它更像一个被封装好的特殊工具。我在用 Microsoft Agent Framework 搭建多智能体项目时最大的体会就是，主从模式（Hierarchical）本质上是把 SubAgent 当作另一种 Tool 来调用，主 Agent 负责拆解任务、调度分工，SubAgent 负责完成某个具体子任务并把结果交回来。这个思路一旦想通，后面很多设计决策都会顺很多。这篇文章我会从一个实际的多智能体客服项目出发，拆解 SubAgent 的原理、常见类型、注册方式，以及我在状态传递、上下文控制和成本优化上踩过的坑。如果你正准备用 Microsoft Agent Framework 做多 Agent 编排，或者只是想把已有的单 Agent 应用改造成多智能体结构，这篇应该能帮你少走不少弯路。
1. 为什么需要 SubAgent：主从模式与工具化思维
1.1 主 Agent 与 SubAgent 的分工逻辑
单个 Agent 的能力边界其实很容易摸到。当你的系统里同时要处理订单查询、退款判断、物流追踪、客户投诉分类，如果把这些指令和工具全部塞进同一个 Agent 的 System Prompt 里，结果往往是谁都做不好。模型在每轮推理时都要面对一大坨互相干扰的工具描述和规则，选错工具的概率会明显上升，上下文也很快被撑满。
这就是 SubAgent 存在的意义：它把复杂系统拆成“一个大脑 + 多个专业执行者”的结构。主 Agent 只负责理解用户意图、拆解任务、决定下一步调用谁；SubAgent 则各自维护独立的指令、工具、模型甚至记忆。你可以把主 Agent 理解成项目经理，SubAgent 是不同工种的专家。项目经理不需要会写代码，他只需要知道“这个活该找谁”，然后把需求丢给专家，最后把专家交付的结果整合给客户。
用 Microsoft Agent Framework 做这种主从结构非常直接。主 Agent 的指令里可以写清楚“遇到订单问题就调用订单查询 Agent，遇到退款问题就调用退款 Agent”，框架会在模型推理时自动把 SubAgent 暴露成可调用的对象。我刚开始设计时还是习惯性地把所有业务规则写在主 Agent 里，后来发现，规则越多，主 Agent 越“糊涂”。真正稳定的做法是把规则下沉到各个 SubAgent，主 Agent 只保留路由信息。
1.2 把 SubAgent 当作特殊 Tool 来设计
这是我这次项目里最重要的一条经验：SubAgent 本质上就是 Tool 的变体。 普通 Tool 是一段确定性的代码函数，输入参数、返回结果都由你自己控制；SubAgent 则是一个由模型驱动的、内部可以包含多轮推理和工具调用的“智能函数”。但从主 Agent 的视角看，两者完全一样——都是给模型一个名字、一段描述、一组参数，模型决定要不要调用它，调用完拿到结果，然后继续自己的推理。
这个视角有一个实际的好处：你在设计 SubAgent 的对外接口时，可以完全参照设计 Tool 的方式。名字要短、描述要清楚、参数要结构化、返回值要统一。我之前犯过一个很典型的错误：把一个 SubAgent 的 description 写成了产品说明书，密密麻麻介绍了这个 Agent 背后的团队、数据来源和技术实现。结果主 Agent 在决策时经常抓不住重点，偶尔还会因为描述里包含其他关键词而选错 Agent。后来我把 description 改成第一句话就说明“在什么情况下使用”，效果立刻好了很多。
本质上，SubAgent 的 description 是给模型看的，不是给人类看的。模型通过描述来判断“当前用户问题是否匹配这个 Agent 的职责”。所以描述应该像函数注释一样，重点写清楚输入条件和使用边界，而不是写背景故事。
1.3 什么场景适合 SubAgent，什么场景不适合
主从模式并不是万能解。我见过有人为了炫技，把一个“计算两数之和”的逻辑也包成 SubAgent，结果延迟高了十倍，成本也高了十倍，收益却为零。SubAgent 这种结构适合解决的是“需要模型理解力”的子任务，而不是“固定规则”的子任务。
适合的场景有几个共同点：首先是任务边界清晰，比如订单查询和退款申请是两套完全不同的流程，彼此之间不需要共享太多运行时状态；其次是子任务本身有复杂度，可能需要多轮推理、需要调用自己的工具、甚至需要和用户确认信息；第三是主 Agent 不需要关心子任务内部怎么执行，只需要拿到最终结果。
不适合的场景也很明显：任务简单固定、对延迟和成本极度敏感、子任务之间需要频繁共享大量动态变量。这些情况用普通 Tool 更合适。下面这张表是我在项目里用的判断逻辑，基本能覆盖大多数情况。
| 维度 | 普通 Tool | SubAgent |
|---|---|---|
| 内部实现 | 代码固定 | 模型推理 |
| 上下文消耗 | 低，只输入输出 | 高，自带指令和工具描述 |
| 延迟 | 毫秒级 | 秒级起步，多一次模型调用 |
| 调试难度 | 低，直接看函数 | 高，要查模型中间输出 |
| 适用任务 | 稳定可复现的规则操作 | 多变、需要理解力和判断力的任务 |
| 替换成本 | 低，改代码即可 | 高，改提示词后还要回归测试 |
我在客服项目里最后的结论是：能用普通 Tool 完成的功能，不要轻易上 SubAgent。SubAgent 的价值在于它内部有“智能”，如果子任务本身不需要智能，那它就只是给系统增加延迟和成本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与最小工程骨架
2.1 安装与版本选择
Microsoft Agent Framework 目前的迭代速度非常快，版本和兼容性需要认真对待。我建议在虚拟环境里安装，避免和项目里的其他依赖冲突。以 Python 环境为例，安装命令大概是：
bash复制pip install microsoft-agent-framework
不过这里要特别提醒一句：不同版本的框架对 Agent 的初始化参数、Host 运行方式甚至模型输出格式的兼容性都不太一样。我最早随手装了最新版，结果发现旧项目里用的 instructions 字段在某个版本被改名成了 system_prompt，整个项目