<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Toolboxes | The .NET Blog</title><link>https://thedotnetblog.com/zh/tags/toolboxes/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>zh</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Sat, 18 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/zh/tags/toolboxes/index.xml" rel="self" type="application/rss+xml"/><item><title>Microsoft Foundry 2026 年 6 月：从功能更新到受治理的智能体平台</title><link>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/microsoft-foundry-june-2026-from-features-to-platform/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/microsoft-foundry-june-2026-from-features-to-platform/</guid><description>6 月的 Foundry 更新标志着一个平台转型：分发、工具、记忆、可观测性和优化正在融合成一个企业级的智能体运维栈。</description><content:encoded>&lt;p&gt;2026 年 6 月的 Foundry 更新不仅仅是一个月度摘要。它标志着一个从&amp;quot;构建酷智能体&amp;quot;到&amp;quot;将智能体作为受治理的企业系统来运维&amp;quot;的成熟度转型。这一区别比任何单一功能都重要。&lt;/p&gt;
&lt;p&gt;原文来源：https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/&lt;/p&gt;
&lt;p&gt;三个更新定义了这一转变。首先，智能体发布到 Microsoft 365 Copilot 和 Teams 达到 GA，将分发从自定义集成项目转移到一个有意见的部署通道。其次，Toolboxes 获得了更强的发现和执行控制，包括工具搜索和 routines。第三，可观测性加优化变成了一个有意识的闭环，而非事后想法。&lt;/p&gt;
&lt;p&gt;我的看法：这是版本中最重要的模式。&lt;strong&gt;追踪、评估、优化和受控推广&lt;/strong&gt;组成了非确定性系统的最小可行运维模型。如果你只有其中一个，你拥有的是遥测或调优，而不是治理。&lt;/p&gt;
&lt;p&gt;Foundry 内部的 Claude GA 也具有战略意义，但主要不是因为模型质量。更大的价值在于企业集成：Entra 认证、RBAC、计费连续性和策略一致性。从直接模型端点迁移到 Foundry 的团队应将此视为运维整合，而非仅仅是提供商切换。&lt;/p&gt;
&lt;p&gt;Autopilot 智能体前景广阔，但组织应以清醒的架构选择来对待它们。Teams 中的共享空间协作可以解锁生产力，然而它也迅速带来身份、权限和问责的复杂性。从有界范围开始，在广泛部署之前设置严格的审批检查点。&lt;/p&gt;
&lt;p&gt;实用建议：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;如果你已经在试点阶段&lt;/strong&gt;，优先进行仪表化而非能力扩展。先接入 GenAI 追踪。然后建立与业务结果（而非通用模型指标）绑定的评估套件。只有在这些之后，才运行优化循环和推广工作流。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;对于 toolbox 密集型智能体&lt;/strong&gt;，尽早启用工具搜索，以在目录增长时减少上下文噪音和错误工具选择的风险。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;对于启用记忆的智能体&lt;/strong&gt;，提前定义 TTL 和保留策略。没有生命周期控制的记忆会成为合规债务。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;我能得出的最个人化的结论是：Foundry 现在更少关于&amp;quot;我该选哪个模型？&amp;quot;，而更多关于**&amp;ldquo;我能将智能体行为作为受管理的生命周期来运行吗？&amp;rdquo;** 能回答好第二个问题的团队，将轻松适应模型更替。执着于模型排名的团队将每季度重建脆弱的栈。&lt;/p&gt;
&lt;p&gt;6 月的发布让一件事变得清晰：Foundry 正在成为&lt;strong&gt;AI 系统的运维平台&lt;/strong&gt;，而不仅仅是一个开发工具包。这是一个更难构建的产品，也是一个更有价值去采纳的产品。&lt;/p&gt;</content:encoded></item></channel></rss>