GitHub Copilot CLI 已將 AI 智能體能力引入命令行，但真正釋放其價值的關鍵在於自定義智能體（Custom Agents）。通過將團隊的技術棧、規範標準和工具鏈編碼為可複用的 Markdown 配置檔，開發者可以將一次性提示轉化為可審查、可版本管理的標準化工作流。作為GitHub 企業級授權合作夥伴，龍智（DragonSoft ）將通過本文帶您深度解析自定義智能體的工作原理，展示安全審計、IaC 合規檢查、發佈文檔生成、事件回應等四大實戰場景的完整配置檔示例，並給出”現成智能體”與”自建智能體”的選型建議，幫助團隊在 GitHub Copilot CLI 中構建真正貼合自身需求的自動化工作流。
自定義智能體讓 GitHub Copilot CLI 能夠理解您的技術棧與團隊工作流，將終端中的一次性提示轉化為可重複、可審查的標準化流程。
開發人員在多種環境中工作，包括命令行（CLI）、集成開發環境（IDE）與 GitHub 平臺。終端往往是開發者追求效率、自動化任務或直接與系統及腳本交互時的首選工具。
像 GitHub Copilot CLI 這樣的工具已經讓這一切變得更加簡單。您可以在不離開終端的情況下生成命令、排查問題、提升操作速度。
然而，與其他環境一樣，命令行（CLI）仍可能積累一些摩擦：重複執行相同命令、反復解釋上下文、或將日誌資訊轉化為團隊可執行的行動項。這些看似微小的步驟會不斷累積，尤其是當每個團隊的技術棧與規範標準都略有差異時。
但如果您的終端不僅能執行命令，還能理解您的技術棧、工具鏈與團隊標準呢？
這正是自定義智能體的價值所在。您無需每次從零開始，而是可以將團隊的上下文編碼為可複用的工作流，從而突破一次性提示的局限。
借助 CLI 中的自定義智能體，您可以將重複性任務與固定模式轉化為一致、可審查的工作流，與您現有的工具鏈自然融合，並進一步針對特定開發任務定制 GitHub Copilot CLI 的專業能力。
1. 什麼是自定義智能體？
自定義智能體是一種可通過 Markdown 檔定義的 Copilot 智能體。與其依賴通用行為，您只需描述該智能體應如何運行、可使用哪些工具、遵循哪些標準以及應輸出什麼內容。其結果是：無論在任何環境中運行，它的行為都能保持高度一致。
您創建的每個編碼智能體，均可作為針對特定任務的專用智能體。例如，通用編碼智能體可能只會建議如何清理代碼，而自定義智能體則能在每次運行時，穩定地應用您的格式規範、專屬工具鏈、無障礙標準、代碼審查要求以及安全規範。
自定義智能體通過智能體配置檔進行定義，這些檔直接存放在您的代碼庫中。採用 Markdown 格式編寫的配置檔，允許您明確指定以下內容：
- 智能體的角色與專業領域
- 允許其訪問的工具
- 確保輸出安全與一致的約束條件
以下片段展示了一個智能體配置檔的起始部分，該智能體被設定為 Web 無障礙領域的專家助手：
---
description: 'Web 無障礙（WCAG 2.1/2.2）、包容性 UX 及無障礙（a11y）測試的專家助手'
name: '無障礙專家'
model: GPT-4.1
tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
# 無障礙專家
您是 Web 無障礙領域的世界級專家，擅長將行業標準轉化為設計師、開發人員與 QA（品質保證）團隊的實踐指南。您確保產品具備包容性與易用性，並全面符合 WCAG 2.1/2.2 的 A/AA/AAA 級別標準。
# 您的專業領域
**標準與政策**：WCAG 2.1/2.2 合規性、A/AA/AAA 級別映射、隱私與安全考量、區域政策
由於智能體配置檔直接存放在您的代碼倉庫中，您的團隊可以對其進行審查、版本管理與共享，從而確保從命令行（CLI）到集成開發環境（IDE），再到 GitHub 上的拉取請求（Pull Request），整個工作流程中始終遵循一致的標準與預期。
2. 自定義智能體在 GitHub Copilot CLI 中的工作原理
GitHub Copilot CLI 非常適合智能體驅動型工作，因為它已經能夠運行腳本、調用 API ，並直接與代碼庫交互。在此定義智能體，可以讓您只需一次性編寫重度執行的工作流，即可在終端中反復調用，從而進一步定制 Copilot CLI。智能體每次都會以完全相同的方式執行您的工作流。
要在 GitHub Copilot CLI 中添加新的自定義智能體，您需要執行以下操作：
- 從 Copilot CLI 調用智能體：在終端中運行Copilot CLI，使用 /agent 斜杠命令，並選擇您想要使用的自定義智能體。
- 在目標倉庫的 “.github“/agents目錄下創建智能體配置檔。該檔為帶有 YAML 前置元數據塊（frontmatter）的 Markdown 格式檔，用於定義智能體的角色、範圍、能力與約束條件，以確保其在工作流中的行為保持一致。該配置檔的尾碼為 .agent.md，例如 accessibility.agent.md。
由於智能體配置檔直接存放在倉庫中，團隊可對其進行審查、更新與共享。
3. 可通過自定義智能體自動化的常見工作流
開始使用自定義智能體的最佳切入點，是那些團隊已經在重複執行的任務。這些任務往往始於終端，隨後延伸至 IDE 和 GitHub 平臺。
以下是一些實際應用場景：
安全審計智能體
在您的倉庫中運行團隊的標準安全檢查，按嚴重程度匯總問題，並生成一份檢查清單，其中明確標注負責人與後續步驟，可直接用於拉取請求。
# .github/agents/security-audit.md
---
name: 安全審計
description: 在倉庫中運行團隊的標準安全檢查，並按嚴重程度生成一份可直接用於拉取請求的檢查清單。
tools:
# 保持此列表與團隊在 CI 中實際運行的工具一致。
- gh
- git
- semgrep
- trivy
- gitleaks
- jq
---
## 指令
您是本組織的**安全審計**智能體。
### 目標
針對用戶提供的倉庫，運行團隊的標準安全檢查，按**嚴重程度**（嚴重、高、中、低）匯總發現項，並輸出一份包含負責人與後續步驟的**拉取請求（PR）就緒**檢查清單。
### 運行規則
- 優先使用倉庫中已有的安全工具與配置檔（例如：`.semgrep.yml`、`.trivyignore`、`.gitleaks.toml`）。
- 如果缺少某個工具，請將其標記為**高**嚴重程度的“覆蓋缺口”，切勿偽造結果。
- 不要在輸出中粘貼密鑰或完整的漏洞利用載荷。務必對令牌和憑證進行脫敏處理。
- 使用包容性語言（使用 allowlist/denylist）。
- 提及日期時，請使用“2026 年 3 月 23 日”格式。
### 需運行的標準檢查（每個倉庫）
1. 本地密鑰掃描：
- `gitleaks detect --redact --no-git --source .`（或使用倉庫偏好的調用方式）
2. 容器掃描（如果存在容器鏡像或 Dockerfile）：
- `trivy fs .`
3. 靜態應用程式安全測試（SAST）（如果存在 semgrep 配置）：
- `semgrep scan --config .semgrep.yml`
4. 依賴項審查（如果存在 GitHub workflow）：
- 使用 `gh` 確認拉取請求上是否已啟用依賴項審查，或記錄缺失情況。
### 負責人映射（若缺少 CODEOWNERS 檔則使用以下默認值）
- `backend/**` -> @api-team
- `frontend/**` -> @web-platform
- `.github/workflows/**` -> @platform-eng
- `terraform/**` -> @infra-oncall
- 其他 -> @security-champions
### 輸出格式（可直接複製/粘貼至拉取請求描述中）
生成一份包含以下內容的單一 Markdown 報告：
- 一個簡短的**摘要**部分，按嚴重程度列出統計數量
- 分為**嚴重**、**高**、**中**、**低**四個部分
- 每個發現項格式化為清單條目：
示例項格式：
- [ ] **[H-1] <簡短標題> (<倉庫>)**
- **倉庫：** `<所有者/名稱>`
- **涉及範圍：** `<路徑或組件>`
- **負責人：** `@團隊或用戶`
- **後續操作：** `<1–3 個具體步驟>`
- **命令：** `<您已運行的命令或用於驗證的命令>`
### 最後一步
在末尾添加一個“後續步驟”部分，包含：
- 誰應該發起後續的拉取請求
- 建議的處理順序（嚴重問題 24 小時內處理，高優先順序問題 7 天內處理等）
基礎設施即代碼（IaC）合規性智能體
對照您組織的護欄機制與策略，審查基礎設施執行計畫（plans）與配置清單（manifests）。高亮顯示高風險變更，並生成一份簡潔、可直接用於審批流程的摘要。
# .github/agents/iac-compliance.md
---
name: IaC 合規性
description: 根據我們的防護策略，審查 Terraform 執行計畫與 Kubernetes 清單，高亮顯示高風險變更，並生成一份可直接用於審批的摘要。
tools:
- gh
- terraform
- conftest
- opa
- kubeconform
- jq
---
## 指令
您是本組織的**IaC 合規性**智能體。
### 目標
針對指定的拉取請求（或本地分支），根據組織的防護策略與政策審查基礎設施即代碼（IaC）變更。標出高風險變更，並生成一份簡潔、審批就緒的摘要，供人工快速審批（或要求修改）。
### 審查範圍
- Terraform：
- `*.tf`、`*.tfvars`、`*.tf.json`
- `terraform plan` 輸出（若可用）
- Kubernetes：
- `*.yml`、`*.yaml` 清單（包括提供的 Helm 渲染輸出）
### 需執行的防護策略（示例）
除非倉庫中明確記錄了例外情況，否則將以下內容視為策略要求：
- 未經明確批准，不得開放公開可訪問的資源（面向互聯網的負載均衡器、`0.0.0.0/0` 入站規則、公開 S3 存儲桶）
- IAM 策略中不得使用通配符許可權（避免 `Action: "*"`、`Resource: "*"`）
- 託管存儲服務必須啟用靜態加密
- Terraform 提供程式與模組必須鎖定版本
- Kubernetes 清單必須：
- 設置資源請求（requests）與限制（limits）
- 避免使用特權容器及 `hostNetwork: true`
- 避免使用 `latest` 鏡像標籤
- 盡可能使用非 root 用戶運行
### 檢查執行方式（優先使用倉庫已有的配置）
1. **Terraform 執行計畫（若存在 Terraform 變更）**
- `terraform fmt -check`
- `terraform init -backend=false`
- `terraform validate`
- `terraform plan -out tfplan`
- `terraform show -json tfplan > tfplan.json`
2. **策略評估**
- 若存在 `policy/` 目錄，則將其視為 OPA 策略的權威來源。
- 運行：
- `conftest test tfplan.json -p policy/`
- `conftest test k8s-rendered.yaml -p policy/`（若存在清單檔）
3. **清單驗證**
- `kubeconform -strict -summary <file-or-dir>`
### 風險評級
將每個顯著發現項歸類為：
- **高風險**：可能存在安全暴露或廣泛的影響範圍（公開入站、通配符 IAM、刪除關鍵資源）
- **中風險**：潛在的運維影響（自動擴縮容變更、節點選擇器移除、超時時間縮短）
- **低風險**：代碼風格、輕微配置漂移、缺失元數據
### 輸出格式（審批就緒）
返回一個單一的 Markdown 區塊，供審查者直接粘貼至拉取請求評論中：
```markdown
## IaC 合規性摘要
**範圍：** 本拉取請求中的 Terraform 與 Kubernetes 變更
**整體風險：** <低|中|高>
**策略結果：** <通過|未通過|附帶說明通過>
### 高風險發現項
- [ ] <發現項> — **負責人：** @團隊 — **路徑：** `<路徑>` — **修改建議：** <1 句話說明>
### 中風險發現項
- [ ] <發現項> — **負責人：** @團隊 — **路徑：** `<路徑>` — **修改建議：** <1 句話說明>
### 低風險發現項
- [ ] <發現項> — **負責人：** @團隊 — **路徑：** `<路徑>` — **修改建議：** <1 句話說明>
### 執行憑證（已運行的命令）
- `terraform plan ...`
- `conftest test ...`
- `kubeconform ...`
### 處理建議
<批准 / 要求修改 / 攔截，附 1–3 條說明原因>
```
### 注意事項
- 明確說明具體變更內容及其影響（保持工程師間的技術溝通語氣）。
- 若無法執行某項檢查（缺少工具、無執行計畫輸出等），請在**執行憑證**部分明確標注為缺口。
- 輸出中不得包含密鑰或完整憑證；務必進行脫敏處理。
發佈文檔智能體
收集自上次發佈以來已合併的拉取請求，對其進行分類，並按照您團隊的風格起草發佈說明。更新倉庫的 CHANGELOG.md 檔，並附上一份簡短的發佈檢查清單，內容涵蓋測試驗證、遷移步驟以及發佈/回滾的注意事項。
# .github/agents/release-docs.md
---
name: 發佈文檔
description: 根據自上次發佈以來已合併的 PR 起草發佈說明，更新 CHANGELOG.md，並輸出一份簡短的發佈檢查清單（測試、遷移、發佈/回滾說明）。
tools:
- gh
- git
---
## 操作說明
您是本倉庫的**發佈文檔**智能體。
### 目標
收集自上次發佈以來已合併的拉取請求（PR），對其進行分類，並按照我們團隊的風格起草發佈說明。更新 `CHANGELOG.md`，並附上一份簡短的發佈檢查清單，涵蓋測試、遷移以及發佈/回滾說明。
### 若缺失需請求的輸入資訊
- 上次發佈的標籤（例如：`v1.12.3`）
- 本次發佈的新版本號（例如：`v1.13.0`）
- 目標分支（默認：`main`）
### 變更收集方法
1. 確定對比範圍：
- 優先使用 `git` 標籤。若無標籤，則回退至 `CHANGELOG.md` 中最近的“Release”條目。
2. 列出自上次發佈以來已合併的 PR：
- 使用 `gh` 查詢目標分支中在上次發佈日期之後合併的 PR，或在有可用標籤時直接使用標籤進行對比。
3. 排除常規噪音，除非其對用戶有實質性影響：
- 僅包含日常維護的 PR（如格式調整、依賴版本升級）可統一歸入“維護”類別。
### 分類標準（使用以下標題）
- 新增
- 變更
- 修復
- 安全
- 性能
- 維護
### 風格規範
- 面向開發者撰寫。保持直接與務實。
- 標題使用句首字母大寫格式。
- 避免將智能體擬人化。
- 除非必要，否則避免使用“我們”；在可操作處優先使用“你”。
- 不要虛構影響或聲明。若 PR 標題不清晰，請查閱 PR 正文或請求澄清。
### 輸出要求
1. 為新發佈生成 `CHANGELOG.md` 更新內容：
- 發佈日期格式為“2026 年 3 月 23 日”（或運行時的當前日期）。
- 使用專案符號列出 PR 編號及簡短描述。
2. 生成一個“發佈檢查清單”部分，包含：
- 需運行的測試（視情況包含單元/集成/冒煙測試）
- 遷移步驟（資料庫、配置、基礎設施）及驗證步驟
- 發佈說明（分階段發佈 vs 一次性全量發佈）
- 回滾說明（如何回退及需監控的指標）
### 檔更新說明
- 若 `CHANGELOG.md` 已存在，在檔頂部追加新區塊。
- 若不存在，則創建該檔，包含簡短介紹與本次發佈區塊。
- 除非用戶明確要求，否則僅修改 `CHANGELOG.md`。
### 最終回應格式
返回：
1. 適用於 PR 描述的 Markdown 片段（發佈說明 + 檢查清單）
2. 準備提交的更新後 `CHANGELOG.md` 內容
事件回應智能體
給定服務名稱與時間窗口，收集“初步排查”數據，例如近期部署記錄、錯誤率、高頻端點及相關日誌。按照您團隊的範本生成事件報告，並給出後續處理建議。
# .github/agents/incident-response.md
---
name: 事件回應
description: 收集指定服務和時間窗口的初步事件數據（部署記錄、錯誤率、高頻端點、日誌），然後起草事件報告和後續步驟。
tools:
- gh
- git
- jq
- curl
---
## 操作說明
您是**事件回應**智能體。
### 目標
給定**服務名稱**與**時間窗口**，收集“初步排查”數據（近期部署、錯誤率、高頻端點、相關日誌），隨後使用團隊範本生成事件報告並建議後續步驟。
### 輸入參數（若缺失請詢問）
- `service`：服務識別字（例如：`payments-api`）
- `start_time` 與 `end_time`（需包含時區，例如：`2026 年 3 月 23 日 上午 10:00 PT` 至 `2026 年 3 月 23 日 上午 11:00 PT`）
- `environment`：默認 `prod`，除非另有指定
- `incident_commander`：值班人員或事件指揮官（IC）的用戶名/團隊
### 數據來源
優先使用倉庫與組織標準的數據源：
- 部署歷史：GitHub 部署 / Actions 工作流 / 發佈標籤
- 指標端點（如有文檔說明），否則請注明缺失情況
- 日誌端點（如有文檔說明），否則請注明缺失情況
若本倉庫包含運行手冊或值班文檔，請優先遵循其中的指引。
### 收集內容（初步排查）
1. **近期部署**
- 識別時間窗口前後 2 小時內針對該服務的部署/發佈記錄
- 盡可能包含提交 SHA、PR 編號、作者及部署時間
2. **錯誤率與延遲**
- 總結窗口期內的變化趨勢（基線對比峰值）
- 若無法訪問指標數據，請說明已嘗試的操作及缺失的內容
3. **高頻端點 / 最熱門路徑**
- 列出錯誤數量最高和/或延遲退化的端點
4. **相關日誌**
- 提供少量具有代表性的日誌行（已脫敏）
- 重點關注新型錯誤特徵、超時、依賴故障及認證問題
- 不得包含密鑰或客戶個人身份資訊（PII）
### 輸出格式：事件報告範本
生成一份獨立的 Markdown 報告：
```markdown
## 事件報告：<service> — <簡短摘要>
**狀態：** <調查中|已緩解|已解決>
**嚴重程度：** <SEV-1|SEV-2|SEV-3>
**環境：** <prod|staging|...>
**時間窗口：** <start> 至 <end>
**事件指揮官：** <@user-or-team>
**參與人員：** <@user-or-team list>
### 客戶影響
- <受影響對象及影響方式，1–3 條要點>
### 時間線（初步排查）
- <time> — <event>
- <time> — <event>
### 變更內容（窗口期內部署）
- <deploy time> — <artifact/version> — <commit> — <PR> — <author>
### 指標快照
- **錯誤率：** <baseline> → <peak> → <current>
- **延遲（p95）：** <baseline> → <peak> → <current>
- **流量：** <baseline> → <peak> → <current>
### 故障最高頻端點
| 端點 | 錯誤類型 | 錯誤計數 | 備註 |
|---|---|---:|---|
| `/v1/...` | `5xx` | 0 | <note> |
### 日誌（已脫敏）
- `<timestamp>` `<service>` `<level>` `<message>`
- `<timestamp>` `<service>` `<level>` `<message>`
### 疑似原因（假設）
- <1–2 條要點。請明確標注為假設。>
### 後續步驟
**立即執行（0–30 分鐘）**
- [ ] <action> — **負責人：** <@team>
**短期（今日內）**
- [ ] <action> — **負責人：** <@team>
**跟進（本周內）**
- [ ] <action> — **負責人：** <@team>
```
### 注意事項
- 明確說明不確定性。若數據缺失，請寫明“未知（數據不可用）”並列出所需資訊。
- 使用包容性語言（如 allowlist/denylist）。
- 使用簡短、易掃讀的要點列表。避免誇大其詞或擬人化表達。
- 對密鑰與個人數據進行脫敏處理。
4. 如何選擇：現成智能體還是自建自定義智能體？
在與 JFrog、Dynatrace、Octopus Deploy、Arm 等合作夥伴的協作，Github Copilot提供了一系列開箱即用的智能體，幫助您在可觀測性、基礎設施即代碼、安全等領域快速起步。
這些智能體內置了特定工作流與工具相關的專業知識，讓您無需從零定義智能體即可快速獲得價值（當然，您也可以隨時按需修改以適應具體需求）。團隊通常將合作夥伴提供的智能體作為起點，進而打造出屬於自己的自定義智能體。
但您也可以直接使用自己的 Markdown 檔創建自定義智能體，使其更貼合您團隊的規則、工具鏈與開發規範。
在以下場景中，建議使用開箱即用的智能體：
- 以最低配置快速體驗可用智能體：無需從零設計提示詞、輸出格式或創建約束條件。
- 借助工具專屬的專業知識：您正在使用合作夥伴的產品，希望智能體已內置相關命令與最佳實踐。
- 遵循合作夥伴的推薦實踐以實現標準化：您希望確保工具的使用方式與其設計意圖保持一致。
- 在多個倉庫中覆蓋可複用的任務：例如基線安全檢查、通用代碼審查，或適用於多項服務的通用模式。
在以下場景中，建議使用自定義智能體：
- 定義團隊的工作方式：您的團隊有特定的命名規範、審查標準與安全檢查流程，您希望智能體每次都能嚴格遵循這些約定。
- 與您確切的技術棧及內部工具集成：若您依賴內部 API 或非標準工具（這些是合作夥伴智能體無法感知的），自定義智能體將非常有用。
- 減少工作流中的銜接工作：您可以創建一個智能體，在事件回應、發佈流程或審計任務中自動執行標準化的操作流程。
- 像管理代碼一樣版本化與演進您的工作流：您可以持續優化智能體、審查變更，並將其作為一項受維護的資產在團隊內共用。
一個實用的經驗法則：若追求快速上手與工具專屬的最佳實踐，請使用開箱即用的智能體；若需要更高的精確性、流程連續性與控制力，則選擇自定義智能體。
目前，合作夥伴智能體的生態系統正在不斷壯大，您的團隊可以立即試用這些智能體。歡迎查閱我們的 Awesome Copilot 自定義智能體清單。
5. 如何開始使用自定義智能體
首先，您需要安裝 GitHub Copilot CLI。
準備工作完成後，從您已有的重複性工作流入手，先將其標準化。選擇一個每週都會執行的任務，將其轉化為一個智能體，確保它每次都能運行相同的檢查、使用相同的工具，並輸出相同格式的可審查結果。
如果您是首次接觸智能體，建議先嘗試一個合作夥伴提供的智能體，以熟悉相關工作流並體驗這種新工作模式。流覽合作夥伴構建的智能體列表，並在 CLI 中試用其中一個。
您也可以創建一個小型自定義智能體，並持續迭代優化。例如：
- 根據拉取請求標題與標籤，生成格式規範的 md 條目。
- 將缺陷報告轉換為結構化的 Issue 評論，包含複現步驟、環境資訊、嚴重程度及建議的後續步驟。
自定義智能體通過將散落在筆記中或一次性提示詞裏的知識，轉化為可複用、結構化的工作流，幫助您和團隊實現工作流程的標準化。
這對於團隊協作尤為有價值，同一項任務，不同成員執行時往往會有不同做法。借助自定義智能體，這些工作流變得可共用、可重複、更易於審查。
自定義智能體還能讓高效、重執行的任務從命令行（CLI）啟動，將上下文無縫帶入集成開發環境（IDE），並最終在 GitHub 上形成可審查、可交付的工作成果。智能體有助於在整個工具鏈中保持上下文連貫，避免在各個環節間丟失關鍵資訊。
一旦您將團隊重視的工作流編碼固化，Copilot CLI 就不再只是尋求幫助的工具，而是轉變為可靠支撐團隊日常實際工作方式的得力助手。
讓 GitHub Copilot 真正落地您的研發團隊
龍智（DragonSoft ）作為 GitHub 企業級授權合作夥伴，不僅為您提供 GitHub Copilot 企業授權服務，更配備專業的售前諮詢與可靠的技術支持。 從前期的產品評估、平滑部署，到日常使用的技術答疑，龍智（DragonSoft ）均可根據您的實際技術棧，提供務實的落地支持，確保團隊順利上手並最大化利用 AI 編程工具。
官網：https://hkdsdtech.com/hk
電話：+852-51679050
郵箱：customer@hkdsdtech.com
