GitHub Agentic Workflows 不用 PAT 後：權限、費用與寫入邊界怎麼設

先拆成三種權限，而不是只看一個 token#

GitHub Agentic Workflows 的 frontmatter 同時會影響讀取、模型呼叫與寫入；把它們視為同一種「權限」很容易設過頭。

GitHub 的 Agentic Workflows 預設採唯讀；寫入由另一個受控 job 處理。也就是說，copilot-requests: write 的 write 是用來允許 inference，不是允許提交程式碼。這個命名很容易讓人誤加 contents: write，但兩者用途不同。

一個從唯讀開始的最小設定#

以下範例只讓 agent 查看 repository 與 PR，並可建立一張整理結果的 Issue。先把可做的事情縮到這裡，比一次開放建立 PR 更容易驗證。

1
---
2
on:
3
  schedule: weekly
4
permissions:
5
  contents: read
6
  issues: read
7
  pull-requests: read
8
  copilot-requests: write
9
safe-outputs:
10
  create-issue:
11
    title-prefix: '[repo-review] '
12
    labels: [maintenance]
13
---
14

15
## Repository review
16

17
整理最近一週的失敗 CI、尚未回應的 bug 與依賴更新。
18
不要修改檔案；每個建議都要附上對應的 Issue、PR 或 workflow run 連結。

safe-outputs 不是裝飾性的 YAML。agent 先輸出結構化結果，之後由有明確權限的 job 驗證並執行建立 Issue 的動作。官方文件也說明這個分離會帶來審計軌跡、較小的影響範圍，以及對 prompt injection 的一層防線。

不再用 PAT，不等於不用管費用#

當組織已啟用對應 Copilot policy，copilot-requests: write 會使用 Actions token 進行 inference，且費用會計入組織的 Copilot 方案。它省掉的是長期 secret 管理，不是自動幫你限制每次排程要跑多久、要讀多少內容。

我會先加三個限制：

1. 只排程低頻、範圍固定的工作：例如每週整理失敗 CI，而不是每次 push 都做全 repository 分析。
2. 把任務輸入寫成可驗證條件：限定時間範圍、資料來源與輸出格式，避免 agent 把模糊目標擴成大量搜尋。
3. 看每次 run 的 token 與輸出：GitHub 也提供成本管理與每 run 的用量資料；先累積幾週基準，再決定是否提高頻率或擴大範圍。

不要把使用者層級的 Copilot 預算拿來推估這種 workflow。官方公告明確指出，組織計費的 agentic workflow 不會計入使用者個人的 inference budget。

要開寫入時，先讓「可寫什麼」變得具體#

若下一步想讓 agent 開 PR，先不要直接給 repository 寫入權限。Safe Outputs 的 pull request 設定可以限制可修改檔案；而 gh aw 對 package manifest、CI 設定與 AGENTS.md 等敏感檔案也有額外保護。

一個比較穩健的演進順序是：

1
唯讀報告
2
  -> 建立 Issue（safe output）
3
  -> 僅修改 docs/** 的 PR
4
  -> 指定測試與來源檔案的 PR
5
  -> 仍由人審查與合併

每升一級都要重新問：這個 workflow 的輸入是否可能含有不可信內容？它能碰到哪些檔案？失敗時會留下什麼紀錄？如果答案仍是「讓 agent 自己決定」，那還不適合開寫入。

這次設定的重點#

GitHub Agentic Workflows 改用 GITHUB_TOKEN 是降低 PAT 維運風險的機會，但安全設計仍在你的 frontmatter：讀取 scope、copilot-requests: write 與 Safe Outputs 要各自明確。先把 agent 留在可觀測的唯讀分析，讓每一個寫入都變成受限、可查、可審的後續工作。

常見問題#