GitHub Copilot for JetBrains 8 月更新：Memory、Ollama 與企業設定怎麼分開驗證

先拆成四張設定表#

不要因為這些功能同時出現在 JetBrains，就把它們當成一個總開關。先分開記錄，再用無 secrets 的測試 repository 驗證。

Copilot Memory：保留的是可驗證上下文，不是永久知識庫#

GitHub 文件將 Memory 分成兩類：repository-level facts，例如 coding conventions、架構決策和 build commands；user-level preferences，則是某個使用者的互動偏好。repository facts 會附帶支援它的程式碼引用，Copilot 在使用前會對照目前 branch 驗證；user preferences 則只在同一位使用者後續互動中使用。

這裡要注意三個限制：

• Memory 目前是 public preview，行為可能變更。
• Copilot Memory 的 repository facts 和 user preferences 不是同一個可見範圍；Business／Enterprise 管理員也有額外的查看、匯出或刪除能力。
• 沒有使用的 fact 或 preference 會在 28 天後自動刪除；成功驗證並使用時，計時器可能重新計算。

導入時先做一份「不應被記住」清單。API token、個資、一次性 incident 細節和仍未確定的架構結論，不要當作可寫進 instructions 或 prompt 的普通資料。Memory 有引用與驗證機制，也不代表它可以取代 secrets 管理或正式技術文件。

Enterprise managed settings：把政策和個人開關分開#

官方更新指出，企業 managed settings 現在涵蓋 plugin availability、MCP server access、permission bypass behavior 和 OpenTelemetry。建議把設定拆成以下驗證項目：

管理員開啟一項能力，不代表每個 project 都應該直接採用。先以測試帳號和最小權限 MCP 做驗證，才知道 plugin、MCP 和 permission bypass 之間是否有預期的組合。

Ollama BYOK：先確認 provider 邊界，再談模型選擇#

JetBrains 現在可以把 Ollama 當成 BYOK provider，並在 Copilot for JetBrains 的體驗中設定 provider 與模型。這對本機模型工作流有幫助，但「模型在本機」和「整個 agent workflow 都不會離開本機」不是同一句話。

導入 Ollama 前先確認：

1. Ollama API endpoint 是否只綁本機，還是會被區網其他裝置存取。
2. 使用的是哪個模型名稱與 context 設定，是否有固定版本的測試記錄。
3. Copilot plugin、MCP server、customization 和 agent debug logs 是否仍會產生外部服務流量。
4. 失敗時是 provider 不可達、模型不支援，還是組織 policy 沒有允許 BYOK。

不要把 Ollama 出現在 model picker 解讀成所有模型都會有相同的功能或 agent 能力。先用一個不含 secrets 的 repository 做最小 chat、tool call 和拒絕寫入測試，再決定是否擴大。

Codex workflow 與 Copilot CLI：需要可回溯的操作證據#

這次 JetBrains 更新把 Codex session 放進 agent debug logs，也支援更新後的 permission modes，以及透過 instructions 和 skills 調整 agent 行為；另外，在 macOS、Linux 和 Windows 的整合 terminal 中可以自動安裝 Copilot CLI。

這些功能適合降低開始 agent workflow 的摩擦，但導入時要保留操作證據：

• debug logs 是否能指出實際使用的 agent、工具和失敗原因？
• permission mode 是否讓 agent 在寫檔、執行指令或呼叫 MCP 前停下來確認？
• instructions 與 skills 是 repository 級規則，還是使用者個人偏好？
• CLI 是由 IDE 安裝到哪個環境，版本更新和登入狀態由誰負責？

如果用途是 PR 審查，可再參考 GitHub Copilot Code Review 的 Skills 與 MCP 邊界。本文聚焦 JetBrains 內的 agent workflow，不把 code review 的 repository policy 當成 IDE 端的通用設定。

用小型 repository 驗證四個邊界#

不要直接拿含 secrets 或 production 設定的專案測試。準備一個可丟棄的 repository，放入一個只讀任務，例如「讀取指定檔案，列出三個測試缺口，不修改檔案」，再依序做：

1. 啟用或停用 Copilot Memory，確認 repository facts、user preferences 和可查看／刪除的範圍。
2. 在組織 managed settings 下檢查 plugin、MCP、permission bypass 和 OTel 的實際狀態。
3. 設定 Ollama provider，記錄 endpoint、模型、context 和一次最小請求結果。
4. 讓 Codex workflow 執行只讀任務，查看 agent debug logs 是否能回溯操作。
5. 從整合 terminal 啟動 Copilot CLI，記錄安裝版本、登入帳號和可見的 instructions／skills。
6. 關閉其中一項政策後重開 IDE，確認狀態真的變更，不是目前 session 的快取。

測試結果應至少包含 IDE 與 plugin 版本、組織政策、provider、模型、驗證日期和負責人。遇到「同事看不到功能」時，再用這些欄位分流帳號、方案、政策和 client 版本，不要先要求所有人清除設定。

結論：把 Memory、模型和工具權限各自驗證#

GitHub Copilot for JetBrains 的 8 月更新讓 agent workflow 更容易啟動，也讓治理邊界變多。Memory 要看資料如何保留與驗證；Ollama 要看 provider 和 endpoint；MCP、Codex permission modes 與 CLI 要看工具和寫入能力；企業 managed settings 則要確認誰能控制這些選項。

只要用小型 repository 做一次可回溯測試，就能避免用「model picker 看得到」推論資料安全，也避免用「agent 回答正確」推論它沒有使用超出範圍的工具。

常見問題#