技术知识库 · 架构设计 · · 国科智飞 Gavin

用微软生态搭多智能体系统：官方路径整理

微软把多智能体拆成了三件事：连接代理做编排、MCP 管工具、线程日志与身份体系管治理。本文是官方文档的整理与解读。

本文基于微软开发者社区博客（Microsoft Tech Community）的文章《使用微软构建多智能体 AI 系统》（作者 Lee Stott，2025 年 9 月 18 日）与 Azure AI Foundry 官方文档整理，正文是我们的梳理与解读，架构判断与案例归微软原文。文中引用的数字均来自原文及其引用的 Anthropic 研究，我们未做独立复测。

什么时候值得上多智能体

构建单个 AI 代理通常不难，难的是让它应对现实流程。深入研究、企业工作流自动化、多步骤客户服务这类任务，涉及频繁的上下文切换和多种专业知识，单个聊天机器人很难同时具备。多代理系统把工作分配给专业代理并保持协调，原文给出四个收益：

原文引用 Anthropic 的研究作为佐证：多代理系统在一次评估中正确回答的问题比单代理方法多出约 90%；代价是 token 消耗约为普通单次聊天会话的 15 倍。微软的观察类似——多代理更耗资源，是否采用，要让任务价值证明成本合理。

参考架构：主代理编排

微软的方案是协调者—工作者模式，在 Azure AI Foundry 中落地为连接代理（Connected Agents）：主代理理解用户请求、拆分成子任务、委派给专业代理，子代理并行工作后把结果回报，主代理整合并决定是否继续探索，直到生成最终答案。

每个代理由三个核心部分组成：说明（定义目标、角色和约束的提示词）、模型（驱动推理的 LLM）、工具（搜索、数据库、API 等外部能力）。关键设计是：主代理用自然语言的推理来分配任务，而不是硬编码 if/else 编排树——"你，代理 A，做 X；你，代理 B，做 Y"，平台负责其余的消息传递、工具调用重试和对话日志。

原文给的例子是销售准备助手：主代理带着四个子代理工作，市场调研代理查行业趋势和新闻，竞争分析代理查竞争对手与市场地位，客户洞察代理从 CRM 数据总结客户历史，财务分析代理审查财务表现，最后由主销售助理综合成简报。原文的判断是：专注的小代理并行工作，比一个 AI 全包更快、质量更高，而且扩展更容易——要新增一个合规监管代理，直接插入即可。

工具与 MCP

企业代理必须外接知识来源和业务动作，微软强调一个丰富的工具集成层。其中最关键的是 MCP（模型上下文协议）：工具集中定义在工具服务器上，包括描述和端点，代理在运行时动态发现可用工具，SDK 生成调用存根。带来三点好处：

一个经验教训是：工具描述决定成败。描述含糊或互相重叠时，代理会选错工具。原文举例说，代理曾固执地查询内部知识库，而信息其实只存在于公网——仅仅因为工具提示让网络搜索看起来不那么相关。解决办法是精心策划工具描述，甚至建一个内部"工具测试代理"自动试用工具、给出更好的描述。多模态也按同样思路接入：视觉模型要么作为专业代理，要么作为可调用的工具。

可靠性与企业治理

可观测性：多代理链路非确定性，每次运行路径都可能不同，不能当黑箱对待。Foundry 把代理之间和与用户之间的每条消息、每次工具调用和结果都记录到结构化线程日志，可与 Application Insights 集成，实时监控性能、延迟、错误和 token 消耗。原文提到，一次流程异常通过回放日志发现两个子代理职责重叠、重复取数，随即重新界定角色；AutoGen 与 AutoGen Studio 则提供指标跟踪、消息追踪和可视化调试，可以暂停代理或即时调整行为。

协调与状态管理：代理变多后，协调和共享上下文会变难，早期原型甚至出现过两个代理互相交还控制权、毫无进展的退化循环。除了连接代理这种即席委派，Foundry 还提供更结构化的"多代理工作流"，显式定义状态、转换和触发器，适合长时运行或关键流程——原文举的例子是"验证 → 配置 → 通知"的入职流程，工作流引擎保证当前状态的代理都完成且条件满足后才进入下一状态，并支持持久化等待与恢复。简单任务用连接代理，需要确定性顺序时用工作流编排。

信任与治理：所有输出经过内容过滤器，防住不当内容和提示注入；代理身份由 Microsoft Entra ID 管理，RBAC 限定其可访问的数据与 API，每个动作可归因、可审计；企业部署可以让代理跑在隔离网络里，并使用客户管理的存储与索引控制数据边界。原文举例说，财务分析代理被配置为不输出特定 PII，检测到监管合规问题时停止并转人工。完整推理轨迹和来源引用，是受监管行业能接受多代理决策的前提。

性能与成本：尽量并行——主代理同时启动多个子代理，代理本身也支持批量并行工具调用；原文引用 Anthropic 的报告称并行把研究任务时间最多缩短约 90%，微软观察到类似量级。同时要防止"代理蔓延"：简单查询单代理处理，中等复杂 2–3 个，只有真正复杂的项目才动用十几名"专家"。模型也不必都用最大号，便宜模型做数据提取、更强模型做最终合成，是控制成本的常见做法。

最佳实践

多代理的提示工程是另一个难度级别。不光要管单个代理的行为，还要塑造代理之间的互动。原文推荐"像你的代理一样思考"：调试时从每个代理的视角逐步回放对话，找出它为什么做出愚蠢的选择；给协调者明确的委派指导，比如为两个研究代理指定不同的目标和背景，减少重复劳动和覆盖盲区。

让 AI 参与自我改进。让代理批评自己的输出或计划，或者设一个"法官"代理按准确性、完整性等标准评估最终答案，反馈往往能指出偏离轨道的位置，加快迭代。

知道何时简化。如果带智能提示的单代理能可靠完成任务，就用单代理。只有并行探索、专业知识差异或长推理拆分带来明显收益时，多代理才是正确选择。

小结

微软的路径可以概括为：用连接代理做低门槛的即席编排，用多代理工作流管高确定性流程，用 MCP 管工具，用线程日志和 Entra ID 做可观测与治理，再按任务价值控制代理数量和模型成本。原文强调这套能力已在 Azure AI Foundry 上以预览形式提供，可直接作为企业多智能体系统的起点。我们的补充判断是：如果团队当前并没有明确的多步骤、多领域任务，先把单代理做扎实更划算——多代理的收益和资源消耗，需要放在一起算账。

参考来源