从 SDK 到受支持的运行时
8月上旬，微软将 Agent Framework 从"构建代理的库"推进到"运行代理的运行时"。核心组件 Agent Framework Harness 与 Foundry Hosted Agents 正式 GA（普遍可用）。此前框架在4月发布 1.0，整合了 Semantic Kernel 和 AutoGen；现在 Harness 把函数调用、历史持久化、上下文压缩、计划/执行模式、文件记忆、技能、网络搜索、工具审批、内置 OpenTelemetry 等九项能力，默认打包进一个二进制文件，跨本地、容器、托管部署一致运行。开发者只需提供聊天客户端、操作指南和自定义工具，一行调用就能拿到完整代理运行时。
所谓上下文压缩，是指代理在长对话或长工具调用链里，自动把历史摘要化，避免超出模型窗口而"失忆"——这类问题在真实长任务里会悄悄让代理中途出错，过去要各团队自己写代码处理。现在它成了开箱即用的默认能力，等于把最容易被忽视、也最容易埋坑的一环先堵上了。
安全默认，危险能力要手动开
设计上最值得企业关注的是"安全默认"：上述九项默认开启且可单独关闭；而 Shell 工具、文件访问、后台子代理、自动循环这些更危险的，默认关闭，开启时还会弹出警告。微软工程师的原话很直白："单有模型，只能生成文本。"代理要能调工具、跑多步任务、持续运行，靠的是外面这层运行时。
有第三方测试做了对比：同样的模型，Agent Framework 在第 40 轮自动刹车停住，而另一家 SDK 在宿主未设停止控制时跑到了 300 轮。对真正接入了能"动手"工具的代理，这种内置刹车不是小事——失控循环在接入真实系统后会放大成实际风险，而不是屏幕上的卡顿。
把第三方代理纳入同一治理
Foundry Hosted Agents 按用量计费，更重要的是它把 GitHub Copilot SDK、Claude Agent SDK、Azure OpenAI 乃至自研代理，放进同一套治理策略下管流量和 Trace。治理问题从"代理能做什么"变成了"是谁、按哪条策略、在哪里留痕"。在竞品格局里，它直接对标 LangChain、AWS Bedrock Agents 和 OpenAI 的代理方案，差异点在于"运行时治理"而非"构建便利"。
按用量计费的托管模式，意味着企业不用先养一支基础设施团队，就能让多个来源的代理在同一治理下跑起来；代价是调用量和 Trace 都在微软云里，选型时要权衡便利与数据驻留，尤其对金融、医疗等敏感行业。
对想做企业级 Agent 的团队
- 不必再自研"代理装配层"。MBZUAI 一篇分析 Claude Code 的论文估算，代理代码里约 98% 是装配层（运行时、权限、上下文、工具路由），只有约 2% 是模型决策。微软把这块做成受支持的产品，能省掉大量重复工程。
- 选型可以"模型无关"。Harness 能托管任意模型，包括竞争对手的，企业不用被单一云绑定。
- GA 不等于万能。代理权限、数据边界、审计留痕这些老问题仍在，只是从"自己造"变成"配置好"。
代理框架之争，正从"谁更好构建"转向"谁更好运行和治理"。微软这次把运行时产品化，等于把竞争维度抬高了一层——当大厂把"运行时"本身做成商品，企业做 Agent 的门槛在下降，但责任边界也更清晰：工具好用，治理不能省。
信息来源
- AgentMarketCap《Microsoft's Agent Harness Goes GA: The Runtime Becomes the Product》（2026-08-08）https://agentmarketcap.ai/blog/2026/08/08/microsoft-agent-framework-harness-ga-governed-runtime
- AI产品库《微软Agent Harness正式GA 一键封装》（2026-08-03 宣布/8月初 GA）https://aiproducthub.cn/newsflash/microsoft-agent-framework-harness-ga-stable-runtime-released
- ByteIota《Microsoft Agent Harness Is GA: Ship Agents Now》（2026-08）https://byteiota.com/microsoft-agent-harness-ga