之前我写过一篇文章，介绍 Context Mode 可以帮 Pi 精简上下文。但今天我把这个插件删了，因为我发现它可能正是 Pi 启动慢的原因之一!!!!!… · @chasen_liao · TwKit

@chasen_liao

之前我写过一篇文章，介绍 Context Mode 可以帮 Pi 精简上下文。但今天我把这个插件删了，因为我发现它可能正是 Pi 启动慢的原因之一!!!!!!🤯 这段时间我用 Pi 的时候，经常感觉启动要等很久。后来排查了一圈，发现问题和 Context Mode 有关，其他插件没有出现同样明显的慢启动 更让我意外的是，我顺着这个问题往下查，发现这个号称能精简上下文的插件，本身就会给上下文增加一笔不小的开销 我和 Codex 用 Pi 做了一组隔离对照，模型用的是 GPT-6 Luna，Context Mode 版本是 1.0.169。两边使用同一个提示词，只让它写一个内容为 hello 的文件，同时保留 Pi 的 Code Mode 和 Tool Search 装着插件的时候，发给模型的工具一共有 17 个，第一次请求的输入是 8,021 token。卸载插件后，同样的任务只剩 6 个工具，第一次请求是 2,004 token 也就是说，文件还没开始写，装着 Context Mode 的这次请求就多带了大约 6,000 token 原因也比较直观：它额外注册了 11 个 ctx_ 工具，这些工具的描述加起来有一万多字符，还要带上参数定义。插件也会给模型补充工具使用的路由提示，所以这笔开销不全是工具描述，但工具定义确实占了很大一块 启动时间也测了一下。隔离环境里，从启动到进入 Agent 阶段，装着插件大约是 2.37 秒，卸载后大约是 0.28 秒。我们看了插件代码，它会在处理提示词前等待 MCP bridge 启动并注册工具，这和测试里多出来的等待是对得上的 当然，这只是我的电脑上做的小样本测试，不代表所有人都会慢这么多 至于它到底帮我省了多少上下文，我们还测了日志统计。让模型自己完成任务时，Context Mode 用自己的工具处理日志；没有插件时，模型也会用 shell 先筛选，两个结果都找对了，这个案例里没有看到明显的上下文节省 另外一次要求模型用 read 读取原始日志，两边返回的都是约 4 万字符，Context Mode 也没有自动把这次 read 输出压缩掉。这不代表它在所有大输出场景都没用，但至少我之前把它理解成会自动拦截所有大输出，这个说法需要修正 所以我现在把 Context Mode 删掉了，保留 Pi 内置的 Code Mode 来编排工具。对于日常找文件、搜代码，我更愿意留 pi-fff：用 fffind 定位文件，用 ffgrep 搜内容和按需翻页，找到位置之后再读取相关代码 如果你跟我一样，主要想解决代码搜索把上下文塞满的问题，我会更推荐先试试 pi-fff。Context Mode 则可以按自己的任务需要再考虑，尤其要把它额外带来的工具上下文和启动开销一起算进去 pi-fff 安装命令：pi install npm:@ff-labs/pi-fff 传送门 👉 https://github.com/dmtrKovalenko/fff/tree/main/packages/pi-fff

曝光 686 · 评论 6 · 点赞 5 · 书签 2