maogeigei
757c2f1959
- 自动化任务调度机制.md: Debug SQL cd ~/.workbuddy + python 便携化
- mcn-data-insight(SKILL+抖音数据规则): 榜单落盘 C:/Users/maidou/Desktop 改桌面解析规则
- MCP_工具调用规范.md(主+ dou-analysis 副本): 废弃 MCNVideo AI 路径锚点改 D:/AgentSkill 两步判定
- 创作流程规范.md + 4_/11_ 流程: MCNSkillCase 残留改 产出根目录/{账号名} 规则
- mcn-video-prompt(SKILL+references-add): 废弃 DSHSkill项目 兜底并入用户环境
- 豁免保留: 禁止性规则示例行/变更记录历史行/references-add 路径配置
5.3 KiB
5.3 KiB
自动化任务调度机制（09-01 定稿，实测验证）
本文档固化 08-31~09-01 多次调试理清的客户端自动化调度机制，是工作台
/api/run链路唯一权威说明。 结论均来自本机实测（automations / automation_runs / sessions 三表 + 调度器实际行为），非推测。
一、完整链路
工作台按钮 → POST /api/run → 直写 ~/.workbuddy/workbuddy.db automations 表
→ 客户端调度器按 next_run_at 扫描（周期 ≈30s）
→ 命中 → automation_runs 写 QUEUED → 建会话（sessions 表, is_background_automation=1）
→ IN_PROGRESS（meta 含 conversationId/sessionId）→ 执行 → ACCEPTED（含 resultState/resultEvidence）
1 任务 = 1 会话，一一对应。
二、根因（必须牢记）
| 现象 | 根因 |
|---|---|
| 工作台任务全卡死、永不执行 | 调度器按 next_run_at 列扫描。工作台直写 SQLite 时若缺/空该列 → 永不拾取（08-31 P2「去掉 next_run_at 用 scheduled_at」是错误判断，09-01 已纠正） |
scheduled_at 写过去时间 → 卡死 |
客户端只对未来 scheduledAt 自动补算 next_run_at；过去/太近时间 → 不补算 → 扫不到 |
| 误以为「调度器停摆」 | 调度器从未停摆（33022 秒级准点执行过）；停摆假象 = next_run_at 没填 |
三、硬规则（实测阈值）
- scheduled_at 必须未来，且留足余量：+60s 稳、+17s 失败（update 往返有几秒延迟，越近越险）
- next_run_at 必须显式写入（工作台链路）：
Date.now() + 5000（+5s 即可，因为这是直写、无补算依赖） - 立即执行参数不存在：argv.json（仅 IDE 渲染）、settings.json（仅插件/sandbox/claw）、无 workbuddy CLI，客户端无并发数/扫描周期配置项 → 无法通过参数控制
- 实际开始时间 = 写库时刻 + 5s（next_run_at）+ 扫描周期（≤30s）≈ 5~35s（工作台按钮链路已是最快路径）
四、并发与排队（09-01 实测）
- 客户端后台自动化并发上限 ≈ 3：同秒触发 5 任务 → 3 个立即并行（各建会话）、2 个排队
- 排队标记：automation_runs.metadata_json 含
queuedPosition（1、2、…） - 并行是任务层面天然支持的，无需任何配置；超出 3 个自动排队
五、automation_runs 状态机
QUEUED（排队, meta.queuedPosition）
→ IN_PROGRESS（建会话, meta.conversationId/sessionId）
→ ACCEPTED（完成, meta.resultState=delivered|side_effect_only|partial_delivered, resultEvidence=assistant_output|external_action|local_file_mutation|none）
另有 PENDING_REVIEW（待人工确认，工作台轮询时显示「待确认」）。
表结构：thread_id / automation_id / status / read_at / thread_title / source_cwd / runs_json / result_success / metadata_json / created_at / updated_at
六、排查命令（Windows / Git Bash）
cd ~/.workbuddy
python -c "
import sqlite3
db = sqlite3.connect('workbuddy.db'); db.row_factory = sqlite3.Row
for r in db.execute(\"SELECT id,name,scheduled_at,next_run_at,last_run_at,status FROM automations WHERE deleted_at IS NULL ORDER BY created_at DESC LIMIT 10\"):
print(dict(r))
print('---runs---')
for r in db.execute(\"SELECT automation_id,status,metadata_json FROM automation_runs ORDER BY created_at DESC LIMIT 10\"):
print(dict(r))
"
判定要点：
- 任务有
next_run_at且 < now → 应已被拾取（看 automation_runs） last_run_at仍 None + runs 无记录 → next_run_at 没补算（scheduled_at 太近/过去）- runs 有 QUEUED → 在排队（并发 >3）；有 IN_PROGRESS → 正在跑（看 sessions working）
- 会话：
SELECT id,title,status,created_at FROM sessions WHERE is_background_automation=1
七、服务维护
- 启动：
node server.js（零依赖，端口 8899 自动避让） - 改 server.js 后必须重启才生效（Windows：
taskkill /PID <pid> /F后重启） - 后台运行：
node server.js > /tmp/mcn-workshop.log 2>&1 &
八、重新执行历史任务的标准姿势（09-02 固化）
背景：用户要求"前3条重写"时，曾误在会话内直接手写脚本草稿（影子脚本：不入库、不在左侧会话栏、不走技能会话）。根因=没有先判定执行方式。正确姿势如下：
- 取原任务 prompt：从
~/.workbuddy/workbuddy.db的automations表按任务 id 读取完整 prompt（含人设卡+视频选题+创作要求+落库字段） - 组装并提交：
POST /api/run，body 含{ prompt: <原prompt>（可按需附注"执行最新技能版本"）, name: '重写-...', skills: ['短视频工作台'] }——skills_json让客户端会话挂载指定技能，任务自动应用当前技能版本（含最新优化） - 轮询状态：
GET /api/run/status?id=<新任务id>（queued/pending/running/done/error/review） - 验证落库：任务完成后查
mcn-plugin.db的rewrite_log表，确认video_id/script_text/status='done'已更新；前端在 AI写脚本页可见 - 不重复建任务：同一"重写"诉求只提交一次；若用户要"改一版"，也是新任务而非改原任务
与并发约束的关系：一次提交 3 条重写任务 → 3 个并行（上限≈3）或部分排队（queuedPosition），均正常；先提交先执行，无需手工控制。