要解决的问题
一个技能在单个智能体上跑通只是起点。要让多个智能体共用，常见做法是各存一份副本，但技能一更新，所有副本都得同步。来源文章（Microsoft Foundry 博客，2026-10-12）讨论的就是这个分发问题：技能放在哪里，才能让兼容的智能体按需找到并加载。
来源文章的要点
文章介绍的是 MCP 的官方 Skills 扩展，标识为 io.modelcontextprotocol/skills，对应提案 SEP-2640，文章称其已达到 Final 状态。它建立在 MCP 的资源机制之上，增加了"列出服务器提供哪些技能"以及"取得加载所需信息"的标准方式。它不改变技能格式，也不在服务器端运行技能。如何向用户或模型展示技能、如何加载指令，仍由运行智能体的宿主（host）决定。
流程大致是三步：先列出可用技能，再选择，最后读取所需内容。服务器可以提供清单（manifest），记录每个文件的地址、大小和 SHA-256 摘要。宿主读取文件后，要核对大小与摘要，也要核对前置元数据是否与列表一致。不需要的文件不会被读取。
文章还说明，经过校验只能证明内容与服务器所列一致，不代表内容安全或指令质量高。读取脚本也不等于获得执行权限，执行前宿主必须取得用户的明确批准。
Foundry 的位置
文章称，Microsoft Foundry 目前以预览形式支持技能，通过 toolbox 提供统一的 MCP 端点。做法是：在 Foundry 项目中上传技能版本，在同一项目的 toolbox 里加入技能引用，再让支持此方式的智能体连接该端点。文章给出的 REST 示例中，技能引用与 tools 是分开的字段，空的 tools 数组对只含技能的 toolbox 同样有效。
我的分析
以下为作者观察，不属于来源事实。
- 对团队而言，最直接的收益是技能有了单一来源。更新只需发布一次，各智能体不再各自维护副本。
- 摘要与大小校验把"技能内容被悄悄改动"变成宿主可以发现的事件。这对多团队共享技能的场景很有价值。
- 开发者需要分清三件事：服务器端是否实现了扩展，宿主是否支持，以及审批与执行控制是否到位。只能调用 MCP 工具，并不意味着具备远程技能能力。
- 如果你已经在用 Foundry 的 toolbox，这是一个低成本的试验入口。但目前是预览，不宜直接依赖在生产流程里。
值得继续观察的问题
- 文章指出客户端支持仍在发展中。哪些主流宿主会跟进，何时跟进，目前不清楚。
- 文章提到 Foundry 的测试端点在初始化时返回的协议版本是 2025-11-25，与文中通用示例使用的 2026-07-28 版本不同。两者何时统一是值得留意的问题。这属于推测性的关注点，并非来源给出的结论。
- 预览期的接口、区域支持和权限要求可能变化，需要以官方文档为准。
来源
- Microsoft Foundry Blog：https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/delivering-agent-skills-over-mcp/4562722
- 作者:月明
- 链接:https://lunalight.top//article/azure-foundry-4562722
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
