Microsoft Copilot Harness 通过 Foundry 开放，改变自建或采购的决策
Microsoft 于 10 月 28 日通过 Foundry 开放了其 Microsoft Copilot harness，在保留运营控制权的同时，将一套内部执行基础设施扩展给开发者。Harness 是围绕 AI 模型运行的软件，负责组织指令、上下文、工具与执行过程。这项公告改变了企业可采购而非自行构建的内容，但并未免除其对最终工作结果的责任。
核心选择在于：是内部维护这套执行机制，还是采用 Microsoft 的托管方案。智能体，即利用模型和工具完成任务的软件，需要的不只是访问强大模型。还必须有人决定它如何继续执行、如何处理失败，以及如何遵守业务边界。
Anthropic 已提供了竞争性的托管方案，为买家提供了 Microsoft 产品家族之外的有用参照。Microsoft 的独特主张是通过共享基础设施提供对不同模型家族的访问。对于开发团队而言，这引出了一个实际问题：哪些责任更容易委托出去，哪些仍需要针对具体应用作出判断？
Microsoft Copilot Harness 进入 Foundry 公共预览
Microsoft 正将一套共享产品基础转化为面向客户应用的托管构建模块。
根据 Microsoft 的多模型 harness 公告，GitHub 工程团队在 Microsoft 将其应用于各类 Copilot 体验之前开发了这套 harness。该公司指出，Copilot Code、Copilot Studio、GitHub Copilot app、命令行界面和 VS Code 都在使用它。
Foundry Agent Service 是 Microsoft 用于构建和运营智能体的平台，现在以公共预览形式提供这套 harness。这一状态很重要，因为该公告结合了一项成熟的内部技术和一项新近可用的托管服务。在 Microsoft 产品中的实践经验，并不能自动证明它已适用于每位外部客户的工作负载。
Microsoft 描述了一种责任划分：由其运营执行机制，客户则提供特定于应用的指令与连接。这使此次发布的意义超出了编程助手。一家开发研究助手或运营智能体的公司，可以考虑采购过去通常被视为内部工程工作的基础设施。
公告还提到一个可下载的软件开发工具包，即开发者用来将该技术集成到应用中的软件包。这一路径不应与 Foundry 的托管体验混为一谈。选择分发方式与选择由谁运营服务，是相关但不同的问题。
对企业买家而言，眼前的变化是多了一种实施选项。正在评估智能体的团队不再必须假定，支持不同模型就意味着要维护自己的外围执行系统。Microsoft 正提出代表客户维护这套共享基础。
这一提议需要被准确理解。购买托管 harness 并不代表某个具体工作流一定能产出正确答案或采取恰当行动。它改变的是谁提供部分执行机制。买家仍需要证据，证明完整应用满足自身要求。
设想一个假设性的研究应用：它比较供应商公告并准备内部简报。其有用产出应包括准确的来源标注、清晰的日期，以及对冲突信息的明确处理。一个正常运行的执行系统能够支持这些工作，但无法替组织定义这些编辑要求。
因此，这次发布改变了架构讨论的起点。团队不再只问哪个模型应当回答请求，也可以问智能体执行中的哪些部分值得进行定制工程。这比在选择菜单中多出一个模型更具影响力。
压力落在维护自身执行机制的团队身上
Microsoft 的方案让内部基础设施项目受到审视，尤其是那些复现现有能力却未创造业务优势的项目。
最强的压力落在已经维护智能体外围机制的应用团队身上。他们的管理者如今有了可供考察的外部替代方案。继续采用定制实现，成为一项需要论证的决定，而不再是推出智能体的自动前提。
这种论证依然可能很有说服力。企业可能需要非常规的执行行为、专门的集成，或对工作推进方式的直接控制。关键区别在于，这些要求是否会实质影响应用。当组织能够明确说明这种控制能实现什么时，自行掌控才更有意义。
采购基础设施带来了另一项义务：理解供应商的边界。开发团队不能仅凭演示中展示的功能评估托管服务。它必须识别平台在哪里结束，以及自身的软件、流程和监督从哪里开始。
Microsoft 的托管智能体执行公告概述了技能、连接工具、文件与代码执行，以及受限委派。技能是由指令和支持资源打包而成的可复用流程。工具让智能体能够访问外部信息或执行外部操作。这些能力描述的是比单纯文本生成更广泛的应用基础。
同一公告还提供了早期客户的观点。Confluence Technologies 首席技术官 Chris Evans 表示，该公司在不到一周内就让一个解决方案运行起来。这是一个有用的实施案例，但并不能证明这代表典型部署周期或长期运营结果。
对买家来说，重要区别在于达到初步可用状态与维持可靠服务之间。内部原型可以容忍运营应用无法接受的假设。托管基础能够缩短部分工程工作，但集成审查、验收标准和责任归属的决定仍未解决。
因此，有意义的财务比较应审视完整工作流，而不是单次模型响应。相关考量包括工程维护、故障调查、人工审核，以及连接系统的变化。此次发布无法得出通用计算结论，因为这些责任因组织而异。
压力同样会波及围绕模型提供产品的基础设施供应商。Microsoft 的分发方式让客户多了一个理由去质疑自己究竟需要哪些独立组件。这并不意味着独立产品变得没有必要，而是提高了它们说明自身所提供额外控制、可见性或专业化价值的标准。
对知识工作者而言，影响以另一种形式显现。他们所感受到的是，智能体是否完成可用的交付物、是否保留恰当的证据，以及是否能适当地升级处理不确定性。架构变化只有在减少未完成工作，或让错误更容易被发现和纠正时，才会对他们产生意义。
这就是为什么自建或采购的讨论应当属于产品负责人，而不只是工程师。组织必须先定义令人满意的结果，再决定哪种基础设施安排能够实现它。否则，即使部署在技术上成功，实际业务问题仍可能大体未被解决。
模型选择与运行时控制是两项独立决策
获得不同模型的访问权限，并不意味着客户可以无限控制托管服务如何执行其工作。
Microsoft 的harness 可用性 FAQ明确了预览阶段的边界。不支持自带模型。客户在创建新的提示词智能体时选择 harness，之后无法切换。可用性还可能因区域、客户端、工具、网络和配额而异。
这些限制澄清了多模型支持的含义。客户可以在服务边界内评估受支持的选项。这不同于因为更广泛的战略强调选择，就假定任何模型、连接或部署安排都能正常工作。
这一差异在采购过程中很重要。某个模型出现在供应商产品组合的其他位置，并不能回答它是否受特定托管体验支持。买家需要评估计划使用的组合，包括相关部署位置和连接系统。
改变模型与保持应用行为之间也存在区别。即使接口保持一致，不同模型也可能作出不同判断或产生不同输出。应用负责人应将模型变更视为需要根据业务要求进行评估的事项，而不是一项行政替换。
设想一个审查供应商提案的假设性采购助手。其中一项任务是提取交付日期，另一项是解释含义模糊的取消条款。组织可能更偏好不同模型在这些活动中的不同特性，但仍需要对可接受证据和升级处理作出一致定义。
共享执行基础可以让这种比较更容易组织起来。但它并不能证明相同指令在所有受支持模型上都同样有效。有用的结果是获得一个受控机会来比较结果，并清晰记录发生了什么变化以及原因。
Anthropic 的托管智能体架构提供了相关的竞争性比较。其 2026 年 4 月的工程文章描述了如何将模型和 harness 与执行环境及持久会话记录分离。其明确目标是让实现能够在稳定接口之后演进。
这一比较说明，行业竞争已超出模型选择。供应商也在竞争：在保留客户可依赖接口的同时，谁能够承担更多执行责任。Microsoft 对多个模型家族的强调，解决的是这一更广泛采购决策中的一个维度。
这两种架构描述都无法确立普遍赢家。企业在不同托管方案之间选择时，需要比较自身实际工作流、所需集成和运营约束。一项服务可能非常适合某个应用，却可能给另一个应用带来不合适的假设。
更深层的权衡在于灵活性位于何处。团队可以保留在受支持模型之间选择的空间，同时接受供应商的执行设计。或者，它可以保留更多执行控制权，并承担维护责任。这是两种不同形式的灵活性，带来不同的工程后果。
因此，对于 Microsoft Copilot harness，最切实可行的解读是有限选择。客户获得了一条额外的托管式智能体开发路径。他们应根据该路径已文档化的能力进行评估，而不应将更广泛的品牌宣传视为对普遍兼容性的承诺。
Microsoft 的评估提升需要谨慎解读
Microsoft 的内部结果支持进一步评估，但并不能证明每个 Foundry 应用都能获得同等提升。
在其智能体评估结果中，Microsoft 将 Copilot Studio 中的 Copilot harness 与 Standard harness 进行了比较。该公司称，使用 OpenAI 模型时通过率提高了 10.8 个百分点，使用 Anthropic 模型时提高了 22.1 个百分点。
Microsoft 还表示，在评估案例中，工具调用失败后仍继续尝试的比例为 84–91%，而 Standard harness 的这一比例不足 7%。其附注明确区分了持续使用工具、成功重试与最终成功完成整体任务。这些均为公司自行报告的发现，本文未能确认其已获得独立验证。
这一限定对于解读该公告至关重要。坚持执行描述的是某个环节出错后的行为；完成则描述所要求的结果是否达成。一个系统可以继续工作，却仍可能误解任务、使用不恰当的证据，或产出不可接受的结果。
在假设的客户服务工作流中，这一区别就很具体。智能体或许能成功重试访问某条案例记录，却仍给出错误的解决建议。衡量其从连接失败中恢复的能力，有助于解释执行行为；但并不能说明客户是否获得了准确答案。
同样，更高的评估通过率取决于评估所要求完成的内容。买方需要先了解相关任务、验收标准和配置，才能将结果迁移到自己的环境中。百分点提升只有结合其所衡量的测试，才具有参考意义。
这并不削弱周边执行系统的重要性。Microsoft 报告的对比结果与这样一种观点一致：模型能力本身并不单独决定智能体结果。这为客户提供了一个理由，即在模型选择之外也测试执行选择，同时明确归因与局限性。
Microsoft 还介绍了一项内部支持应用，该应用在 2026 年 8 月实现了超过 35% 的完全自主解决率。该公司将这一指标定义为无需人工干预即可解决案例。这是一个具体的已报告部署案例，但其是否适合作为比较依据，取决于案例类型和运行条件。
对于正在评估类似应用的企业而言，自主性应与正确性及其后果一并考量。无需干预即可解决的案例，在解决方案准确且恰当时可以成为有用证据。仅仅缺少人工干预，并不能证明结果达到组织的标准。
评估还应考虑转移给审阅者的工作量。如果智能体产出更多材料，却需要大量修正，产出量就可能误导人们对其实际贡献的判断。业务问题在于已完成且可接受的工作，以及获得这些工作所需的投入。
同样的逻辑也适用于那些直到更晚才暴露的失败。一份措辞精致却包含无依据主张的简报，在交付时可能看似成功。检查证据和归属的评估则会呈现不同的结果。验收标准应反映结果将如何被实际使用。
目前，Microsoft 的数据是关于其自身测试环境的有用证据。它们足以支持进一步调查，但不能替代针对客户自身情况的测试。买方不应将供应商对比转化为对未纳入所报告评估的工作负载的预测。
托管执行并未将业务责任从客户手中转移
委托基础设施并不意味着将决定智能体获准执行哪些操作的责任一并转移。
最明确的边界涉及会产生实质后果的操作。准备建议的智能体，与代表组织落实该建议的智能体，需要不同的控制措施。托管执行服务可以支持任一种设计，但组织必须决定授权的起点和终点。
Fashable 在 Microsoft 的发布材料中提供了客户视角。首席执行官 Orlando Ribas Fernandes 描述了与采购工作流相关的机会，同时将具有商业约束力的决策保留在人工控制之下。这是一条预期的运营边界，而非每项拟议能力都已取得可量化成果的证据。
这个例子说明，不能从自动化本身推断出问责关系。采购助手可能比较规格、识别缺失信息，或准备谈判材料。授权采购则引入了不同的责任。即使这些活动出现在同一次对话中，这一区别也应保持清晰。
长期运行的工作引入了另一条边界：记住发生过什么，与知道哪些信息仍然有效，是两回事。智能体可以保留先前结果，却未必知道环境已经变化。应用所有者需要确定何时应重新核查早期信息，以及哪些决策依赖于当前证据。
Anthropic 的长周期智能体研究描述了跨会话中未完成工作以及过早宣称完成等失败情形。其提出的方法使用明确的进度记录和增量式工作。更广泛的教训是，持续执行需要对未完成义务作出可靠记录。
对企业而言，这一教训意味着应将完成视为一项业务条件。当任务满足验收标准时，它才算完成，其中包括任何必要的审查或确认。一条自信的最终消息不能替代这些条件已满足的证据。
重启中断的工作会带来相关问题。设想一个假设中的智能体，它准备一份报告并将其提交至另一个系统。如果提交成功但确认信息丢失，重复该操作可能会创建重复记录。应用需要有办法区分未完成的操作与未经确认的操作。
Microsoft 还宣布，其托管智能体的长周期韧性功能已全面可用，在这种模式下客户提供自己的执行逻辑。其文档将保存进度和防止重复的责任置于应用代码之上。这项独立功能不应被视为对新 harness 预览版的全面保证。
信息质量带来了进一步责任。连接到过时指南的智能体，即使能始终如一地执行指令，也仍可能产出不适当的工作。考虑建设可检索知识库的团队，应将来源组织与维护视为应用的一部分。
这种关系使知识管理与此次发布相关，但并不意味着存在某种特定集成。基础设施决定工作如何推进；可用证据则限制智能体能够合理得出何种结论。改善其中一项，并不能消除另一项的弱点。
因此，组织应在完整工作流中明确责任归属。需要有人负责源材料、权限、验收标准，以及结果失败时的纠正。托管执行可以改变工程负担，但不会消除这些组织层面的决策。
最可信的采用理由，应同时明确供应商承担的工作与客户保留的义务。这种清晰度更便于判断该服务是否总体上降低了复杂性。它也能避免一个成功的原型演变成无人完全负责的应用。
三项信号将显示托管方式是否兑现价值
下一批有价值的证据，应聚焦服务成熟度、对比结果和客户运营，而非额外的发布声明。
第一个信号是 Microsoft 在未来几个月如何推进 Foundry 预览版。买方应关注更清晰的可用性、支持的配置、迁移选项和生产环境指南。更广泛的文档化支持，将增强在更多应用中采用共同托管基础的理由。
最有意义的扩展，应解决当前阻碍真实部署的一项需求。当另一种受支持配置使组织能够在其技术和业务约束范围内运行时，它才具有意义。仅靠更长的功能列表，并不能充分说明某个特定应用是否变得可行。
如果预览版限制对客户的目标环境仍有重大影响，那么该客户立即采用的理由就会减弱。这是针对工作负载的判断。一项限制可能对研究原型无关紧要，却可能对连接敏感运营系统的应用具有决定性影响。
第二个信号是能够将模型变化与执行变化区分开的对比证据。评估应明确哪些组件发生了变化，以及如何衡量成功。这将帮助买方判断所报告的收益究竟来自 harness、模型，还是两者的交互。
独立评估将增加可信度，尤其是在其披露失败类别和审查要求的情况下。一项聚焦已完成工作的比较，会比仅聚焦活动量的比较更直接地强化 Microsoft 的论点。显示结果高度依赖配置的发现，则会缩小该主张可被广泛适用的范围。
竞争动态也应纳入同一比较之中。Anthropic 托管产品的变化，或其他供应商执行方式的变化，都可能改变可选方案。买方应根据稳定的应用需求比较服务，避免市场不断变化使评估演变为无休止的功能追逐。
第三个信号是客户在初始部署速度之外的报告。有价值的案例应描述持续运行、可接受的结果、修正工作量，以及客户保留的责任。较低维护成本与可靠结果并存的证据，将增强购买共享执行层的理由。
若案例显示存在大量定制工作，则需要更谨慎地解读。定制可能反映有价值的业务专业化，也可能反映托管服务的缺口。理解适用的是哪种解释，比单纯统计客户编写了多少代码更重要。
这些信号也提供了一种重新审视早先决定的实际方式。团队今天完全可以自行构建执行系统，之后再采用托管服务。另一支团队也可以从托管基础设施起步，并仅在这种安排持续满足其需求时继续保留它。
针对贵组织熟悉的工作流程评估 Microsoft Copilot harness。明确可接受的结果，识别哪些操作需要审批，并记录仍需人工修正的环节。以相同的证据和完成标准，将托管方案与现有方法进行比较。纳入信息来源质量、恢复行为，以及调查错误所需的工作量。让决策与团队实际能够委派的职责保持一致，并随着文档支持和客户证据的发展重新审视。Microsoft 的发布为完全在内部维护整个执行基础设施提供了一个具体替代方案。下一步应明确，这一替代方案能改善自身工作流程的哪些部分，以及哪些证据会改变你的决策。
