我最近把自己的 pi Coding Harness 又改了一轮,目标很明确:把上下文效率压到极限
我现在不管模型的 Context Window 有多大,我会把每一段进入 Context 的内容,尽可能的做到和当前任务相关,过滤无关内容
实际 coding 时,最容易烧掉上下文的,往往是工具输出、重复读取、失败返工,以及每轮都重新加载的能力说明
我的 Harness 现在主要靠四道闸:
1️⃣ 常驻内容做薄
AGENTS.md 只放长期不变的规则,具体能力交给 Skills。
不常用的 Skill 默认隐藏,需要时再用 $ 拉出来。这样每次启动不会把几十个 Skill 的说明全部塞进系统上下文。
我现在的思路是:
│ 规则常驻,能力按需加载。
2️⃣ 工具输出先过滤,再进入 Context
我装了 context-mode
大日志、Shell 输出、API 响应和大文件,不直接整段灌进主会话,而是先在沙箱里处理,默认只返回摘要。需要细节时,再从本地知识库里按需检索。
搜索则交给 @ff-labs/pi-fff,用常驻索引、frecency 排序和分页结果,把「搜一遍仓库」变成「只看最相关的几段」
这两层叠起来,Context 里留下的是结论和命中位置,不是几百 KB 的原始输出
3️⃣ 长任务拆开 Context
多 Agent 不共用一条长对话。
我用 pi-subagents 把 scout、worker、reviewer 放进独立 Context,父 Agent 只接收结果、产物和验证证据。
临时问题则丢给 pi-btw,避免一个小问题污染主线程。
pi-auto-compact 作为最后一道保险,Context 接近上限时自动收缩历史。
4️⃣ 把返工也算进 Context 成本
pi-ask 负责在目标、文件和验收标准不明确时先停下来问。
改完之后,走测试、检查、看 diff,再让 fresh reviewer 看一遍。
少一次误改,通常比少几段 Prompt 更省上下文。
所以我现在这套配置里,和 Context 直接相关的核心包大概是:
[
"npm:pi-subagents",
"npm:pi-skillful",
"npm:@eko24ive/pi-ask",
"npm:@ff-labs/pi-fff",
"npm:pi-auto-compact",
"npm:context-mode"
]
什么内容进入主对话,什么内容只保留摘要,什么任务应该切到独立 Context,什么时候必须停下来请求人工确认
它也有代价:索引需要预热,摘要可能丢细节,独立 reviewer 也会带来重复读取
但方向已经很清楚了
Harness 不是越厚越强。好的 Harness,是让模型少看无关内容,却在真正需要的地方拿到完整证据
如果你也在搭 pi,可以先别急着装更多包,先问一句:
这段输出,真的需要进入主 Context 吗?
#PiAgent #AIcoding