卸载pi-web-access后,我留下了这3个工具

我自己的翻车现场，是 pi-web-access。这是一个热度很高的工具，我使用下来体验却不是很好。

这个包把搜索、抓取等好几个工具打包在一起，自身 schema 注入就要1800–2500 token 甚至更多，而且每次启动全量加载——明明这轮只想读个文件，却被迫背着一整个"网页访问全家桶"。更糟的是，实际用下来它搜索偏慢，还解析不了 JS 渲染的页面。

于是我开始研究怎么给它"瘦身"和替代，期间撞见了三个工具：pi-lazy、pi-tool-search、pi-mcp-adapter。后来我把 pi-web-access 卸了，但这三个反而留了下来。这篇文章，就聊聊它们分别是什么，又是怎么接力解决 pi-web-access 的。

一、pi-lazy：把整个包"关机"，自身 0 token

是什么：pi-lazy 是 Pi 生态里一个"扩展管理器"。它不关心你包里具体有什么工具，只关心一件事——这个包，开机到底要不要加载。

怎么做到的：它的全部戏法，是改写 settings.packages 里的字符串。原本你写的是 "npm:pi-web-access" 这种纯字符串，Pi 开机就会执行它的扩展工厂，把里面所有工具一股脑注册进上下文。而 pi-lazy 把它改写成：

{ ”source”: ”npm:pi-web-access”, ”extensions”: [] }

那个空的 extensions: [] 就是开关——它告诉 Pi：这个包先别加载。

加载策略分三档：eager（立即加载）、after-start（启动后加载）、lazy（用到才加载）。

关键数字：pi-lazy 自己不注册任何 LLM 可调用函数，只加了几个 slash 命令（/lazy、/lazy migrate、/lazy load）。slash 命令在命令面板里，不占函数 schema。所以 pi-lazy 自身的 schema 注入是0 token。

对比一下：

它的局限：一旦懒加载的包被触发，它就会变成常驻——等于"开机自动装回全部"。虽然可以通过 /reload 让它重新进入懒加载状态，但总归有点不爽快。这就引出了第二个工具。

二、pi-tool-search：工具级门控，把 25KB 压成 4KB

是什么：pi-tool-search 是一个"工具搜索门控"扩展。它给 Pi 加了一层惰性加载机制：模型默认看不到所有工具的完整定义，只看到一份紧凑清单，需要谁，再点名解锁谁。

机制：它只注册一个工具 tool_search，而这个工具的描述（description）里，内嵌了一份 manifest——所有注册工具的名字 + 一句话简介。这份清单约 4KB，"不管工具数多少，基本都是这个数"。

背景账是这样的：每个工具的完整 schema（参数、类型、描述）大约 500 字节。工具一多，比如 50 个，每轮对话都要白白带上25KB 的"schema 噪音"。pi-tool-search 把它压到4KB——只留一份"名字 + 一句话"的通讯录。

和 pi-web-access 的关系：pi-web-access 里其实有多个工具（搜索、抓取等）。与其一次加载整个包，不如把它们逐个写进门控清单，用哪个解锁哪个，不用再一次性加载整个包。

代价（很重要）：pi-tool-search 自身有固定 ~4KB 的 schema 消耗，不管你里面注册了几个工具，基本都是这笔固定开销；而且多了一层 tool_search 调用 + 解锁流程，延迟和复杂度都上去了。所以——

工具少，直接挂；工具多，挂门控。

这也是我在考虑要不要卸载 pi-tool-search 的原因，等回头让我的 AI 助理算一笔账，看看当前规模下到底是赚是亏，结论到时候再分享。

三、pi-mcp-adapter：MCP 世界的"单接口代理"

前两个工具解决的是"工具包的 schema 太重"，而第三个工具面对的则是另一个问题：MCP 的 schema 同样巨大，而且 pi-web-access 搜索速度偏慢、无法解析 JS 渲染的网页。

为什么考虑 MCP：调研后发现，很多 MCP 服务不仅能解析 JS 网页，搜索能力也更强。但 MCP 的痛点和 pi-web-access 如出一辙——每个 MCP 工具的全量 schema 都会注入到上下文里，token 消耗非常可观。

是什么：pi-mcp-adapter 是一个MCP 代理适配器。它在 Pi 里只注册一个代理工具（约 200 token 注入），通过 mcp({search / describe / tool}) 这样的调用方式按需发现和调用 MCP 服务。这正是 Cloudflare Code Mode / Anthropic code-execution 那种"端口代理"思路在 Pi 上的实现。

怎么做到的：

• 单入口：只暴露一个轻量代理工具，schema 注入从"每个 MCP 一份"降到固定 ~200 token；
• 按需发现：模型需要某类能力时，先通过 search / describe 查询有哪些 MCP 工具可用及其描述，再精确调用；
• 按需连接：MCP 服务器用到才连，不用时不建立连接，也不注入任何 schema。

这个工具很多公众号文章都有详细介绍，这里就不再展开了。

它们是怎么接力替代 pi-web-access 的

把时间线拉直，其实是三步接力：

1. pi-lazy 先让这个重包开机不加载——用不到时，schema 直接归零；
2. pi-tool-search 再把包里多个工具拆开，按需解锁，避免"要么全要、要么全不要"；
3. pi-mcp-adapter 解决了"想换更强的 MCP（能解析 JS），却又怕 schema 爆炸"的难题。

最终，网络搜索这块我用了一个叫one-search的 MCP 来替代 pi-web-access（具体为什么选它，篇幅所限，下篇文章再讲）。

但那三个工具我却留了下来——准确说，pi-lazy 和 pi-mcp-adapter 稳稳留下，pi-tool-search 可能要被我卸掉：前面说过，它本身有固定 4KB 基线，而我现在的工具数量并不多，套它反而可能净亏。到底赚还是亏，我打算后面让 AI 按实际工具数帮我算一笔账，再下定论。

一句话总结

三者是互补的车道：

• 重包不想开机 → pi-lazy
• 单工具想按需显形 → pi-tool-search
• MCP 想接入又怕膨胀 → pi-mcp-adapter

写在最后

这类工具的本质，是在回答同一个问题：在一个工具越来越丰富、上下文越来越昂贵的时代，我们该如何为"选择"本身定价？Schema 注入 token，就是你为"随时可用"付的订阅费。而懒加载、门控、代理这三层方案，则提供了从"全额订阅"到"按次付费"的不同折扣档位——它们没让我"能用更多工具"，而是让我只为这轮真正需要的工具付 token。