实验平台：pi-coding-agent|windows
为什么选择pi而不是codex,cc？
因为pi可以通过自己写插件来操控全流程，包括直接修改上下文，我认为pi的设计是未来的方向，像codex和claude code，开放给社区的优化空间都是极为有限的(顺便吐槽一下mcp这个垃圾设计)，GSD2也选择脱离这两个平台，转而使用pi-agent来开发自己的coding cli
实验模型：gpt-5.5 xhigh 费用以官方美刀计
本次实验均运行在相同初始仓库快照下，控制变量为插件工具
人工操作仅有初始提示词，全程由agent自己完成任务，不额外请求用户输入
仓库主要语言为ts，代码量级为10000LOC左右
为什么所有模式都 pass？
因为任务名本身非常强：
Add a read-only Context Map health command...
baseline为完全不使用额外功能，仅用pi原生tools
scan-only为仅允许额外使用Context Map工具
cold为在scan的基础上，允许agent额外提出proposal，即提出对两个文件之间相互联系的猜测
warm为启用全部功能（但不包含人工参与部分），agent会读历史关系/概念/proposal、理解它、判断它是否可信、再去 source 里验证
scan做了什么？
在代码层面对代码库进行分析，对相互之间可能存在引用或潜在引用的代码文件建立图谱
设计最复杂的warm模式居然在三个模式中表现最差
这个数据有点超出了我的预期，稍微的有点反直觉
我觉得需要考虑当前的设计理念是否走弯路了，这样的设计是否增加了上下文的噪声
我准备在这个插件开发相对成熟，我自己重度使用体验后再进行开源
所以针对目前的问题，我想让社区的大佬们提提建议，给我一点启发
6 个帖子 - 3 位参与者
来源: LinuxDo 最新话题查看原文