Fork 子代理不是優化技巧，是架構決策
Fork 子代理不是優化技巧，而是一個架構決策——它解決 context 膨脹的同時，引入了參數傳遞的新風險。
問題出在「什麼都往主對話裡塞」
大多數開發者在設計 AI agent 的 skill 時，其實沒有真正算過成本。邏輯寫了 74 行，最後只輸出 10 行答案，剩下的 64 行都在消耗主對話的 context 預算。這不是效率問題，這是一個選擇——你選擇了用 context 換簡潔度。
王拐子提到的 fork 子代理模式解決的就是這個選擇的反面。不是所有 skill 都該 inline。有些 skill 天生應該被隔離出去。
成本-收益的分界線在哪裡
這篇文章的價值不在「fork 很牛」，而在它提供了一個具體的決策框架。當你的 skill 滿足這些特徵時，fork 會更划算：
- 邏輯量和輸出量的比例嚴重失衡
- 執行結果不需要立即融入後續對話
- 可以獨立驗證成功或失敗
反過來，如果 skill 的輸出會直接影響下一步對話方向，或者需要實時調整參數，inline 仍然是更好的選擇。
Fork 引入的新問題：參數黑洞
但這裡有個容易被忽視的脆弱點。Fork 解決了 context 膨脹，代價是 subagent 看不到對話歷史。它只能依賴 $ARGUMENTS 顯式傳入的資訊。
當 skill 由使用者手動觸發時還好——你知道要傳什麼參數。但當 Claude 自動決定調用某個 fork skill 時，它必須猜測該傳什麼。這時候傳漏了什麼關鍵資訊，subagent 就會做出錯誤判斷，而主對話看不到執行過程。
所以 fork 的設計重點不在「怎麼拆」，而在「怎麼定義清楚這個 skill 的輸入邊界」。
查詢型和狀態型應該分開設計
素材裡隱含了一個分類框架，但沒有明說。有些 skill 是「查完就走」的——推薦、查表、格式轉換，執行完就沒了。另些 skill 需要維持對話上下文——協作編輯、多步驟調試、漸進式提問。
前者天生適合 fork。後者強行 fork 會讓人工作變得割裂。
實務上應該建立清晰的決策樹：無狀態的查詢型 skill，邏輯量遠大於輸出量的，fork。需要對話記憶的、需要即時調整的、輸出會直接影響下一步的，inline。
這不是工程問題，這是一個架構選擇。選錯了，你省了 context 成本，卻付出了可靠性的代價。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。