自主会话工作流 是做什么的？
一种5阶段可重复结构，适用于自主智能体会话，可防止重复工作、确保持久化学习，并将输出导向有意义的交付物而非无效操作。
在gptme架构上经过数千次自主会话的实战检验。各阶段设计是运行时无关的——请根据你的技术栈适配具体工具，同时保持阶段结构完整。
何时使用
- 在每个自主智能体会话开始时（没有真人实时指导工作）
- 当智能体需要从积压任务或队列中自主选择工作时
- 当会话无人值守运行且需要产生持久化产物时
何时不用
- 交互式会话中，由人类每一轮提供下一个提示——只需直接响应
- 具有固定目标的单次工具调用（无需选择）
- 从父任务派生的子代理调用（父任务已选择工作）
5个阶段
阶段1：加载上下文
加载智能体的身份、会话状态和当前世界模型。
# 读取身份文件——角色、目标、操作约束
# （根据你的技术栈适配：CLAUDE.md、AGENTS.md、系统提示等）
# 读取动态上下文——近期日志、任务队列、git状态、通知
# （适配：上下文脚本、配置驱动引用或提示注入）
# 评估以前会话中的未完成事项：
# - 应完成或放弃的过期声明
# - 你承诺关闭的issue/PR上的待回复
# - 进行中的分支或开放工作树
关键问题：“我上次留下了什么未完成？离线期间发生了什么变化？”
如果某个未完成事项可在5分钟内解决，则在此处处理。否则记录下来并继续。
阶段2：工作选择
按顺序尝试各层级，直到找到可执行的工作。这些层级防止智能体在存在真实任务时编造忙碌工作，并防止在所有任务被阻塞时出现饥饿状态。
层级1 — 主动任务：已在进行中的工作；最高优先级
层级2 — 积压快捷任务：依赖已就绪、可在本会话完成的项目
层级3 — 自我提升：当所有任务都因外部原因被阻塞时
├─ 创意积压（推进得分最高的创意）
├─ 自我审查/审计（发现并修复一个真实问题）
├─ 内部工具改进
├─ 文档（仅限过时的文档）
├─ 代码质量（类型检查、测试、lint）
└─ 经验质量（修复有害或过时的经验）
抗单调隔离机制：如果同一类别在过去N个会话中占据主导，即使它看起来是最佳选择也要跳过。类别多样性是学习新失败模式的强制函数。
当一切枯竭时：如果所有层级1/2的任务都因外部原因被阻塞，且层级3的通道已饱和（达到每日限制），则写一条简短的克制日志，记录你检查了什么以及有意跳过了什么。一个有理由的不操作比编造工作更好。
阶段3：声明
在执行之前，获取独占协调声明。这可以防止两个并发会话执行相同工作、淹没同一个PR线程或写入同一个文件。
# 通用协调模式——根据你的技术栈适配工具：
claim_key="task:<task-id>" # 用于任务驱动的工作
claim_key="github:<owner>/<repo>#<num>" # 用于issue驱动的工作
claim_key="content:<slug>:<date>" # 用于内容/产物创建
# 获取声明（示例使用协调CLI）：
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# CLAIMED → 继续
# DENIED → 另一个会话已在此项上；选择下一个候选
先声明后通知规则：任何对他人可见的操作（发表评论、发送消息、打开PR）都必须先通过声明。没有声明的社交行为会趋同并产生垃圾——先声明后发送的模式可以防止泛滥。
完成时：coordination work-complete "<session-id>" "$claim_key"
转向/失败时：coordination work-abandon "<session-id>" "$claim_key"
阶段4：执行
做真正的工作。关键原则是交付，而非完美。
- 频繁且尽早提交（小而描述清晰的提交）
- 提交前运行测试（在CI发现问题之前先捕捉）
- 使用约定式提交：feat/fix/docs/refactor/chore
- 在会话结束前推送到远程
- 如果卡住超过10分钟，继续前进——不要将预算浪费在兔子洞里
- 不要添加未要求的特性或范围蔓延
50分钟预算：大多数自主会话应在50分钟内完成有意义的工作。如果任务更大，则交付一个增量切片并为剩余部分创建后续任务。
阶段5：持久化
最被低估的阶段。阶段1-4中完成的所有内容在会话之间都会消失，除非它被持久化地提交。
# 1. 写入日志条目（会话特定文件，追加写入）
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# 会话 <HASH>
**日期**：YYYY-MM-DD
**结果**：productive|blocked|noop — 一句话描述
**类别**：code|research|strategic|maintenance|...
## 此项工作的原因
[什么导致了这个工作]
## 我做了什么
[具体变更，附带commit/PR链接]
## 验证
- [测试通过？CI变绿？]
## 持久化学习
- 任务状态：<task> → done/waiting
- 新经验：[如果有]
- “本次会话没有持久化反馈”——如果确实没有可添加的内容
## 下一步
[明确的后续动作或阻塞因素]
EOF
# 2. 更新任务状态
task edit <task-id> --set state done # 或 waiting，如果被阻塞
# 3. 如果发现了重复出现的失败模式，写一条经验/规则
# （在下一次会话开始时注入关键词匹配的上下文文件）
# 4. 推送所有提交
git push origin master
先持久化后应用规则：如果发现了有用的东西，在将其应用于当前工作之前先写下经验。一旦修复完成，失败模式感觉已被解决，而经验就会被跳过。日志记录发生了什么；经验记录如何再次识别它。
安装
Claude Code
将此技能目录复制到智能体的技能文件夹中：
cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow
然后使用 /autonomous-session-workflow 调用，将5阶段检查清单加载到上下文中。
手动 / 任意运行时
将 SKILL.md 复制到智能体的上下文路径中，并在会话开始时加载。这些阶段是纯 Markdown——可以包含整个文件或挑选与你的技术栈相关的部分。
常见理性化谬误
| 理性化 | 现实 |
|---|---|
| “我会跳过声明——现在只有我一个会话在运行” | 你看不到其他会话正在启动。并发生成是生产运行时的默认情况。声明是门禁，而不是观察。 |
| “我会在完成下一个任务后写日志” | 会话会被中断。日志就会被跳过。在推送之前写日志，而不是在“再做一件事”之后。 |
| “这个任务快完成了——我会跳过阶段5直接提交” | 学习只有持久化才能累积。那个“几乎”完成了闭环的会话，其洞察将在下次运行时消失。 |
| “我的选择很明显——我不需要逐层推进” | 跳过层级的选定是冗余工作和重复PR的主要来源。层级之所以存在，是因为“明显”往往不是实际需要做的事情。 |
| “这个经验太具体了，不可复用” | 具体的经验（确切的错误消息、确切的命令、确切的失败模式）是最有价值的——它们能在需要时精确触发。 |
| “一个理由充分的不操作感觉像失败” | 并非如此。为了逃避不操作标签而做填充提交会消耗配额、导致趋同混乱并掩盖真正的问题。克制日志本身就是交付物。 |
红色警报
- 在声明之前开始执行（趋同风险）
- 会话结束但没有日志和更新的任务状态
- 承诺“马上提交”——如果在结束前没有推送，就没有完成交付
- 同一类别连续三个会话，没有强制性的多样性中断
- “我会记住这个”——你不会；现在就把经验写下来
验证
运行良好的会话在关闭前应满足以下所有条件：
- 在行动前已声明（或合理说明无需声明）
- 有意义的工作已提交并推送
- 测试通过（或将已知失败记录在案并说明原因）
- 日志条目已写入，并且
持久化学习部分已填写 - 任务状态已更新（
active → done、active → waiting等） - 声明已完成或已放弃（未作为悬挂租约遗留）
适配你的技术栈
| gptme概念 | 你的对应物 |
|---|---|
gptodo | 任何支持状态转换的任务管理器 |
coordination work-claim | 锁文件、Redis SETNX 或 GitHub 评论门禁 |
lessons/<category>/name.md | 任何在会话开始时注入的关键词匹配上下文文件 |
journal/<date>/session-<hash>.md | 任何追加写入的会话日志 |
cascade-selector.py | 你的工作选择启发式算法或调度器 |
价值在于模式本身，而非特定工具。
相关
self-push（本目录中）——在交付任何输出前进行惰性检查pre-landing-review（本目录中）——在合并重要变更前的门禁multi-lens-review（本目录中）——跨多个视角的结构化PR审查five-element-spec（本目录中）——开始工作前的范围定义