- blacksein2026-09-28
现在用pi感觉整体挺好的。
但是他的上下文不像codex会自己有时候缩小（比如查阅了大量资料 有时候codex会做内部的压缩 将上下文减少 不是触发/compact）
所以上下文用起来比较快
佬有什么插件推荐不
好像看到有几个
比如
pi.dev
Pi Coding Agent
A terminal-based coding agent
（看描述这个插件好像是二合一了 pi-vcc和pi-observational-memory了吧…）
有使用的佬分享下使用效果不
主楼 - 小诗音2026-09-28
magic-context，直接不compact。
现在很多harness工具都在去compact，例如codex的实验性上下文管理等。
compact的问题在于，信息是有损的，多次compact后，agent很容易丢失一些关键信息。
- awoaCrim2026-09-28
用gpt的话非常推荐使用codex的实验性context management，本来在codex中似乎只有astra可以用，移植到Pi后发现其实sol和luna都能用，相对于传统compact在长上下文 工作流上不会丢失过多的信息
【开源自荐】pi-openai-toolkit：把 GPT 的原生能力带进 Pi - 开发调优 - LINUX DO
- Kcompactd2026-09-28
可以试试 magic context，基本无感，上下文保持在合适的大小（可根据模型自行设置）
- 小诗音2026-09-28
codex从某个版本之后因为早停和回复旧消息的问题关闭了实验性上下文管理。
- blacksein2026-09-28
咦 这个看着只能gpt系列模型能用是吗 而且是还会发给openai服务端 ^-^
- awoaCrim2026-09-28
是的，并且数据都是加密发codex后端的
- awoaCrim2026-09-28
目前看下来oai远端仍然接受context management的端点并且可以正常工作，只是在客户端关闭了
- 小诗音2026-09-28
既然用pi了，实际上magic-context和codex的上下文管理区别就不大了。两者的原理是基本相同的。个人感觉magic-context会比目前的codex的实验性上下文管理更灵活。
- awoaCrim2026-09-28
缓存和长任务的稳定性明显是后者占优
- 小诗音2026-09-28
codex官方都因为稳定性问题关闭了实验性上下文管理，竟然是稳定性更优吗？有相关的数据参考吗？我这边好像没有找到相关的对比之类的。