ChatCrawlersearch across public Telegram Open the app
P

Python 中文交流群

22 936 members
22 July 2026
我个人建议花点钱买个课
不是我群群友们能回答好的问题
W
三年前可以回答
C
ai面试你能随便过我觉得基础差不多了
W
能上 tg 就不是一般人类,肯定是聪明的。 为什么不去和 AI 聊聊。
24 July 2026
agent设计: 我把每次会话拆分成【订阅模式】,即前端只发创建会话任务的请求,任务放在后台跑 现在有个问题,我想问,要为后续中断恢复做准备,我该怎么设计数据存储的位置
是存在服务器本地,读取本地文件,还是用redis,拿到上次的job_id匹配 去读取里面的信息
由于是用docker,redis倒也能做持久化操作
我会把最后的job_id存在pgsql,不知道这样是不是有点蠢
W
Xiaoagent设计: 我把每次会话拆分成【订阅模式】,即前端只发创建会话任务的请求,任务放在后台跑 现在有个问题,我想问,要为后续中断恢复做准备,我该怎么设计数据存储的位置
我的设计 不恢复。 无非是那个断掉的服务端 session 知道自己(我跑完了,但前端和我网断了) ,或者是他妈的我自己进程重启了,没来得及落库。 但本来已经跑了的部分,那些如果你存储了,能落库的已经落库了。 我自己的方式是 session Id + 文本 grep 。 这里和 redis 、pg 什么的关联,各有各的设计思路,就我个人是坚定的文本,filebased 。 因为我有激进的跨对话查询需求。 走 db 的话一样能走,但浪费我时间,且代码看起来复杂度会上来点。 中间的 id ,什么 tool,job, 各种,丢了就丢了。 下次是继续对话重跑一次,比起试图继续一个 session 里的一个 job ,好一点。 对话过程不重建。 断是事实,丢就丢了。 对话还在就行,agent 又不是不能继续跑
W
如果断了,那不是不断重复吗
W
只是没跑完的可能会丢失
25 July 2026
X
我整理一下,下周和我们组的商量一下,因为这是我第一次接触agent的开发工作,有些拿不定主意
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