編排模式(Orchestration) 是Harness中"上下文與工具"層面的組織方式 -- 它決定上下文如何在LLM調用之間流動、工具如何被調度，以及Agent的執行路徑是預先設定還是動態生成。AI Agent系統的編排方式經歷了從簡單到複雜的演進過程，每種模式都有其適用的場景和相應的取捨。根據Anthropic與數十個團隊合作建構LLM Agent的經驗，最成功的實現往往不是複雜的框架，而是採用簡單、可組合的模式。

建構LLM應用時，應遵從"從簡單到複雜"的原則：首先考慮單個LLM調用(如果簡單任務使用多模態Agent完全沒必要且浪費資源)。如果通過優化prompt和上下文示例就能解決問題，就不用引入Agent系統。當需要多步驟處理時，對於可以清晰分解為固定子任務的場景，考慮使用工作流(work flow)。只有當需要動態決策和靈活的執行路徑時，才使用自主Agent。需要記住的是：Agent系統通常會用延遲和成本換取更好的任務性能，應該謹慎思考並權衡這種交換是否值得。

一個常見的反面例子，是一開始就建構一個非常複雜的工作流或多Agent系統。例如為："從百萬條聊天紀錄中提煉個人記憶"設計Agent，一些AI 模型很容易迅速畫出一條看似嚴謹的流水線：先切分對話片段，在依次安排提取、證據驗證、身分解析、記憶整理和合併覆核Agent，最後建立事實圖、覆蓋帳本和不可變版本。每個部件單看都很有道理(看得出來嗎0.0)，組合起來其實非常低效、不可靠的。因為複雜工作流的執行拓樸是固定的，遇到新的例外，系統容易繼續增加節點，架構越來越複雜，通用性卻越來越差。模型原本可以根據上下文處理的語意判斷，反而被工作流寫死了。

因此，Harness很重要，不等於Harness越複雜越好。Manus官網用"Less structure, more intelligence." 概括這種取捨：先給一個能力足夠的Agent清晰的目標，必要的上下文和可組合的工具，用自然語言告訴它如何向人一樣查證、比較、處理衝突;程序固化權限、不得覆蓋原始材料、原子發布等必須始終成立的邊界。只有業務約束本身要求，或評估反覆暴露出某種穩定失敗時，才把對應步驟升級為專門的驗證器、獨立Agent或確認性流程。好的結構不是替Agent預演全部思考，而是守住邊界，並把邊界內的決策空間還給模型。

目前可用的模型評比網站(記得點擊leaderboard)，Hugging face的已經停止更新
閉/開源模型評比 Arena AI： https://lmarena.ai/

開源模型評比 vellum： https://www.vellum.ai/open-llm-leaderboard