讓多個 LLM 供應商共享一層上下文

Published: at 02:00 PM

我經常在不同的 LLM 供應商之間切換。我可能先在 ChatGPT 裡開始一個想法，再到 Gemini 繼續，之後又回到 ChatGPT。有時候原因很實際：一個供應商的額度用完了，或者另一個供應商剛好有更適合的模型或插件。

真正麻煩的是交接。每個供應商都有自己的對話紀錄、記憶、工具與上下文視窗。把整段對話複製過去不但嘈雜、浪費 token，很多時候也根本做不到。通常真正有用的資訊少得多：我們想完成什麼、已經做了哪些決定、還有哪些不確定，以及下一步應該做什麼。

讓檔案成為中間的橋樑

插件可以讓這件事發生，而不必要求每個供應商都直接理解其他供應商。如果兩個 LLM 客戶端都能存取同一個儲存服務，那個服務就能成為中立的交接層。Google Drive 是一個例子，但 Dropbox、OneDrive、Git repository、共享資料庫，或同步到雲端的本機資料夾，都可以採用同樣的模式。

流程其實很簡單：

  1. 請第一個 LLM 把對話整理成一份小型 Markdown 交接檔。
  2. 透過儲存插件，把檔案放進可預期的共享資料夾。
  3. 開啟第二個 LLM，請它先讀取最新的交接檔再繼續工作。
  4. 當第二個 LLM 做出新決定或改變計畫時，請它更新檔案。

例如，我可以這樣要求：

請把這段對話整理成 ai-handoffs/project-name.md。包含目標、決定、待解問題、相關檔案或連結、限制條件，以及建議的下一步。不要包含秘密或完整對話紀錄。

接著在另一個供應商裡這樣說：

從共享雲端硬碟讀取最新的 ai-handoffs/project-name.md。把它當作目前的工作上下文，指出任何已過時的內容，然後從下一步繼續。如果計畫有變，請更新檔案。

這不是神奇的跨供應商通用記憶，而是兩個助理之間一份刻意整理、可以檢查的契約。這反而是優點。我可以打開檔案、修正內容、刪除它，也可以為不同專案保留不同的交接檔。

為什麼 Markdown 很適合

Markdown 便於攜帶、容易閱讀、可以比較差異，而且幾乎所有 coding 與寫作工具都支援。交接檔不需要很複雜：

# 專案交接

更新日期：2026-08-11
狀態：探索中

## 目標

描述我們想達成的結果。

## 已做決定

- 記錄沒有新證據就不應重新討論的選擇。

## 待解問題

- 記錄不確定性，以及可以解決它的人或資料來源。

## 有用上下文

- 連結、檔名、限制條件與相關資料。

## 下一步

下一個助理或人類最適合執行的最小行動。

重要的是「帶有意義的壓縮」。交接檔應保留意圖與狀態，而不是每一句對話。適當時也應記錄來源：哪份文件、哪個 repository 或哪個決定支持這項結論，以及資料最後確認的時間。

把知識留在自己手上

共享的上下文層不必永遠放在某個供應商的工作區裡。它可以成為個人知識庫的一部分：筆記資料夾、Markdown vault、Git repository，或由你自己控制的儲存系統。雲端硬碟插件可以負責傳輸與同步，但不應該成為知識唯一存在的地方。

選擇儲存服務時，應該先確認能否匯出原始 Markdown 與中繼資料、搬到另一個供應商、在沒有插件的情況下讀取，以及從備份還原。誰控制存取權限、保存期限與刪除？方便的整合很有用，但開放且可攜的來源檔案，才是避免被第三方綁住的保障。

同一種方法也適用於 coding agent

這不只是切換 ChatGPT 與 Gemini 時的應急做法。本機 coding agent 也可以使用同一個共享資料夾。Coding harness 可以把 handoff.md、decisions.md、current-state.md 或簡短的任務摘要寫入一個會同步到雲端的目錄。另一個 agent，甚至另一台機器，就能從這些檔案接續工作。

這會在終端機、編輯器、雲端助理與本機模型之間，形成一層輕量的連續性。Agent 仍然需要被明確要求讀取相關檔案；檔案不會自動成為它的上下文。但提示詞可以變得很短而且容易重複：「讀取目前的專案交接檔，檢查 repository，然後從檔案記載的下一步繼續。」

當長時間任務超過單一工作階段的生命週期時，這尤其有用。對話可以結束，但專案狀態仍然保留。一個新的 agent 不必先重建整段歷史，才有辦法開始產生進度。

幾個重要的界線

共享上下文應該被視為工作文件，而不是未經篩選的記憶傾倒。不要放入憑證、私鑰、個人資料，或任何下一個供應商不應看見的內容。使用可預期的命名方式，記錄更新時間，並分清楚已確認的事實與猜測。在協作情境中，重要變更也應記錄是哪個助理或哪位人員做出的。

最重要的是，交接必須是明確的。使用者應該決定哪些內容值得帶到下一個工具。插件提供連線，但小型共享檔案提供界線。這道界線可以減少切換工具時的「上下文宿醉」，同時讓上下文在不同供應商之間保持可攜、可檢查，而且真正有用。