loop-engineering

Loop Engineering 不只是概念 — 我做了一個跨 Session 的狀態交棒系統

Loop Engineering 不只是概念。我做了一個跨 session 的狀態交棒系統 — Session Baton。三層交棒（影響/決策/經驗）+ Anti-Ouroboros gate + PyPI 一行安裝。

江中喬

17 6月 2026 • 5 min read

Boris Cherny（Claude Code lead）說：「我不再 prompt Claude。我讓 loop 去 prompt Claude。我的工作是寫 loop。」

這句話在 AI coding 圈炸開。Addy Osmani 把它系統化成五大 building block。每個人都在談 Loop Engineering。

但大部分討論停在概念層。我花了一週把它做出來。

問題：你的 AI session 是平的

大部分人用 AI coding agent 的模式是這樣的：

Session 1: 打 prompt → 做事 → 結束
Session 2: 打 prompt → 做事 → 結束（不記得 Session 1）
Session 3: 打 prompt → 做事 → 結束（不記得 Session 1 和 2）

每次都從零開始。你手動補 context。Agent 忘了上次犯什麼錯、做了什麼決策、有什麼待辦。

有人會說：「那不是有 CLAUDE.md 和 session memory 嗎？」

有。但那些是模糊搜尋的知識（warm tier）。你搜「上次部署」，它可能回你三個月前的部署紀錄。你真正需要的是：「我上次部署了 X，它現在還活著嗎？」

不是 cron job，是 loop

加個 timer 讓 AI 定時跑，那叫 cron job。Loop 的差別在於：

	Cron Job	Loop
State	無記憶	知道上次做了什麼
Decision	每次做一樣的事	根據上次結果決定這次做什麼
Verification	無	追蹤上次行動的效果
Escalation	無	處理不了才叫人

Loop 的產出會變成下一輪的輸入。 它是螺旋上升的，不是平行重複的。

三層交棒：經驗、決策、影響

設計系統時我發現，跨 session 要交棒的東西有三種完全不同的生命週期：

影響 — 短壽命
「我部署了 X，expected outcome 是 health 回 200。」
下一個 session 自動驗證。通過就關掉，沒通過就升級。

決策 — 中壽命
「改用 --update-env-vars，因為 --set-env-vars 會清掉既有變數（上週 production 事故的 root cause）。」
帶 rationale + evidence。活到被推翻為止。

經驗 — 長壽命
「第三次在沒有讀 docker-compose.yml 的情況下假設架構了。」
單次沒價值。重複出現才有價值。累積到閾值 → 提議升級為 enforced rule。

Anti-Ouroboros：LLM 不能自己升級自己的規則

這裡有一個關鍵的治理問題：pattern-to-rule graduation 意味著 LLM 的產出會影響未來 LLM 的行為。

如果不加閘門，這就是自我強化的迴圈 — LLM 觀察到「我常犯這個錯」→ 自動寫成 rule → rule 改變所有未來行為。聽起來很高效，但也可能把錯誤的觀察永久化。

所以我加了 Anti-Ouroboros Gate：

每個 baton item 都帶 source_tier：llm_derived 或 human_confirmed
llm_derived 的 pattern 不能自動升級為 rule
必須人類確認後改為 human_confirmed，才能寫進 rules/
這是 ACA (Agent Civilization Architecture) 協定的一部分

最被忽略的 Loop：你的日常對話

大多數人聽到 Loop Engineering，第一反應是去想「我哪個 cron job 可以升級」。

但最強大的 loop 不是自動化腳本 — 是你每天跟 AI 的工作對話本身。

想想看：

Session 開場：載入上次的決策和進度
工作中：寫 code、解問題、踩坑
收工前：把教訓沉澱成 rule
下一個 session：受到上一輪 rule 的約束

這是 meta-loop — 一個會改寫自己規則的 loop。

Addy Osmani 講的 loop 改的是 code。Meta-loop 改的是改 code 的規則本身。前者是效率，後者是能力的複利。

Session Baton：開源實作

我把這個系統開源了：github.com/MakiDevelop/session-baton

已發佈到 PyPI，一行安裝：

pip install session-baton
python -m session_baton
# Server 跑在 http://127.0.0.1:9101

106 行 Python。FastAPI + SQLite。可以獨立跑，也可以加進任何現有的記憶系統（memhall、mem0、Letta 都相容）。

在你的 AI coding agent 的 session start 時讀 baton、session end 時寫 baton。完整 schema、skill templates、規格書都在 repo 裡。

業界現況

偵察了 X/Twitter、GitHub、HN、Reddit、arXiv 之後，結論是：

Compounding Knowledge Loop（MindStudio）：session 結束 dump 摘要。沒有 action-outcome 驗證。
bmo（ngrok）：跨 session telemetry。追蹤工具成功率，不追蹤 expected outcome。
Stability Tier（arXiv）：三層記憶架構。學術論文，無工程實作。
Meta HyperAgents：failure → rule proposal 的 pipeline。需 human review，沒有自動閾值。

跨 session 的閉環驗證 + pattern-to-rule 自動升級 + 三層結構化交棒 — 目前沒有公開的 end-to-end 實作。

Session Baton 是第一個。

下一步

Session Baton 剛開始 dogfooding。接下來幾週會觀察：

Baton 真的會螺旋上升嗎？還是只是另一個寫了不看的 log？
Pattern-to-rule graduation 在實務中好用嗎？
Action-outcome verification 能抓到多少「上次改壞了但沒注意到」的情況？

有發現會再分享。

Session Baton: chiba.tw/baton
PyPI: pypi.org/project/session-baton
ACA Protocol: chiba.tw/acap
Loop Engineering 知識頁: chiba.tw/loop-engineering/

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。