← 返回 PaperDaily 大模型与智能体

工具海时代来了：Agent挑工具快8.9倍

Agent 不是不会干活，是经常被“工具海”淹没。本文把 MCP 从直连玩成云端网关，顺手把旧 API、协议兼容、工具筛选和会话路由一起收拾了，属于真能落地的基础设施活。

龙哥读论文发布于 2026-08-14 09:11:21 阅读 3 查看原文

#大语言模型 #Agent #AI应用

原论文信息如下：

论文标题:
Scalable LLM Agent Tool Access in the Cloud 发表日期:
2026年07月发表单位:
南京大学、阿里云、复旦大学、RMIT University、Politecnico di Milano、浙江大学原文链接:
https://arxiv.org/pdf/2607.15593v1.pdf

引言

大模型智能体最怕什么？不是不会推理，而是“会推理，没工具”。工具一多，LLM 的上下文窗口先扛不住，token 成本和延迟也跟着起飞，最后还可能把正确工具选歪。本文给出的答案很工程：把 MCP 从“客户端直连服务器”改造成云端网关，让协议适配、工具推荐、权限控制和会话路由都在网关侧统一处理。

这篇工作最有意思的地方在于，它不是只做一个“更聪明的检索器”，而是直接把 MCP 的生产部署痛点摊开：旧 API 接不进来、协议版本不兼容、工具太多塞不进上下文、状态化会话一扩容就容易乱。换句话说，这不是论文里那种“看起来很完整，落地就散架”的方案，而是明显带着云厂商实战味道的系统设计。

如果把 Agent 工具访问比作外卖平台，本文做的不是再造一个厨子，而是先把订单路由、门禁、菜单推荐和回执同步这些脏活累活收进“中央厨房”。结果也很直接：在 3,616 个工具规模下，Top-15 召回率能到 98% 以上，工具选择时间和 token 消耗分别降到原来的 1/8.9 和 1/23.8。

原论文信息如下：

工具（API）太多塞不进LLM的“大脑”怎么办？

这篇论文一上来就把一个很现实的问题摊开了：Agent 不是不会用工具，而是工具太多，LLM 的上下文窗口先爆了。在传统“直连式”MCP（Model Context Protocol，模型上下文协议）里，客户端要把工具描述尽量塞进提示词，让模型自己选。工具少的时候还能凑合，工具一多，token 成本、推理延迟、选错工具的概率就一起上升，场面很像把整座超市的货架都搬进脑子里，再让模型闭眼挑一瓶矿泉水。

更麻烦的是，现实世界里的工具并不都“生来就是 MCP”。大量生产系统仍然是 OpenAPI/Swagger 体系，历史包袱一大堆；MCP 本身又在快速演化，传输层、认证方式都在变；再加上很多工具是有状态的，多副本部署时还得考虑会话黏性。也就是说，真正要解决的不是“让模型会调用工具”，而是让海量工具在云上可管、可控、可扩、可用。

图：云端网关式 MCP 架构。本文不是在客户端里继续硬塞工具，而是把协议适配、权限控制、工具检索和会话路由统一收进网关，直接把“工具海”变成可治理的基础设施。

这也是本文最核心的判断：MCP 真正要走向生产，不能只做协议标准，还得补上一层云原生网关。标准解决“怎么说话”，网关解决“怎么大规模说话”。前者是接口，后者才是工程。

给MCP加个“云原生”网关！

论文的整体思路其实很清楚：既然 MCP 直连模式在云上不够用，那就把原本分散在客户端、工具提供方、后端服务里的脏活累活，统一搬到网关层。这个网关不是简单转发请求，而是同时承担四类职责：协议适配、功能卸载、工具推荐、会话感知路由。

图5：网关系统总体架构。客户端只需要连到一个统一入口，网关再把请求拆分、改写、鉴权、检索、路由到不同后端。这个设计的妙处在于，它把原来分散的集成成本集中到了一个可控位置。

先说协议适配。生产环境里最常见的矛盾不是“有没有工具”，而是“工具能不能接进来”。大量 legacy API 仍然停留在 OpenAPI 时代，MCP 客户端却要按 MCP 的方式发现和调用工具。本文提出的做法很直接：在网关中把 OpenAPI 操作编译成 MCP 工具，做到一对一映射。这样做的好处是工具粒度清晰、调用语义稳定，不需要把后端 API 重新改造成 MCP 原生服务。

这里还要补一个必要缩写：MCP 是 Model Context Protocol，中文可理解为“模型上下文协议”。它的作用不是规定工具怎么做业务，而是规定 Agent 和工具服务之间怎么统一说话。论文里也强调了，MCP 只是标准化互操作，不会替你解决后端实现、权限、调度这些工程问题。

图1：MCP 示意。Agent 通过统一协议发现工具、选择工具并发起调用，理论上很优雅，现实里则会碰到工具爆炸、协议分裂和会话路由这些“工程副本地狱”。

再说功能卸载。很多工具后端本来就有身份认证、访问控制、审计等逻辑，但如果每个后端都自己做一遍，工程重复度会高得离谱。本文把认证和细粒度工具权限收敛到网关侧：入口处识别客户端身份，出口处再映射成后端需要的凭据。这样既能统一安全策略，也能避免每个后端重复造轮子。

图6：细粒度访问控制功能卸载。网关负责统一认证、统一授权、统一身份映射，后端只专注业务本身，不再被安全逻辑拖着跑。

这一步很像云时代的老经验：把共性能力收进平台层，业务层才能轻装上阵。MCP 只是换了个名字，本质上还是那套老道理。

然后是最关键的工具推荐。如果把全部工具都塞进模型上下文，代价太大；如果只给一小撮工具，又怕漏掉正确答案。本文的做法不是让 LLM 自己在海量工具里瞎翻，而是让网关先做一轮确定性的候选过滤，再把少量相关工具交给模型。换句话说，先让检索系统干粗活，再让模型干细活。

图7：混合工具检索引擎。离线阶段为工具建索引，在线阶段先做语义召回，再做词法匹配，最后通过融合排序返回候选工具集。

混合检索+知识缓存：Agent也能挑对工具

本文在工具推荐上没有迷信单一路线，而是把语义检索和词法检索拼在一起。原因很朴素：工具名、资源名、参数名往往带有非常明确的关键词，光靠向量语义有时会“懂意思但抓不住名字”；反过来，纯关键词又容易漏掉同义表达和模糊意图。混合检索的思路就是两条腿走路，既保召回，也保精度。

表1：前沿基础模型的上下文窗口与可挂载工具数。即使上下文已经做到 1M token，实际能塞进的工具数量也仍然有限，工具规模一大，模型就会被 schema 直接挤出“可思考空间”。

这里有个很重要的现实约束：上下文窗口不是越大越自由。表1已经说明，即便是大模型时代的“超长上下文”，也挡不住工具描述本身的膨胀。工具越多，提示词越长，模型越容易把注意力浪费在无关 schema 上，最后既慢又不准。本文用混合检索把候选工具控制在较小范围内，本质上是在给模型做“减负”。

图4：工具规模对模型能力的影响。工具数量上来以后，不只是 token 多了，推理延迟也会明显拉长，工具选择准确率还会下降，甚至出现“不调用任何工具”的情况。

论文在这里还引入了一个很实用的补丁：知识缓存。很多工具调用其实具有明显的依赖链，前一步工具的结果会决定后一步工具能不能正确执行。与其每次都让模型重新“想一遍”，不如把高频依赖链缓存起来，尤其是当查询模式高度重复、工具链高度局部化时，缓存能明显降低推荐延迟，还能避免漏掉前置工具。

表5：知识缓存评估。这里重点看两个指标：Prereq. Completeness 表示前置工具是否完整召回，Extra RTTs 和 Tokens 则表示迭代式发现带来的额外往返和 token 开销。缓存的价值就是把这些重复损耗压下去。

这部分最值得肯定的地方在于，它没有把“智能”全部塞给大模型，而是把推荐系统、缓存系统和规则系统做成了一个可控组合。在云上，大规模工具访问不是越聪明越好，而是越稳定越值钱。这句话听起来不够浪漫，但很接近生产真相。

图A5：候选数 k 变化时的召回率、选择准确率与端到端准确率。候选集太小会漏工具，太大又会把模型拖回“上下文地狱”，所以关键不是多，而是刚刚好。

图18：语义缓存。相近意图可以复用历史检索结果，避免每次都从零开始做候选发现。

大规模部署的“坑”，我们替你踩了

这篇论文最像生产系统报告的地方，不在于它讲了多少概念，而在于它把部署中的坑讲得很实在。第一个坑是协议兼容。MCP 的传输层已经出现 HTTP+SSE 和 Streamable HTTP 等不同形态，认证方式也不统一，单靠客户端去适配会非常痛苦。网关把这些差异吸收掉，等于把“协议变化的成本”从每个客户端和后端身上卸下来。

图A4：多阶段路由决策流水线。请求会先被解析，再被标注后端与传输类型，最后改写并转发到合适的目标。这个过程看起来繁琐，但它换来的是后续演进的灵活性。

第二个坑是状态化会话。MCP 服务在多副本部署时，如果请求被随便打散，后端很可能找不到前文状态。本文的做法是维护会话到后端实例的映射，并通过中心化存储在多个网关实例之间同步。这样一来，网关扩容不会把会话一致性搞崩。

图8：会话感知请求路由。网关不仅要知道“发给谁”，还要知道“同一会话的后续请求必须发给同一个副本”，否则状态型后端会当场失忆。

第三个坑是长连接和吞吐。很多人一听网关，第一反应就是“会不会把性能拖垮”。论文给出的答案挺直接：长连接保活不是负担，反而能显著降低平均和尾延迟；而网关本身的处理开销在生产环境里可以做到很低。换句话说，网关不是性能黑洞，做对了反而是减压阀。

图17：长连接与非长连接的延迟对比。对于状态型后端，保留长连接能明显降低平均延迟和尾延迟，说明“少折腾连接”本身就是优化手段。

图14：网关响应时间分解随实例数变化。随着实例数增加，网关的各阶段开销保持在可控范围内，说明方案具备横向扩展基础。

图15：网关系统可扩展性。系统在扩容时没有出现明显的性能塌陷，这一点对生产部署很关键，因为云上最怕的不是慢，而是“一扩容就乱套”。

还有一个很像“老工程师会心一笑”的点：知识缓存和语义缓存不是锦上添花，而是生产环境里压成本的关键。很多工具调用是重复的、局部的、带依赖链的。把这些模式缓存下来，能减少重复检索和重复推理，把推荐延迟压下去，也把 token 消耗压下去。对云服务来说，这类优化往往比再堆一个“更大模型”更实用。

图19：不同生产轨迹下的 LRU 缓存延迟与召回。缓存策略在真实轨迹上能明显减少推荐耗时，同时保持较好的召回表现。

总结与展望：通往Agent Tool使用的基础设施

这篇论文真正有价值的地方，不只是把 MCP 跑起来，而是把它当成一种云上基础设施问题来处理。它说明了：当 Agent 从 demo 走向生产，单靠“更聪明的模型”远远不够，必须把协议兼容、鉴权、检索、缓存、路由这些系统能力补齐。否则工具再多，也只是摆设。

从工程角度看，这套方案的优点很明确：把复杂性集中到网关层，把不稳定因素隔离在可控边界里。从产品角度看，它也很有现实意义：云厂商、平台型公司、内部大规模工具平台，都可以借这种思路把“工具接入成本”变成“平台治理能力”。

不过边界也要说清楚。第一，这套系统很依赖生产环境里的工具分布、调用局部性和协议治理能力，离开这些条件，缓存和推荐的收益会打折。第二，工具编排本身仍然需要模型参与，网关只能把候选集缩小，不能替模型做所有推理。第三，协议和认证的演化还会继续，网关虽然能吸收变化，但也意味着平台维护成本会长期存在。

认真说，这类工作最难得的不是“某个模块很花哨”，而是它把一整条链路的工程问题都压实了。没有这个网关，MCP 在云上会越来越像“标准很好看，落地很费劲”；有了这个网关，Agent 的工具访问才算真正开始像平台，而不是像玩具。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决什么问题？它解决的是 Agent 在云上访问海量工具时的基础设施问题：旧 API 接不进来、协议版本不兼容、工具太多塞不进上下文、状态化会话在多副本下容易乱。网关把这些问题统一收口，才能让工具访问真正规模化。

MCP 和 MCP Host、MCP Server 分别是什么？MCP 是模型上下文协议；MCP Host 是发起工具调用的 Agent 或 LLM 应用；MCP Server 是把工具暴露给 Host 的服务端。可以把 Host 理解成“会思考的前台”，Server 理解成“真正干活的后端”。

混合检索为什么比只靠大模型更靠谱？因为工具名、资源名、参数名这类信息既需要语义理解，也需要关键词命中。纯语义容易漏掉专有名词，纯关键词又抓不住意图。混合检索相当于“语义+字典”双保险，再加缓存，才能又快又稳。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★☆☆

创新点不在某个单点算法，而在于把 MCP 生产化所需的几项关键能力系统化地收进网关，属于“工程架构级创新”，不是炫技型新模型。

实验合理度：★★★★☆

实验围绕召回率、延迟、token 成本、扩展性和会话路由展开，指标和问题一一对应，比较像生产系统该做的评测，而不是只挑一个漂亮数字。

学术研究价值：★★★★☆

它把 Agent 工具访问从“模型能力问题”推进到“系统基础设施问题”，对后续做大规模 Agent 平台、工具市场和协议治理都有启发。

稳定性：★★★★☆

网关式设计天然比客户端直连更稳，协议和权限也更容易统一管理；但它仍然依赖后端协议质量、缓存命中和会话同步正确性。

适应性以及泛化能力：★★★★☆

对多工具、多协议、多副本的云环境适应性很强，尤其适合平台型系统；但对小型单体应用来说，网关层可能有点“杀鸡用牛刀”。

硬件需求及成本：★★★★☆

网关侧开销较低，推荐和缓存也偏轻量；真正的成本主要来自生产部署、协议维护和状态同步，而不是算力本身。

复现难度：★★★☆☆

论文给了较完整的系统思路，但这类工作强依赖生产环境和真实工具分布，实验室里能复现原理，完整复现生产效果并不轻松。

产品化成熟度：★★★★☆

从论文内容看已经很接近可落地平台方案，尤其适合云厂商和工具平台；但要做到大范围稳定商用，仍需持续打磨协议兼容和运维细节。

可能的问题：方案强依赖云平台治理能力和真实工具生态，若工具分布稀疏或协议长期分裂，网关收益会下降；此外，缓存与规则维护也会带来长期工程成本。

主要参考文献

[1] Scalable LLM Agent Tool Access in the Cloud. arXiv:2607.15593v1, 2026.

[2] Model Context Protocol (MCP) official specification and ecosystem materials.

[3] OpenAPI/Swagger specification and public API ecosystem references cited in the paper.

工具越多，Agent越容易“眼花”。想继续看这类云原生Agent基础设施、MCP实战和大模型落地拆解，欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称，更快通过并拉你进对应技术群。

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群。
wechat_helper