sampeng

@sampeng 我做过量化测试。最近一周只有 1%的浪费的多读。默认的 read 是读所有，我也加了 offset 。limit 啥的。85%在 250 行以内就解决战斗了。超过了的只有 15%。99%的知道用 offset 进行翻页读。昨天研究了一上午，以为 read/grep 还有优化空间。看了一下数据没啥好优化的。上下文 60%是 read 贡献的。

@phrack 有空了改成插件格式开源出来吧，我是看有很多的类似插件，但我没看他们怎么实现的，好像就叫 pi-hash edit 啥的，我就不掺合了。不过我这个需要接管和修改这 4 个基础工具…思路不一样。

@phrack 我就看了一下 omp 的 hashtag ，然后再让 codex 去看看为啥 claude 编辑成功率那么高。学习一下，其实很简单，claude 在编辑之前是要求 read 一遍，那就结合一下，把 read 和 grep 两个输出都加上行 hash 。另一个就是这 4 个工具本身有点问题，gpt 好使，但 claude/gemini 还是喜欢用 bash 去修改文件。我就再让 codex 去分析 claude 的这四个工具的提示词和定义格式…改成一模一样的完事。改完再没有问题了，而且还多出来并发修改单文件的感觉。

@skuuhui 我非常认同你的看法，非特殊情况我当然也是选择固定的工具，但是，我经历过 claude code 帐号被封，然后干等 1-2 天…

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

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

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

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

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

@way2explore2 没法分享。。我也没打包成插件，直接扔到插件目录的。使用过程但凡不对劲就是 btw 去修改了。

@xiaoHuaJia 回测都是历史，历史不能说明未来。但单边可以= =！所以还是谨慎点，弄个止损线就好了，其实无所谓

因为最近单边啊…