2. Linux.do
  3. Pi上下文占用讨论

Pi上下文占用讨论

heylong 2026-07-25 23:02 1

最近在折腾pi，想和各位大佬讨论以下上下文占用的问题。


1.我注意到pi给工具的截断量还是比较大的，比如bash和read都是2000行或者50kb，在实际使用中如果频繁调用工具的话，上下文提升非常快，tool output可以占到上下文的60%~70%。我想问一下，是否该调整阈值，如果调整阈值的话，把被截断的信息放到额外tmp路径会不会影响模型的速度或者表现


2.我当前用fff替代了原有的grep和find，并在permission-system里把这两个命令设置成了deny，对于system prompt和tool的这两个工具描述去掉或替换成fff是否会有影响


3.在使用过程中我不是很倾向于用compact，但当连续性任务对话过长时还是需要，想问一下各位佬有没有什么比较好的compact机制或者工具让模型上下文保持一个较好的水平并且不会丢失重要细节


最新回复 (17)
  • Alexhh 07-25 23:15
    1楼

    claude 也是 2000 行吧

  • heylong 楼主 07-25 23:31
    2楼

    好像是stdout/stderr各16kb

  • nico4499 07-25 23:47
    3楼

    2.我当前用fff替代了原有的grep和find，并在permission-system里把这两个命令设置成了deny，对于system prompt和tool的这两个工具描述去掉或替换成fff是否会有影响



    我不喜欢截断，所以我把这个阈值取消了。对你调不调，放不放到tmp都差别不大吧。oh my pi就专门有个tmp路径放这些。

    2. 它这个system prompt里的工具描述和它这个单独的tool declaration里的工具描述感觉重复了，我把system prompt基本都删完了。fff它自己的单独tool declaration有写怎么用fff

    3. opencode-acp这种风格的插件可以模型自主决定什么时候compact。还有各种花里胡哨的插件改压缩模式。然后你可以自己写压缩提示词。我没试过哪种好，我就用的默认的。

    4. 我没明白大家怎么都喜欢用pi，感觉可定制程度和opencode也差不多。

  • Xu 07-26 00:00
    4楼

    这个Context Usage显示是使用的插件吗？看起来挺好看的，佬可以分享一下吗？

  • heylong 楼主 07-26 00:10
    5楼

    非常感谢佬的回答，我也准备替换掉system.md；对于压缩我个人还是倾向于手动触发并且尽量可控，扩展好像有挺多压缩策略的，包括codex的自动压缩，我都还没怎么实践，不过佬觉得默认压缩的效果怎么样？opencode扩展性相当，但是感觉不如pi透明吧，而且最近win上还遇到内存泄漏的问题，pi这种最小实现上搭积木定制的感觉我还挺喜欢的

  • heylong 楼主 07-26 00:11
    6楼

    就在package里搜就有，好像是叫pi-context-visual

  • prosumer 07-26 00:19
    7楼

    我觉得all you need is magic-context

    你可以看我这个帖子https://linux.do/t/topic/2643301/78

    这玩意是真magic

    或许我该专门写一个magic-context的使用感受帖了

  • xiewuzhiying 07-26 00:29
    8楼

    支持佬，还没有看过 magic-context。

  • prosumer 07-26 00:30
    9楼

    如果你用过opencode-dcp, 你会大概理解一部分它的原理, 但它神在从不compact

    在使用过程中, 它的context基本保持在50%左右, 基本不超过70%

    就和opencode-dcp在之前所声称的那样, opencode-dcp虽然会破坏一定的缓存命中, 但是考虑到context价格和输入价格的平衡, 同样多的钱对应的调用次数会增多(实测确实如此

    考虑到opencode-dcp摆烂了, magic-context绝对可以称得上它的pro版

  • heylong 楼主 07-26 10:16
    10楼

    magic-context我还没用过，看介绍是解决跨session遗忘的问题吗，和trellis是同一类的吗，看佬的介绍还挺不错的，希望佬可以专门出一个magic-context的实践感受 ^-^

  • heylong 楼主 07-26 10:30
    11楼

    哈哈是pi-context-view，昨天在手机上回的没看

  • prosumer 07-26 11:07
    12楼

    和trellis思路很不同, trellis应该是在执行之后, 让这个agent自己, 根据trellis提供的skill写规范文档之类的, magic context就是偏记忆, 从context中通过类似compact的思路提取记忆, 带有记忆衰减等东西

    而且除了session遗忘它也能帮你prune运行时context, 让你的context保持在良好水平

    而且magic context是无感的

  • 初九猫 07-26 11:11
    13楼

    我看还要下载嵌入模型，对小鸡上跑Agent不太友好啊

  • prosumer 07-26 11:12
    14楼

    嵌入模型好像90MB, 对我来说没啥影响, 可以通过配置关掉吧, 它主要影响持久memory, magic context的prune也不错, 我认为仅就prune来说就已经超越opencode-dcp了

  • LouisL 07-26 11:57
    15楼

    magic-context 确实好用，很无感，也有跨 session，跨项目的 memory。至于效果。。。不好说，但是我用起来感觉是比 DCP 好（当然和暴力 compact 比就更好了）

  • nico4499 07-26 18:41
    16楼

    非常感谢佬的回答，我也准备替换掉system.md；对于压缩我个人还是倾向于手动触发并且尽量可控，扩展好像有挺多压缩策略的，包括codex的自动压缩，我都还没怎么实践，不过佬觉得默认压缩的效果怎么样？opencode扩展性相当，但是感觉不如pi透明吧，而且最近win上还遇到内存泄漏的问题，pi这种最小实现上搭积木定制的感觉我还挺喜欢的



    我都是简单的活，没感受到什么压缩的影响。你不放心压缩可以最后让他检查一遍交付结果之类的 ^-^

  • prosumer 08-07 17:13
    17楼

    拖延症, 今天才写完

    https://linux.do/t/topic/2719693

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐