集中用了 3 周 pi，可以搬家了，再见了 claude code，再见了 codex。刚看 pi 要发布 3.14 版本了

pi 的作者也是性情中人，挺有意思。新的版本不是常规的 2 啊之类的。“管他妈的语义话版本，咱们用圆周率版本”。

这个想法 opencode 的出来的时候我就有了的，但是当时用了 3 天 opencode ，觉得也不得劲，总的来说是成也插件，败也插件，上来就用 oh my claude 不是一个好的主意，就是整个人都是懵逼的。不知道为什么会这样，让我心里很不安，各种插件代码也参差不齐，当时的模型其实很需要系统提示词的引导和约束，用 opencode 我并没感受到和 cc/codex 的任何差异，反而在某些任务上是下降的，是乱来的，是不理解我意图的。然后就放弃了。

然后随着日子的流逝，模型开始强大了，重要的是现阶段无论哪家的模型，其实不需要那么多约束和引导，有项目约束也能很好的执行，很多 skill 我就自然而安都删掉了，正常 oneshot 就很好了。我是从一步一步引导到长时间任务再又回到一步一步引导的开发流程的。中间的长时间任务做过 2-3 个月，回头看，这个样本挺多了，分析了一下 session ，长时间任务和我预期还是偏差挺大的。这个时候我就开始经历为什么没有一个 agent 可以用所有模型的阶段。但因为 opencode 的第一印象并不好，而且这么久过去，又多了一堆功能。搞开发的应该理解这种心态，莫名其妙多出来功能自己是懵逼状态的。

最后是什么契机呢？ cc 第一次做提示词注入的破坏性的安全事件，我当时就开始反感 cc 。你可以用脱敏的方式探测我是不是 cn ，但你破坏性注入，和黑客又有什么区别？紧接着就是 cc 发布长篇的安全通告，我又炸了。这个事我一直的判断其实不光是分析了聊天记录，而是结合了遥测，甚至遥测可能比例更大。这个时候我就已经很恼火了。最后的契机就是 cc 又又又又又悄悄改变功能不发公告不写 release note ，还要我 codex 反编译出来看为啥行为变了，相信大家会发现突然 cc 不用 edit/write 工具，而是用 bash 工具。不是说 bash 工具不好，是 bash 写代码改了什么我压根看不出来，而且是完全黑盒摇控关闭。这就比较离谱了。

这个时候 pi 就进入视线了，首先 pi 他很干净，不会有 opencode 那种进去一堆功能的挫败感。反正上来就只有 4 个 tool 。确实干净，确实快。但太简陋，我就开始施工。
这一次我完全没有用任何插件，opencode 给我的经验就是用插件为什么不回去用 cc/codex 。我要的是集众家之所长。

我专门开了一个窗口常驻再~/.p/agent 下。
先开发了一个 peer 的插件，开源的各种实验我都研究了一遍，结合我的喜好和功能需求，我就自己做了一个。这样一来，我在任何时候觉得 pi 不好用的时候/btw 临时发 peer 消息，让 peer 在 pi 的目录下进行调整插件行为。

再参照 example 里面的例子搞了 subagent ，我不喜欢 claude 和 codex 的 subagent 的最大原因是不可见，以及每次都销毁，每次都销毁其实在 explore 的时候是很有意义的。但是在处理任务的时候是没意义的，这是我个人的判断，在一次 session 中，反复的调用 subagent 的时候，为啥要清理掉上下文？ subagent 当一次 session 用不也挺好么。第一轮是一致的，一旦有第二轮，subagent 的意义就有了。而且 subagent 他也有 peer 能力，他随时可以 call 另外的窗口，比如前端项目 call 后端项目的窗口做一些额外的工作。提示词也非常克制，非必要不要自己起 subagent ，我甚至是把 subagent 是关着的，不注入系统提示词，只有我需要的时候，我会自己主动的注入工具，并没什么问题，因为这个时候一般是一次 session 刚开始，我觉得这个任务需要多个 subagent 来并发执行。我就不指望模型能把 subagent 用好，我的观点是如果一个模型连文档的逻辑都写的到处都有 bug ，代码也有逻辑问题。凭什么 subagent 他就能起的刚刚好呢？在我看起来 cc/codex 的大量自动的 subagent 都是在浪费 token ，明明自己就能快速处理完的，他要拉个 subagent 出来。

最后就是那 4 个默认工具，我全重写了，然后参考 cc 和 codex 的这 4 个工具的提示词和能力进行扩展。现在终于乖乖的都用 edit ，也不会 edit 歪了。并且支持并发 edit ，我才发现原来不是每个模型支持并发 tool ，claude/gpt/gemini/grok 是支持的，同时修改一个文件的多处，会自动的多个 edit tool 并发调用，或者同时 read+edit+bash 。但是 deepseek 没这个，所以看着 deepseek 快，但他是线性的。

然后就是各种我需要的什么 statusline 啊，todo 啊，code-review/plan/readonly 之类的功能性了。
除非这些模型要干掉第三方 agent ，我应该就焊死在 pi 上了吧。所有的插件都自己慢慢折腾，又不着急。只要有那 4 个基础 tool ，没有啥事是做不了的。系统提示词现在稍微多了一点 11k 。加了 5-6k 的样子，我还是比较谨慎的扩张系统提示词和 AGENTS 。应该就控制在 10k 上下，再多就变成 cc/codex 了。

sampeng

9 月 18 日

@CouleurApp
其实整个过程就是心得，都是我做的比较大和久的插件。为了配合我需要达到的效果。

至于使用心得就是，不要装插件。装插件就去用 omp/opencode/cc/codex 。绝大多数人如果只是为了体验一个 agent ，一定会把这玩意配得根 cc/codex 一模一样。然后装一堆互相打架的插件，或者装一堆自己都不知道里面怎么工作的插件。举个栗子，pi 的上下文管理就很简单粗暴。有口碑很好的 magic context 。我看了一下，这插件里面带一堆功能。我其实并不需要，但也有一些比较好的思路。那就结合 magic context/cc/codex 的现有的压缩规则，折中一个我认为还可以的策略就行（我其实不怎么依赖上下文压缩，我都是直接 limit40%）

对 pi 的任何改造都是出于不爽，用的不舒服，或者哪不对劲。改着改着就顺手了。

pi 只适合喜欢折腾的，或者喜欢自己把控的。因为 pi 足够简单，我是认为没必要再造个轮子去搞 agent ，从这个底座出发可以有一切可能就够了。我也不喜欢炫酷，解决问题，让我看见在做什么。就够了

控制上下文，不要无脑加上下文。我隔几天就精简一遍 agents.md 。现代模型，不要写小作文的 agents.md 和设计文档。我都服了，他是不需要，这些模型自己写文档动不动上来就是一片小作文。