一切皆在調度框架：如何優化你的 AI 調度配置

工程師們過去爭論的是 IDE，如今爭論的是調度框架（harness）。調度框架的本質是一個圍繞大語言模型（LLM）的循環：while (have next message) do {tool}。一個流暢的調度框架能夠極大地提升代碼生成的速度和質量。

本文總結了優化調度框架的三個通用模式，這些模式仍然需要人工判斷來執行。

保持 .md 文件精簡且由人工編寫

LLM 存在“指令預算”限制——前沿模型只能遵循幾百條指令，之後便會進入“遲鈍區”。過多的指令實際上會鼓勵模型產生幻覺。全局系統提示（如 CLAUDE.md 或 AGENTS.md）應由人工編寫，而非由 LLM 生成。ETH 的研究發現，LLM 生成的系統提示會降低性能，同時增加約 20% 的推理成本。描述項目的核心要求和最終用户即可，每個 token 都應爭取其存在的價值。不要試圖將所有規則都塞進提示中；相反，採用漸進式信息加載：僅在需要時讓智能體拉取上下文，並通過描述性文件名讓智能體知道有哪些可用信息。

對於 CLI，智能體可以通過運行 --help 發現子命令，而不是將所有文檔都加載到上下文中。這對於模型從未見過的自定義內部工具尤為重要。技能（Skills）方面，行業已趨於一致：啓動時只加載名稱和描述，完整指令僅在智能體決定需要時才讀取。MCP 工具同樣需要選擇性連接項目相關的服務器，並編寫具體且關鍵詞豐富的描述，以便基於搜索的發現機制能正常工作。

使用 R.P.I. 框架提升抽象層次

HumanLayer 提出的 R.P.I. 框架是一種有用的指導原則：每個提示在與調度框架交互時都應只做三件事之一：研究（Research）、規劃（Plan）、執行（Implement）。研究階段讓智能體探索代碼庫結構，但不採取行動；規劃階段生成分步驟的執行計劃，人工需主動審查；執行階段在一個新的上下文窗口（主窗口）中按批准的計劃實施。如果計劃較長，可使用子代理模式，每個子代理有自己的會話，避免中間狀態污染主上下文。

使用子代理維護乾淨的上下文

核心啓發式原則是：當主智能體只需要子代理的工作總結時，就應該使用子代理。兩種模式效果良好：並行扇出和流水線。並行扇出適用於調查和研究，例如當警報觸發時，主智能體可以生成三個候選根因理論，並分別為每個理論啓動一個子代理並行調查。流水線則通過順序角色（如 UX 設計師、架構師、反對者）對功能進行多角度評估，每個階段接收前一階段的輸出並添加分析。子代理不僅保持主對話乾淨，還將子代理自身保持在“聰明區域”，無需承載無關的早期信息。

結論

當調度框架在某個任務上失敗時，很容易想切換框架。本文並非建議不體驗各種工具，而是強調需要花時間真正適配一個框架到自己的工作流程中。不同框架有不同的約束、上下文窗口策略和工具路由邏輯；頻繁切換意味着喪失配置文件中的機構知識，並從零開始積累失敗案例。因此，建議選擇一個覆蓋團隊大部分用例的框架（後續文章將討論如何選擇），並將每次失敗視為數據點：記錄在什麼條件下哪個步驟出了什麼問題，並相應調整 .md 文件和提示詞策略。最好的調度框架是通過人工工程持續定製和迭代的框架。