22 July 2026
24 July 2026
Xiaoagent设计:
我把每次会话拆分成【订阅模式】,即前端只发创建会话任务的请求,任务放在后台跑
现在有个问题,我想问,要为后续中断恢复做准备,我该怎么设计数据存储的位置
我的设计
不恢复。 无非是那个断掉的服务端 session 知道自己(我跑完了,但前端和我网断了) ,或者是他妈的我自己进程重启了,没来得及落库。
但本来已经跑了的部分,那些如果你存储了,能落库的已经落库了。 我自己的方式是 session Id + 文本 grep 。 这里和 redis 、pg 什么的关联,各有各的设计思路,就我个人是坚定的文本,filebased 。 因为我有激进的跨对话查询需求。 走 db 的话一样能走,但浪费我时间,且代码看起来复杂度会上来点。
中间的 id ,什么 tool,job, 各种,丢了就丢了。 下次是继续对话重跑一次,比起试图继续一个 session 里的一个 job ,好一点。
对话过程不重建。 断是事实,丢就丢了。 对话还在就行,agent 又不是不能继续跑
25 July 2026
Zhijiang LanPostgreSQL is all you need
当然,前提是,你这个项目要服务多用户、多客户端,如果是单纯服务一个人,那sqlite就整挺好了,甚至我更推荐file-based