其实，

Peri Code 的工具分层——LLM 面对 个工具时会停止调用工具

接入 MCP 之后Peri Code 的行为开始变奇怪。

工具列表膨胀到 个出头，DeepSeek、GLM、Qwen 的 tool 调用命中率明显下降。按理说，不是选错了工具——是完全不调用工具。直接凭记忆回答，Bash 不执行，文件不读写，该搜索的不搜索。工具越多，LLM 越懒，这不是某个模型的特例，三个不同提供商都复现了。

Peri Code 的答案是只给 LLM 看 个工具，剩下的按需发现、代理执行。

工具列表越长。命中率越低

这个结论有点反直觉，但可以解释。

LLM 做工具调用本质上是在所有选项里挑一个最合适的。选项越多，「不调用」也是一个合理的选择，而且是回避风险最安全的选择。个工具摆在那里模型好像在一张巨大的菜单面前选择直接背菜单，而不是点菜。

还有一个更硬的问题是缓存。工具列表是每轮 API 请求的一部分，也是 Prompt Cache 前缀的组成部分。个工具的完整 schema 大概要吃掉上万 token，如果工具列表每轮内容不一致。缓存前缀就断了所有命中全部失效，这万 token 每次都要重新传输。一个中等规模的 MCP 服务器接进来工具列表动辄多出十几二十个，而且连接状态可能在会话中变化——缓存根本稳不住。

工具列表不应该无限膨胀，而且膨胀本身就是在破坏程序。

固定的 个主要工具

一个 Coding Agent 真正高频用到的工具并不多。文件读写 个，执行 个，Web 个，交互 个。管理 个——总共 个，覆盖编码场景的绝大多数需求。

这 个工具始终对 LLM 可见。每轮请求都在工具列表里顺序固定，缓存前缀稳定。

剩下的是长尾——Cron 定时任务、各种 MCP 外部服务、LSP 工具等。一次会话可能只用其中一个，也可能一个都不用。这些工具不该出现在工具列表里但不能就此消失，需要能找到和执行它们。

这就是对了 个元工具的职责——SearchExtraTools 和 ExecuteExtraTool

Agent 是怎么知道要填什么参数的

当 Agent 需要调用一个不在-tool 列表里的能力时这整个流程分两步走。

第一步先是搜索。不过，检索所有延迟函数，并返回匹配度最高的一些结果。但关键点是这里返回的是完整函数定义，而不是仅仅是一个函数名。

在 Agent 获得这些信息时它能够知道如何填写相应参数。

如果找到的函数不是它想要的，或其参数不足。则 Agent 可以继续寻找其他函数，或直接告诉使用者它找不到合适函数。不过，

接下来就是执行。不过，在确认要调用的函数和已填充好的参数之后。Agent 就可以调 ExecuteExtraTool 并将其和已填好的参数一起打包传递过去。

框架内部会找到注册表中的相应功能并透传参数进行执行，并将结果原样返回给-Agent。整个过程对于-Agent 只需要两次功能调用的次数。从外部看起来像 “search + execute”，比直接调用的次数还要多一步，但信息则更为全面。其实，

为什么不能动态注册?

你也许想过如果我们搜到了新的函数后就把它动态添加到 LLM 的功能列表里不就省事了吗？这是不行，因为原因仍然是缓存问题。

如果我们把新添加的功能添加到 LLM 的功能列表里那么一轮有几个功能。一轮又变成几个不同的功能，接下来前缀就断裂了那么之前积累起来的缓存命中都会失效。代理执行一次新的功能调用，就代表着功能列表永远不会超出几个固定数量。所以缓冲器前缀从不会发生变化。不过，这笔交易值得做，

当 MCP 服务器连接后续时我们会把新添加到延迟加载注册表里的新函数加入到搜索索引。但是我们不会把它们加入到启动时注入给 LLM 的功能摘要，因为 MPC 连接状态可能在会话途中发生变化，在这样的情况下我们注入进去反而让程序提示词变得不稳定，从而破坏缓冲器一样如此！