自我改進的工程:AI 系統的線束設計
本文探討了遞迴自我改進(RSI)的概念,重點介紹了現代AI系統中“線束”(harness)工程的作用。線束是基礎模型周圍的系統,負責編排執行、管理上下文、呼叫工具和持久化狀態。文章分析了三種設計模式:工作流自動化、檔案系統作為持久記憶體、子代理和後臺作業,並以程式設計代理線束為例展示了具體實現。進一步討論了上下文工程(ACE 和 MCE)以及元線束(Meta-Harness)的最佳化策略,預測了RSI的近期路徑:線束工程將朝著元方法論演進,使線束系統本身成為最佳化目標。
遞迴自我改進(RSI)的概念源自I. J. Good在1965年定義的“超智慧機器”,即一種能在所有智力活動中超越人類並設計出更優機器以自我改進的系統。Yudkowsky在2008年將“遞迴自我改進”具體化為一個反饋迴圈:AI利用其當前智慧來改進產生智慧的認知機制。在現代AI中,這種反饋迴圈可能直接體現為模型重寫自身權重,或更廣泛地,模型改進訓練管道和部署系統,從而催生效能更優的後續模型,在經濟上重要的任務中表現出色。前沿實驗室(如Anthropic和OpenAI)的研究開發速度已呈急劇加速之勢。
顯式提及“部署系統”的原因在於,原始模型與現實世界之間的介面層與模型的原始智慧(即預訓練後的評估)同樣重要。成功的程式設計代理產品(如Claude Code和Codex)展示了線束(harness)作為AI部署關鍵元件的價值。線束是圍繞基礎模型構建的系統,負責編排執行,決定模型如何思考、規劃、呼叫工具、行動、感知和管理上下文、儲存工件以及評估結果。本文將聚焦於線束工程的研究及其對RSI的貢獻,涵蓋自動研究、自我改進代理和進化程式搜尋等領域的工作。
線束設計模式
與早期代理框架(“代理=LLM+記憶+工具+規劃+行動”)相比,線束工程額外包含工作流設計(如迴圈工程)、評估、許可權控制和持久狀態管理。它不再僅僅是提示模板,而是更接近執行時和軟體系統設計:模型如何觀察、行動、記憶、自我檢查並改進。設計應刻意保持簡單和通用,以促進泛化,並借鑑現有軟體工程實踐以受益於預訓練知識。線束與作業系統有強烈類比:應封裝複雜邏輯,同時保持介面簡單。同時,配置、工具介面等協議可能逐步實現行業標準化。
模式1:工作流自動化
定義一個模型可操作、測試和迭代的工作流是自動化的關鍵設計。Karpathy的autoresearch倉庫是一個簡潔示例。常見工作流遵循目標導向的迴圈:規劃、執行、觀察/測試、改進,直至達成目標。過程中可能主動向使用者請求澄清任務規範或執行偏好。簡化的Codex代理迴圈:代理呼叫工具,工具響應影響模型的下一次生成。工作流圖強調模型分析自身軌跡和失敗案例,在“代理執行時”中迭代,而非靜態提示模板。
模式2:檔案系統作為持久記憶體
長週期代理系統中反覆出現的模式是對豐富狀態和工件的簡單控制。線束不應將整個工作流和所有日誌放入上下文,而應將持久狀態儲存在檔案中。在長週期代理部署中,實驗日誌、程式碼差異、論文摘要、錯誤追蹤和過去軌跡等工件常常遠超模型訓練的上下文視窗。學習透過檔案系統(常用bash命令)讀寫和編輯是LLM的基礎技能,因此以檔案形式管理持久記憶體自然受益於核心模型能力的提升。
模式3:子代理和後臺作業
線束可以生成多個子代理並行執行並監控後臺作業。當主代理需要搜尋多個假設、並行執行實驗或委派孤立子任務而不汙染主上下文時,此模式尤其實用。父代理需要一個輕量級程序管理器:啟動作業、檢查日誌、取消失敗任務、將結果合併回主執行緒。關鍵設計是使並行性顯式且可審查。子代理輸出若僅存在於瞬態聊天上下文中,則很快過時且不可見;若儲存為檔案、日誌和狀態記錄,則模型可在中斷後恢復並對其執行歷史進行推理。
案例:程式設計代理線束
主流程式設計代理的核心介面已在Claude Code、Codex、OpenCode和Cursor風格代理中趨於穩定。它們通常使用如下迴圈:
- 工具組定義:檔案系統(發現、讀取、修改)、Shell執行、IO(lsp、git)、外部上下文(MCP、技能)、Web搜尋、工件(讀取文件、生成HTML)、後臺程序(Cron)、代理委派等。
線束層 vs. 核心智慧?
很難預測RSI未來在多大程度上依賴線束工程,但近期路徑不太可能始於模型直接重寫權重。我預測的實用近期路徑是:線束工程將朝著元方法論演進——即改進獲取更好答案的機制,而非僅僅是改進答案本身。線束系統本身成為最佳化目標,減少啟發式規則,增加通用機制。成熟線束使自動研究成為模型自我改進的迴圈,更智慧的模型則防止線束過度工程化,保持系統可持續性。最終,許多線束改進可能內化到核心模型行為中,但與外部上下文和工具的介面應保留。提示工程已展現了這種模式的柔和版本:手動提示技巧隨著指令調整和模型推理改進而變得不那麼核心,但指定目標、約束、上下文和評估的需求並未消失。
線束最佳化
線束系統中被最佳化的物件大致演進為:指令提示 → 結構化上下文 → 工作流 → 線束程式碼 → 最佳化器程式碼。隨著模型變得更智慧、更強大,我們轉向更復雜的目標和更通用的方法。
上下文工程
簡單地將所有工具響應和模型生成追加到上下文會隨代理任務時間增長而迅速失控。上下文管理是為LLM構建更結構化和簡潔上下文並管理持久狀態的一層。長上下文研究會持續進步,但當前長上下文智慧與上下文工程常常交織。
代理上下文工程(ACE; Zhang et al. 2025)將上下文視為不斷演化的劇本,而非不斷加長的提示。它包含三個元件:生成器(產生任務軌跡,引用要點)、反射器(從成功和失敗軌跡中提煉洞察)和策展人(以增量、條目化條目更新結構化上下文)。為防止迭代重寫中的上下文崩潰和簡潔性偏差,ACE的關鍵設計是策展人不會重寫完整提示文本,而是輸出結構化、條目化的要點集合(識別符號,描述),這些要點透過確定性邏輯合併到結構化上下文日誌中,並定期精煉和去重。
元上下文工程(MCE; Ye et al. 2026)將機制(如何管理上下文)與工件內容(上下文中的內容)分離,在元最佳化層面執行技能進化,在基礎層面執行上下文最佳化。MCE不強制執行ACE那樣的啟發式規則,而是使用自由形式的技能儲存任務關鍵知識,並迭代演進技能和技能條件上下文。技能資料庫追蹤歷史技能、上下文函式和評估指標。元級代理執行代理交叉,建立新技能;基礎級上下文工程師執行技能並學習上下文函式。實現中,上下文函式例項化為專用目錄中的檔案集合,包括靜態(skill.md)和動態(上下文和資料回滾)元件。
元線束(Meta-Harness; Lee et al. 2026)將最佳化又提升一層:被最佳化的物件是決定和最佳化哪些資訊應儲存、檢索和呈現給模型的程式碼。其元迴圈最佳化演算法中,提議者負責建立新線束配置,評估者並行評分,進化者透過交叉和變異生成改進版本。該方法將線束設計視為一個可搜尋的空間,使系統能夠自動發現更高效的互動模式。
總之,線束工程在RSI中扮演核心角色,提供從手動提示向自主、自我改進系統演進的橋樑。隨著模型能力增強,線束本身變得越來越智慧和自適應,最終可能內化為模型行為的一部分,但與外部世界的介面將持續存在。