20.04拆解更新于 2026年9月17日

企业 Agent 平台

Copilot Studio 等:知识、工具、工作流、治理与生命周期。

20.04 · 课时讲解

产品拆解:企业 Agent 平台

卖的不是一个 Agent,而是让很多人安全地造出很多 Agent 的能力。

1 / 13

一句话理解:企业 Agent 平台卖的不是“一个 Agent”,而是“让很多人安全地造出很多 Agent”的能力——知识接入、工具与工作流、运行时选择只是一半,另一半是身份、数据策略、审计、评测与发布生命周期。

当一家企业里有几十个团队都想做 Agent 时,问题就从“怎么做好一个 Agent”变成了“怎么管住一千个 Agent”:谁能造 Agent?Agent 能连接哪些系统?它以谁的身份访问数据?出了问题谁能查到?新版本上线前有没有测过?

本课以 Microsoft Copilot Studio 为例拆解企业 Agent 平台。之所以选它,是因为它把平台型产品的两面都做得很完整,而且在 2026 年引入了一个与本课程高度契合的概念——Harness。以下内容依据 Microsoft Learn 官方文档(截至 2026 年 9 月),其中标注“预览”的功能以官方状态为准。

它是什么

官方文档将 Copilot Studio 定义为一个用于构建和管理 AI Agent 与工作流的图形化、低代码工作室,可以连接组织数据与系统,并把成果发布到 Microsoft Teams、Microsoft 365 Copilot、网站、移动应用等渠道。它包含三类构建块:

构建块 是什么
Agents 处理对话、完成任务的 AI 助手;遵循指令、使用知识源、调用工具,并根据上下文决定下一步
Workflows 用拖拽设计器构建的自动化,每一步可以推理和行动,内置测试与人工介入控制
Agent flows 既有的流程格式,体验接近 Power Automate;可独立运行,也可作为工具挂到 Agent 上

更值得注意的是 Harness 的概念。官方文档把 Harness 解释为介于你的设计与模型之间的运行时:决定何时调用模型、发送哪些组件、如何解释返回、调用哪些工具。Copilot Studio 提供三种:

Harness 工作方式 适合
GitHub Copilot harness 接受目标、拆解步骤、跨连接器/知识/MCP/其他 Agent 调用工具,失败时重试或换路径;原生创建和编辑 Word、Excel、PowerPoint、PDF;支持 Skills 与 Memory;每个任务在受平台治理的安全沙箱中运行 多步骤、需要推理的业务流程,如应付账款核对
标准 harness 按作者设计的 Topic(对话片段)匹配请求,Topic 之外可从知识源生成回答 规则明确、需要稳定一致的场景,如内部服务台
Copilot chat harness 把企业知识接入 Microsoft 365 Copilot Chat 员工在日常工具中获取有依据的答案

同一个平台同时提供“Agent 式”和“Workflow 式”两种运行时,本质上就是「Workflow 与 Agent」那条光谱在产品里的落地:让构建者按场景选择确定性与自主性的比例。

把构建块、Harness、工具与知识、发布渠道和治理放在一起,就是 Copilot Studio 的整体架构:

Copilot Studio 架构图:构建者与触发、构建块、三种 Harness、工具与知识、评测、发布渠道,以及底部的治理体系 构建者与触发 低代码 Maker 专业开发者 VS Code 扩展 管理员 安全 · 合规 · 成本 用户对话 事件触发器 SharePoint 新建条目 OneDrive 新建文件 Planner 任务完成 定时重复 Copilot Studio · 图形化、低代码的构建与管理工作室 构建块 Agents 对话与任务 · 用知识与工具 Workflows 拖拽设计 · 内置人工介入 Agent flows 类 Power Automate · 可作工具 Harness(运行时) GitHub Copilot harness 目标驱动 · Skills · Memory 标准 harness Topic 匹配 · 稳定一致 Copilot chat harness 接入 M365 Copilot Chat 工具 · 知识与上下文 工具 连接器 · Agent flows · Workflows MCP Server · Computer use 其他 Agent(A2A) 知识与上下文 SharePoint · Bing Custom Search Microsoft IQ · Foundry IQ(预览) Memory(按用户) 验证与可观测 Agent 评测 · 活动图 · 分析 测试集与 graders · 多版本并排对比 · REST API 接入 CI/CD 发布渠道 Microsoft Teams Microsoft 365 Copilot 网站 移动应用 发布前 修改默认安全配置 会收到安全警告 并持续做风险评估 治理:企业平台的真正核心 身份 Entra Agent ID 数据策略 连接器、渠道、触发器 审计 Purview · Sentinel 清单 Agent inventory 生命周期 Git 部署 · 环境路由 成本上限 Copilot Credits 加密与数据 CMK · 驻留 · 标签
图 1 · Copilot Studio 架构:中间是构建与运行,两侧是构建者与渠道,底部一整层是治理

用八个问题拆解

1. 它完成什么 Job?

平台本身的 Job 是“让组织里的构建者造出并运营 Agent”。它服务两类用户:构建者(低代码 Maker 与专业开发者,后者可以使用 VS Code 扩展)和 管理员(负责安全、合规与成本)。平台上的每个 Agent 再各自服务具体的业务 Job。

2. 它能调用哪些工具?

  • 连接器:预置或自定义连接器,接入 Microsoft 与第三方系统。
  • Agent flows 与 Workflows:把多步骤确定性流程作为工具挂到 Agent 上。
  • MCP Server:作为工具接入外部服务;GitHub Copilot harness 上的 MCP 与 Workflow 工具在 2026 年 7 月处于预览。
  • Computer use:2026 年 5 月正式发布,可以控制浏览器和桌面应用,自动化没有 API 的系统。
  • 其他 Agent:可以连接其他 Agent 进行委派,Agent-to-Agent(A2A)协议连接于 2026 年 4 月正式发布(参见「Agent 间协议概览」)。

3. 它拿得到什么上下文?

  • 企业知识:SharePoint(支持按文件名、所有者、修改日期等元数据过滤)、Bing Custom Search 等知识源。
  • 工作数据:GitHub Copilot harness 上的 Agent 可以使用 Microsoft IQ,访问邮件、日历、文件、Teams 消息与人员信息;也可以连接 Azure AI Foundry 中构建的 Foundry IQ 知识库(预览)。
  • 记忆:GitHub Copilot harness 支持为 Agent 开启 Memory,按用户存储偏好与模式。
  • 权限感知:SharePoint 知识源在回答中展示所用来源的最高敏感度标签。

企业平台的上下文设计有一个与个人产品不同的重点:同一个 Agent 面对不同用户时,必须只看到该用户有权看到的数据(参见「知识保鲜与权限」)。

4. 它在哪里执行?

Copilot Studio 以 Web 应用形式提供,构建者无需自己部署运行环境;按官方文档,GitHub Copilot harness 的每个任务在受 Copilot Studio 治理的安全沙箱中运行。需要操作界面时,可以通过 Computer use 或 Windows 365 for Agents MCP Server 控制云电脑。

触发方式上,除了用户对话,标准 harness 的 Agent 可以使用 事件触发器:SharePoint 新建条目、OneDrive 新建文件、Planner 任务完成、定时重复等事件发生时,Agent 收到一个包含事件信息与指令的 payload 并自主行动。

5. 它如何决定下一步?

取决于 Harness:GitHub Copilot harness 由模型根据目标规划与调整;标准 harness 通过生成式编排或 Topic 匹配选择动作。官方文档对事件触发场景给出了很务实的建议,例如尽量让 Agent 连续调用的动作或 Topic 少于 15 个,否则复杂序列难以稳定运行;如果 Agent 总是调用不到预期的动作,考虑改用确定性的 flow 来完成。这与「混合架构」的思路一致。

构建者还可以为 Agent 选择主模型,官方文档列出的可选模型来自 OpenAI、Anthropic 等多家提供商。

6. 它如何验证结果?

企业平台把验证做成了 生命周期功能:

  • Agent 评测(2026 年 3 月正式发布):用上传、手工创建或 AI 生成的测试集,配合不同评分方法(graders)对照参考答案打分;支持多轮对话测试;可以并排比较多个版本以发现回退;可以通过 Power Automate 连接器或 REST API 自动触发,接入 CI/CD。
  • 活动图(Activity map):查看 Agent 每一步的输入、决策与输出,诊断为什么没调用预期动作。
  • 分析:自定义指标、问题与反馈明细、会话转录,可以把环境级遥测导出到 Azure Application Insights(预览)。

参见「线上评估与回归」。

7. 什么时候需要人确认?

  • 流程中的人工步骤:Workflows 内置人工介入控制;Agent flows 可以包含人工审阅步骤,“request information”动作(预览)能暂停流程,通过 Outlook 向指定人员收集信息后再继续。
  • 发布前的安全提醒:修改默认安全配置后,Maker 在发布前会看到安全警告;系统还会在配置知识、工具与动作时持续给出风险评估。
  • 管理员层面的“确认”:管理员可以通过数据策略禁止某些连接器、知识源、HTTP 请求、发布渠道或触发器,甚至关闭生成式 AI Agent 的发布能力。

8. 失败如何恢复?

  • GitHub Copilot harness 在步骤失败时会重试或寻找替代路径;标准 harness 按构建好的路径处理。
  • Agent flows 支持异步响应,让长时间运行的流程突破两分钟限制,完成后再把结果返回给 Agent。
  • 状态页(预览)汇总发布错误、运行时问题与配置阻塞,并标注严重程度。
  • 版本比较、评测回归与从 Git 部署的审计记录,使“回到上一个可用版本”有据可依。

企业平台的真正核心:治理

如果只看上面八个问题,Copilot Studio 与其他 Agent 构建工具差别不大。真正体现“企业平台”属性的,是官方安全与治理文档列出的这一整套控制:

治理维度 官方文档中的控制 解决的问题
身份 自 2026 年 7 月起,平台为每个新 Agent 自动创建 Microsoft Entra Agent ID;接入 Microsoft Agent 365 后可对 Agent 身份应用条件访问等控制 Agent 以什么身份行动,能否像员工账号一样被管理
数据策略 在 Power Platform 管理中心配置数据策略,管控认证方式、知识源、动作/连接器/Skills、HTTP 请求、发布渠道、触发器等 Agent 能连接哪些系统、数据能流向哪里
审计 Microsoft Purview 中的 Maker 审计日志,Microsoft Sentinel 中的活动监控与告警 谁造了什么、Agent 做了什么
清单 Agent inventory,可从管理中心、API 或 Azure Resource Graph 发现和审计全部 Agent 组织里到底有多少 Agent、归谁负责
生命周期 基于 GitHub 的源代码管理与从 Git 部署,保留可审计的部署历史;环境路由为 Maker 提供安全的构建空间 开发、测试、生产如何隔离与发布
成本 使用量可视化,设置按需付费的 Copilot Credits 上限 防止失控的触发器或调用烧掉预算
加密与数据 客户管理密钥(CMK)、数据驻留、敏感度标签 合规要求

官方文档中还有一个非常值得产品经理注意的风险说明:事件触发器只能使用 Agent 作者的凭据进行认证。这意味着发布一个带认证触发器的 Agent 后,使用者可能借助作者的授权访问数据或执行动作。平台会在发布前提醒 Maker,管理员也可以通过数据策略禁止触发器。这正是「最小权限与凭据管理」在真实产品中暴露出的典型难题:自主运行的 Agent 需要一个不依赖用户在场的身份,而这个身份的权限边界必须被单独管理。

这条风险链可以画成下面这样:

事件触发器的凭据风险:Agent 只能用作者凭据认证,使用者可能借助作者的授权访问数据或执行动作 事件发生 如 SharePoint 新建条目 Agent 收到事件 payload 作者的凭据 触发器只能用它认证 数据与动作 以作者的权限执行 使用者 并非作者本人 可能借助作者的授权 平台与管理员的控制 发布前向 Maker 发出提醒 管理员可用数据策略禁止触发器 新 Agent 自动获得 Entra Agent ID 自主运行的 Agent 需要不依赖用户在场的身份,这个身份的权限边界必须被单独管理
图 2 · 作者凭据风险:自主运行的 Agent 以谁的身份行动,必须被单独审查

可借鉴的设计决策

设计决策 Copilot Studio 的做法 迁移到你的产品
让构建者选择运行时 三种 Harness 覆盖从规则驱动到目标驱动 为不同风险与复杂度的场景提供“流程模式”与“Agent 模式”
Agent 拥有独立身份 自动创建 Entra Agent ID 业务 Agent 用独立服务身份运行,而不是借用员工账号
管理员能力按维度拆分 数据策略分别管控知识、连接器、HTTP、渠道、触发器 权限配置按能力维度拆开,而不是一个“是否启用 AI”的总开关
评测进入发布流程 测试集、多版本对比、REST API 接入 CI/CD 每次修改 Prompt、工具或模型都自动跑回归
发布前的安全扫描 修改默认安全配置时发出警告,持续风险评估 在构建阶段而不是上线后发现数据外泄风险
坦诚暴露身份风险 文档明确事件触发器使用作者凭据 自主运行的 Agent,要在 UI 中清楚展示“以谁的身份运行”
成本上限 Copilot Credits 按需付费上限 给每个 Agent 或环境设置预算上限与告警

常见误区

  • “低代码平台做出来的 Agent 不需要评测。” 构建门槛越低,Agent 数量越多,越需要平台级的评测与清单能力。
  • “有了平台治理,单个 Agent 就不用设计权限了。” 平台提供的是控制手段,具体 Agent 的最小权限、审批点和验证方式仍要逐个设计。
  • “Agent 数量越多说明平台越成功。” 没有清单、负责人和使用数据的 Agent 会变成新的“影子 IT”,增加风险而不是价值。

设计要点

  • 为每个 Agent 明确:身份、负责人、连接的系统、发布渠道、成本上限。
  • 在平台层按能力维度提供管理员控制,而不是一个总开关。
  • 把评测与版本对比放进发布流程。
  • 对“以作者或服务身份自主运行”的 Agent 做额外的权限审查。
  • 同时提供确定性流程与自主 Agent 两种运行时,并给出选择指引。

练习

假设你是公司的 AI 平台负责人,要允许 20 个业务团队自建 Agent。用 45 分钟写一份一页纸的治理方案:

  1. 列出 Agent 上线前必须填写的 8 个字段(例如身份、负责人、数据范围、审批点、评测集、成本上限)。
  2. 按“知识、工具、渠道、触发器”四个维度,各写一条默认策略。
  3. 设计一个检查:自主运行的 Agent 是否在使用某个员工的个人凭据。

延伸阅读

下一步

企业平台强调集中治理,下一课「个人常驻 Agent」走向另一个极端:运行在你自己的机器上、通过聊天软件随叫随到的 OpenClaw 与 Hermes Agent。

试试:上下文、MCP、沙箱、Prompt 注入、外链