maogeigei
b2e472bf27
- 调度根因修复：工作台/api/run 显式写 next_run_at=now+5s（17列），scheduledAt=now+5s 带秒 - 新增 自动化任务调度机制.md（根因/硬规则/状态机/并发上限≈3/排查命令） - 并发方案A（浏览器锁）：/api/run 对浏览器类任务自动注入锁约束；浏览器搜索抖音账号操作规范.md 新增5.6并发互斥 - 端口 8899→8900 可传参（8899被小米MiPCAudio.exe系统服务占用且杀后复活） - cdp-test-junxi.mjs 支持 --port 参数 - SKILL.md 工作台段落同步修正（旧认知 scheduled_at=now 已废弃） - 俊希全流程 TC-01~11 复测全通过（验收表更新）：并行解析6条+AI写脚本会话链路完整跑通
5.6 KiB
5.6 KiB
2026-09-01 工作日志
调度链路修复后：重派 6 条俊希视频解析任务（00:02-00:08）
- 背景：08-31 深夜确认调度根因=automations scheduledAt 必须未来时间才补算 next_run_at；金丝雀任务（337935e0）已验证成功执行并开出会话 f4232ef1
- 重派（用户选「重派6条视频解析任务」）：6 条 once 任务，scheduledAt 依次 00:03:07~00:08:09（未来时间错开 1 分钟），cwds=D:\AgentSkill\mcn-workshop（会话归 mcn-workshop 空间）
detailId 任务名 scheduledAt nextRunAt 补算 33022 俊希-解析视频-33022 00:03:07 ✅ 1788192187000 33021 俊希-解析视频-33021 00:04:08 ✅ 1788192248000 29596 俊希-解析视频-29596 00:05:08 ✅ 1788192308000 15729 俊希-解析视频-15729 00:06:09 ✅ 1788192369000 21514 俊希-解析视频-21514 00:07:09 ✅ 1788192429000 20164 俊希-解析视频-20164 00:08:09 ✅ 1788192489000 - 关键验证点：6 条全部返回 nextRunAt（此前卡住的 6 条即这批 detailId 全无 nextRunAt）→ 预期调度器逐条拾取、mcn-workshop 空间陆续出现 6 个后台自动化会话（1 任务=1 会话）
- prompt 自包含：明确 mcn-dou-analysis 技能路径 + 功能五解析 + MCP short_video_detail/upload_douyin_video + content.json 边界规则 + 落盘
桌面\MCNSkill项目\俊希\视频分析\{标题}_标签1_标签2\+ 完成后回解析摘要 - 待追加：6 条任务执行结果（automation_runs ACCEPTED / 会话创建 / 解析产出落盘）
调度器秒级准点实证 + 并行改期教训 + 工作台 next_run_at 修复（00:03-00:07）
- 33022 准点执行实证（调度器从未停摆）：create 时补算 nextRunAt=00:03:07 → 调度器准点拾取 → automation_runs ACCEPTED（00:03:17）→ 会话 442280f0「解析俊希账号指定视频」completed。后台会话 5→6。即 create 时设 +60s 未来时间 → 秒级准点执行
- 改期教训（我的失误）：为并行把 6 条 update 到 00:04:50（距 update 时刻仅 ~17s 余量）→ 客户端判定太近清空 next_run_at → 5 条卡死（33022 因已在 00:03:07 执行不受影响）。规则：automation_update 的 scheduledAt 必须留足够未来余量（实测 +60s 稳、+17s 失败），update 往返有几秒延迟，越近越险。已用 +60s（00:07:06）恢复 5 条，nextRunAt=1788192426000 全部补算成功
- 工作台 server.js 根因修复（08-31 P2 判断有误需纠正）：实测证明客户端调度器按 next_run_at 扫描（33022 有 nextRunAt 才执行；工作台直写 SQLite 的 next_run_at=null 全卡死）。之前 P2「去掉 next_run_at 列（执行器用 scheduled_at/created_at）」是错误判断。修复：
/api/run①scheduled_at=now+5s（带秒，未来）②恢复 next_run_at 列 = Date.now()+5000（17 列）→ 工作台按钮触发后 +5s 调度器拾取，满足用户「10 秒内执行」诉求 - 「10 秒内」机制边界：Agent 侧 automation_update 受客户端补算阈值限制（余量不足不补算），无法稳定 10s 内；工作台直写 next_run_at=now+5s 可稳定 10s 内执行。用户诉求正确落点=工作台按钮链路
- 服务当前未运行（8899 无响应）；server.js 已改+语法通过，下次启动生效
09-01 00:10 关键验证：并行执行实测通过 + 立即执行参数结论
- 5 任务并行实测（00:07:06 触发）：调度器 00:07:32.7 全部拾取（拾取延迟 ~27s = 客户端扫描周期）；3 个立即 IN_PROGRESS 各建会话（29596/33021/15729 working），2 个 QUEUED 排队（21514 pos1/20164 pos2）→ 客户端后台自动化并发上限≈3，超出排队（queuedPosition 标记）；1任务=1会话 1:1 并行成立
- automation_runs 状态机：QUEUED(排队,有queuedPosition)→IN_PROGRESS(建会话,meta含conversationId/sessionId)→ACCEPTED(完成,meta含resultState/resultEvidence)；表列=thread_id/automation_id/status/read_at/thread_title/source_cwd/runs_json/result_success/metadata_json
- 立即执行参数：不存在。已查 argv.json(仅IDE渲染参数)/settings.json(仅插件/sandbox/claw)/无 workbuddy CLI；客户端无并发数/扫描周期配置项 → 无法通过参数控制立即执行
- 工作台按钮已是最快路径：server.js /api/run 写 scheduledAt=now+5s + next_run_at=now+5000（17列），点击后 5s 进入调度器视野 + 扫描周期(≤30s) → 实际开始 5~35s
- 服务已重启（00:10:08, PID 23820），server.js 修复代码确认在位（369-375行）
09-01 00:25 并发方案A（浏览器锁）落地 + 端口迁移 8899→8900
- 方案A 落地：server.js /api/run 对浏览器类任务（正则匹配 账号信息|视频列表|保存并分析|采集|导入账号|网页采集|浏览器）自动注入【浏览器锁约束】——锁文件
D:/AgentSkill/mcn-workshop/.browser-lock，操作前查锁→10s重试×18次（3分钟）→死锁保护（超10分钟可抢占）→完成后删锁；规范文档新增 5.6 并发互斥节（含 bash 拿锁/释放示例） - 8899 被小米占用（新坑）：
MiPCAudio.exe（小米 PC 管家音频共享服务）系统级占用 0.0.0.0:8899 且杀后自动复活（taskkill 无效）→ server.js 绑定 127.0.0.1:8899 不生效、curl/内置浏览器全 000 - 修复：server.js 支持
node server.js [端口]传参（PORT_BASE=argv[2]||8899），改用 8900 启动，HTTP 200 验证通过，内置浏览器已打开 - bash
&后台进程会被会话回收：必须用 run_in_background=true 方式启动长驻服务，普通&+ 重定向会在命令返回后被清理