PiAI Agent内存管理

浅浅吐槽一下pi

remilia，持续分享值得阅读的内容。关注

虽然说搞个pi durable，不过为啥不直接在pi上加个内存索引呢。

Pi 都 1.0 了，单个 session 的完整历史还一直留在内存里。用得越久，内存占用越大。session 历史已经写进 JSONL，冷历史也不是高频访问，内存留索引、正文按需读盘不就行了吗？感觉更离谱的是 issue #6841 提过完全相同的问题和方案，被 bot 自动关闭后，到现在还是 not planned。无法理解，pi 是不打算做一直运行的 agent 吗？

添加评论
点赞收藏
点踩分享
评论9
?
参与讨论
围棋饼干
可以看下 9613 这个 issue 是我提的，也是被标记不在计划中， 如果说你工作流有大量的图片的话 单个 session 一次性加载到内存中可能是 gb 级别，甚至超过一定数量后 session 会直接无法加载
8小时前
1回复
z101z
我也发现问题，对话条目过多，pi就占大量内存
8小时前
1回复
xx111
可能很多harness不考虑这种用途，我codex之前有一个session用了太久，每次打开都要卡10-15s，后面不得不改了适应习惯，用一天之后就切session
8小时前
3回复
remiliaOP
不知道他们怎么计划pi的
8小时前
5回复
黃澤義
以前看到说是让用户积极new的，那就是仅限开发场景了。
6小时前
回复
remiliaOP
想把这个当personal agent放生产里还是要改太多了，不过这说的也有道理，现在定位是coding agent
5小时前
回复
疾风之龙
从保证上下文纯净度来说确实应该积极new，不过不分页全部放内存也是离谱
3小时前
6回复
室长
用sdk能绕过去吗
11小时前
回复
remiliaOP
主要是吐槽一下，绕过去或者改都比较容易了
10小时前
回复
室长
回复 @remilia 你不说我都不知道。我想确认一下，这个问题出在哪部分啊，用sdk真能绕过去吗？不fork的情况下
9小时前
2回复
remiliaOP
回复 @室长 得改下代码，它session manager每次都把session所有历史都加载进内存了，然后做了个entry id的map，这里搞的内存占用会无限膨胀的
9小时前
回复
室长
回复 @remilia 好我去看看，谢谢你
7小时前
回复
不是游客
开源项目就这点麻烦，各种长尾的奇奇怪怪小地方用起来难受
9小时前
2回复
红魔馆の穷酸管家
我感觉还是pi的问题，他们老用不符合规划还有过度圹展理由关闭pr。明明社区都帮他们写好了
9小时前
回复
000000
回复 @红魔馆の穷酸管家 现在这个年代pr随便合，很快就成💩山了（）
9小时前
1回复
時間の旅人
我觉得ok吧，我的使用场景是经常开新session来个干净的上下文。就算这东西把对话消息写入磁盘，但实际上那个磁盘文件的page cache还是在操作系统里，只不过不显示在pi进程的rss里而已。
2小时前
2回复
邪恶的半自动洗衣粉
只能说特定场景适合
2小时前
回复
嘿嘿猫猫虫
不懂就问，调用大模型的messages是这些历史消息吗
7小时前
2回复
夜一YaiChi
并不是，现在都是 Responses API，只提交最新一条消息就行
6小时前
回复
账号已注销
工程学上的取舍问题嘛，即使你把索引放在内存里面，总有一天索引也会让内存爆啊。它只是一个临时解决方案，而不是一个终极解决方案。Durable+SQLite 的数据库存储才可能是最优解吧
14小时前
1回复
remiliaOP
所以索引分页一下，我感觉整个sqlite真是挺好，不过可能pi想简单点吧
10小时前
回复
邪恶的半自动洗衣粉
直接codex魔改得了，我感觉agentscope都比pi好用点
11小时前
回复
remiliaOP
是真的
10小时前
回复
邪恶的半自动洗衣粉
回复 @remilia 什么东西都自己做，到最后就是一坨屎。
10小时前
回复
魔化赤衣尊者
这是什么实现方案 我在优化这个 单session 动不动就一百多内存占用 得优化一下
4小时前
回复