自主會話工作流程 是做什麼的？
一個為自主代理會話設計的五階段可重複結構，可防止重複工作、確保持久性學習紀錄，並將輸出成果導向有意義的已交付成品，而非無效動作。
該流程已在 gptme 架構上經數千個自主會話的實戰驗證。這些階段與運行時無關 — 可根據你的技術棧調整具體工具，但保留階段結構不變。
使用時機
- 每個自主代理會話開始時（無人直接指揮工作）
- 當代理必須從待辦事項或佇列中自行選擇工作時
- 當會話在無人看管下執行，且需要產出持久性成品時
不適用時機
- 互動式會話，人類在每一輪提供下一個提示 — 只需回應即可
- 一次性的工具調用，且目標固定（無需選擇）
- 從父任務產生的子代理呼叫（父任務已選定工作）
五個階段
階段 1：載入情境
載入代理的身份、會話狀態及當前世界模型。
# 讀取身份檔案 — 角色、目標、操作限制
# （根據你的技術棧調整：CLAUDE.md、AGENTS.md、系統提示等）
# 讀取動態情境 — 近期日誌、任務佇列、git 狀態、通知
# （調整：情境腳本、設定驅動的引入，或提示注入）
# 評估先前會話中未完成的事項：
# - 應完成或放棄的過期聲明
# - 你承諾要關閉的問題/PR 上待回覆的訊息
# - 進行中的分支或開放的工作樹
關鍵問題：「我留下了什麼未完成？離線期間有什麼改變？」
如果未完成事項可在 5 分鐘內解決，在此處處理。否則記下它並繼續。
階段 2：工作選擇
按順序嘗試各層級，直到找到可執行的工作。這些層級可防止代理在有真實任務時發明無意義的工作，並防止所有任務都被阻塞時代理無事可做。
第 1 層 — 進行中的任務：已經在進行的工作；最高優先級
第 2 層 — 待辦事項快速勝利：依賴項已就緒、可在本次會話完成的事項
第 3 層 — 自我改進：當所有任務都被外部阻塞時
├─ 點子待辦清單（推進得分最高的點子）
├─ 自我審查／稽核（找出並修復一個真實問題）
├─ 內部工具改進
├─ 文件（僅限過時的文件）
├─ 程式碼品質（型別檢查、測試、lint）
└─ 教訓品質（修復有害或過時的教訓）
反單調守衛：如果同一類別在過去 N 次會話中佔據主導地位，即使它看起來是最好的選擇，也要跳過它。類別多樣性是學習新失敗模式的強制函數。
當一切乾涸時：如果所有第 1/2 層任務都被外部阻塞，且第 3 層車道已飽和（達到每日限制），則撰寫一篇簡短的「克制日誌」，記錄你檢查了什麼以及刻意跳過了什麼。合理的無操作 (NOOP) 勝過捏造工作。
階段 3：聲明
在執行之前，獲取一個獨佔的協調聲明。這可以防止兩個並發會話執行相同的工作、在同一 PR 討論串中刷屏，或寫入同一個檔案。
# 通用協調模式 — 根據你的技術棧調整工具：
claim_key="task:<task-id>" # 用於任務驅動的工作
claim_key="github:<owner>/<repo>#<num>" # 用於問題驅動的工作
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 之前發現問題）
- 使用 Conventional Commits：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|...
## 為何做此工作
[導致此工作的原因]
## 我的作為
[具體變更，附提交/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 將五階段檢查清單載入到情境中。
手動安裝／任何運行時
將 SKILL.md 複製到代理的情境路徑中，並在會話開始時載入它。這些階段是純 Markdown — 可以包含整個檔案，或挑選與你的技術棧相關的部分。
常見的自我合理化陷阱
| 合理化說法 | 實際情況 |
|---|---|
| 「我跳過聲明 — 現在只有我一個會話在運行」 | 你看不到其他會話正在啟動。並發產生是生產環境運行時的預設行為。聲明是閘門，不是觀察結果。 |
| 「我完成下一個任務後再寫日誌」 | 會話會被中斷。日誌就會被跳過。在推送之前就寫，不要等到「再做一件小事」之後。 |
| 「這個任務快完成了 — 我跳過階段 5 直接提交」 | 學習只有在持久化後才能累積。那個「幾乎」閉環的會話，其洞察力在下一次運行時就會消失。 |
| 「我的選擇很明顯 — 不需要逐層進行」 | 跳過層級的選擇是產生冗餘工作和重複 PR 的主要原因。層級存在的理由是「明顯的」往往不是真正需要做的事情。 |
| 「這個教訓太具體，無法重複使用」 | 具體的教訓（確切的錯誤訊息、確切的命令、確切的失敗模式）最有價值 — 它們能在最需要的時候精確觸發。 |
| 「合理的無操作 (NOOP) 感覺像失敗」 | 它不是。為了逃避 NOOP 標籤而提交無意義的修改，會消耗配額、助長收斂混亂，並隱藏真正的瓶頸。克制日誌本身就是交付物。 |
危險信號
- 在聲明之前就開始執行（收斂風險）
- 會話結束時沒有日誌，也沒有更新任務狀態
- 「稍等一下」就提交 — 如果在結束前沒有推送，就等於沒有交付
- 連續三次會話屬於同一類別，且沒有強制多樣性中斷
- 「我會記住這個」 — 你不會的；現在就寫下教訓
驗證
一個良好的會話在關閉前應滿足所有這些條件：
- 在行動前已聲明（或證明為何不需要聲明）
- 有意義的工作已提交並推送
- 測試已通過（或記錄了已知失敗及其原因）
- 已撰寫日誌條目，且「持久化的學習」部分已填寫
- 任務狀態已更新（
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（本目錄中）— 在開始工作前的範圍定義