GitHub Copilot 內部架構：上下文注入與會話存儲分析

透過中間人 (MitM) 代理伺服器對 GitHub Copilot 的網路流量進行分析，並結合 VS Code 源碼研究發現，該工具正演進為一個有狀態的系統。它透過結合使用者工作區數據、近期編輯紀錄、對話歷史以及本地 SQLite 資料庫來組裝 LLM 的上下文。

模型路由與發現

GitHub Copilot 使用多階段流程來決定應由哪個模型處理特定的使用者請求。此流程始於引導階段 (bootstrap stage)，在此階段擴充功能會透過 OAuth 進行身分驗證並發現可用模型。

模型發現

Copilot 會發送兩個不同的請求來識別可用功能：

向 /models 發送請求以獲取可用模型的通用列表。
向 /agents/swe/models 發送請求以識別特別適用於代理式軟體工程 (SWE) 能力的模型。

基於意圖的路由

當使用者在「Auto」模式下發送訊息時，Copilot 並不會立即呼叫生成式模型。相反地，它會將提示詞 (prompt) 發送到 /models/session/intent 端點。系統會根據各種意圖（例如 code-gen、debugging、reasoning 和 tool-use）對提示詞進行評分，並利用此分類將請求路由至最適合該任務的模型。

上下文注入與隱私風險

Copilot 提供相關建議的能力取決於它注入提示詞中的上下文。然而，這種機制可能會在無意中洩露使用者目前並未編輯的文件中的敏感數據。

「近期編輯」洩露

Copilot 為上下文實作了滑動窗口 (sliding window)，其中包含最多 20 個文件、8 個編輯摘要以及每個變更周圍的 3 行上下文。由於此窗口會追蹤工作區內的近期編輯，儲存在 .env 文件中的秘密資訊可能會在觸發完全無關文件（例如 pyproject.toml 文件）的按鍵動作中被包含在提示詞內。

缺乏預設的秘密資訊過濾

對 VS Code 源碼的分析證實，在上下文的寫入路徑中，並沒有預設的清理、遮蔽或秘密資訊過濾步驟。雖然 Business 和 Enterprise 方案提供了「儲存庫政策 (repository policies)」來限制某些文件，但個人方案沒有將 .env 文件視為特殊的預設規則，也沒有與 .gitignore 整合以防止敏感文件被發送到 API。

本地狀態與 Chronicle 工具

GitHub Copilot 維護本地狀態以提供跨會話的長期記憶，這是透過一個名為 Chronicle 的工具來實作的。

session-store.db

Copilot 利用名為 session-store.db 的本地 SQLite 資料庫來儲存會話摘要、儲存庫、分支以及使用者提示詞與助手回應的完整歷史紀錄。

明文存儲與工具存取

session-store.db 中的 user_message 和 assistant_response 欄位是以明文形式儲存的。LLM 可以透過一個名為 session_store_sql 的工具來存取此歷史紀錄，這使得模型能夠針對本地資料庫執行 SQL 查詢，以回答有關先前工作的問題（例如：「我這週做了什麼？」）。

對 sessionStore.ts 的源碼分析證實，turn.user_message 是按原樣插入資料庫的，沒有經過任何遮蔽或清理。

技術實作分析方法

為了揭示這些行為，研究人員使用 mitmproxy 來攔截 Electron 架構的 VS Code 應用程式與 GitHub 伺服器之間的 HTTPS 流量。

攔截設置

由於 VS Code 是基於 Electron (Chromium + Node.js) 構建的，可以透過配置以下設置來將流量路由至代理伺服器：

Http Proxy: http://localhost:8080
Http Proxy Strict SSL: 取消勾選（以允許 mitmproxy CA 憑證）。
Http: Proxy Support: 設定為 override 以強制擴充功能使用代理。

其他觀察方法

社群討論建議了其他觀察 Copilot 內部運作的方法：

eBPF: 使用 eBPF 可以直接從線路上擷取原始明文數據，在加密或解密後進行攔截，從而繞過對憑證釘選 (certificate pinning) 或 mTLS 的挑戰。
Agent Debug Logs: VS Code 內建了一個功能，可透過 Copilot 對話選單中的「show agent debug logs」選項來存取，該功能會顯示工具呼叫、提示詞、模型選擇邏輯。

結論：上下文即產品

AI 編碼工具之間的差異化正在從底層模型的原始能力，轉向「框架 (harness)」的複雜度——即組裝正確上下文的系統。主要的工程挑戰現在在於如何平衡上下文密度（保持提示詞精簡且對快取友善）與嚴格的隱私邊界，以確保敏感的開發者狀態不會跨越到模型 API 或明文本地存儲中。