Autonomous Delivery Loop — 讓 Agent 自主跑完整個交付循環

你叫 agent 做一件事，它做完說「完成了」。你打開來一看——後端跑了，前端看不到。API 連通了，但使用者完全感受不到有什麼改變。系統狀態 exit code 0，但你問一句「我得到什麼？」，沉默。

這不是 agent 能力不足的問題。這是「交付的定義」缺失的問題。

問題：Agent 通常只做到後端

我們在 SuperPortia 建了 5 個 n8n workflow，JSON 結構正確、API endpoint 通了、Codex 審過了、unit test 跑過了。從工程角度，這批工作算完成。然後 Captain 問了一句讓整個流程重新設計的問題：

「我怎麼知道它在跑？它解決了我什麼問題？」

這個問題問到了核心。Agent 完成的是技術任務——程式能跑、測試通過——但沒有完成使用者任務：讓 Captain 感受到自己手上有什麼新能力、少做了哪些事、在哪裡能看到結果。

技術交付和使用者交付之間，有一段 agent 普遍忽略的距離。

三大方法論的交匯點

這個問題不是 SuperPortia 獨有的。研究社群裡有三個彼此獨立、但不謀而合的答案。

Thariq 的 Product Verification：做完自己驗證，不等人測。Thariq 在設計 agent skills 時強調「每個 skill 完成後，agent 必須自行驗證 artifact 存在、內容合理、可被使用者看到」。這把驗證從 review cycle 拉進了 task cycle 本身。

“An agent that can’t verify its own output is a liability, not an asset. The cost of asking a human to validate every artifact is higher than the cost of teaching the agent to validate itself.”
— Thariq Halabi，Agent Skills Manifesto

Beast Mode 的 Never Yield：壞了自己修，不問人類。Beast Mode 核心哲學是 agent 在整個任務週期裡保持自主——遇到問題先自己解決，最多嘗試三次，不到山窮水盡不打斷使用者。這把修復責任從人類還給了 agent。

“Never yield. Never ask for help until you’ve exhausted every option. The user hired you to solve problems, not to hand problems back.”
— Burke Holland，Beast Mode v3.1

Karpathy 的 autoresearch：閉環迭代，做完自動再跑到好。Karpathy 的 autoresearch 架構把 research loop 設計成自驅動的——找到資料 → 分析 → 發現缺口 → 再找 → 直到 research question 被充分回答才停。這是迭代收斂的思路。

三個方法論都在回答「怎麼讓 agent 做好」，但都還有一個共同的缺口：交付給使用者什麼價值。它們都在 task 的 closure 裡停了，而不是在 user experience 的 closure 裡停。

這個缺口就是 Autonomous Delivery Loop 想填補的。

Autonomous Delivery Loop 框架

參考 orchestrator-discipline-method 裡的分派紀律設計，我們在 SuperPortia 把三大方法論的優點合在一起，加上使用者交付層，形成一個完整的 8 步 Loop。

Iron Rule：使用者感受到價值才算交付。

flowchart TD
    A["夏哥: 搞定 X"] --> B["Step 0: 治理前置\n有 WO？UB 先例？HITL？"]
    B --> C["Step 1: PK 判斷\n需要驗證？派 Gemini"]
    C --> D["Step 2: 審查\nCodex 二輪審查"]
    D --> E["Step 3: 統合\n整合研究結果"]
    E --> F["Step 4: 實作\n派 Sonnet 執行"]
    F --> G["Step 5: 驗證\nThariq Product Verification"]
    G --> H{"驗證通過?"}
    H -- "否（max 3 retries）" --> F
    H -- "是" --> I["Step 6: Delivery Card\n以使用者價值開頭"]
    I --> J["Step 7: 自修待機\n監聽後續問題"]
    J --> K["HITL boundary → 叫夏哥"]

    style A fill:#d97757,color:#fff
    style K fill:#d97757,color:#fff
    style H fill:#f5e6e0

每一步在做什麼

Step 0 — 治理前置檢查：有 Work Order 嗎？需要建嗎？搜尋 UB 有沒有類似任務的先例？這個範圍有沒有觸碰 HITL boundary？這一步防止 agent 在沒有授權的情況下做了不該做的事。

Step 1 — PK 判斷與派遣：需要 Perishable Knowledge 驗證嗎？框架版本、API 格式、最新最佳實踐——這些訓練資料很快就過期的知識，自動派 Gemini CLI（免費，每天 1000 次）去查，不要用記憶裡的版本。

Step 2 — Codex 審查：研究結果回來後，不直接用，先送 Codex 做二輪審查。給足背景（任務目標、現有架構、已知限制），讓 Codex 當第二雙眼睛。Codex 不是障礙，是品質閘門。

Step 3 — 統合：orchestrator 自己來。不等指令，把 Gemini research 和 Codex review 統合成一個清晰的實作方向，決策理由記錄下來。

Step 4 — 實作：派 Sonnet subagent 執行。明確說清楚：做什麼、輸入是什麼、產出在哪、怎麼判斷完成。不模糊，不讓 Sonnet 自行解讀。

Step 5 — 驗證（Thariq Product Verification）：實作完不等於完成。Artifact 存在嗎？路徑正確嗎？使用者打開看得到嗎？Build 有沒有 error？這些由 orchestrator 自己查，不等 Captain 發現問題。

Step 6 — Delivery Card：驗證過了才交付，而且交付的是使用者語言，不是工程師語言。

Step 7 — 自修待機：交付後 agent 進入監聽模式——如果 Captain 問了問題或發現問題，自己先處理，處理不了才報告。

HITL boundary：什麼時候才叫人類

Loop 的設計原則是「能自己解決就自己解決」，但有明確的邊界：

Delivery Card：不是 changelog，是使用者價值卡

這是 Loop 裡最容易被忽略、但對 Captain 體驗影響最大的一步。

Delivery Card 不是技術報告。以下是典型的錯誤範例：

❌ 工程師語言（沒人想看）:
- 改了 worker.js 第 247 行
- 新增 batch_runner.py，678 tokens processed
- exit code 0, 3 files committed

Delivery Card 應該這樣寫：

✅ Delivery Card — text_batch_runner

你現在可以: 不用每次手動跑分類，鍋爺每 5 分鐘自動清 Dock pending

在哪裡看: Cloud UB Dashboard → 分類頁 / 或等 5 分鐘後 search_brain 就能找到新分類的內容

為什麼重要: 積壓的 102 筆 pending 會在今天清完，之後不用再擔心 Dock 塞車

落地分層:
- 使用者端: search_brain 搜尋結果會更完整
- 本地固化: text_batch_runner.py 每 5 分鐘 cron 執行
- 全域同步: UB 分類結果同步到 classified_entries
- 對外分享: 這篇文章（如適用）

Delivery Card 的開頭永遠是「你現在可以…」，站在使用者視角說。

交付的六個層次

這是我們在 SuperPortia 踩過坑後整理出來的。大多數 agent 只做到第一層就宣稱完成。

Layer 1: 後端 ← 大多數 agent 在這裡停下來
  ↓「邏輯跑得了」
Layer 2: 前端 ← 使用者看得到
  ↓「打開來有東西」
Layer 3: 使用者體驗 ← 使用者看得懂、用得到
  ↓「有說清楚帶來什麼改變」
Layer 4: 系統維護 ← 不需要 Captain 每次手動觸發
  ↓「自動跑、自動恢復」
Layer 5: 效能數字 ← 有量化指標
  ↓「有 metrics 可以看」
Layer 6: 帳單風險 ← 成本在控制範圍內
  ↓「不會有 API 超額的驚喜」

使用者感受到的價值 = 至少做到 Layer 3。

Layer 1-2 只是「能跑」，不是交付。這兩層是工程前提，不是使用者價值。我們在設計 MTAAA 分類系統時，第一版只驗證到 Layer 2（頁面顯示了），後來才發現 Layer 3 完全沒做——分類結果顯示出來，但沒有跟任何工作流串接，Captain 的日常工作沒有任何改變。

SuperPortia 實戰：我們怎麼落地的

這套框架最初是一堆沒有名字的習慣，在每次踩坑後慢慢累積。然後我們做了一件很重要的事：把它固化成 Rule，不是 Skill。

這個區別很關鍵。

在 SuperPortia 的 Progressive Disclosure 架構裡：

• Rule（L2）：每個 session 都載入，agent 永遠遵守
• Skill（L3）：按需載入，不主動觸發就不存在

如果把 Delivery Loop 寫成 Skill，每個 session 的 orchestrator 都要記得去載入它。LLM 每個 session 是全新的，它不記得上個 session 有這個習慣。如果不強制載入，這個框架就只在你記得提醒的時候有效——那等於沒有。

所以我們把它寫進 orchestrator-baseline.md，這份文件是 L2 Rule，每個 session 必定載入。現在不管哪個 agent 接手，Delivery Loop 都是預設行為，不需要有人每次提醒「你要做 Delivery Card 喔」。

結果：
- 之前：Captain 每天說幾十次「派 Gemini」「送 Codex 審」「你統合」
- 之後：orchestrator 自動跑完整個 loop，Captain 只在 HITL boundary 被叫到

關於 Codex 審查的設計，我們參考了 beast-mode-deep-dive 裡 Beast Mode 的 Never Yield 哲學——agent 在有能力自我驗證的範圍內，不應該把責任推回給使用者。Codex 的角色不是讓 orchestrator 偷懶，而是在 orchestrator 的判斷之外加一層交叉驗證。

這個決策在我們上線第一個月就被證明是對的。有三次 Sonnet 生成的 workflow 有邏輯上的微妙問題，Codex 抓到了，orchestrator 重派 Sonnet 修改，Captain 完全不知道有問題——也不需要知道。

結語

我們做了很長一段時間的「能跑的東西」。然後有一天 Captain 問了那句話——「它解決了我什麼問題？」——我們才意識到：Agent 的價值不是「它能做什麼」，是「使用者感受到什麼」。

技術是手段，體驗是目的。能跑只是開始，有感受才是結束。

Autonomous Delivery Loop 不是什麼高深的框架，它就是把「做到使用者有感受」這件事，拆成 agent 可以自動執行的步驟，然後固化成系統約束，讓它在每個 session 都發生，不依賴任何人的記憶或提醒。

如果你也在建多 agent 系統，或者你的 agent 也有「說完成但 Captain 感受不到」的問題——從 Iron Rule 開始：交付的標準不是「系統能跑」，是「使用者感受到價值」。其他一切都從這裡出發。