Day 30｜三十天後，這位新同事能幫我做多少事？
前言
到 Day 29 為止，探索、判定、開單、修復、測試、CI、分流、flaky 各自都跑得動了，但每一段還是你在按下開始。今天把它們串成一條線交出去：哪些動作它自己做、哪些要先問你、什麼情況必須停手，全寫進授權分級。
開始之前
前面二十九天累積了一整套能力。但只要每一段都要你發動，這位同事就還是一個很好用的工具，不是一位同事。
這一步要交出去的是流程的發起與接續：先由人安排排程或啟動一輪，代理人再依授權把各站接著跑完，不必每一步都由你下指令。本篇的實驗是手動啟動，沒有示範代理人自己設定排程。
但能接著跑，不代表什麼都能做。合併 PR、重置共享環境、清空共享資料庫，會影響別人正在使用的程式或資料，所以本流程不把這些動作交給代理人。
今天把授權分成三層：可自行執行、需要授權，以及本流程禁止執行。設定檔告訴代理人每個動作屬於哪一層，執行前必須檢查；工具端有沒有真的限制住，則是另一件要確認的事。
還有一件容易被忽略的事：值班要留下可稽核的紀錄。 一輪跑完，你要能在五分鐘內看完它做了什麼、開了什麼、擋下什麼、花了多少，而不是重跑一遍才知道。
動手試試
這次沿用 charters/toolshop-login-cart.yaml，交給值班代理人跑一輪。開跑前先講清楚受測範圍、預算，以及這輪授權它做到哪裡。
在已授權的範圍內，它可以接著探索、整理證據、安排盲驗和檢查閘門。遇到開單、改碼、開 PR 這些動作，就再對照授權：已有涵蓋目標與範圍的授權可以沿用，沒有就先交草稿等人確認。禁止的動作則停下來，不會因為「正在值班」就多拿到權限。
跑完之後
這輪跑了 30 分鐘，整輪紀錄寫在 output/runs/2026-07-30.yaml：
date: 2026-07-30
charter: charters/toolshop-login-cart.yaml
tokens:
subagent_total: 103665 # 盲驗 subagent（含補證那次）＝實測值
main_loop: not-instrumented # 主迴圈沒有 per-turn token 計數，無法如實填；不編造
duration_min: 30
findings: 8 # 候選 6（high）＋ 2 筆未達門檻留人判
gate_passed: 6
issues_opened: 6 # 當班先寫成本地問題單；收班後另依使用者要求開到 GitHub
prs_opened: 0
held_for_human: 2
forbidden_attempts: 0
confirmed_by_human: null # 待回填main_loop: not-instrumented 這一格值得看。沒有量到就寫沒有量到，不編一個數字填進去。旁邊的 note 直接寫「本輪很可能已接近或超過預算上限，但無法精確斷言」，並且指出下一輪要嘛壓低讀取量、要嘛調高預算，別再靠估。
forbidden_attempts: 0 是另一個要每輪看的數字。它不為 0 就是事故，要報。
issues_opened: 6 也要看清楚範圍：當班先產出六份本地問題單，收班後才依使用者要求，將同一批內容開成 GitHub Issues。這不是半夜無人確認就自動對外開了六張單。
同一份 log 還有一段 deviations，如實記下這輪跟規格的差距：
- item: "bug-fixer 未執行"
why: "受測對象是外部託管的 demo build，本機沒有它的產品碼 repo……prs_opened 記 0。"
- item: "6 個候選共用 1 個盲驗 subagent，而非一候選一個"
why: "所有 subagent 共用同一個瀏覽器，平行盲驗會互搶分頁與 sessionStorage……這是本輪的已知折衷。"
- item: "C-05 的 verdict 一開始沒附自己這輪的證據"
why: "違反鐵則，已退回該 subagent 重跑並補證，重驗後仍為 confirmed 才採計。"
- item: "C-07 / C-08 未送盲驗"
why: "當時為省預算，將低於信心門檻的兩筆直接記成 hold；verifier_verdict 記 not-sent。"四條都是「沒有照理想跑」。最後一條就是 Day 24 檢討過的地方：沒送盲驗的候選，依現在的規則應先 block，不能只算成分數不足。這些差距留在 log 裡，才知道下一輪要補哪裡。
背後怎麼做
六個步驟：編排，但不越權
| # | 步驟 | 交給誰 |
|---|---|---|
| 1 | 獵 | Day 22 的 Hunter，四道關卡在它體內 |
| 2 | 驗 | Day 23 的盲驗，每個候選一份 verdict |
| 3 | 把關 | Day 24 的六條閘門 |
| 4 | 分派 | pass 的交開單流程；範圍清楚可修的再交 Day 25，兩者都要另查授權 |
| 5 | 記帳 | 每個階段當下記錄用量與結果，收班時彙整 |
| 6 | 留摘要 | 一份五分鐘能複核完的值班摘要 |
站與站之間交的是檔案，不是對話記憶。這是整條線能被稽核的前提：每一站的輸入輸出都落在磁碟上，任何一站你都可以單獨拉出來重看。
記帳雖然列在第 5 步，資料要從開班就開始收。每個階段的用量、通過幾筆、留下什麼檔案，都當下記錄；收班只是彙整。否則最後問它花了多少，它也只能猜。
還有一條編排紀律：編排不越權。 各站自己的鐵則與確認規則原封生效，值班不代跳任何一道門、不代任何人確認。任何一站失敗就記進 log、往下能走多遠走多遠，不得無聲吞掉。
授權分級：能做、要問、永遠不准
tiers:
autonomous: [] # 未預先授予此分級表管理的副作用動作
needs_review:
- file_local_report # 寫成本地問題單前，須有涵蓋本次內容的授權
- open_pr # 開 PR 前，須有涵蓋目標與範圍的授權
- override_gate # 硬推放行要留痕
forbidden:
- merge_pr
- reset_shared_env
- truncate_shared_db
override:
require_reason: true # 硬推閘門必須留痕（誰、何時、理由）autonomous 是空的，表示這份表沒有預先授予任何副作用動作的自主權，不是連讀檔、分析和準備草稿都要逐次問。file_local_report 指的是把內容正式寫成本地問題單，也不是所有執行紀錄的統稱。
needs_review 或表上沒列的動作，要看這次使用者給的授權是否已經涵蓋。已有授權就沿用，沒有才提出具體內容請人確認。這一輪能自行接著跑到哪裡，取決於這個範圍，不能把「開始輪值」理解成所有事情都自動放行。
圖中的授權清單管理的是上述副作用動作。那一輪的 forbidden_attempts 是 0，底下四條折衷也要一起看。
forbidden 三項是本流程明確禁止代理人執行的動作，不能用一般確認當成解除禁止，也不能為了跑完就自行改設定。這份 YAML 本身不會撤掉工具權限；本次紀錄只能說沒有發生禁止動作，不能據此宣稱工具已經把它們完全封鎖。
要求例外處理也要留紀錄，require_reason: true 要求記下誰、何時、為什麼。至於缺盲驗、缺證據或重複問題，仍照 Day 24 的規則處理，不能用例外要求把條件當成已經滿足。
預算也是開班前要說好的限制。達到上限就停下來，記錄做到哪裡；但今天這輪連主迴圈用量都沒量到，只能承認沒有足夠資料判斷是否超支，不能順便宣稱預算限制已經驗證有效。
今天學到什麼
今天把找問題、獨立驗證、開單前檢查與後續分派，串成一輪值班。代理人可以在已授權的範圍內接著做，遇到超出範圍的動作，就留下具體內容等人確認。
這輪交回六份本地問題單，收班後才依使用者要求開到 GitHub；修復流程當時沒跑，兩筆低分候選也沒有送盲驗。主迴圈的 token 用量漏了，所以連有沒有守住預算都還說不準。Day 25 後來補跑成功，只代表修復那一站跑通了，不能算成這輪已經自動做完。
三十天到這裡，這位新同事已經能接下不少工作，但還需要有人看結果、補判斷。接下來先把校準表的人工確認補齊，累積幾輪紀錄，再決定哪些動作可以多放手一點。你要判斷的是它實際交回了什麼，不能只看它說自己會做什麼。
參考資料
- Lisanne Bainbridge（1983）《Ironies of Automation》，Automatica 19(6) - 自動化把例行的部分接走，留給人的反而是最難的判斷，這篇是所有「人機分工」設計的起點
- David D. Woods、Erik Hollnagel（2005）《Joint Cognitive Systems: Foundations of Cognitive Systems Engineering》 - 人與自動化是一個共同體，設計要問的是「誰在什麼情況下負責什麼」，不是「自動化程度多高」
- Betsy Beyer et al. 編（2016）《Site Reliability Engineering》 - on-call 的紀律：可稽核的紀錄、事後檢討、以及為什麼要量測而不是憑感覺
- SAE International（2021）《J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems》 - 把自主性拆成分級而不是開關，並且明訂每一級由誰負責，是授權分級最成熟的類比
- 本專案
config/governance.yaml- 三層授權與留痕規則 - 本專案
skills/agents/duty-oncall/SKILL.md- 六步編排與鐵則 - 本專案
output/runs/2026-07-30.yaml- 實跑的值班紀錄，含三條 deviations