微软将 Agent Harness 与 Foundry Hosted Agents 推向正式可用,集中处理权限、上下文、沙箱、工具路由、恢复和可观测性。其核心思路是把模型视为可替换组件,将生产难点放在稳定的代理运行基础设施上。
AI Agent 的故事,大部分其实并不是 AI 的故事。这是 Build 2026 带来的一个令人不太舒服,却很有价值的结论。在这次大会上,Microsoft 宣布 Agent Harness 和 Foundry Hosted Agents 正式进入 General Availability(GA)阶段——这是一个真正可用于生产环境的运行时,而不是又一个实验性 SDK。
根据近期对 Claude Code v2.1.88 的研究,在一个 Agent 系统中,大约 98.4% 都是 Harness 基础设施:权限、上下文管理、沙箱、工具路由和故障恢复。只有 1.6% 是模型在做决策。Microsoft 刚刚把这 98.4% 做成了一个提供正式支持的产品。这才是这项发布真正值得理解的地方。
每一个尝试把编程 Agent 投入生产环境的团队,最终都会遇到同一个瓶颈:模型反而是最简单的部分。把模型接入你的工具、持久化对话历史、决定哪些操作需要人工批准、在耗尽 token 预算前压缩上下文、生成真正能够用于告警的遥测数据——这些才是真正的工作。
而在此之前,这些工作都要由你自己完成:编写一套专用的循环逻辑,没有支持合同,也没有明确的升级路径。
Microsoft 的判断——而且这是一个正确的判断——是:Harness 才是产品,模型只是一个可以随时替换的部件。
Build 2026 公布了两项内容:
Agent Harness——一个单独的二进制程序,负责处理任何 Agent 的核心运行能力:函数调用、每次调用的历史记录持久化、上下文压缩、支持规划与执行模式的待办列表、文件记忆、Skills、Web 搜索以及工具审批。默认内置 OpenTelemetry。
Foundry Hosted Agents——将同一个 Harness 作为托管服务部署,并采用按用量计费。你只需要提供聊天客户端、指令和工具;Harness 会通过一次 API 调用完成规划、历史记录管理、上下文压缩、审批、Web 搜索和遥测。
两者都可以在本地、容器或托管环境中运行。一个二进制程序,三种部署形态。这个框架还提供了稳定的多 Agent 编排模式,以及 GitHub Copilot 和 Claude Agent SDK 的连接器;两者都接入同一个治理策略平面。
[[DIAGRAM: 一条用户消息进入 Harness,Harness 调用模型,工具调用通过审批网关进行路由,历史记录被持久化,在下一轮交互前压缩上下文,每个步骤都会发送 OpenTelemetry span,随后循环返回模型,由模型做出下一个决策]]
这份功能清单,读起来就像是对 2024 年和 2025 年运行 Agent 循环的团队所遭遇的每一种故障模式,逐项给出的解决方案:
支持每次调用历史记录持久化的函数调用——Harness 会记住自己调用了什么、返回了什么,以及模型接下来又说了什么。不会再出现“Agent 忘记自己已经读取过那个文件”的情况。
上下文压缩——长时间会话不会撑爆 token 窗口。Harness 会决定何时进行总结,以及需要保留哪些内容。
支持规划与执行模式的待办列表——Agent 可以拆解任务、向你展示计划,并且只有获得批准后才开始执行。
文件记忆与 Skills——跨会话保存持久化上下文,同时提供 Harness 知道如何调用的可复用工具包。
Web 搜索与工具审批——所有对外调用都要经过同一个审批网关。你可以看到 Agent 请求执行什么操作,并选择批准或拒绝。
内置 OpenTelemetry——提供 spans、traces 和 metrics。每一次函数调用、每一次上下文压缩、每一个审批决定,默认都具备可观测性。
所有这些功能默认启用,同时每一项都可以单独移除。需要主动启用的功能——Shell 工具、文件访问、后台子 Agent、自动循环——在激活时仍然会发出警告。这就是直接内置在二进制程序中的治理立场。
托管版本之所以存在,是因为大多数平台团队并不想再维护一项服务。Foundry Hosted Agents 提供按用量计费的托管部署方式:你提交 Agent 定义,其余工作都交给平台处理。
其中真正值得停下来关注的是它的集成方式。你需要提供:
Harness 会通过一次 API 调用处理其余所有工作。规划、历史记录持久化、上下文压缩、审批、Web 搜索、遥测——所有这些能力都通过同一条代码路径运行,无论是在本地、容器还是托管环境中。你不需要另外学习一种独立的“托管”模式。
这才是一套真正适用于生产环境的方案:开发环境使用同一个二进制程序,预发布环境使用同一个二进制程序,生产环境仍然使用同一个二进制程序。变化的是账单,而不是行为。
该框架同时提供 GitHub Copilot 和 Claude Agent SDK 的连接器,并且两者都会接入同一个治理策略平面。具体到编程 Agent 的工作场景,这意味着无论 Agent 使用哪个模型进行推理,都可以共用同一套审批规则和审计轨迹。
连接器就是委托边界:Agent Framework 的编排层调用连接器,连接器与 Copilot 或 Claude 通信,结果再通过同一条遥测管线返回。即使替换模型,也能保持完整的可观测性,无需重写 Harness。
根据 Build 2026 的发布公告,这正是 Microsoft 在“增强编程 Agent 治理能力”方面重点强调的部分——底层模型可以改变,但审计日志不会改变。
该版本已经 GA,因此从零开始运行一个 Agent 的路径非常短。根据发布公告,Agent Harness 以单一二进制程序的形式分发,同一份制品同时支持本地开发、容器和托管部署:
# Pull the harness as a container for local-equivalent behavior
docker pull mcr.microsoft.com/agents/harness:latest
# Or install the CLI directly
dotnet tool install -g Microsoft.Agents.Harness
一个最小化的 Agent 定义只需要连接运行时所期待的三样东西——聊天客户端、指令和工具——其余工作则交给 Harness:
var agent = new HostedAgent {
ChatClient = new AzureOpenAIClient(env.OPENAI_ENDPOINT, env.OPENAI_KEY),
Instructions = "You review PRs and flag risky diffs.",
Tools = { new FileReadTool(), new GitDiffTool() }
};
await agent.RunAsync("Review PR #482");
对于 Foundry Hosted Agents,部署过程会把同一份定义注册到托管运行时;首次调用时即开始按用量计费。本地二进制程序与托管二进制程序共享同一套配置界面——在本地开发,再将其提升到托管环境,无需重写代码。
对于 GitHub Copilot 和 Claude SDK 连接器,相关连接器包会注册到与 Harness 本身相同的治理策略端点。无论 Harness 将任务委托给哪条模型路径,审批规则、审计日志和 OpenTelemetry traces 都会覆盖其中。
工具更迭是常态。今天的 Harness 来自 Microsoft;明天的 Harness 可能来自 Anthropic,也可能是某个开源重构版本。Harness 底层的模型还会不断变得更便宜、更快、更小——这是 AI 故事中真正与 AI 有关的那一半。
另一半——也就是那 98.4%——不会随着模型变化而变化。审批网关、历史记录持久化、上下文压缩、遥测、策略执行,以及决定接下来调用什么的循环逻辑。这才是值得投入的层,也是 OTF 所处的底层:一个统一的组件界面,让相同的基础组件在 Web、iOS 和 Android 上拥有一致的外观与行为,无论负责思考的是哪个模型或 Harness。
模型会变,Harness 的形态也会变。但把整个系统维系在一起的约束——一个 API、一条渲染路径,以及覆盖用户接触的每个平台的一套不变量——才是真正持久的部分。
使用 Microsoft 的新运行时吧。它确实是一套真正适用于生产环境的方案。同时,也要构建那些不会随着运行时改变而改变的部分。
Microsoft 的 Agent Framework 生产运行时,是大型平台厂商第一次把 Harness 层作为提供正式支持的 GA 产品交付,而不再只是一个参考实现。
98.4% 这个数字重新定义了我们讨论 Agent 的方式:模型是可以替换的部件,Harness 才是产品。Foundry Hosted Agents 负责部署,连接器负责适配不同模型,治理平面负责审计,而能够穿越所有这些变化继续存在的部分——应用程序与每个季度最热门的 Agent 运行时之间那层持久接口——才真正值得投入工程时间。
如需采取进一步措施,你可以考虑屏蔽此人和/或举报滥用行为。