Enterprise AI | The .NET Blog

Microsoft Foundry 2026 年 6 月：从功能更新到受治理的智能体平台

Emiliano Montesdeoca — Sat, 18 Jul 2026 00:00:00 +0000

2026 年 6 月的 Foundry 更新不仅仅是一个月度摘要。它标志着一个从"构建酷智能体"到"将智能体作为受治理的企业系统来运维"的成熟度转型。这一区别比任何单一功能都重要。

原文来源：https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/

三个更新定义了这一转变。首先，智能体发布到 Microsoft 365 Copilot 和 Teams 达到 GA，将分发从自定义集成项目转移到一个有意见的部署通道。其次，Toolboxes 获得了更强的发现和执行控制，包括工具搜索和 routines。第三，可观测性加优化变成了一个有意识的闭环，而非事后想法。

我的看法：这是版本中最重要的模式。追踪、评估、优化和受控推广组成了非确定性系统的最小可行运维模型。如果你只有其中一个，你拥有的是遥测或调优，而不是治理。

Foundry 内部的 Claude GA 也具有战略意义，但主要不是因为模型质量。更大的价值在于企业集成：Entra 认证、RBAC、计费连续性和策略一致性。从直接模型端点迁移到 Foundry 的团队应将此视为运维整合，而非仅仅是提供商切换。

Autopilot 智能体前景广阔，但组织应以清醒的架构选择来对待它们。Teams 中的共享空间协作可以解锁生产力，然而它也迅速带来身份、权限和问责的复杂性。从有界范围开始，在广泛部署之前设置严格的审批检查点。

实用建议：

如果你已经在试点阶段，优先进行仪表化而非能力扩展。先接入 GenAI 追踪。然后建立与业务结果（而非通用模型指标）绑定的评估套件。只有在这些之后，才运行优化循环和推广工作流。
对于 toolbox 密集型智能体，尽早启用工具搜索，以在目录增长时减少上下文噪音和错误工具选择的风险。
对于启用记忆的智能体，提前定义 TTL 和保留策略。没有生命周期控制的记忆会成为合规债务。

我能得出的最个人化的结论是：Foundry 现在更少关于"我该选哪个模型？"，而更多关于**“我能将智能体行为作为受管理的生命周期来运行吗？”** 能回答好第二个问题的团队，将轻松适应模型更替。执着于模型排名的团队将每季度重建脆弱的栈。

6 月的发布让一件事变得清晰：Foundry 正在成为AI 系统的运维平台，而不仅仅是一个开发工具包。这是一个更难构建的产品，也是一个更有价值去采纳的产品。

Agent Skills for .NET 已经稳定，这改变了企业智能体架构

Emiliano Montesdeoca — Sat, 11 Jul 2026 00:00:00 +0000

Agent Skills for .NET 达到稳定是当前智能体生态中最实用的里程碑之一。它解决了一个核心的规模化问题：领域专业知识不应该属于一个巨大的指令块内部。

原文来源：https://devblogs.microsoft.com/agent-framework/agent-skills-for-net-is-now-released/

其设计既优雅又务实。Skills 将指令、资源和可选脚本打包为可复用单元，通过渐进式披露按需加载。这保持了上下文精简，减少了提示词膨胀，并实现了跨团队的专业知识所有权。

我的观点：这是 .NET 技术栈中实现企业级智能体可维护性的第一条可信路径。没有模块化的专业知识边界，每一次新的策略或手册更新都会变成脆弱的提示词手术。

这里最重要的不仅仅是模块化，而是治理。内置的加载技能、读取资源和运行脚本的审批模型，正好解决了安全团队在智能体从演示走向生产时提出的操作担忧。可扩展的脚本执行模型也明确了责任：如果你想要基于文件的脚本执行，你需要自己负责沙箱和审计。

实用采纳模式

从基于文件的 skills 开始——适用于由混合技术团队维护的策略密集型内容。
使用基于类的 skills——当你需要通过 NuGet 进行包分发并有更严格的工程生命周期控制时。
保留代码定义的 skills——用于需要状态化组合的动态运行时组装。

尽早添加筛选功能。并非每个技能都应该对每个智能体或租户可见。经过策划的技能可见性既是安全控制，也是相关性控制，能提高路由质量。

同时，记录一切：技能选择、资源读取、脚本执行请求和审批。如果你的事件审查无法重建哪个技能影响了回答，那你就没有生产级的可观测性。

更大的战略转变是：skills 将智能体行为转变为可组合的供应链。团队可以对专业知识进行版本控制、审查和发布，就像对待软件组件一样。这使得独立演进成为可能，而不必不断培训人类来重写巨型提示词。

核心观点

如果你正在企业级规模上构建 .NET 智能体，推迟采用这个模式会让你付出代价。你最终会遇到指令蔓延、策略应用不一致以及变更下的脆弱行为。

Agent Skills 并没有消除复杂性，而是将复杂性转移到可治理的组件中。这正是成熟的软件架构应该做的。对许多团队来说，这次发布是 .NET 智能体工程开始看起来像真正平台工程的时刻。

AI 本身无法改变业务——围绕它的系统才能

Emiliano Montesdeoca — Sun, 14 Jun 2026 00:00:00 +0000

在最新的 Microsoft AI 平台文章中，有一句话我认为直击当前时刻的核心：

赢家不会是那些拥有最多演示的组织，而是那些将 AI 转变为用于实际工作的、受治理且持续改进的系统的组织。

这完全正确。

这是最好的战略性 AI 文章之一，因为它把层级定位对了

太多 AI 对话仍然停留在模型争论上。

哪个模型更聪明。哪个模型更便宜。哪个模型最新。

这些并非无关紧要的问题，但如果你以企业的视角思考，它们格局太小了。

源文章正确地把握了挑战的规模。它明确表示："决定成功的是 AI 周围的系统。"

这才是有用的框架。

因为真正的企业价值来自于模型周围的系统：

智能体是如何构建的
它们如何在企业上下文中落地
它们是如何部署的
它们是如何治理的
它们如何随时间改进

这就是分散的实验与真正的转型之间的区别。

为什么我认为这个框架如此重要

如果你只关注模型，你得到的是短暂的优势。

如果你关注系统，你得到的是复利式的杠杆。

这是关键的区分。

这与 Foundry、GitHub、Microsoft IQ 和 Agent Framework 最近的发展方向高度吻合。

我的看法

这是该批次中较强大的战略性文章之一，因为它将 AI 描述为工作的操作系统，而非一组孤立的演示。

这正是企业实际需要思考的层面。

老实说，公共领域的 AI 对话应该更多地发生在这个层面上。

原文：AI alone won’t change your business. The system running it will.