團隊協作與 CI/CD：GitHub Actions 天生一等公民

想像 GitHub Actions 是一條全自動生產線，專門處理「有人交程式碼進來 → 自動檢查 → 自動處理」這件事。前面三套終端機 agent 想加入這條生產線，都得先辦一張臨時通行證：自己裝、自己認證、自己想辦法把 API key 藏好，一切從零開始。GitHub Copilot CLI 不一樣——它是 GitHub 自己家的員工，一走進去就自帶識別證，連內建的 GitHub 專屬工具都已經幫你掛在腰帶上，不用臨時申請。

但「自帶識別證」這件事有好有壞。好處是省事；壞處是如果你沒把識別證的權限範圍收好，這位員工可能不小心就被外面混進來的人借去做壞事——這正是本章除了教你怎麼接上之外，一定要花篇幅講清楚安全風險的原因。這一章你會學到：

• 官方逐字給範例的兩條路徑，把 Copilot CLI 接進 GitHub Actions：一條用個人存取權杖（PAT）、一條直接用 Actions 內建的權杖，怎麼選；
• 為什麼「直接在 workflow step 裡跑 copilot」有風險，尤其是外部人開的 Pull Request 觸發時風險最高；
• 官方力推的更安全做法——GitHub Agentic Workflows：一個用 Markdown 寫 CI 流程、引擎不綁 Copilot（claude／codex／gemini 都能選）的新框架，目前仍在 Technical Preview；
• 收尾看清楚 Copilot CLI 在 GitHub 生態系裡「開箱即用」的天然優勢，跟 Codex CLI／Claude Code 得自己另外接 GitHub MCP 的差別在哪。

11.1 兩條官方路徑，把 Copilot CLI 接進 GitHub Actions

官方文件針對「在 GitHub Actions 裡跑 Copilot CLI」給了兩條各自完整、各自有逐字範例的路徑。兩條路徑做的事情類似（在 workflow step 裡執行 copilot 指令），差別在認證方式與要不要另外申請權杖。

路徑一：申請 PAT，帶上「Copilot Requests」這個新 scope

第一條路徑，是自己去申請一把個人存取權杖（Personal Access Token，PAT），存成 repo 的 secret，再透過環境變數注入。

官方完整 workflow 範例（逐字節錄）：

name: Daily summary
on:
  workflow_dispatch:
  schedule:
    - cron: '30 17 * * *'
permissions:
  contents: read
jobs:
  daily-summary:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 0
      - name: Set up Node.js environment
        uses: actions/setup-node@v4
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: Run Copilot CLI
        env:
          COPILOT_GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        run: |
          copilot -p "Review the git log for this repository and write a bullet point summary..." --allow-tool='shell(git:*)' --allow-tool=write --no-ask-user
          cat summary.md >> "$GITHUB_STEP_SUMMARY"

(料源：official，Automate Copilot CLI with GitHub Actions，逐字節錄)

拆開看重點只有三個：

1. 先裝、再跑：跟你自己電腦上裝的是同一招——npm install -g @github/copilot，runner（GitHub 幫你跑流程的那台臨時機器）上現裝現用。
2. PAT 要帶新的「Copilot Requests」權限：這把 PAT 不是隨便一把帶 repo 權限的權杖就能用，申請時要額外勾選「Copilot Requests」這個 permission（在 github.com/settings/personal-access-tokens/new 建立），存成 repo secret，再透過 COPILOT_GITHUB_TOKEN 這個環境變數注入給 copilot 指令。
3. -p 加一串權限旗標：範例裡的 --allow-tool='shell(git:*)' --allow-tool=write --no-ask-user 是第 10 章教過的非互動權限語法，CI 場景一定要用，不然 copilot 會卡在等你核可。

路徑二：不辦 PAT，直接用 Actions 內建的 GITHUB_TOKEN

第二條路徑更省事：不用另外申請、保管 PAT，直接用 GitHub Actions 自動幫每次執行產生的內建權杖 GITHUB_TOKEN。

官方範例（逐字節錄）：

permissions:
  contents: read
  copilot-requests: write

jobs:
  copilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: Run Copilot
        run: copilot --yolo -p "Summarize the changes in this commit"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

(料源：official，Use Copilot CLI in GitHub Actions，逐字節錄)

這條路徑有兩個前提要先滿足，缺一不可：

• workflow 的 permissions 區塊要新增一個新 scope：copilot-requests: write——官方原文：「required for the workflow to make Copilot requests.」（要讓 workflow 能夠發出 Copilot 請求，這個權限是必要的。）
• 組織管理員要先開一個開關：「Allow use of Copilot CLI billed to the organization」。這是組織層級的政策設定，一般成員自己開不了，得先請管理員到組織設定裡打開。

範例裡的 copilot --yolo 是第 10 章教過的 --allow-all 別名：它能避免非互動環境卡在提示，卻也是最大授權選項，不是 CI 的唯一或日常預設。優先用任務需要的 --allow-tool／--allow-url 搭配 --deny-tool 明列範圍；只有可丟棄、隔離的 runner，且 prompt、repo 與輸入都已審查時，才考慮 --yolo。

兩條路徑怎麼選

兩條路徑的取捨，官方文件沒有直接給一句「該選哪個」的建議，但把兩頁內容放在一起看，可以整理出一個合理的判斷方向：

(料源：practice／推論——這張表是研究者基於官方兩頁內容合理整理，不是官方逐字給的選擇建議，僅供參考)

11.2 安全警語：workflow 裡直接跑 copilot，fork PR 風險最高

兩條路徑都能動之後，接下來這件事比「怎麼接上」更重要：官方明確警告，直接在 workflow step 裡跑 copilot 指令本身是有風險的。

官方原文：

「Invoking Copilot CLI directly in workflow steps gives it broad access to your workflow environment.」
（直接在 workflow step 裡呼叫 Copilot CLI，會讓它拿到你整個 workflow 執行環境的廣泛存取權。）

特別點名一個最危險的觸發情境：

「workflows triggered by pull requests from forks」
（由 fork（分支複製）出去的儲存庫發起的 Pull Request 觸發的 workflow。）

翻成白話：如果你的 CI 設定是「有人開 PR 就自動跑 Copilot CLI」，而這個 PR 是外部、不受你控制的人從自己 fork 的儲存庫發起的，等於讓一個你不認識、也審查不到底細的人，有機會透過 PR 內容（標題、內文、甚至藏在改動裡的東西）去影響一個擁有你 repo 廣泛存取權、還可能碰得到金鑰的執行環境。這不是危言聳聽的假設——這正是第 5 章、第 6 章提過的「不可信輸入」與 prompt injection（把惡意指令偽裝成普通內容混進 AI 會讀到的資料裡）在 CI 場景的具體翻版。

11.3 更安全的官方路徑：GitHub Agentic Workflows（Technical Preview）

(料源：官方文件描述詳盡，但社群討論顯示這是 Technical Preview 狀態的新功能，仍在快速迭代中，本節整體標記 experimental)

GitHub Agentic Workflows 是一個獨立於 Copilot CLI 本體的新產品/框架，核心概念是「用 Markdown 寫 CI workflow」，取代你熟悉的純 YAML 寫法。

長什麼樣子

檔案放在 .github/workflows/，副檔名是 .md（不是純 YAML），結構分成兩塊：

• YAML frontmatter（用 --- 包住的開頭區塊）：設定觸發條件 on、權限 permissions（預設 read-all，最小權限優先）、允許的寫入操作 safe-outputs、要用哪個 AI 引擎 engine。
• Markdown 本文：用自然語言寫給 AI agent 的指示，就像你平常在互動模式裡打的 prompt 一樣。

寫完 Markdown workflow 之後，要編譯成 .lock.yml——.md 來源檔跟 .lock.yml 編譯產物兩個檔案都要 commit 進 repo，實際觸發執行的是編譯後的 .lock.yml，不是那份 Markdown 原始檔。

兩條安全設計（官方逐字）

GitHub Agentic Workflows 之所以官方認為比「直接在 workflow step 裡裸跑 copilot」更安全，核心是這兩條設計：

1. 「Read-only by default (Workflows have read-only repository permissions unless you explicitly grant more)」
   （預設唯讀：除非你明確授予更多權限，否則 workflow 對 repo 只有唯讀權限。）
2. 「Safe outputs (Write operations such as creating issues, adding comments, or opening pull requests are only allowed through validated safe-outputs declared in the frontmatter)」
   （安全輸出：像是建立 issue、加留言、開 PR 這類寫入操作，只能透過 frontmatter 裡宣告過、經過驗證的 safe-outputs 進行。）

翻成白話：跟 11.1 那兩條路徑「你自己手動把 permissions 收緊」不同，Agentic Workflows 是框架本身就把「預設唯讀」跟「寫入操作要先申報」這兩件事內建成規則，就算你什麼都沒特別設定，也不會一不小心就給了 AI 過大的寫入權限。

怎麼快速建一份

官方提供一個 GitHub CLI extension，可以用 add-wizard 指令，指定 OWNER/REPO/WORKFLOW-NAME 格式從範例庫產生 workflow，並自動開一個 PR 把 .md 與 .lock.yml 兩個檔案一起加進 .github/workflows/——不用你從零手刻 frontmatter 格式。

11.4 收尾：Copilot CLI 在 GitHub 生態系裡的天然優勢

講完怎麼接、怎麼避開風險，最後回到本章開頭的主題：為什麼這是 Copilot CLI 相對其他三套 CLI 最明顯的主場優勢章節。

內建 GitHub MCP server，免設定即可用

官方原文：

「The GitHub MCP server is built into Copilot CLI and is already available without any additional configuration.」
（GitHub MCP server 內建在 Copilot CLI 裡，不需要任何額外設定就能用。）

而且預設「All read-only tools are available by default」——所有唯讀工具預設就開著，寫入類工具（例如建立 issue、開 PR）才需要另外允許。這代表你不用像第 9 章教的那樣，自己去 mcp-config.json 裡手動加一個 GitHub MCP server——它一開機就在那裡了。

可以直接操作 GitHub 物件

因為 Copilot CLI 本來就是 GitHub 自家的 CLI，跟 gh 生態系（issue／PR／gist）天然互通。官方 overview 頁提到它能「與 GitHub.com 互動」，包含「創建 pull request、管理 issue」——這些對其他三套 CLI 來說，都得先自己接一個 GitHub MCP server 才做得到。

對比一下：同一個官方 MCP endpoint，待遇完全不同

值得特別點出的是，Codex CLI、Claude Code 如果想接上同一個官方 GitHub MCP（endpoint 是 api.githubcopilot.com/mcp/），得自己動手把它加進各自的 MCP 設定檔；Copilot CLI 因為是 GitHub 自家產品，同一個 endpoint 直接內建、預設唯讀工具全開，不用你動一根手指。「自家工具」跟「外部工具」的待遇差異，在這裡看得非常清楚。

本章小結

這一章你學會了怎麼把 GitHub Copilot CLI 接進團隊的 CI/CD 生產線：官方給了兩條各自完整的 Actions 整合路徑——路徑一申請帶「Copilot Requests」scope 的 PAT、透過 COPILOT_GITHUB_TOKEN 注入；路徑二直接用 Actions 內建的 GITHUB_TOKEN，但 workflow permissions 要加 copilot-requests: write，且組織管理員得先開放對應政策。兩條路徑各有取捨，前者權限模型更細緻，後者更省事。接著你認識了官方明確點名的風險：直接在 workflow step 裡裸跑 copilot，會讓它拿到整個工作環境的廣泛存取權，fork PR 觸發的情境風險最高——官方給的正解不是「小心用」，而是改用 GitHub Agentic Workflows：一個引擎無關（copilot／claude／codex／gemini 四選一）、用 Markdown 寫 CI 流程、預設唯讀＋安全輸出的新框架，目前仍是 Technical Preview。最後你看清楚 Copilot CLI 在 GitHub 生態系裡真正的主場優勢：內建免設定的 GitHub MCP server、預設唯讀工具全開、能直接操作 issue／PR／gist——跟 Codex CLI、Claude Code 得自己另外手動接 GitHub MCP 形成鮮明對比。

動手試試

1. （需 GitHub repo） 挑一個你自己的小 repo，照 11.1 路徑二的範例，在 workflow permissions 加上 copilot-requests: write，跑一次看看（記得先確認組織/個人帳號的 Copilot CLI 政策是否允許）。
2. （查權限） 到 github.com/settings/personal-access-tokens/new 看一眼「Copilot Requests」這個 permission 選項長什麼樣子，不用真的申請也能先熟悉介面位置。
3. （讀官方安全頁） 找到官方針對 fork PR 風險的完整安全指引，對照 11.2 引用的兩句原文，看看官方還提了哪些你這章沒讀到的細節。
4. （查新功能） 搜尋 GitHub 官方文件裡 GitHub Agentic Workflows 目前的最新狀態，確認它是否還在 Technical Preview，engine 欄位支援的引擎清單有沒有變動。
5. （對照第 9 章） 回頭翻第 9 章教的 GitHub MCP server 手動設定方式，跟本章「Copilot CLI 內建免設定」的差異實際感受一次。

本章官方文件參考

• Automate Copilot CLI with GitHub Actions（路徑一逐字出處）：https://docs.github.com/en/copilot/how-tos/copilot-cli/automate-copilot-cli/automate-with-actions
• Use Copilot CLI in GitHub Actions（路徑二逐字出處，頁面網址依官方站內導覽路徑推算，若連結失效請直接在 docs.github.com 搜尋頁面標題）：https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli-in-actions
• About GitHub Copilot CLI（GitHub 生態系整合描述）：https://docs.github.com/copilot/concepts/agents/about-copilot-cli