Human-in-the-loop

前三篇依序談 Contract（合約）、Evidence（證據）與 Attestation（獨立確認）；本文聚焦信任鏈的最後一環：Authority（授權），以及如何依風險在 Human-in-the-loop 與 Human-on-the-loop 之間配置人的決策位置。本文可以獨立閱讀。 前言 先從一個常被混淆的問題開始：所有必要檢查都通過、審查也完成了，是不是就等於可以合併、發布或上線？ 前一篇已經把驗收和獨立確認分開。Evidence 回答「在已定義的檢查條件下，結果是否符合預期」；Attestation 則由與產出角色分離的審查者或審查機制，判斷這些證據是否足以支撐受治理需求。Authority 要回答的是另一個問題：誰有權依照什麼規則，做出合併、發布、部署或正式放行的決定？ 因此，檢查通過與審查完成，不會自動產生放行權限。若把「驗收結果」直接當成「授權結果」，責任邊界就會被綁在檢查的完備性上；而任何檢查都不可能覆蓋所有情境。 commit、push 與放行是不同的授權動作 授權分離的重點是： commit、push、merge、publish 與 deploy 是不同動作；完成前一個動作，不會自動取得下一個動作的 Authority。 在許多流程裡，這些動作可能被串成一條自動化路徑：push 之後執行 CI，CI 通過後自動 merge，再由部署流程發布。自動化本身不是問題，問題在於每一個放行動作是否都有明確的治理規則、適用範圍與授權來源。 放到 agent 的工作流程裡，可以先分清楚幾件事： agent 可以在授權範圍內建立 commit 或 push 變更，但這只代表版本被提出或送進流程，不代表需求已經被核准。 Evidence 與 Attestation 都完整，也不代表自動取得 merge、publish 或 deploy 的權限。 merge、publish 與 deploy 可以由人類明確決定，也可以由事先核准的政策自動串接；前提是每一步的放行條件與授權來源，都已經由治理規則明確定義。 每一個放行結果都應該能回到一條清楚的授權規則，而不是前一步流程的無條件延伸。 薄介面：入口不能偷偷升級授權 現代的 agent 工具通常會用不同入口操作同一套流程：命令列（CLI）、給 agent 使用的 MCP、CI 的 adapter，或其他內部服務。如果每個介面各自實作一套授權規則，規則就可能逐漸漂移：某個入口多開了一個操作，另一個入口的把關又比其他地方寬鬆。 比較實務的做法，是把這些介面維持成薄介面：負責解析輸入、基本格式驗證、authentication / scope 檢查、呼叫共用的治理邏輯，再把結果格式化輸出。真正涉及敏感操作的 authorization，仍應在共用的受治理路徑中重新確認。 多加一個介面，可以多一個入口，但不應因此多出一份 Authority。 CLI、MCP 或 CI adapter 都可以有自己的 authentication、authorization 或 scope 檢查，但不能自行擴大底層已授予的權限。能呼叫某個 tool，不等於有權執行底層的敏感動作。...