Agent 能力越完整，越容易把工作流一路接到底：

改 Code
→ 跑 Test
→ Deploy
→ Smoke

工具都接好之後，技術上完全做得到。

問題也從這裡開始。

會做，和這次被允許做，是兩件事。

Capability 描述 Agent 能做到什麼；Authority 描述這個任務允許它做到哪裡。

Day 1、Day 2 已經提過這個差別。到了這一篇，問題不再只是提醒 Agent「不要亂做」，而是：怎麼讓一條真的會自行執行的 workflow，在正確的位置停下來。

一條真的會自己往前走的 Workflow

這個系列已經有每日自動寫稿流程。

Workflow 會自動判斷下一個 Day、建立 GitHub Issue，再把工作指派給 Copilot cloud agent。Agent 收到工作後，會讀 Repository 規則、建立分支、完成文章並開 PR。

如果只看 capability，流程可以很自然地繼續：

Draft
→ PR
→ Merge
→ Publish

但這個 Repo 的 contract 沒有授權後兩步。

目前規則明確要求：

• article automation 只走 PR；
• 不直接把文章推進 main；
• 不啟用 auto-merge；
• 不允許 Agent 自己 merge PR；
• 沒有另外授權時，不產圖、不發布圖片。

Workflow 本身也沒有 merge step，而且內建 GITHUB_TOKEN 的權限是：

permissions:
  contents: read
  issues: write
  pull-requests: read

這條 workflow 也不是只靠一組 credential。

建立 Issue 使用內建 token；把 Issue 指派給 Copilot cloud agent，則走另一個專用 credential。缺少 assignment credential 時，workflow 直接 fail closed，不會假裝完成，也不會改走其他路徑。

建立工作單
→ 允許

指派 Agent
→ 需要另一條授權路徑

直接寫 main
→ 這條 workflow 沒有取得這個 Authority

這個差異把 Authority 從「Agent 有沒有權限」拆成更精確的問題：

這個 action，在這次 task、這條 execution path 上，有沒有取得 Authority？

同一個 Agent 可以具備更大的工具能力，但不同 action 不會因此共享一個「全開」的 Authority。能被執行環境直接限制的部分，也不必只靠 Agent 記得。

Tool Access 不是 Permission

只要 Agent 可以呼叫某個 command，就代表它具備 capability。

例如真實開發流程裡，Codex 可能碰到：

wrangler d1 execute
wrangler deploy

但 command 存在，不代表每個 task 都自動取得執行它的 authority。

同樣一組工具，在不同任務裡可以有不同邊界：

Task A
允許 code + tests
不允許 deploy

Task B
允許 bounded backend deploy
完成後驗證 remote behavior

如果只看 Tool availability，兩個任務幾乎沒有差別；真正區分它們的是 task contract。

最容易越界的動作，通常看起來很合理

Agent 不需要有「越權」意圖，也可能跨過 boundary。

最典型的推進是：

Tests 都過了，只剩 deploy；那就順便把整個任務完成。

問題是，「完成」不只是技術狀態。

在文章 automation 裡：

完成 Draft
→ 開 PR

已經符合這次 work order。

它不需要自行補上：

→ Merge
→ Publish

那兩步屬於另一層 authority。

這修正了我原本一個很直覺的想法：

Agent 越 autonomous，就越應該把整條流程一次做到底。

實際上，更可靠的 autonomy 需要知道 stop boundary。

Authority 要落在三個不同位置

以這個 Repo 為例，Authority 至少出現在三層：

三層不能完全互相取代。

只有文字規則，Agent 仍可能誤解或把「完成任務」理解得太寬。

只有工具權限，也只能告訴它「做不到」，卻不一定能說明：

為什麼這次應該停在 PR？

所以 Capability ≠ Authority 不是把工具全部拔掉。

比較接近：

能力可以保留，但每一次 execution 只拿完成這個 task 所需的 authority。

Capability Matrix 只能當檢查表

我會先用一張很簡單的表，把兩個問題分開：

這張表不是 access control system。

它只是要求每個 action 都回答兩次：

Can it?
≠
May it, in this task?

如果 workflow 只回答第一題，Agent 的能力邊界還沒有變成可操作的授權邊界。

Autonomy 不是一個總開關

「要不要讓 Agent 自動部署？」這個問題本身太大。

Day 19 先只留下幾個更小的問題：

這次允許哪一類 action？
Authority 從哪裡來？
只適用哪個 task？
哪些 action 明確被排除？
Stop boundary 在哪裡？

至於不同 Production action 到底哪些可以自動前進、哪些值得停下來讓人判斷，留到後面的 Deploy Gate 再處理。

這一篇只建立基線：

Capability 可以很大；Authority 必須 bounded，而且要能從 task、repo 與 execution path 看得出來。

以前驗收 Agent，比較容易只看：

它能不能完成？
Tests 有沒有過？

現在我會再補一題：

它為什麼有權做到這一步？

如果答案只是：

因為工具可以。

那還不夠。

下一篇會把這個問題帶到 Migration：當 action 會直接改變 schema 或資料時，除了「有沒有 authority」，還必須先證明 Agent 面前的是正確的 Artifact、Environment 與 Target。