从100个工具缩减至3个：Prime Video的渐进式工具发现方法

来源: Agentic AI Foundation (AAIF)
作者: Agentic AI Foundation
发布时间: 2026/5/20 05:44:53
原文链接: https://aaif.io/blog/prime-videos-approach-to-progressive-tool-discovery/

---

以下是符合 WordPress 发布标准的中文翻译：

---

深入解读 Billy Hickman 和 Lilia Abaibourova 在 MCP Dev Summit North America 2026 上的演讲

想象一下：忙碌了一整天回到家，你想看一部剧，但应用却给你展示了几百个选项、预告片、推荐页，让你不停滑动。二十分钟过去了，你依然什么都没选。

“我们为 AI 代理（AI agent）制造了同样的问题，”Billy 说道。

Billy 是 Prime Video 的高级软件工程师（senior software engineer），负责核心基础服务。与他一起演讲的是 Lilia Abaibourova，她是 Prime Video 主导 AI 原生赋能的首席产品经理（principal product manager）。他们的演讲针对一个已在生产环境中遇到并解决的问题，提供了一个可行的解决方案。

工具越多，信号越弱

当 Prime Video 的工程团队开始构建代理时，他们遵循了一个看似合理的模式：让代理能访问工程师们使用的相同工具。搭建 MCP 服务器（MCP servers）。让代理自己决定调用什么。

随着更多团队采用这种方法，并贡献到同一个共享 MCP 服务器上，工具数量迅速增长。当数百个工具被加载到单个上下文窗口（context window）中时，问题开始显现：

• 上下文因工具膨胀（tool bloat）而触及限制
• 工具选择变得不可靠
• 性能下降，幻觉（hallucinations）增加

（注：原文最后一行只有一个星号，可能表示斜体段落结束或分段符，翻译时保留）

出自 Lilia Abaibourova 与 Billy Hickman 在 2026 年 MCP 开发者峰会上的演讲。

工具越多 ≠ 智能体越强

核心问题在于机制本身。一个加载了 100 个工具的智能体（agent）即使只需要其中三四个，也必须对每个工具进行解析和推理。这种开销不断累积，上下文（context）迅速填满，模型挑选正确工具的能力也随之下降。

Prime Video 需要一种方式，让智能体能够根据手头的问题获得正确的工具，而无需预加载其他所有内容。

Find Tools：一个工具管控其余工具

他们的解决方案源自一个简单的前提：在每次会话（session）开始时，智能体只知道一个工具。这个工具名为 find_tools。

find_tools 负责两件事：描述 MCP 服务器（MCP server）中可用的问题类别（如“运维”“训练”或“结果”），并告知智能体如何进一步请求。智能体传入一个问题类别，服务器便返回该领域对应的相关工具集。

这一方案之所以能在协议（protocol）层面生效，得益于 MCP 规范中已有的特性。当服务器发送 notifications/tools/list_changed 通知时，兼容的客户端（client）会回调以获取更新后的工具列表。Prime Video 的服务器利用这一机制，在智能体识别出当前处理的问题类别后，将工具动态推入智能体的上下文中。

服务器通过可流式 HTTP 传输（streamable HTTP transport）引入的 Mcp-Session-Id 头部跟踪会话状态，从而知晓哪个智能体在哪个问题空间中工作。当智能体切换到新类别时，旧工具被卸载，新工具随之加载。

实际流程：代理调用 find_tools，服务器以通知响应，代理获取更新的、作用域化的工具列表。

上下文窗口在任何时刻只反映与当前任务相关的内容。

演示：马拉松代理

为了在不暴露 Prime Video 内部工具的情况下展示这一模式，该团队构建了一个用于伦敦马拉松训练的跑步代理和 MCP 服务器。整个过程使机制变得具体：

1. 会话开始时仅有一个工具可见：find_tools
2. 代理被要求查询去年伦敦马拉松的最快完赛时间
3. 代理调用 find_tools，请求结果工具，并收到一个新的 get_marathon_times 工具
4. 代理运行该工具，获取数据——平均 4 小时 28 分钟——并回答
5. 下一个提示要求制定一个与该完赛时间匹配的训练计划
6. 代理再次调用 find_tools，这次请求训练工具
7. 结果工具消失；create_training_plan 出现在其位置
8. 代理使用一个 30 秒前在其上下文中不存在的工具来构建计划

演示结束时，代理在单个会话中循环使用了两个不同的工具集，根据每个任务的实际需求进行加载和卸载。

这种方法的优势

其好处是具体的。只有与当前问题空间相关的工具出现在上下文中，这有助于减少噪音，并保持代理专注。为共享服务器贡献新工具的团队不会给运行无关任务的代理带来成本，因此可扩展性得到提升，而不会使每个工作流变得杂乱。工具还可以在会话中间添加和删除，允许代理在耗尽一个类别后发现另一个类别，而无需重启会话。

该方法适用于使用 HTTP 流和 SSE 的远程 MCP 服务器，以及本地的 stdio MCP 实现。

对于跨团队和组织边界共享的集中式 MCP 服务器，第二点非常重要。如果没有渐进式发现，添加到共享目录中的每个工具都会对运行在该目录上的每个代理（无论相关与否）产生成本。

值得了解的权衡

Billy 和 Lilia 坦诚指出了该方法的局限性。

额外的往返增加了延迟。每次发现调用都需要时间，对于代理在每个会话中都会可靠需要的工具，提前加载它们可能更有意义。从工具到类别的确定性映射也需要治理。如果工具定义重叠或类别增多，代理将难以选择正确的工具。渐进式发现改变了人工管理问题的位置，但并未消除它。

还有一个合规性问题。Prime Video 构建并控制自己的内部客户端，因此他们可以确保完全符合规范。并非所有外部客户端都能正确实现 tools/list_changed 通知，这对于任何试图针对外部或第三方客户端部署此模式的人来说都是一个实际约束。

该方法依赖于 Mcp-Session-Id 标头，在演讲时，该标头正在被积极讨论是否可能从规范中移除。他们表示团队正在密切关注这一点。

团队的下一个步骤是使发现更加动态。代理将描述它试图解决的问题，并从自然语言搜索中接收相关的工具集，而不是从固定的类别列表中选择。目前，确定性方法已经足够好，可以在此基础上继续构建。

*

Billy Hickman 是高级软件工程师，Lilia Abaibourova 是 Prime Video 的首席产品经理。Agentic AI Foundation 是开放代理标准和开源基础设施的家园。要了解更多关于 MCP 的信息，并与思考这些问题的工程师交流，请访问 aaif.io，加入 AAIF Discord 的讨论，或参加即将举行的 AAIF 活动。