正在加载，请稍候
微软 Harness 把 Agent Framework 从 SDK 推进到生产运行时。MBZUAI 拆出 Claude Code 51.2 万行：98.4% 是护栏不是模型——选型关键在运行时治理。
2026 年 8 月 10 日，微软正式发布 Agent Framework Harness 与 Foundry 托管服务。平台团队第一次拿到"能运行智能体的单个二进制"，而不只是"能构建智能体的 SDK"。这篇用 MBZUAI 的代码分析数据，聊清楚一件事：智能体运行时到底该怎么选。
该框架于 2026 年 4 月 2 日发布 1.0，把开源项目 Semantic Kernel 与 AutoGen 整合进来，两个前身项目转入维护模式。1.0 解决的是构建期问题：用哪个框架写智能体。6 月 2-3 日 Build 2026 上，Harness 组件、GitHub Copilot SDK 连接器、Claude SDK 连接器以及多智能体编排模式进入稳定发布阶段。8 月 10 日，它连同 Foundry 托管服务正式发布，进入生产可用。
它解决的是运行期问题：智能体在哪里执行、允许访问哪些资源、行为如何进入现有的可观测性和策略系统。微软首席软件工程师 Wes Steyn 的说法很直接：仅凭模型本身只能生成文本，要让它调用工具、处理多步任务、持续运行直至完成，需要运行时封装——官方把这个运行时命名为 Harness。单个二进制可跨本地开发、容器和托管部署运行。
开发者只需要提供聊天客户端、操作指南和工具，一次调用就能拿到完整的运行能力：
client = FoundryChatClient(credential=AzureCliCredential())
harness = create_harness_agent(
client=client,
agent_instructions="You are a research assistant. Plan your work, then execute it.",
tools=[], # add your own callable tools here
)
resp = await harness.run("Research the outlook for renewable energy stocks.")本次发布把过去团队要自己拼的运行时能力做成了默认项，而不是可选插件。按 InfoQ 报道，以下能力默认启用，可单独禁用：
| 能力 | 说明 | 备注 |
|---|---|---|
| 函数调用 | 模型到工具的调用通道 | 默认 |
| 历史持久化 | 每次调用记录落库，可追溯 | 默认 |
| 上下文压缩 | 长对话自动压缩，控制 token 成本 | 默认 |
| 计划/执行待办列表 | 带计划和执行两种模式的任务队列 | 默认 |
| 文件记忆 | 跨会话状态保留 | 默认 |
| 技能 | 可复用技能包 | 默认 |
| 网络搜索 | 内置检索能力 | 默认 |
| 工具审批 | 敏感工具调用需人工确认 | 默认 |
| OpenTelemetry | 遥测直出，接入现有监控 | 默认 |
| Shell 工具 / 文件访问 / 后台子代理 / 自动循环 | 高权限能力 | 可选，启用时带警告 |
注意最后一行：Shell、文件访问、后台子代理、自动循环仍然是可选功能，启用时会发出警告。这个设计本身就在告诉你，哪些能力是"默认安全"的。Foundry 托管服务按使用量计费。
为什么一个受支持的官方运行时比表面上更重要？MBZUAI 旗下 VILA 实验室 2026 年 4 月发表的论文《深入解析 Claude Code》给出了具体数据：研究人员分析了 Claude Code v2.1.88 的完整 TypeScript 源代码——3 月 31 日 Anthropic 发布含源映射包的 npm 版本时短暂曝光——共 1884 个文件、约 51.2 万行代码。估算结果是：约 98.4% 的代码属于运行时基础设施（权限管理、上下文管理、沙箱机制、工具路由、恢复机制），AI 决策逻辑仅占约 1.6%。
论文作者自己也加了星号：这是对泄露包的代码行分类，包含生成代码和压缩代码，不是全面审计。但即使打折看，趋势依然成立：多个独立开发的产品，包括 Codex CLI 和 Aider，都采用了相同的运行时结构。这说明它是问题约束，而非某家厂商的设计选择——任何要"持续运行、能调用工具、能恢复"的智能体，都得先把 98% 的力气花在护栏上。
这对选型的含义很直接：你真正在比较的不是"谁的模型决策更聪明"，而是"谁的运行时把权限、上下文、沙箱、恢复这些脏活干得更可靠"。
微软人工智能首席架构师 Aqib Sherwani 做了一项比大多数厂商基准更严谨的对比：固定模型参数，先跑确定性模拟测试，确保差异可追溯至运行时。结论是"推理相同，工程实现不同"——该框架与 GitHub Copilot SDK 在相同步数内得出相同答案，差异只存在于运行时。
最关键的差异是安全护栏失控。微软框架在 40 次往返循环后自行终止，返回"达到限制"；而关闭主机端停止控制机制后，Copilot SDK 会持续运行至 300 次而不自行停止。一种运行时把刹车放在循环内部，另一种期望主机提供刹车。对生产系统来说，这决定了一次失控循环是 40 步止损还是 300 步烧钱。
编码代理连接器让治理落地：编排层无需自定义适配器即可把任务委托给 GitHub Copilot SDK 或 Claude SDK，A2A 与 MCP 协议谁主生产环境 一文对这类互联互通做过详细拆解。每个代理跑自己的自主循环，但连接器严格遵循为代理集群设置的身份、内容安全与可观测性策略。编码代理流量与普通流量一样进入相同的 OpenTelemetry 跟踪和 Foundry 仪表板。治理的核心问题已经从"代理能做什么"变成"谁运行了它、依据什么策略、遥测流向哪里"。
把微软官方运行时与 LangChain 托管、Cloudflare Kitesurf 等托管方案放在一起看时，本文只对微软侧数据负责——各厂商具体能力请以官方文档为准。决策维度是一样的：治理、可观测性、计费模型、团队维护成本。想先看各家框架整体图谱，可参考我们整理的11 个主流框架选型指南。
| 路径 | 适用团队 | 推荐做法 | 理由 |
|---|---|---|---|
| A：直接上官方运行时 | 10 人以下、探索期 | 本地跑单二进制，用默认能力清单 | 省掉自建运行时，审批与遥测开箱即用 |
| B：Foundry 托管 | 已有云基础设施的平台团队 | 托管目标按量计费，遥测并入现有监控 | 不维护运行时，成本随用量走 |
| C：自建 / 私有化 | 强合规、数据不出域 | 基于开源运行时自建，审批、审计、遥测当一等公民 | 控制面在手里，但维护成本最高 |
三条路不是互斥的：很多团队会从 A 验证、B 上量，等合规要求出现再切 C。关键是切换时编排模式共享同一套 API——微软这次的顺序管道、并行协作、Magentic 模式共享 API，改协调风格不用重写代码。多智能体并行协作的具体工程做法，可以看这篇多智能体协作编程实战。Magentic 模式源自微软研究院 Magentic-One，2024 年评估在 GAIA 达到 38%、AssistantBench 27.7%、WebArena 32.8%，前两项统计上与当时 SOTA 相当。
我们接触过的某行业客户（脱敏）一开始把官方 SDK 当运行时用：自己写循环、自己接日志、自己调上下文压缩。等到要上生产，发现工具审批、审计追踪、OpenTelemetry 全得补，等于把官方运行时内置的能力重新实现一遍。返工周期比预期多出两到三周，而且自写代码的可靠性远不如官方实现。这类问题并不少见，4590 组实验里的多智能体重复犯错 讲的就是类似场景。
这个方案的边界也要说清楚：如果团队要深度定制调度策略、对接自研沙箱、或对每个内部环节做精细替换，自建仍然合理。但如果你要的只是"让智能体在受控环境里可靠地跑"，那 98.4% 的脏活已经有人做好了，别重复造。
1.0 整合了前身项目，官方运行时负责执行、资源授权与遥测接入，团队不用再纠结构建期选型。
SDK 是构建库，官方 Harness 是生产运行时：函数调用、持久化、压缩、审批、OpenTelemetry 默认可用，高权限项可选并带警告。
MBZUAI VILA 实验室对 Claude Code v2.1.88 的 51.2 万行代码做行分类，只有 1.6% 是决策逻辑，其余均为权限、上下文、沙箱、恢复等基础设施。作者注明该估算基于泄露包，非全面审计。
.NET 和 Python，框架与连接器均已在 GitHub 开源。
按使用量计费，适合不想维护运行时、成本随用量走的团队。
如果你的平台团队正在做智能体运行时选型，欢迎把场景与约束发给我们——蓝曜炬辉在 RAG、多智能体编排与运行时治理上有实际交付经验，可以在联系页说明需求。