11 月 7 日，微软 Copilot Studio 团队发布了一份技术白皮书；两天后，又补了一篇面向 makers 的解读文章。里面有一组对比，值得正在做企业 AI 项目的人停下来看一眼：同一批任务、同一批模型，只把智能体背后的执行框架从 Standard harness 换成 Microsoft Copilot harness，复杂任务的通过率变成 78%（OpenAI 模型）和 89%（Anthropic 模型），最多提升 22 个百分点（微软 Copilot 博客，白皮书见 aka.ms/MCSQuality/Whitepaper）。
模型没有换。多出来的二十几个点，来自大量原本"跑不完"的任务变成了"跑得完"。
一次工具调用失败，不该让整个任务重来
所谓 harness，是决定智能体怎么规划、怎么调用工具、怎么给出回答的那层引擎。它不像模型参数那样能拿来做宣传，却直接决定了任务能不能收尾。
微软给了一个很直白的算术：如果每一步有 5% 的失败概率，听起来不高，但一个 10 步的任务里至少一步失败的概率会爬到 40% 左右。一个遇到第一次失败就交还给人处理的智能体，等于把这四成任务提前判了死刑——无论它背后的模型多聪明。
换成持续循环的框架之后，数据变了：工具调用失败时，智能体在 84%–91% 的情况下继续往下做；大约五次里有两次，先前失败的那个工具会在同一段对话里最终调用成功。失败不再是终点，而是又多了一条可以处理的信息。
这也是企业验收里最容易被放过的一处。演示环节通常是一问一答，跑得漂亮；真实业务流程是几十步、要中途核对、数据量超过一个提示词能装下的上限。微软提到一个 5 万行的导出文件——在带命令行和文件系统的容器里，它被存成文件、用代码去查询和抽样，而不是硬塞进上下文。
调用次数几乎翻倍，Token 账单反而降了
更反直觉的是成本。同一批任务上，Microsoft Copilot harness 的模型调用次数接近原来的两倍，但按成本加权的输入 Token 下降了 15%–21%，其中 83%–88% 的输入直接来自缓存。
原因不复杂：每一步都建立在已经完成的工作上，而不是推倒重来。多调用几次，换来的是不重复搬运上下文。
这对采购和报价的口径是个提醒。按千 Token 单价比较模型，和按"完成一个任务的总成本"比较方案，常常得出相反结论。前者算的是单价，后者才是账单。
最不性感的一环：工具本身好不好用
同一份材料里还有一组数字容易被忽略。Excel Online 连接器此前的成功率是 85.6%。排查后发现，多数失败并不怪 Excel，而是智能体"用对了动作、带错了预期"——比如向一个根本没有表格的工作簿索要表格。团队给 harness 加了几个只读的探测工具，让它先确认有哪些文件、表和列，再用线上遥测调优行为，成功率升到 96.3%，而 makers 不需要改任何设置。
放在定制项目里，这就是那些自建接口、老 ERP、行业系统的对接层。字段含义、前置条件、空数据怎么返回，文档里少写一句，模型就会理直气壮地问错问题。真正花时间的往往不是接上，而是把"对方实际怎么工作"这件事补全。
安全边界同理。按微软的描述，智能体本身不持有密码和凭据，也不直接访问企业系统，凭据管理、模型调用治理和连接器执行都留在平台侧。对交付方来说，这意味着权限模型要在设计阶段就切好，而不是上线前补一层网关。
执行层正在变成基础设施
这轮变化不只发生在微软。据 36 氪 11 月 10 日的报道，DeepSeek 在 8 月以 MIT 协议开源了自己的 harness，Kimi 在 11 月 5 日推出 Hosted Agents，Anthropic 和 OpenAI 也把执行层单独打包；微软则把原来的 GitHub Copilot harness 统一改名为 Microsoft Copilot harness，作为 Copilot Studio 的默认可选能力。
如果调度循环、重试、上下文缓存最终都由平台提供，定制与交付的价值就要往别处挪：业务工具的质量、贴合本行业的任务评测集、失败恢复策略，以及上线之后长达数年的迭代。这些东西不会因为换了个更强的模型就自动变好。
一个可操作的判断是：下次评审 AI 项目，少问"用的是哪个模型"，多问三个问题——任务失败一次之后系统会做什么、通过率是在多少步的任务上测出来的、单个成功任务的成本是多少。这三个问题，恰好是 harness 这一层能回答、而模型榜单回答不了的。
需要说明的是，上述数字来自微软自家的评测任务与生产数据，并非第三方审计，具体口径以其白皮书为准。但方向足够清楚：企业 AI 项目的分水岭，常常不在选了哪个模型，而在有没有人把"跑不完的那部分"当工程来做。