OpenAI 研究人員建議不要過度構建 Agent 框架 — 未來模型可能會將這些能力內部化
目錄
你可能想知道的事
1. 如果下一代模型獲得目前透過外部 harness 實現的能力，團隊應如何優先分配工程精力？
2. 依賴框架工程與押注模型快速進步之間存在哪些權衡？
主要議題
OpenAI 研究科學家 Noam Brown（o 系列推理模型的重要貢獻者）公開建議開發者避免把過多精力投入到構建複雜的 Agent harness 上——這些外部框架負責工具整合、步驟拆解以及模型周邊的協調。Brown 的核心觀點很務實：模型能力正在迅速提升，今天被工程化到 harness 中的許多功能，可能在數月內成為下一代模型的原生能力。當那時候到來時，投入在穩健框架的大量工程工作可能產生邊際遞減，甚至變得多餘。
Brown 的建議根植於對推理模型演進的經驗。在專門的推理模型出現之前，開發者常須在通用模型周圍構建複雜的外部流程——將任務拆成微步驟、協調工具調用，並將輸出重新作為上下文回饋，以誘導期望的推理行為。隨著能在測試時執行更深入模型內推理並更複雜地使用計算資源的 o 系列模型出現，許多手工設計的變通方案失去效用。在某些情況下，移除繁複的支架，讓推理模型直接處理問題反而產生更好的結果。
OpenAI 企業產品負責人 Alexander Embiricos 也表達了類似立場。他觀察到，當工程團隊費力去實現那些很可能落在未來模型學習範疇內的功能時，這些努力可能等於預先構建出模型日後會內化的功能。Embiricos 建議採取保守做法：保持 harness 精簡，並在合理情況下將責任轉移給模型，避免團隊在可能被模型進步取代的能力上浪費開發週期。
此觀點與社群中一部分激烈主張相左，後者認為框架設計是可防禦的核心資產。支持者主張上下文工程、工作流程設計與穩健的協調是產品差異化的關鍵。LlamaIndex 創辦人 Jerry Liu 簡潔地總結了這種觀點：「框架就是一切。」他與其他人指出有實證證據顯示，在不更換底層模型的情況下，改進框架能帶來實質的性能提升。例如，一項在 2026 年初報告的實驗顯示，調整一個 harness 數小時就能同時提升 15 個不同大型語言模型的程式碼撰寫表現，證明框架工程可以釋放多個模型的潛在能力。
雙方都提出了真實結果。框架支持者強調，許多部署的 Agent 都會收斂到一個重複的操作模式：調用工具、檢索結果、將該資訊加入上下文，然後再次詢問模型。這個重複循環意味著仔細設計控制迴路與上下文處理，可能構成實際的產品價值。換言之，雖然模型能力很重要，但管理互動、錯誤處理、快取、重試與上下文構建的包裝層，能顯著影響面向使用者的效能與可靠性。
這場辯論的核心是策略性的押注：你是押注模型持續改進，還是建構專有的框架專長？這呼應了 AI 研究中的一個長期教訓，常被稱為「苦澀教訓」：擴大計算與通用學習的方法，從長期來看往往勝過依賴大量人為設計的啟發式方法。大量投資於人工工程化 harness 的開發者，隱含地押注下一代模型不會吸收那些工程化行為。如果他們錯了，工程投入可能成為沉沒成本；如果他們是對的，這些 harness 可以提供持久且有防禦性的價值，跨越模型升級仍然有效。
對於評估應將精力配置到哪裡的團隊，有一些實際的折衷做法。一是將 harness 設計為模組化且精簡：將那些模型不太可能快速學會的元件隔離（例如系統層級整合、專有商業邏輯與合規控制），並避免過度規格化模型很可能能處理的部分（例如創意式拆解、靈活的推理步驟或臨時串接的子任務）。另一種做法是實施快速迭代週期並持續對新模型進行 A/B 測試，讓團隊能夠及早發現模型升級何時使某個 harness 元件變得多餘。
OpenAI 的內部訊息直言不諱：構建僅僅支撐模型當前限制的支架，可能是「強硬支撐，而非可擴展的增強」。當工程資源受限且產品時程緊迫時，這一觀察最為相關。然而，這並不普遍否定 harness 的價值。需要嚴格可稽核性、可重現性或精確工具協調的用例，在可預見的未來仍可能從穩健的外部框架中受益。因此建議的立場是有細微差別的：偏好簡單性、優先考慮長期存在的整合，並保持 harness 的可調整性，以便隨著模型能力演進能夠簡化或退役。
總結來說，討論不是要全盤否定框架，而是要認識到一個不斷移動的前沿。隨著推理模型持續改進，曾經只能透過複雜 harness 工程實現的功能，可能會成為模型的內部能力。開發者與產品團隊應從短期效用與長期過時風險兩個角度評估投資，保持 harness 模組化，並採用快速驗證迴路來決定是投資框架複雜性還是信任模型承擔更多責任。
重點洞見表
| 面向 | 說明 |
|---|---|
| 專家建議 | 保持 harness 簡單；避免對那些可能成為未來模型原生能力的功能進行過度工程化。 |
| 理由 | 模型能力正在快速提升；外部支架有可能在數月內變得多餘。 |
| 反論 | 框架工程能顯著提升跨模型的性能，並可能是產品的核心價值。 |
| 實證證據 | 一次僅限 harness 的短期改進據報告在一個下午內提升了 15 個大模型的程式碼表現。 |
| 策略性權衡 | 押注模型進步（過時風險）與建構可防禦的框架功能（被超越的風險）。 |
後續…
展望未來，團隊應密切關注模型發布並持續重新評估 harness 的投資。對許多企業來說，務實的路徑是將短暫且依賴模型的支架與長期存在的系統整合分離，維持模組化的 harness 設計，並以快速實驗來判定何時簡化或退役外部協調。harness 優先還是模型優先的辯論反映了關於產品策略、工程優先順序以及如何在模型能力加速提升的時代構建持久價值的更深層問題。最終，能在工程選擇上保持適應性與以數據為導向的組織，將最有利於同時受益於穩健框架與進步中的模型。
常見問題
- 什麼是 AI Agent harness？ — harness 是在模型周圍的外部流程，負責處理工具調用、步驟排序、重試與上下文管理，而非執行核心推理本身。
- 為何建議避免大量投入 harness？ — 因為快速的模型改進可能會內化許多由 harness 提供的功能，使大量工程投資可能變得浪費。
