Copilot Studio 新 Harness 实战：GitHub Copilot 引擎与 MCP、技能全解析

微软 Copilot Studio 不再只是一个"搭建 Agent 的工具"，而是演进为一个完整的 Agent 平台。在最新的 Captain's Training 分享中，演讲者系统拆解了 Copilot Studio 的定位、全新的 GitHub Copilot Harness、MCP 服务器、技能（Skills）、记忆（Memory）与沙箱（Sandbox）等核心能力。本文梳理其中最具价值的技术要点，并解释它们在实际落地中的意义。

Copilot Studio 在微软 AI 工具矩阵中的定位

微软如今提供了大量功能相似的 AI 工具，容易让人选择困难。演讲者给出的核心原则很直白：永远从最简单、能满足目标的工具开始。就像跨城出行用不着波音 737，一架小型水上飞机就够了。

工具大致分两类：一类是我们直接使用的生产力工具，如 Microsoft 365 Copilot、Copilot Co-Work、Microsoft Scout；另一类是用来构建 Agent 的工具，如 Agent Builder、Copilot Studio 和 Foundry。Copilot Studio 的定位是：当 Agent Builder 已经满足不了需求时的进阶选择。

它的能力边界也在扩张——不仅能构建对话式 Agent，还能搭建工作流（workflow）处理确定性流程，甚至新上线了构建应用（app）的能力。你可以根据场景自由组合：需要对话界面用 Agent，需要可预测流程用 workflow，需要查看和操作数据用 app。同时它支持多渠道部署，既能嵌入 Microsoft 365 Copilot，也能发布到公开网站或内部门户，并自带企业级治理与安全能力。

什么是 Harness：Agent 的运行时中枢

Harness 是本次分享的关键概念。它不是"遛狗的牵引绳"，而是指介于**模型（底层大脑）和我们为 Agent 搭建的组件（指令、知识、工具、技能、工作流）**之间的运行时。

Harness 负责几件核心的事：

上下文管理：决定模型该看到哪些指令和工具
选择：判断当前任务该调用哪个工具或技能
执行：决定实际运行哪些工作
恢复：找不到结果时的备用方案
终止：判断任务何时算完成，之后该做什么

GitHub Copilot Harness 与 GitHub 许可证无关

Copilot Studio 目前有三种 Harness：

Standard Harness（标准）——最初的"元老"，基于 topics（预定义路径）的规则化、结构化对话模式。过去你搭建的所有 Agent 其实都运行在它之上。
Copilot Chat Harness（扩展器）——用于扩展 Microsoft 365 Copilot 本身能力的 Agent。
GitHub Copilot Harness（全新）——面向复杂多步流程的"新主力"。需要特别澄清：虽然名字里有 GitHub，但它与 GitHub 许可证毫无关系。

GitHub Copilot Harness 带来了哪些根本改变

从 Standard 切换到 GitHub Copilot Harness，变化是结构性的：

更智能的追问：标准模式需要为每种输入写死刚性提示，按固定顺序运行；新模式凭借推理能力，能问更少、更聪明的问题，自动补全缺失信息。
处理"岔路"：标准模式下，一个未被预设的"支线任务"可能直接中断整个计划。比如员工入职 Agent 被问"午饭吃什么"，旧模式会卡住，新模式能应对后再拉回正题。
并行调用工具：旧模式一次只用一个工具；新模式能链式调用、并行运行多个独立工具（如同时查 SharePoint 列表和内部数据库），性能更好。
动态工具选择：旧模式高度依赖对工具描述的精确撰写；新模式写好指令后，能更动态地判断该调哪个工具。
错误恢复：权限不足或服务 404 时，旧模式往往直接报错；新模式会重试、换路径，尝试恢复。

Agentic Loop：背后的运行逻辑

关键差异在于运行机制。标准 Harness 走的是"识别意图 → 制定计划 → 执行 → 响应"的线性流程。而 GitHub Copilot Harness 使用 agentic loop（代理循环）：制定计划 → 行动 → 观察（结果是否满意？有无错误？）→ 若不满意则重新规划。

遇到 404 时，它会追问：我还有哪些可用工具？为什么会 404？是否需要向用户要更多信息？然后生成新计划，不断循环，直到得到满意结果，或判定无法处理并走升级路径。

Agentic loop 是当前主流"推理型 Agent"架构的核心范式，在学术和工程实践中也常被称为 ReAct（Reasoning + Acting）框架。其基本思路是：模型不再一次性生成最终答案，而是交替进行"思考（Thought）→ 行动（Action）→ 观察（Observation）"的循环，每次行动后将结果作为新的输入重新送入模型，驱动下一步推理。这种机制使 Agent 能处理初始信息不完整、中间步骤可能失败、或任务目标需要动态调整的复杂场景。与此对应，标准 Harness 的线性流程类似于传统的"链式调用"（Chain），适合流程固定、步骤可枚举的任务；而 agentic loop 则更接近"自主决策"，代价是执行路径不可完全预测，因此需要配合良好的错误恢复和终止条件设计，避免陷入无限循环或产生意外的副作用操作。

实战演示：IT 设备更换场景对比

演讲者用同一场景对比了两种 Harness。场景是帮助处理 IT 请求和设备更换。

切换到 Copilot Studio 进行演示

在 Standard Harness 中，指令必须写得极其详尽——要一步步说明如何排障，还要单独定义设备更换的"设备助手工作流"，并手动调用 topics（预定义路径，比如筛选状态为"可用"的设备）。当用户问"我把笔记本摔了屏幕裂了，怎么办、能换什么"时，Agent 立即识别意图并给出设备列表——响应很快，但它只处理了"换设备"，漏掉了"是否需要先排障"这一层。

切换到 GitHub Copilot Harness，界面明显更简洁——没有 topics、没有 child flows，取而代之的是 skills、tools 和 knowledge。同样的提问下，它自动识别出需要"先排障、再推荐设备"的双重意图（而无需在指令里写死）。它会：

调用两个专家技能：troubleshooting 技能和 asset device management 技能
搜索知识库查找处理流程
请求权限去拉取已批准设备列表
返回更完整的回复——先报告损坏、提交工单，再给出替换选项

更值得关注的是推理能力：当用户模糊地说"我是开发者，跑本地 AI 模型、做很多视频"，它能自行推断需要大内存、高存储、强 CPU，并填入请求。最后调用工具把数据写入 SharePoint 列表，并通过工作流自动发送请求邮件。整个过程在调试模式下可见思考链，终端用户则看到干净的交互界面。

组件如何归位：指令、知识、工具、技能、工作流

搭建 Agent 时，判断每类行为该放在哪里，可以用一组提问来决策：

对每次对话都成立？ → 放进指令（Instructions）。新 Harness 下指令应更窄、更聚焦。
需要查询的事实？ → 用知识（Knowledge），可来自上传文件、SharePoint 站点或公开网站。
要触达系统并改变数据？ → 用工具（Tools），负责读写等操作。
针对特定情境的流程？ → 用技能（Skills）。
必须每次都完全一致地运行？ → 用工作流（Workflow），换取可预测性。

工作流与 Agent 可以互相调用：工作流可触发 Agent，Agent 也可调用工作流，甚至工作流能编排 Copilot Co-Work 任务与 Microsoft 365 Copilot Agent，构成系统级编排。

MCP 服务器：Agent 的集成层

MCP（Model Context Protocol，模型上下文协议）为 Agent 提供对外集成。MCP 服务器本质上是添加进 Agent 的工具集，分三种来源：

内置：Dataverse、SharePoint 等微软服务
伙伴：经微软认证的第三方，如 Adobe、DocuSign
自建：你可以把自己的 MCP 服务器接入

MCP 的价值在于：它能帮 Agent 自动发现工具（一个库存 API 的 MCP 服务器包含查询、更新库存等多个动作，Agent 能智能判断该调哪个）；高度可移植（同一个 MCP 服务器可在 Copilot Studio、Co-Work、Claude 等工具复用）；并自带编排逻辑，而非简单的 API 封装。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年底提出并开源的标准协议，目标是解决 AI 模型与外部数据源、工具之间的集成碎片化问题。在 MCP 出现之前，每个 AI 平台都要为每个外部服务单独开发适配层，形成大量重复工作。MCP 类似于给 AI 工具世界定义了一套"USB 接口标准"——只要服务商实现了 MCP 服务器，任何支持 MCP 的 AI 客户端（包括 Claude、Copilot Studio、Cursor 等）都能直接调用，而无需重新开发集成。协议分为三层：Resources（让模型读取上下文数据）、Tools（让模型执行操作）和 Prompts（可复用的提示模板）。微软在 Copilot Studio 中采纳 MCP，意味着企业自建的 MCP 服务器可以同时被多个 AI 平台复用，大幅降低集成成本，也是业界 AI 工具互操作性逐步标准化的重要信号。

技能、记忆与沙箱：精细化的三块拼图

技能对性能的重要性在于节省上下文

技能（Skills） 为 Agent 提供领域知识。它的关键价值在于效率——每次提问都会把指令加载进上下文窗口，指令越长成本越高、可用响应越少。而技能只在编排器判断需要时才加载，既省成本又提升准确率。一个技能就是一个 skill.markdown 文件，含标题、描述（决定何时被调用）和指令，还可选附带资源文件和 Python 脚本并打包成 zip。

使用技能要避免四类错误：

模糊描述——技能不触发多半是描述问题
巨型技能——一个 Agent 最多可放约 50 个技能，应保持窄而精
事实堆砌——技能是指南，不是知识源，FAQ 应归入 Knowledge
未审查的技能——从外部获取的技能要像对待示例代码一样先审查

记忆（Memory）（目前预览版）通过一个开关启用，能按 Agent、按用户捕获个性化信息，如用户所在地、混合办公排班，在排会议等场景中提供上下文，且隔离可控，无法看到他人记忆。

沙箱（Sandbox） 为 Agent 提供精度。大模型本质是预测引擎，不擅长重计算、文件生成和信息解析，而运行 Python/Bash 则很擅长。沙箱让 Agent 以安全方式执行脚本、生成图表、做数值运算，从而给出更精确的结果，而非让模型"猜"。

在库存分析演示中，一个只有简单指令、无技能无工具的 Agent，上传一份百行 CSV 后，仅凭开箱即用的数据分析技能和沙箱，就自动清洗数据、标记日期格式问题，并生成含汇总、按门店分表、Top 50 老化 SKU、分桶、数据质量等多个工作簿的透视表仪表板。

上下文窗口（Context Window）是大语言模型在单次推理中能处理的最大文本长度，以 token 为单位计量。所有送入模型的内容——系统指令、对话历史、检索到的知识、工具定义——都会占用这一有限空间。窗口用尽时，模型要么截断早期信息，要么拒绝处理，直接影响回复质量和任务完成率。同时，输入 token 数量也直接决定 API 调用成本：指令越长，每次对话的费用越高。这正是"技能按需加载"设计的核心动机——将大量领域指令拆分为独立技能文件，由编排器在需要时动态注入，而非在每次对话开始时全部塞入上下文，既压缩了单次调用的 token 消耗，也为模型留出更多空间处理当前任务的实际内容。

部署前的"飞行前检查"

演讲者最后给出了部署 Copilot Agent 前的检查清单：

接地气的数据（Grounding）：垃圾进、垃圾出，别把"最终版B2"这类混乱文件丢进去
权限设置：Agent 只能回答它有权限看到的内容
评估与测试："在我机器上能跑"不算数，要做正经的单元测试
所有者与限额：设置支出告警和限制

遇到问题时的排查顺序：先收紧指令 → 修正工具与技能的命名和描述（命名不当会导致不触发）→ 去除重叠项 → 合理拆分 Agent，不要堆成一个庞然大物。

对新手，演讲者推荐了官方免费的 Agent Academy，提供 IT 帮助台的入门实战，以及新上线的多 Agent 员工入职的进阶课程。