微软 Agent Framework Harness 正式发布：智能体的运行时成了产品

发布了什么

微软把 Agent Framework 从 SDK 推进到受支持的生产运行时。1.0 版本在 2026-04-02 发布；6 月 2 至 3 日的 Build 2026 上，Agent Harness、GitHub Copilot SDK 与 Claude Agent SDK 连接器、以及多智能体编排模式进入稳定版；此次 Harness 与 Foundry Hosted Agents 正式发布。Harness 是单个二进制文件，本地开发环境、容器和托管部署跑的是同一个东西。

默认开启、且可逐项关闭的能力：函数调用、每次调用历史的持久化、上下文压缩、带计划与执行两种模式的待办清单、文件记忆、技能、网络搜索、工具审批，以及内置 OpenTelemetry。Shell 工具、文件访问、后台子智能体和自动循环仍是可选，而且启用时会发出警告。开发者只提供聊天客户端、指令和工具，其余由一次 create_harness_agent 调用接管；Foundry Hosted Agents 作为托管部署目标按用量计费。

为什么一个运行时值得单独看

微软首席软件工程师 Wes Steyn 的说法是：模型本身只能生成文本；要让它调用工具、处理多步任务并持续运行到完成，必须把它包在一个运行时里，而那个运行时就是 Harness。

支撑这句话的是一个具体数字。MBZUAI 旗下 VILA 实验室 2026 年 4 月的论文《深入解析 Claude Code》分析了 v2.1.88——该版本完整 TypeScript 源码曾在 3 月 31 日因一次带 source map 的 npm 发布短暂曝光——统计得出 1884 个文件、约 512,000 行代码，其中约 98.4% 属于 Harness 基础设施：权限管理、上下文管理、沙箱、工具路由与恢复机制；AI 决策逻辑约占 1.6%。

这个数字带着星号，而且是作者自己标的：它是对泄露包的行数分类，包含生成代码与压缩代码，不是一次完整审计。但趋势另有旁证——Codex CLI 与 Aider 各自独立演化出了相同的 Harness 结构。三个团队分别走到同一个形状，更像是问题施加的约束，而不是某一家的设计偏好。

那个 40 对 300

微软 AI 首席架构师 Aqib Sherwani 做的对比测试比多数厂商基准克制：固定模型参数，并先跑一个确定性的模拟测试，确保差异可以追溯到 Harness 而不是模型。结论是「推理相同，工程实现不同」——两个运行时在相同步数内给出了相同答案。

差异出现在护栏失控这一项：Agent Framework 在 40 次往返后自行终止循环并返回「达到限制」；而在关闭宿主端停止控制机制的情况下，Copilot SDK 一直跑到 300 次仍不自停。

一个把刹车放在循环内部，另一个默认由宿主提供。这不是性能差异，是责任归属的差异——而它只在宿主那一侧恰好没做的时候才会暴露出来。这正是《人在回路的审查》里那条判据的机器版本：一个从不触发的限制，和没有限制无法区分。

治理的问题换了一个

编码智能体连接器不需要自定义适配器就能把任务委派给 GitHub Copilot SDK 或 Claude Agent SDK，每个智能体跑自己的自主循环；但连接器严格遵循为整个集群设置的身份、内容安全与可观测性策略——编码智能体的流量进入同一批 OpenTelemetry 跟踪和 Foundry 仪表板，而不是成为一个有独立访问模型的孤立集成。

于是治理的核心问题从「智能体能做什么」变成了三问：谁运行了它、依据什么策略、跟踪信息最终流向哪里。同样的控制层关注点也出现在亚马逊云科技的 Loom 参考平台里。编排模式与测试框架同步进入稳定版，覆盖顺序管道、并行协作，以及源自微软研究院 Magentic-One 的 Magentic 模式。

放在这条线上看

这是同一种收拢的第四种形态。MCP 2.0 把协议改成无状态，好让任意实例承接任意请求；Gemini API 用一个 background:true 把执行、状态与工具接入收到服务端；LLM 0.32 让供应商在单次请求内替你执行远程 MCP 调用——而这一条把运行时本身做成了按用量计费的产品。

一次 create_harness_agent 调用换来的是不必自己实现审批、压缩、持久化和遥测。它同时买走的是控制权，而这正是《系统设计的权衡》里那句话：默认值是别人替你做完的权衡。40 与 300 的差别说明这笔交易值得逐项看清楚——你要的是循环内部就有刹车的运行时，还是一个假设你会自己装刹车的运行时。