baa-conductor

commit

cecd1c1

parent

b0e89a5

author

im_wower

date

2026-03-30 11:50:35 +0800 CST

discuss: Claude 回复定时任务与续命需求讨论 — 六个讨论点

 1@@ -110,3 +110,76 @@ GUI / a11y 作为后续扩展能力，留到下一阶段。
 2 - 续命任务是否应单独建模，而不是直接复用现有 task 结构
 3 - 续命状态集合是否足够支撑首版和后续扩展
 4 - API 代理是否可以作为第一阶段唯一执行路径
 5+
 6+
 7+## Claude 回复 — 2026-03-30
 8+
 9+### 整体判断
10+
11+方向对，拆分合理。插件定位为"事实上报者"，续命决策权收归 conductor 后台，这个架构决策解耦了感知和执行，后续扩展（超时补偿、人工重放、多策略续命）都有空间。
12+
13+以下是需要进一步讨论的六个点：
14+
15+### 讨论点 1：本地消息表的映射 — 建议加一层"对话身份"
16+
17+当前模型是 `本地消息ID + 平台类型 + 平台消息ID + 对话ID`。但三家 AI 的"对话"概念不统一 — Claude 有 conversation，ChatGPT 有 conversation 但 SSE 结构不同，Gemini 更特殊。
18+
19+**建议：** 消息表之外再建一张轻量的**本地对话表**（local_conversations），统一映射三家的对话身份。这样续命任务的"属于哪个对话"不用每次去消息上反查，也为后续"对话级策略"（比如某个对话暂停续命）留了锚点。
20+
21+**待确认：** 三家平台的对话 ID 格式和生命周期是否已经摸清？是否存在同一个对话在平台侧 ID 会变的情况？
22+
23+### 讨论点 2：续命任务独立建模 — 同意，但建议共享状态机基础设施
24+
25+不强行和现有 `tasks/runs` 等同是对的。但状态机本身（状态流转、重试计数、错误记录）是通用能力。
26+
27+**建议：** 抽一个轻量的 `job` 基础结构（状态 + 重试 + 错误 + 时间戳），续命任务和未来的执行任务都基于它扩展。不是复用 task 模型，而是共享状态机骨架，避免后续对接时再做一次合并。
28+
29+**待确认：** 现有 `tasks/runs` 的数据结构是什么样的？是否有字段可以直接复用到 job 基础结构中？
30+
31+### 讨论点 3：状态集合 — 建议首版精简
32+
33+原文列了六个状态：待开始 / 执行中 / 已发送 / 重试中 / 已完成 / 失败。
34+
35+**建议首版压到四个：** `pending → running → done → failed`
36+
37+理由：
38+- "已发送"和"已完成"的边界模糊 — 发送成功就是完成，发送失败就进重试
39+- "重试中"本质上是再次 running，用 `attempt_count` 字段区分即可
40+- 四状态足够支撑首版闭环，后续要加"已发送待确认"这种中间态再扩展不迟
41+
42+**待确认：** 是否有场景需要区分"已发送但未确认对方收到"？如果 API 代理返回 200 就算完成，四状态够用。
43+
44+### 讨论点 4：API 代理超时兜底
45+
46+API 代理受 Cloudflare 27-30s 超时限制。续命消息发送如果卡住，需要明确处理策略。
47+
48+**建议：** 定时任务对每个续命执行设一个 execution timeout（建议 20s），超时直接标记为需重试，不要等 Cloudflare 断连后再被动处理。
49+
50+**待确认：** 续命发送走的是公网 `conductor.makefile.so` 还是内网 `100.71.210.78:4317`？如果是内网直连则没有 Cloudflare 超时问题，但仍需要自己的超时保护。
51+
52+### 讨论点 5：定时任务扫描周期
53+
54+文档未提扫描频率。续命场景对时效性有要求（太慢了对话上下文就断了）。
55+
56+**建议：** 首版用固定间隔 10-15 秒扫一次。后续可演进为事件驱动 — 插件 WS 推送直接触发扫描，而不是等轮询。
57+
58+**待确认：** 各 AI 平台对话的"上下文窗口"有多长的容忍度？即从 SSE 结束到下一条消息发出，最多能间隔多久不影响连续性？这决定了扫描间隔的上限。
59+
60+### 讨论点 6：谁决定"要不要续命"？（核心问题）
61+
62+文档说"将满足条件的消息同步为续命任务"，但"满足条件"的规则未展开。这是核心业务逻辑。
63+
64+需要回答的问题：
65+- 是所有 SSE 结束消息都续命？还是只有特定对话 / 特定 AI？
66+- 是否有冷却期？同一个对话 N 秒内收到多条 final-message，是否只续一次？
67+- 是否需要"续命开关"？某些对话可能是一次性问答，不需要续命。
68+- 续命内容是什么？固定模板还是根据上下文动态生成？
69+
70+**建议：** 首版先做最简单的规则（"所有 final-message 都生成续命任务"），但把规则判断抽成独立函数（如 `shouldRenew(message): boolean`），方便后续加策略。
71+
72+### 建议的讨论优先级
73+
74+1. **讨论点 6**（续命判断规则）— 直接影响消息表到续命任务的转换逻辑
75+2. **讨论点 1**（对话身份映射）— 直接影响表结构设计
76+3. **讨论点 3**（状态精简）— 影响首版实现复杂度
77+4. 其余点可以在实现过程中逐步确认