ChatCrawlersearch across public Telegram Open the app
P

Python 中文交流群

snapshot for July 2026
July 2026 ×
24 July 2026
是存在服务器本地,读取本地文件,还是用redis,拿到上次的job_id匹配 去读取里面的信息
由于是用docker,redis倒也能做持久化操作
我会把最后的job_id存在pgsql,不知道这样是不是有点蠢
W
Xiaotext not yet in the index
我的设计 不恢复。 无非是那个断掉的服务端 session 知道自己(我跑完了,但前端和我网断了) ,或者是他妈的我自己进程重启了,没来得及落库。 但本来已经跑了的部分,那些如果你存储了,能落库的已经落库了。 我自己的方式是 session Id + 文本 grep 。 这里和 redis 、pg 什么的关联,各有各的设计思路,就我个人是坚定的文本,filebased 。 因为我有激进的跨对话查询需求。 走 db 的话一样能走,但浪费我时间,且代码看起来复杂度会上来点。 中间的 id ,什么 tool,job, 各种,丢了就丢了。 下次是继续对话重跑一次,比起试图继续一个 session 里的一个 job ,好一点。 对话过程不重建。 断是事实,丢就丢了。 对话还在就行,agent 又不是不能继续跑
W
如果断了,那不是不断重复吗
W
只是没跑完的可能会丢失
25 July 2026
X
我整理一下,下周和我们组的商量一下,因为这是我第一次接触agent的开发工作,有些拿不定主意
26 July 2026
设置一下重试强限制
超过就直接输出当前结果 然后丢掉
Y
具体的checkpoint放在哪里 这个就无所谓了 看场景
28 July 2026
讨论了一下 目前还用不到这些, 不过我打算参考basefiled的那个法子
现阶段只适合做个售前产品
后续如果要真的跑业务数据, 即时记录sql进行到哪一步, 还是非常有必要的
因为是要操作多个服务器的多个项目
只适合做售前工具
X
先提交一板混混👻,预留一些位置便于后续迭代
Open in Telegram Каталог площадок Искать в ChatCrawler

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