自主会话工作流机制

要解决的具体问题

自主代理在无人值守会话中常陷入几种结构性困境。首先是重复工作：多个会话同时启动时，如果没有协调机制，它们可能选中同一任务并各自实现一遍。其次是会话间记忆断裂：上一轮会话发现的教训、修复的缺陷，在下一次会话中往往被遗忘，因为"等会儿再写下来"变成了永远的"等会儿"。最后是交付偏好偏移：代理容易把"做了动作"等同于"交付了价值"，产出一堆无实质进展的提交。

五阶段工作流如何运转

该技能将一次完整的自主会话划分为五个阶段，形成可重复的检查清单：

1. 上下文加载 — 恢复代理身份、会话状态和当前世界模型。核心问题是弄清"上次留下了什么，离线期间发生了什么变化"。
2. 工作声明（Claim） — 在动手前通过 coordination work-claim 机制锁定任务，防止并发会话重复选中同一工作。失败或转向时调用 work-abandon 释放租约。
3. 任务选择 — 通过 cascade-selector 启发式从待办队列中按优先级分层选择工作，避免"看起来最明显的任务"垄断会话资源。
4. 执行 — 核心纪律是交付而非完美。多数会话应在 50 分钟预算内产出有意义的增量；任务过大时提交切片并为剩余部分创建后续任务。
5. 持久化 — 在推送代码前先写下教训，否则修复完成后的上下文会消失。日志记录发生了什么，教训则捕捉再次识别它的时机。

适用边界与注意点

该工作流不适用于以下场景：人类每轮提供提示的交互式会话、固定目标的一次性工具调用、由父任务启动的子代理。核心价值在于模式而非工具——gptodo 可替换为任意带状态机的任务管理器，lessons/ 可替换为关键词匹配的上下文文件。

需要警惕的合理化行为包括：跳过声明（"只有我一个会话在跑"）、延迟日志（"做完下个任务再写"）、跳过分层选择（"这个任务很明显"）、用填充提交逃避 NOOP 标记。一个成功结束的会话应满足：行动前已声明、有意义的工作已推送、测试通过或已知失败已记录、日志已写入、任务状态已更新、声明已完成或放弃。