GitHub Copilot for JetBrains 更新後怎麼管 OTel 與模型？先分開三個設定面
GitHub 在 2026 年 7 月 27 日發布 GitHub Copilot for JetBrains 更新，將幾個原本容易混在一起的控制面放進 IDE：agent workflow 的 OpenTelemetry 匯出、BYOK 與 custom endpoint 的 token limits、內建模型啟用管理，以及 Claude agent flow 的 MCP server 與 custom agents。
這次的重點不是多了幾個選項，而是觀測資料、模型路由和 agent 工具權限應該分開審核。如果只看到「模型選單變多」就直接開放，之後很難回答資料送去哪裡、模型用了多少 token，以及 agent 是否真的呼叫 MCP。
先拆成三個設定面
| 設定面 | 官方更新提供什麼 | 導入時要回答的問題 |
|---|---|---|
| OpenTelemetry | 在 GitHub Copilot Chat 設定 agent workflow 的 OTel export | 哪些 telemetry 可以離開 IDE？collector、保留期與責任人是誰？ |
| Model management | 開啟或停用內建 Copilot models；BYOK／custom endpoint 可設 maxInputToken、maxOutputToken | 哪些模型能被選？token 上限和方案／成本如何對齊？ |
| Claude agent flow | 連接 MCP servers 與 custom agents | agent 允許哪些外部工具？每個 repository 如何驗證實際呼叫？ |
GitHub 的原始公告把這些能力放在同一份 JetBrains 更新裡，但它們的風險不同。先用三張設定清單分開記錄，再決定是否在組織中推廣。
OTel：先確認匯出目標與資料邊界
官方公告指出，可以在 Settings → Tools → GitHub Copilot → Chat 設定 agent workflow 的 OpenTelemetry export。這代表 IDE 端有一個可調整的觀測出口，不代表「開啟 OTel 就等於所有 prompt 都會被安全地送到你的 collector」。實際送出的欄位、collector 端的採集規則與保存政策仍要另外確認。
導入前可以先留下這些答案：
- OTel collector 的 endpoint 是本機、公司網路，還是第三方服務？
- collector 是否會保存 prompt、工具名稱、檔案路徑或錯誤訊息？
- 哪些使用者或 organization 的設定可以覆寫 IDE 預設？
- 如何用測試 repository 驗證「有送出」和「沒有送出」的行為？
- 若 collector 無法連線，Copilot workflow 應該繼續、警告，還是停止？
不要把 OTel 設定和 GitHub Copilot usage metrics 當成同一份報表。前者是觀測資料出口，後者回答組織或 repository 的使用量與活動；若要看 repository 層級指標，可以參考 GitHub Copilot repository usage metrics，但不要把任何一份資料直接當成程式品質分數。
Model management：把「可選」和「可用」分開
這次更新可以從 model-management controls 啟用或停用所有內建 Copilot models，也能替 BYOK 與 custom endpoint 設定預設的 maxInputToken、maxOutputToken。建議不要只做一張「允許模型名稱」清單，而是分成三欄：
| 欄位 | 代表什麼 | 驗證方式 |
|---|---|---|
| 可選 | 使用者在 JetBrains model picker 能看到什麼 | 以測試帳號重開 IDE，檢查 model picker |
| 可連 | BYOK 或 custom endpoint 的 URL、認證與模型是否真的可呼叫 | 用受控測試 prompt 做一次最小請求 |
| 可負擔 | token 上限、AI credits、方案或 endpoint 的成本界線 | 讀取 usage／billing 資料，確認上限與通知 |
maxInputToken 和 maxOutputToken 是請求邊界，不是品質保證。上限設得太大可能增加一次請求的成本或延遲；設得太小則可能讓 agent 截斷上下文。先用固定的小型任務測試，再依模型、repository 大小與方案限制調整。
若你正在治理 Copilot app 的入口，也要把 Copilot app 與 Copilot CLI 的獨立政策分開看。client access policy 回答「誰能使用哪一個入口」，JetBrains model management 回答「入口裡可選哪些模型」，兩者不能互相取代。
Claude agent flow：MCP 是工具邊界，不是模型開關
GitHub 公告也提到，Claude agent flow 可以直接使用 MCP servers 與 custom agents。這適合把專案特定的指令、文件查詢或外部工具接進 IDE，但導入時要先列出每個 MCP server 的：
- 讀取範圍：repository、issue、文件、內部服務或本機檔案。
- 寫入能力：純查詢、建立草稿，還是能改變外部狀態。
- 認證來源：使用者 token、組織設定或本機環境變數。
- 失敗行為：工具逾時、回傳空資料或權限不足時，agent 如何回報。
不要因為這些 server 出現在 model picker 附近，就把 MCP 當成模型設定的一部分。模型可以保持不變，工具權限卻可能完全不同；review 流程應以工具清單和實際 session log 為證據。
如果用途是 PR 審查，站內的 GitHub Copilot Code Review Skills 與 MCP 設定已整理 head branch、唯讀工具與 session logs 的檢查。本文聚焦 JetBrains IDE 的導入治理，不重複 PR review 的細節。
用一個小型 repository 做導入驗證
不要直接拿最敏感或最大的專案測試。準備一個不含 secrets 的 repository，放入一個能被人工判斷的任務，例如「讀取指定檔案，列出三個測試缺口，不修改檔案」。依序完成以下檢查：
- 只開啟目標內建模型，確認 model picker 顯示範圍符合預期。
- 對 BYOK 或 custom endpoint 執行固定 prompt，記錄模型 ID、input／output token 上限和失敗訊息。
- 開啟 OTel export，確認 collector 收到哪些事件與欄位；不要把範例 prompt 當成正式資料政策。
- 加入一個最小權限 MCP server，從 session log 確認它是否被實際呼叫。
- 關閉 MCP 或模型後重開 IDE，確認設定真的生效，不只是目前 session 的暫時狀態。
- 將設定、驗證日期、IDE 版本與負責人寫入團隊文件。
通過測試後，再決定是用 organization policy、安裝包設定或團隊 onboarding 文件擴散。遇到「某位使用者看不到模型」時，先分流登入帳號、方案／政策、IDE plugin 版本和 endpoint，而不是要求每個人清除所有設定。
結論：三張清單比一個總開關更好維護
GitHub Copilot for JetBrains 這次更新把 OTel、模型管理與 Claude agent 工具能力放到更容易使用的位置。可維護的導入方式是：用 OTel 清單管觀測出口，用模型清單管可選模型與 token 邊界，用 MCP 清單管外部工具與寫入風險。
三者分開後，成本、隱私和 agent 行為才有各自的驗證證據；不要用「model picker 看得到」推論「collector 安全」，也不要用「agent 回答正確」推論「MCP 沒有讀取超出範圍的資料」。
常見問題
Q: JetBrains 裡的 OTel 設定會改變 Copilot 使用的模型嗎？
A: 不會直接改變模型。OTel export 控制 agent workflow 的觀測設定；模型管理則控制內建模型與 BYOK／custom endpoint 的可用性及 token limits。兩者應分開驗證。
Q: maxInputToken 和 maxOutputToken 是整個組織的費用上限嗎？
A: 不是。它們是 BYOK 或 custom endpoint 的預設 token limits。實際費用、AI credits、方案限制和 endpoint 的計費規則仍要到對應的 GitHub 或供應商帳務控制面確認。
Q: 開啟 Claude agent flow 的 MCP 後，怎麼確認它真的有使用工具？
A: 用不含敏感資料的測試 repository，讓 agent 執行一個需要該工具的明確任務，再查看對應 session log 的 MCP server 與 tool call。不要只用回答內容是否精準來推測工具有沒有被使用。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。