给 agent 接工具这件事，走到今天已经不太像「加功能」了，更像在给一个仓库上货。Zapier 一家就挂了 3 万个工具、覆盖 7000 个服务，Composio 那边一百多个托管 server，Smithery 的目录从去年到现在还在涨。团队里常见的心态是：先接上，反正多一个工具不多。
问题是模型这一端不这么想。工具不是加得越多越好用，装到一定数量，它就开始选错，而且不是慢慢变差，是到某个点直接断崖。
有篇新论文把这件事量化了，结论比「工具多了效果差」这种模糊说法狠得多。
同一个工具目录，两种接法，差距在十几分
论文叫 GatewayBench，做的事情很直白：把 7 个主流 MCP 网关（AWS AgentCore、agentgateway、LiteLLM、Lunar MCPX、Enkrypt、Strata、Bifrost，六个开源一个闭源）放在同一套题上跑。题目 524 个，覆盖 6 个领域，工具池子是 251 个真实 MCP server 里抽出来的 11118 个工具，再往里注最多 1500 个跟任务完全无关的噪音工具，模拟真实环境里「目录很大但你要的只有几个」的处境。
它把网关分成两派：
- 扁平网关：把所有 server 的工具拉成一张平表，每次交互都整表塞给模型。工具名前面加 server 前缀避免重名。
- 分层网关：只暴露几个「找工具」的元工具，模型得先问、再取、再调。
按常理，扁平那派应该更简单更稳。实测不是。
0 个噪音工具涨到 1500 个，扁平网关的任务成功率平均掉 10.0、3.9、6.0 个点（三套 agent 配置各掉一遍）；分层网关最多掉 5.5 个点，在强模型上几乎没动，85.1% 到 85.6%。
token 那边更直观。扁平的消耗随工具数量线性涨，分层基本是平的。原因不难猜，工具表本身就在吃 context，1500 个工具的 schema 光是读一遍就是笔固定开销，而真正干活的那几个工具藏在里面。
分层不是银弹，模型不够强会更糟
这篇论文最有价值的地方，是它没把分层包装成正确答案。
同一套网关，换模型就翻脸。GPT-5.4 下 7 个网关的任务成功率都在 80% 以上，把模型降到 GPT-5.1，分层架构平均掉 37.6 个点，扁平只掉 11.9 个点。个别实现直接崩掉，Enkrypt 在弱模型上任务成功率只有 23.3%，它那些看起来很低的中招率是「活都没干完」的副产品，不是防住了。
原因在交互结构上。分层要求模型多做一件事：先想清楚要什么，再去检索，再决定调哪个。这对推理能力是有门槛的。弱模型经常跳过检索这一步，直接编一个工具名和参数去调；Bifrost 那边更细，它把每个 server 做成 .pyi 桩文件让模型写代码，弱模型在字符串里处理 \n 会写成真的换行，生成的 Python 直接被解析器拒掉，网关等于不可用。
所以「小模型 + 分层网关」是双重错误。要么模型够强，要么别用这套结构。
论文里还有一句结论值得单独拎出来：模型从 5.1 升到 5.4，两派在正常任务上的差距抹平了，但安全上的差距没抹平。这不是能力问题。
加了搜索工具，模型却不用
有个细节我觉得比主结论更有意思。
AWS AgentCore 是扁平阵营里唯一自带语义搜索工具的，理论上可以弥补一下「工具太多」。研究者数了一下，在每套配置 1800 次运行里，这个搜索工具被调用的次数是 11 次、19 次、1 次。
基本等于没人用。
原因也简单：工具都已经在眼前了，模型找不到理由先去搜一遍。模型被训练成尽量少调工具，而搜索本身是一次额外调用。这给人的提醒很实在：如果你的方案是「工具照样全塞进去，另外再给个搜索框」，那等于什么都没做。要省 context，就得真的不把工具放进 context。
网关挡的是工具注入，不是提示词
安全这块的账要算清楚，不然很容易买错东西。
同一份实验里，直接写在用户 prompt 里的攻击，扁平 44.7%、分层 44.2%，两派没区别。这个结果合理，网关管的是工具这一层，它看不到也改不了用户说了什么。
拉开差距的是间接注入，尤其是藏在工具描述里的那类。恶意工具混进目录，模型读工具描述的时候顺手把指令也读了。这时候分层网关的优势非常明显：三套配置下间接攻击成功率分别是 19.6% 对 60.5%、30.9% 对 47.2%、15.6% 对 42.5%。
用大白话讲，工具没被取出来，里面的脏东西也就没机会进模型的脑子。可见性本身就是一道防线。
这也顺带解释了为什么 agentgateway 这类项目把「工具投毒防护」当成一等功能在写，防的是直接篡改、影子工具、以及先用正常版本骗过审核再偷偷换成恶意版（rug pull）这类手法。传统 API 网关没有这些概念，因为它假设后端是可信的、静态的。
两条落地路线，取向完全不同
今天的榜单上正好有两个代表，思路差别挺大。
做基础设施的：agentgateway。 Rust 写的数据面，2025 年捐给 Linux 基金会，2026 年进了 Agentic AI Foundation。它把 MCP 和 A2A 当一等协议处理，重点解决传统网关搞不定的几件事：一个有状态的 JSON-RPC 长连接会话，一次「列出工具」要扇出到多个后端 server 再合并；server 可以主动通过 SSE 推事件回来；路由要能看懂 JSON-RPC 消息体，不能只看 path 和 header；每个客户端的可见工具集可以不一样，按 session 动态生成。
它还兼着 LLM 网关的活，用一套 OpenAI 兼容接口去接二十来家模型服务，自建推理那边能按 GPU 和 KV cache 利用率、LoRA adapter 路由。权限用 CEL 写策略，可观测性走 OpenTelemetry。这套东西的目标用户是已经有网关团队、跑在 Kubernetes 上的组织。
做零售的：treg。 定位一句话说完了，「工具的 OpenRouter」。一个 base URL、一个 token，能调到几千个第三方接口，按次计费，几分钱起。它解决的是很现实的问题：为了跑一次任务去买 Semrush 139 美元一个月的订阅，不划算。
几个设计细节值得看：
- 代理只做转发不改写上游，鉴权在服务端注入，调用方从头到尾拿不到 key。它自己的 token 在上游看到之前就被剥掉了。
- 凭据有优先级阶梯：团队注册过的自己的工具优先，然后是自己存的 secret，然后是有公开免费路由的，最后才落到 treg 自己的账号并按余额扣钱。自己有的 key 永远赢，那些调用不计费。
- 目录按「要干什么」组织，不按供应商。你不用知道做外链数据的是哪家，搜任务就行。
- 自托管，FastAPI 一套，供应商目录是一堆 YAML，密钥用 Fernet 加密存库。
它的取舍也很清楚：多个供应商能提供同一个能力时，它把选项和价格摆出来让你选，不偷偷帮你挑、也不偷偷帮你切换。唯一的例外是你主动选用它托管的路由端点。
我现在会怎么判断
如果你在做 agent 产品，这套东西不是「要不要上」的问题，是「什么时候会撞上」的问题。我自己的判断顺序是这样：
先数工具，别数模型。 单个 agent 可见的工具数量超过三四十个，就该开始想要不要分。这不是精确阈值，各家测出来的拐点从 30 到 120 都有，差别在于工具之间的语义重叠度。重叠越高的工具集，越早出问题，因为模型分不清 get_user 和 fetch_user_profile 的区别。
模型能力和网关架构要一起定。 想上分层，先用最弱的那个模型跑一遍真实任务。分层省下来的 token 和安全性，在弱模型上会被多出来的失败率吃掉，还倒贴。
安全预算花在间接注入上。 如果你的 agent 会接第三方或者社区维护的 MCP server，工具描述本身就是不可信输入，这才是风险面。自己团队写的 server，风险小得多，不必为它上整套策略引擎。
凭据集中化要想清楚代价。 把团队所有第三方 key 收进一个网关，本地不留明文，审计和轮转都方便，这是实打实的收益。代价是这把 token 变成所有工具的通行证，一旦泄露，损失面比单个 key 大得多。treg 那种按次计费的托管目录更极端一点，钱和数据都过第三方，得看你的合规底线在哪。
别把网关当成 prompt 注入的解决方案。 它管不了用户输入。这块还得靠权限最小化和输出侧的校验。
一句话收尾
工具层正在从「接一堆 API」变成「管一个工具市场」，这一层的竞争点已经不是接得多不多，是谁来决定模型看得见什么。这个决定权以前散在每个 harness 的配置里，现在开始收到网关手上，因为省 token、拦恶意工具、留审计记录这些事，都能在这一个地方一起做。
顺手提一句，GatewayBench 这个工作本身也值得关注：它把 11118 个工具做成可注入的噪音池，让「工具规模」变成一个能调节的实验变量。以前这类讨论全靠各家自报经验值，现在有了可比的口径。agent 栈里太多层都是这样，先有工程实践，很久之后才有人认真量一遍。
参考来源
- GatewayBench: Unified Capability and Security Evaluation Platform for MCP Gateways，arXiv:2610.23449，https://arxiv.org/html/2610.23449v1
- Microsoft Research, Tool-space interference in the MCP era，https://www.microsoft.com/en-us/research/blog/tool-space-interference-in-the-mcp-era-designing-for-agent-compatibility-at-scale/
- agentgateway 官方文档，https://agentgateway.dev/docs/standalone/latest/
- superdesigndev/treg 仓库，https://github.com/superdesigndev/treg