自我改進的工程: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中扮演核心角色,提供從手動提示向自主、自我改進系統演進的橋樑。隨着模型能力增強,線束本身變得越來越智能和自適應,最終可能內化為模型行為的一部分,但與外部世界的接口將持續存在。