P
24 July 2026
是存在服务器本地,读取本地文件,还是用redis,拿到上次的job_id匹配 去读取里面的信息
由于是用docker,redis倒也能做持久化操作
我会把最后的job_id存在pgsql,不知道这样是不是有点蠢
X
Z
PostgreSQL is all you need
W
Xiaotext not yet in the index我的设计
不恢复。 无非是那个断掉的服务端 session 知道自己(我跑完了,但前端和我网断了) ,或者是他妈的我自己进程重启了,没来得及落库。
但本来已经跑了的部分,那些如果你存储了,能落库的已经落库了。 我自己的方式是 session Id + 文本 grep 。 这里和 redis 、pg 什么的关联,各有各的设计思路,就我个人是坚定的文本,filebased 。 因为我有激进的跨对话查询需求。 走 db 的话一样能走,但浪费我时间,且代码看起来复杂度会上来点。
中间的 id ,什么 tool,job, 各种,丢了就丢了。 下次是继续对话重跑一次,比起试图继续一个 session 里的一个 job ,好一点。
对话过程不重建。 断是事实,丢就丢了。 对话还在就行,agent 又不是不能继续跑
W
你一个跑完的 loop 的内容已经存了啊
W
25 July 2026
Z
X
我整理一下,下周和我们组的商量一下,因为这是我第一次接触agent的开发工作,有些拿不定主意
26 July 2026
Y
具体的checkpoint放在哪里 这个就无所谓了 看场景
28 July 2026
讨论了一下
目前还用不到这些,
不过我打算参考basefiled的那个法子
后续如果要真的跑业务数据,
即时记录sql进行到哪一步,
还是非常有必要的
X
先提交一板混混👻,预留一些位置便于后续迭代
A snapshot of an open public feed from the search index
ChatCrawler — “Google for public Telegram”; refreshed as the venue is crawled.
Times are UTC.
Public content only, official Telegram API.
About ·
FAQ ·
What we do not do ·
Remove a page ·
Catalog