说说工具的延迟加载，还有 tool-search，这个和 anthropic 的那个服务端工具是类似的东西吗？延迟加载的工具的 schema 会怎么写入上下文

【回复 群友 3892】 延迟加载要解决的问题很直接：工具一多，schema 就把上下文吃满了，模型还没开始干活，预算已经消耗掉一半。所以思路是只在上下文里放一个简短的索引（工具名加一句话说明），真正要调用时再把这个工具的完整 schema 取出来。 tool_search 就是那个检索入口。模型先查“我要做 XX”，返回几个候选工具，然后按需加载完整定义。它本质上是一次“元工具调用”：先用一个工具的 schema 去换另一个工具的 schema。 和 Anthropic 的服务端工具差别在哪：Anthropic 那边的 tool search tool 是运行在服务端的封装，由它们的 API 帮你托管工具库和检索，你传一批工具进去，它内部判断该暴露哪些，调用过程对客户端不透明。而 pi 的 tool_search 是你自己进程里的一个普通工具，检索逻辑、索引结构、加载策略全在你手里，可调可测。前者是托管服务，后者是本地实现。这一点决定了上限：你能自己控制检索质量，也得自己承担召回不准的锅。 schema 怎么写进上下文，通常分三档： 一是不在上下文里，只在索引里留一行名字加简短描述，调用时才把全量 schema 注入并保留到本轮结束。 二是精简版常驻，把参数压成很短的签名，细节靠文档查询补。 三是全量常驻但带用量淘汰，久不用的工具 schema 挤出上下文。 pi 那套的取舍是默认 codemode 而非 direct，等于把“加载 schema”这件事绕过去了：不注入工具定义，而是给模型一份这些工具现在能被写进代码里调用的接口说明，模型自己写脚本去组合。省的不只是 token，还有“每次调用都要重新对齐参数格式”的注意力开销。 实际难点在召回。工具一多，描述写得含糊就检索不到，模型会开始自己瞎编工具名或者干脆不用工具。所以延迟加载的前提是工具描述得当成检索文档来写，带场景词、带同义词，而不是只写参数说明。