工单队列无值守代理批处理

你要解决的问题

待办清单躺在 issue tracker 里，逐个点开、分派、盯进度，把半天时间吃掉。更麻烦的是，自动化脚本一旦跑起来就停不下来：代理卡在某个依赖缺失的问题上反复重试，把无关工单也拖下水。你被拉回来处理的不是真正需要你拍板的决策，而是 car 这种命令行工具该干的机械劳动。

技能做了什么

这套方案把计划好的 backlog 先转成一批 markdown 工单文件，每张工单描述清楚要做什么、验收标准是什么，然后交给编码代理批量执行。

核心机制是一个状态机，称为 CAR：

• 只要队列里还有未完成的工单，就取出下一张，交给 Codex 或 OpenCode 之类的代理运行
• 工单可以由你自己预先写好，也可以由代理生成，或在运行时动态补充
• 每张工单跑完写回结果，状态流转由 run history contract 和 state roots contract 两份契约约束，保证下次启动时能接着上次的进度继续

关键在于升级策略：只有遇到真正的阻塞（环境缺失、需求模糊到无法继续）或需要人来拍板的决定时，流程才会停下来把你拉回来。其余情况——包括修复编译错误、补测试、重写片段——全部留在代理侧闭环处理。

适用边界

• 工单本身需要足够清晰。代理能执行任务，但不能替你把模糊需求翻译成实现细节，写得潦草的工单只会换来一轮又一轮的重试
• 项目需要有 Git 管理的工作区，每次变更才能追溯和回滚
• 批量运行意味着同时存在多个代理改动同一仓库的风险，建议为每个工单准备独立分支或工作树
• 阻塞升级的判断目前依赖代理自身反馈，遇到代理误报阻塞时仍需要人工确认

适合的场景是结构明确、验收标准可写的批量改造任务，比如「给二十个模块各补一组单元测试」或「按迁移清单逐个替换 API 调用」。纯探索性、没有明确终点的工作，放在队列里跑只会浪费 token。