开发者重新设计编码工具pi Coding Harness 极致压缩上下文效率

开发者chasen_liao最近重新设计了自己开发的pi Coding Harness，目标是将上下文效率压缩到极限。无论模型的上下文窗口（Context Window）有多大，这套工具都会尽可能让进入上下文的每一段内容都和当前任务相关，过滤掉无关内容。实际编码过程中，最容易占用过多上下文空间的内容，往往是工具输出、重复读取、失败返工，以及每轮都重新加载的能力说明。重新设计后的pi Coding Harness主要通过四道关卡过滤内容：

第一，对常驻内容做精简，长期不变的规则只放在AGENTS.md中，具体能力交给Skills模块。不常用的技能默认隐藏，需要使用时再调取，这样每次启动就不会把几十个技能的说明全部塞进系统上下文，核心思路是规则常驻，能力按需加载。

第二，工具输出先过滤再进入上下文。通过context-mode处理大日志、Shell输出、API响应和大文件，不直接将整段内容放入主会话，而是先在沙箱处理，默认只返回摘要，需要查看细节时再从本地知识库按需检索。搜索功能由@ff-labs/pi-fff提供，通过常驻索引、近期频率（frecency）排序和分页结果，将搜索整个仓库变为只查看最相关的几段内容。两层过滤后，上下文里只保留结论和命中位置，不会保留数百KB的原始输出。

第三，拆分长任务上下文，多个智能体（Agent）不共用同一条长对话。通过pi-subagents将侦察、工作、审查角色分别放入独立上下文，父智能体只接收结果、产物和验证证据；临时问题交给pi-btw处理，避免小问题污染主线程；pi-auto-compact作为最后保障，在上下文接近容量上限时自动收缩历史内容。

第四，将返工也计入上下文成本，通过pi-ask在目标、文件和验收标准不明确时先暂停询问开发者。修改完成后，依次进行测试、检查、查看差异，再让新的审核人员复查，减少一次错误修改，比精简几段提示词更节省上下文空间。

这套配置中，和上下文直接相关的核心包包括：npm:pi-subagents、npm:pi-skillful、npm:@eko24ive/pi-ask、npm:@ff-labs/pi-fff、npm:pi-auto-compact、npm:context-mode。它也存在不足：索引需要预热，摘要可能丢失细节，独立审核也会带来重复读取。

但方向已经清晰：编码工具框架（Harness）不是功能越复杂越好，好的框架是让模型少看无关内容，在真正需要的地方拿到完整证据。如果自己搭建pi，先别急着安装更多包，可以先问一句：这段输出，真的需要进入主上下文吗？