baa-conductor

git clone 

commit
b0e89a5
parent
4670b3e
author
codex@macbookpro
date
2026-03-30 11:31:00 +0800 CST
docs: add timed jobs renewal discussion brief
1 files changed,  +112, -0
A plans/discuss/DISCUSS-TIMED-JOBS-RENEWAL-REQUIREMENTS.md
+112, -0
  1@@ -0,0 +1,112 @@
  2+# 定时任务模块与续命任务需求讨论稿
  3+
  4+> 日期: 2026-03-30
  5+> 状态: 讨论中
  6+
  7+## 目标
  8+
  9+为 `conductor` 增加一个独立的定时任务模块,统一处理后台异步工作。首版目标不是做完整任务编排,而是先把“消息入库 → 续命任务生成 → API 代理发送 → 状态回写”这条链路跑通。
 10+
 11+这个模块可以视为系统内的轻量消息队列和兜底执行层。
 12+
 13+## 当前范围
 14+
 15+- 支持三类后台任务:消息同步任务、续命任务、执行类任务
 16+- 浏览器插件拦截 AI 页面 SSE 结束消息后,通过 WS 推送给 `conductor`
 17+- `conductor` 将消息保存到本地消息表
 18+- 定时任务扫描新消息,生成续命任务
 19+- 定时任务执行续命任务,调用浏览器 API 代理完成发送
 20+- 执行完成后更新续命任务状态
 21+
 22+## 当前不做
 23+
 24+- 不做 GUI 自动化
 25+- 不做操作系统辅助功能发送
 26+- 不依赖 Safari、前台窗口、剪贴板等本机能力
 27+- 不要求第一版直接复用现有开发任务执行模型
 28+
 29+GUI / a11y 作为后续扩展能力,留到下一阶段。
 30+
 31+## 消息需求
 32+
 33+系统需要一张本地消息表,使用我们自己的唯一消息 ID,不直接使用各 AI 平台的消息 ID 作为主键。
 34+
 35+本地消息表需要满足两个要求:
 36+
 37+- 能表达 `conductor` 自己的统一消息身份
 38+- 能保存与 Claude、ChatGPT、Gemini 等平台消息的对应关系
 39+
 40+这意味着消息模型需要同时保存:
 41+
 42+- 本地消息 ID
 43+- 平台类型
 44+- 平台消息 ID
 45+- 对话 ID
 46+- 消息内容
 47+- 观察时间
 48+- 必要的平台上下文
 49+
 50+## 续命任务需求
 51+
 52+续命任务来自消息表,不直接来自插件。也就是说,插件只负责上报事实消息,续命动作由后台定时任务决定并执行。
 53+
 54+续命任务至少需要表达:
 55+
 56+- 由哪条本地消息触发
 57+- 属于哪个平台和对话
 58+- 要发往哪个浏览器代理目标
 59+- 要发送什么续命内容
 60+- 当前执行状态
 61+- 已尝试次数
 62+- 最近错误信息
 63+
 64+## 续命状态
 65+
 66+续命任务首版至少需要这些状态:
 67+
 68+- 待开始
 69+- 执行中
 70+- 已发送
 71+- 重试中
 72+- 已完成
 73+- 失败
 74+
 75+这些状态要能支持后续补充超时、补偿、人工重放等能力。
 76+
 77+## 定时任务模块职责
 78+
 79+定时任务模块至少负责两条周期性链路:
 80+
 81+1. 消息同步任务:扫描新消息,将满足条件的消息同步为续命任务
 82+2. 续命执行任务:扫描待执行续命任务,调用 API 代理执行发送,并回写状态
 83+
 84+后续如果要纳入“执行指令 / 开发任务”,也应复用同一套定时任务框架,但不要求第一版一次完成全部能力。
 85+
 86+## 与现有 tasks 的关系
 87+
 88+这套需求与当前 `conductor` 已有的 `tasks/runs` 概念有关,但不应强行等同。
 89+
 90+当前讨论倾向是:
 91+
 92+- 消息同步和续命任务先独立建模
 93+- 开发类任务继续沿用现有 `tasks` 方向
 94+- 后续再决定是否将两套模型对接,或由定时任务模块桥接到现有 tasks 接口
 95+
 96+## 第一版验收目标
 97+
 98+第一版只验证下面这条最小闭环:
 99+
100+1. 插件拦截 SSE 结束消息
101+2. `conductor` 将消息写入本地消息表
102+3. 定时任务将消息同步成续命任务
103+4. 定时任务调用 API 代理发送续命消息
104+5. 续命任务状态从待开始推进到已完成,失败时进入重试或失败状态
105+
106+## 讨论重点
107+
108+当前需要重点核对的是:
109+
110+- 本地消息表与平台消息的映射关系是否合理
111+- 续命任务是否应单独建模,而不是直接复用现有 task 结构
112+- 续命状态集合是否足够支撑首版和后续扩展
113+- API 代理是否可以作为第一阶段唯一执行路径