把 copilot 从简单问答升级成真能干活的助手，我很快撞上一堵墙：单个智能体应付不了那种要走好几步、还跨领域的任务。当你指望一个 copilot 同时做推理、读实时数据、又要遵守各领域自己的规则时，问题就冒出来了，比如排障流程、汇总多个系统的洞察，或者把好几条业务线的信息揉到一起。

多智能体编排的思路，是让 copilot 把活儿分给专门的智能体，同时留一个统一的决策层。下面这套编排器—专家（orchestrator–specialist）模式来自真实的客户实践，我照着在 Microsoft Copilot Studio 里从头走了一遍，顺带用 Activity Map 这类内置工具验证了智能体之间到底有没有好好协作。

为什么要用多智能体编排

团队愿意上编排器模式，理由挺实在。第一是可组合，把一个庞杂任务拆成财务、HR、ITSM 这类各管一摊的小智能体。拆开之后治理也顺了，每个专家智能体归它对应的领域团队所有，上线、更新、下线都由懂行的人把关。复用是另一个好处，同一个专家智能体能被多个 copilot 直接调用，逻辑不用再抄一遍。可观测性来自编排器这个唯一的决策层，活动地图会告诉你这次到底路由到了哪个智能体。最后是规模，护栏统一的前提下，团队可以一路扩到几十个智能体。

架构是怎么跑起来的

Copilot Studio 里一套典型的多智能体结构由三部分组成：一个编排器智能体，负责路由用户意图、把各方结果合成最终回答；若干专家智能体，每个只提供一种领域能力；再加上 Agent Actions，也就是让一个智能体干净地调用另一个的机制。

我这个 demo 里的分工是这样：

角色 智能体 职责
编排器 Life Assistant Agent 意图分类、路由、结果合成
专家 Weather Agent 天气查询、预报、特定位置数据
专家 Travel Assistant Agent 行程建议、规划、交通信息

第 1 步 —— 创建专家智能体（“Skills”）

先建 Weather Agent：

  1. 打开你的 Copilot Studio 智能体
  2. 进入 Knowledge 标签页
  3. 点 Add knowledge，选 Public websites

  1. 填入用来查天气的网站 URL（例如 www.weather.com/）
  2. 按需填写描述

需要的话可以再加几个网站。

接着建 Travel Assistant Agent。步骤和 Weather Agent 基本一样，区别只是把网站换成跟旅行相关的，用来给出行程建议、规划和交通信息。

第 2 步 —— 创建编排器智能体

这里建 Life Assistant Agent：

  1. 打开你的 Copilot Studio 智能体
  2. 进入 Agents 标签页
  3. 点 Add an agent，选第 1 步创建好的智能体
  4. 填写名称和描述

  1. 照同样的步骤再加一个智能体

  1. 在 overview 页面写上指令，说明它该怎么把任务合理地分派给下属的专家智能体

第 3 步 —— 端到端测试

打开 Test copilot 面板，问一个跟旅行目的地有关的问题，比如：

“I will travel to Beijing this weekend, provide me the travelling plan based on the weather forecast” （这个周末我要去北京，根据天气预报给我一份出行计划）

我期望看到的是：

  1. Life Assistant 意识到自己既需要天气信息，也需要旅行信息
  2. 活动地图显示编排器在调用任何子智能体之前，先做了正确的路由
  3. 天气数据出现在 Life Assistant 的中间推理过程里
  4. 旅行建议会跟着天气情况变

我的一点体会

走完这一圈，我最直接的感受是：多智能体编排真正解决的不是“能不能做到”，而是“做大之后还管不管得住”。把编排器和各领域的专家智能体拆开，职责就清楚了，复用和运维也跟着清楚。这套分法其实跟企业本来的组织方式对得上：领域团队守着自己那摊专业，中间有一层统一的编排保证行为和策略一致。

让我有点意外的是，整个过程没写一行自定义的编排代码，光靠 Copilot Studio 原生的智能体和 action 模型就够用了。任务越复杂，这种结构越像地基，而不是什么进阶选项。

延伸阅读