微软通过Foundry押注企业AI战场的关键在于可靠性而非能力
在微软Build 2026大会上,微软发布了Microsoft Foundry的一系列更新,旨在使AI代理对企业用户更可靠、更可治理。新功能包括托管代理运行时、通过工具箱进行的工具治理、基于策略的评估(ASSERT)、开放代理控制规范(ACS)、多种记忆类型和知识集成。此举表明微软关注的是生产级代理基础设施,而非原始能力。
在人工智能代理的浪潮中,演示环节从不缺乏令人印象深刻的作品。然而,真正能经受住生产环境考验——面对真实负载、真实数据、真实合规要求——的代理却寥寥无几。在最近的微软Build 2026大会上,微软直接针对这一差距,发布了Microsoft Foundry的一系列更新,这些更新共同构成了一套更接近企业级运行时的产品,而非简单的开发者预览版。
微软发布了一系列涵盖托管代理基础设施、评估工具、开放治理规范、记忆、知识检索和扩展模型选项的更新。单独来看,每一项都是合理的产品更新。但综合起来,它们表明微软已认定企业AI的下一个竞争前沿不是能力,而是可靠性和可治理性。
“在Build 2026上,Microsoft Foundry增加了开发者在生产环境中运行代理所需的更多平台组件:运行时、工具、记忆、基础连接、模型、可观测性和治理,”微软高级项目经理Nick Brady在总结这些公告的博客文章中写道。
无需重写的运行时
基础设施故事的核心是Foundry代理服务中的托管代理,微软预计将在2026年7月初达到正式发布(GA)状态。该设置是一个托管运行时,其中每个会话都在自己的沙箱中运行,拥有专用的计算、内存和持久文件系统访问权限。
值得关注的是其框架中立性。基于微软代理框架、GitHub Copilot SDK、LangGraph或其他SDK构建的代理无需重写即可部署。支持两种协议:用于兼容OpenAI的有状态交互的Responses API,以及用于直通场景的调用协议,开发者可以自行控制请求和响应格式。第二种选择对于已经构建了自定义编排且不愿废弃的团队来说至关重要。
托管运行时还支持例程(现为公开预览),允许任何代理按定时或计划运行——例如过夜问题分类、每日报告等。长时间运行的自主代理可获得持久状态。
与运行时一起,Foundry Toolkit for VS Code现已正式发布。Brady将其描述为让开发者“从模板或使用GitHub Copilot创建代理,通过跟踪可视化本地调试运行,连接到工具箱,并从VS Code部署到Foundry代理服务”的工具。
工具箱与工具治理问题
随着代理工具数量的增长,工具治理本身也成为一个工程问题。Foundry中的工具箱(现为公开预览)为代理提供了一个单一的管理端点,用于所有工具类型。只需配置一次,让任何MCP客户端指向一个URL,Foundry即可处理身份验证、生命周期和治理。
技能(在项目级目录中进行版本控制,并作为MCP资源可发现)现在在工具箱模型中成为一等公民。工具搜索功能(同样处于预览阶段)有助于为每项任务选择合适的工具,而不是将整个目录转储给模型。这对于质量和防止上下文窗口膨胀都很重要。
工具箱还连接到微软IQ——包括Work IQ、Fabric IQ(与Fabric数据代理)、Ontology和语义模型——因此代理可以访问企业数据,而无需为每个来源自定义管道。
基于策略的评估,而非仅仅基准测试
两项治理公告脱颖而出。第一项是ASSERT(自适应规范驱动的评估与回归测试),微软的新的开源框架,用于策略驱动的代理评估,基于微软研究院的工作。ASSERT不是针对静态基准测试运行代理,而是将书面策略转化为具体、可衡量的评估,并生成针对性场景,以在生产之前发现安全和质量缺陷。它支持LangChain、CrewAI、LightLLM、OpenAI等框架。
第二项是ACS(代理控制规范),一个开放的行业规范,用于在代理生命周期的五个检查点(输入、LLM、状态、工具执行和输出)设置确定性的安全和安全控制。ACS表示为可移植的YAML契约——可版本化、可审计且框架无关。发布合作伙伴包括Infosys、KPMG、IBM、Aviatrix、BigSpin和CrewAI。
两者的结合指向了一个真实问题。生产中的代理失败往往不是随机的——它们集中在可预测的输入类型、工具滥用模式和输出边缘情况上。ASSERT使这些失败模式可测试。ACS使控制可跨框架移植且跨组织可审计。
评估堆栈的其余部分包括:Guided Guardrail Setup,一个基于问卷的向导(在Foundry代理构建器中),推荐PII过滤器、越狱保护和任务遵循控制,无需安全专业知识;以及Rubric评估器,可根据代理的定义和用例自动生成加权质量标准。
记忆与知识
Foundry代理服务中的记忆(公开预览)现在涵盖三种类型。Build新推出的程序性记忆帮助代理学习跨运行如何工作——而不仅仅是会话中说了什么。Brady引用了早期的Tau-bench结果,显示成功率绝对提升7-14%,成本近乎基线——这足够具体,值得独立复现。用户记忆跨会话保留偏好和事实。会话记忆在线程内维持上下文。
在知识方面,Foundry IQ获得了公开预览中的无服务器选项,新的知识源包括Work IQ、Fabric IQ、文件搜索、Azure SQL和MCP,以及知识库(公测版,带有SLA支持的检索)。Brady的定位是:用‘Foundry代理背后专门的知识层’替代自定义RAG管道。Web IQ为需要实时外部上下文的代理提供了低于200毫秒的网络基础连接,零数据保留。
模型与计算
微软宣布四个第一方MAI模型进入公开预览:用于聊天和推理的MAI-Thinking-1,用于图像生成和编辑的MAI-Image-2.5,用于带说话人分离的语音转文本的MAI-Transcribe-2,以及用于多语言文本转语音和语音克隆的MAI-Voice-2。
Fireworks AI on Foundry达到正式发布,通过单个Azure端点提供开放模型推理,具有企业SLA、SOC 2就绪和PTU数据区域支持——无需单独基础设施或合同即可企业级访问开放模型。
微软还声称,对于生成技术微软文档等任务,Frontier Tuning的成本效率比GPT-5.5高10倍以上。这足够具体以测试,也足够笼统,在验证之前值得怀疑。
更大的图景
Brady的总结明确表明,Build 2026上的Foundry公告是设计来相互配合的。托管运行时处理部署。工具箱处理工具治理。ASSERT和ACS处理评估和控制。记忆处理状态。Foundry IQ处理基础连接。Rubric和Agent ROI将代理性能与业务成果联系起来。Rubric是Microsoft Foundry中一种新的评估器类型(目前公开预览),可根据代理的具体上下文自动生成评估标准。
微软认为,企业级代理AI需要平台级基础设施——而该平台应该是Foundry。
这一论点能否成立,将不取决于Build上发布了什么,而取决于企业在尝试将代理从演示迁移到部署时实际发现什么。
微软表示,他们正在弥合这一差距。