用 fork 代理處理查詢，主對話的 context 才能真正輕下來
fork 代理執行查詢 skill，讓主對話的 context 預算回歸推理本身——這是一個被低估的 context 優化思路。
問題的本質
LLM 應用裡，context 成本是實打實的約束。每多一個 turn，token 消耗就多一份。但更隱形的成本是：主對話的 context 被查詢邏輯污染了。
常見做法是在主對話裡嵌入查詢 skill——搜索資料庫、呼叫 API、整理結果。看起來流暢，實際上每次查詢都在擠佔主對話的推理空間。到了後期 turn，模型要同時處理對話歷史、查詢結果、業務邏輯，context window 就開始吃緊。
fork 代理的邏輯
王拐子提出的做法很直接：查詢型 skill 不在主對話裡執行，而是 fork 出一個獨立的代理去跑。
這意味著：
- 主對話保持純淨，只關注推理和決策
- 查詢代理有自己的 context 預算，互不干擾
- 查詢結果以結構化形式回傳給主對話，而不是原始的 LLM 生成文本
具體場景是這樣：用戶問「我上個月的訂單狀態」。主對話識別出這是查詢 skill，fork 一個專用代理去資料庫查詢、格式化結果。主對話只需要消化這個結構化的結果，然後生成回答。
為什麼這個方向對
我一開始的反應是：這不就是 tool use 嗎？區別在於粒度和隔離。
傳統 tool use 是同步的——主對話暫停，等工具回傳，再繼續。fork 代理是非同步的獨立執行，主對話和查詢可以各自優化。更重要的是，查詢代理可以用更輕量的模型，甚至根本不用模型——直接 SQL 查詢就行。
這樣做的好處不只是成本。查詢邏輯從主對話分離出來，意味著你可以單獨測試、單獨優化、單獨版本控制。主對話的 prompt 也變得更簡潔，推理品質反而會提升。
實踐上的考量
fork 代理聽起來簡單，實際執行要想清楚幾個點：
- 何時 fork——需要一個清晰的觸發規則。不能每個 turn 都 fork，也不能誤判。
- 結果格式——查詢結果怎麼結構化、怎麼傳回主對話，這決定了主對話能不能有效利用。
- 失敗處理——查詢代理超時、查無結果、格式錯誤，主對話要怎麼應對。
我沒看到王拐子給出完整的實現細節，所以這個方向的成熟度還要驗證。但思路本身是對的——context 成本的優化，不在於壓縮單個 turn，而在於重新設計執行流程。
另一個角度
這個做法也反映了一個更大的轉變：從「讓 LLM 做所有事」回到「讓 LLM 只做它擅長的事」。查詢資料庫，LLM 其實不擅長。讓專用代理去做，LLM 專注推理，各司其職。
這不是技術退步，反而是架構成熟的信號。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。