Autogenesis：一種自我演化的智慧代理人協定
近年來，基於大型語言模型（LLM）的智慧代理人系統在處理複雜、長期的任務上展現了極大的潛力。然而，現有的代理人協定（例如 A2A 和 MCP）在跨實體的生命週期與上下文管理、版本追蹤，以及演化時的安全更新介面等方面規範不足，這常導致系統傾向於單體式架構，並產生脆弱的膠水程式碼。為此，我們提出了 AUTOGENESIS 協定（AGP），這是一種自我演化協定，將「什麼東西在演化」與「如何進行演化」徹底解耦。其「資源基底協定層」（RSPL）將提示詞、代理人、工具、環境與記憶體建模為具有明確狀態、生命週期與版本化介面的協定註冊資源。而其「自我演化協定層」（SEPL）則定義了一個閉迴路運算子介面，用於提出、評估與提交改進，並具備可稽核的譜系與回溯機制。基於 AGP，我們進一步提出了 AUTOGENESIS 系統（AGS），這是一個自我演化的多代理人系統，能夠在執行期間動態實例化、檢索與精煉協定註冊的資源。我們在多個需要長期規劃與跨異質資源使用工具的挑戰性基準測試上評估了 AGS。結果顯示，相較於強大的基線模型，AGS 持續取得顯著的進步，這驗證了代理人資源管理與閉迴路自我演化的有效性。
1. 緒論：從靜態執行到動態適應
基於大型語言模型的代理人系統在處理複雜、長期任務方面已展現巨大潛力。然而，面對真實世界環境的多樣性與隨機性，靜態的代理人設計往往顯得力不從心。為了克服這個限制，賦予代理人自我演化的能力——讓它們能夠根據環境反饋自動調整策略、精煉指令並更新工具——已成為實現穩健自主性的關鍵途徑。這種從預定義執行到動態適應的轉變，代表了代理人系統設計的根本性典範轉移。
儘管對自我演化代理人的興趣日益濃厚，但目前的實作方式多半是碎片化且臨時性的。現有系統通常缺乏共享標準，使得演化過程既不可組合也無法稽核。開發者經常被迫依賴脆弱的膠水程式碼，導致系統架構龐大且難以維護。此外，若缺乏明確的生命週期管理與安全更新介面，自我修改將會引入極大的執行時期不穩定風險。為了解決這些問題，我們必須將開發層級從臨時的工程實作提升到協定層級，透過標準化框架將「什麼在演化」與「如何演化」解耦，以確保演化過程是模組化、可追蹤且安全的。
雖然像 Anthropic 的模型上下文協定（MCP）與 Google 的代理人對代理人（A2A）協定已經標準化了連接性，但若將它們直接應用於自我演化場景，會產生概念上的不符。這些協定主要設計用來解決連接挑戰——特別是模型與工具的呼叫（MCP）或代理人之間的通訊（A2A）。然而，自我演化的核心不在於呼叫，而在於狀態的突變與管理。
現有的連接協定缺乏對實體生命週期與版本譜系的原生支援。在閉迴路演化系統中，如果元件的建立、更新與銷毀未被精確定義，最佳化器就無法安全地套用修改。此外，缺乏版本追蹤與回溯機制意味著錯誤的更新可能導致無法挽回的錯誤。因此，單靠通訊協定是不夠的；我們需要一種能夠管理突變動態的新協定。
為了彌合從連接到演化之間的鴻溝，專門的協定必須解決三個核心問題：
解耦：提示詞、工具與記憶體等資源必須從代理人的核心邏輯中抽象出來，將它們轉化為被動的、獨立管理的實體，而非緊密耦合的程式碼區塊。
安全性與可稽核性：必須引入嚴格的版本控制與回溯機制，以確保每個演化步驟都是可追蹤且可逆的。
形式化：需要定義一組標準化的運算子（例如：反思、提出、驗證）來嚴格管控演化過程，將啟發式的文字修改轉化為嚴謹的控制迴路。
為了應對這些挑戰，我們提出了 AUTOGENESIS。它不僅僅是一個工具庫，而是一個雙層協定架構，旨在嚴格地將演化基底與演化邏輯解耦。我們的核心動機是標準化底層資源的表示方式，讓相同的核心演算法能夠無縫地應用於多樣化的代理人元件上。
第一層：資源基底協定層（RSPL）。此層定義了演化的基底，將提示詞、代理人、工具、環境與記憶體建模為協定註冊的資源。RSPL 賦予這些資源明確的狀態、生命週期與版本化介面，使其成為可供觀察與操作的標準化物件。
第二層：自我演化協定層（SEPL）。此層建立在控制理論的基礎上，建立了一個閉迴路的運算子介面。它定義了原子操作——反思、選擇、改進、評估與提交——以正式執行演化循環，確保每次自我修改都被記錄下來並遵守嚴格的安全約束。
基於此協定，我們提出了 AUTOGENESIS 代理人，這是一個結合推理與行動的工具呼叫代理人。它不依賴硬編碼的元件，而是在執行期間透過協定介面動態實例化、檢索與精煉資源。我們在包含 GPQA、AIME、GAIA 與 LeetCode 等多個挑戰性基準測試上評估了此系統。結果顯示，透過標準化資源管理與閉迴路演化，AUTOGENESIS 代理人相較於強大的基線模型持續取得顯著的進步。
這項工作的意義超越了效能的提升；它展示了從手動提示詞工程邁向自動化協定工程的可能典範轉移。透過賦予代理人標準化的自我修復與演化能力，AUTOGENESIS 為建立能夠在複雜環境中持續自主適應的下一代代理人系統提供了基礎架構。
2. 相關工作
2.1 基於 LLM 的代理人系統與工具使用
基於大型語言模型的代理人系統已展現出解決需要多步推理與外部工具互動的複雜、長期任務的能力。在這些系統中，LLM 通常作為中央決策模組，負責解讀觀察結果、分解任務並呼叫工具來影響環境。然而，大多數現有的代理人框架將提示詞、工具與記憶體視為緊密耦合的內部元件，這限制了系統性的重複使用與受控的適應能力。相較之下，我們的方法將工具（包含原生腳本、MCP 工具與代理人技能）建模為具有明確介面與狀態表示的協定註冊資源，從而實現了執行期間的動態實例化與受控精煉。
2.2 連接性與互通性協定
隨著代理人系統規模與複雜性的增長，出現了許多協定層級的努力來標準化模型與工具的互動及代理人之間的通訊。Anthropic 的 MCP 提供了連接語言模型與外部工具的統一介面；Google 的 A2A 協定則旨在標準化多代理人協作的通訊原語。然而，這些協定主要解決的是呼叫與訊息傳遞層級的互通性，它們並沒有定義管理資源生命週期、追蹤版本譜系或約束狀態隨時間突變的機制。因此，連接協定雖然簡化了整合，但無法直接支援自我修改系統所需的持久狀態演化。
2.3 自我修正與最佳化機制
另一條平行的研究路線探討了讓代理人透過自我修正與最佳化來提升效能的機制。例如 TextGrad 將自然語言反饋視為類似梯度的訊號，從而對提示詞等字串值元件進行迭代更新；強化學習方法如 Reinforce++ 與 GRPO 則將代理人元件視為策略，並使用評估訊號作為獎勵來引導最佳化。雖然這些方法證明了代理人行為可以被迭代改善，但它們通常缺乏管理異質代理人元件的共享抽象，且更新往往沒有明確的生命週期控制或版本追蹤。AUTOGENESIS 提供了協定層級的抽象，將代理人元件暴露為標準化的可演化資源，並定義了運算子層級的介面，讓不同的最佳化方法可以在受控的環境下應用。
2.4 總結
現有關於代理人系統、互通性協定與自我最佳化的工作已為自主行為奠定了重要基礎。然而，這些努力並未提供管理代理人內部資源持久狀態演化的統一協定。AUTOGENESIS 透過引入雙層協定架構，將可演化資源的定義與管控其演化的機制分離，填補了這一空白，實現了多代理人系統中模組化、可追蹤且可稽核的自我演化。
3. Autogenesis 協定詳解
我們提出了 AGP，一個雙層自我演化協定。資源基底協定層（RSPL）定義了可演化的基底，即哪些資源可以改變以及它們如何被表示、版本化與存取；自我演化協定層（SEPL）則定義了演化邏輯，即更新如何透過安全的運算子介面被提出、評估與提交。這種分離清晰地將「什麼在演化」與「如何演化」解耦，實現了跨元件的模組化、可追蹤與安全演化。
3.1 第一層：資源基底協定層（RSPL）
RSPL 將可演化基底定義為一組具有明確狀態、生命週期與版本譜系的協定註冊資源。這些資源包含：指令（提示詞）、決策策略（代理人）、驅動介面（工具，包含原生腳本、MCP 工具與代理人技能）、任務/世界動態（環境），以及持久狀態（記憶體）。重要的是，RSPL 中的資源是被動的：它們不包含任何最佳化邏輯，也無法自我修改；所有的觀察與狀態轉換僅透過高層級呼叫的受控介面操作來發生。
為了支援資源的註冊、統一管理與實例化，RSPL 為每個資源實例儲存了一個可序列化的註冊記錄。這包含了資源的實體元組、版本字串、實作描述符（例如匯入路徑或原始碼字串）、實例化參數，以及一組供 LLM 互動的匯出表示（例如函式呼叫框架或自然語言文字）。
此外，RSPL 將每個實體類型綁定到一個專用的上下文管理器與伺服器暴露介面。上下文管理器維護了資源集合與版本譜系，並實作生命週期與更新操作；伺服器介面則封裝了管理器，並透過委派請求給對應的管理器例程來暴露統一的外部介面。上下文管理器支援合約生成，產生合併的能力與約束規範，這提供了穩定且最新的描述，能提高可靠性並減少提示詞膨脹，實現系統性的上下文工程。
3.1.2 基礎設施服務
RSPL 進一步包含了支援可靠演化的跨領域服務：
模型管理器：統一的模型 API 層，標準化了跨供應商的呼叫，同時支援路由、備援與成本感知選擇。
版本管理器：維護每個資源的版本譜系，支援回溯、分支與差異比對。版本是自動遞增的識別符，引用不可變的設定記錄快照，以確保可稽核性與可重現性。
動態管理器：處理資源設定的序列化或反序列化，支援執行時期的安全熱抽換，無需重啟代理人系統。
追蹤器模組：捕捉細緻的執行追蹤（輸入、輸出、中間決策、工具互動等），用於可解釋性、除錯，並作為資料集合成與回溯改進的訓練訊號。
3.2 第二層：自我演化協定層（SEPL）
SEPL 為代理人系統的演化建立了控制理論的形式化基礎。它將代理人系統的持續改進概念化為定義在異質狀態空間上的廣義最佳化問題。形式上，SEPL 將演化動態建模為由嚴格型別運算子代數控制的狀態轉換函數。透過標準化的 RSPL 介面調解所有狀態突變，協定保證了演化是可追蹤、可逆且建構時即安全的。
3.2.1 可演化變數
為了從啟發式適應過渡到系統性的演化協定，我們引入了「變數提升」的概念。這種抽象將離散的、異質的 RSPL 資源（例如工具程式碼、系統提示詞）投射到可演化變數的統一表示上。這不僅均勻化了演化運算子的互動表面，還透過明確的可學習性遮罩嚴格劃分了可訓練的子空間。
3.2.2 運算子代數
為了將演化軌跡形式化為嚴格的控制過程，我們將狀態轉換函數分解為對應迭代最佳化典型階段的原子操作：觀察、歸因、提案、驗證與提交。我們定義了五個運算子：
反思：橋接原始觀察與最佳化方向之間的鴻溝。它將高維度的執行追蹤對應到變數空間中特定的因果失敗假設，近似系統的「語義梯度」。
選擇：作為生成策略，將診斷假設轉化為具體的更新提案，取樣旨在最小化識別出錯誤訊號的候選修改。
改進：突變運算子，透過標準化的 RSPL 介面應用離散更新，產生暫時的候選狀態。
評估：作為目標函數，將候選狀態與目標規格對應到評估空間（包含量化分數與嚴格的安全不變量）。
提交：作為條件閘門機制，利用評估訊號來管理狀態轉換，僅在滿足特定成功標準時才接受候選狀態，嚴格執行安全不變量與效能單調性。
3.2.3 演化循環
上述定義的原子運算子被編排成一個嚴格的閉迴路過程。從初始狀態開始，SEPL 迭代地執行系統以生成觀察追蹤，推導因果失敗假設，並合成修改原語。關鍵的是，這個循環透過評估空間與提交運算子來閉合。這確保了自我演化不是隨機漫步，而是一條有向軌跡，它基於執行資料，可透過版本化更新追蹤，並在嚴格定義的安全不變量下單調改進。
4. AGS 系統架構與最佳化策略
本節介紹了 AGP 協定的具體實例化，展示了其作為自我演化代理人系統的實用性。
4.1 AGS 架構
基於 AGP，我們將雙層協定實例化為 AGS，這是一個圍繞「代理人匯流排」架構組織的自我演化多代理人系統。AGS 使用共享訊息匯流排作為中央協調骨幹：所有代理人僅透過標準化的匯流排訊息進行通訊，實現了鬆散耦合、透明的可觀察性與並行的子代理人執行。系統透過三個交織的機制運作：
透過計畫生成進行編排：接收到任務後，編排器僅負責規劃與協調，產生結構化的計畫，記錄任務分解與子任務分配。此計畫被註冊為版本化的 RSPL 資源，使協調結構本身也可被檢查與演化。
並行子代理人執行與迭代重新規劃：子代理人獨立從 RSPL 註冊表中檢索相關資源，執行工具呼叫並將中間結果寫入共享記憶體。編排器收集輸出並決定是否需要進一步分解任務。此外，AGS 也支援「代理人即工具」的組合模式，讓子代理人可以被包裝在標準 RSPL 工具框架後面直接呼叫。
自我演化：當觀察追蹤顯示可修正的失敗或次優效能時，AGS 會觸發 SEPL 演化循環。代理人反思執行追蹤、選擇修改提案、應用候選更新、評估效能，並提交接受的修改作為版本化轉換。失敗的演化嘗試會被回溯，成功的則立即供後續匯流排回合使用。
4.2 實例化最佳化器
AGP 協定與特定的最佳化策略無關：任何符合五運算子 SEPL 介面的程序都可以作為演化引擎。
反思最佳化器：我們實驗中的預設最佳化器透過自然語言反思實作 SEPL 循環。給定執行追蹤與目前可演化狀態，反思運算子提示骨幹 LLM 分析失敗並生成結構化診斷假設。選擇運算子將假設轉化為修改提案，改進運算子透過 RSPL 介面應用提案，評估運算式重新執行任務並比較效能，最後提交運算子僅在效能改善或安全不變量保持時接受更新。
替代策略：除了反思，我們的實作也支援 TextGrad（將自然語言反饋視為文字梯度並應用類似梯度下降的更新）與 Reinforce++ / GRPO（採用強化學習視角，將可演化變數視為策略，評估訊號視為獎勵）。這些策略證明了 SEPL 運算子代數足夠通用，能在統一協定內容納推論時期的文字最佳化與基於梯度的參數更新。
5. 實證研究
我們在多個挑戰性基準測試上部署 AGS，以展示其全面能力。
5.1 科學與數學基準測試實驗
為了驗證基於 AGP 協定的自我演化代理人 AGS，我們在 GPQA-Diamond、AIME24 與 AIME25 上進行了實驗，重點關注提示詞與代理人輸出的演化。我們比較了三種演化策略：僅演化提示詞、僅演化解決方案，以及兩者合併演化。
結果揭示了四個關鍵觀察：
弱模型獲益更多；強模型獲益較少：效能較弱的模型由於基線較低，具有更大的改進空間，因此透過演化獲得的相對提升更大；而效能較強的模型已接近天花板，改進幅度較小。
合併演化優於單一演化：在所有模型中，同時演化提示詞與解決方案一致地產生了最佳分數，這表明指令精煉與解決方案精煉解決了互補的失敗模式。
數學基準測試比科學問答反應更強烈：AIME 展現了比 GPQA 更大的相對增益，因為長期的符號推理暴露了更多反思可以針對的中間失敗點，而閉卷科學問答更多依賴事實回憶。
天花板效應限制了飽和基準上的演化：當模型在基準上已達到極高準確率時，演化帶來的增益微乎其微。
總結來說，AGS 在各種模型能力與基準測試中都帶來了一致的增益。合併演化策略始終優於單一策略演化，且數學基準測試比科學問答更能從迭代精煉中受益。
5.2 通用代理人基準測試實驗
在 GAIA 測試中，我們專注於工具的演化，因為 GAIA 任務主要依賴工具能力而非純粹推理。我們的系統架構包含頂層規劃代理人與多個專業子代理人（深度研究員、瀏覽器使用代理人、報告代理人、工具生成器與深度分析器）。
結果顯示了三個關鍵觀察：
AGS 達到了最先進的效能：平均得分 89.04%，超越了所有公開排行榜的項目，特別是在最難的 Level 3 上取得了 81.63% 的高分，證明演化驅動的適應性在任務複雜度最高的地方提供了最大的增益。
工具演化在困難任務上產生巨大收益：相較於基線，演化工具整體提升了 12.6%，且難度越高增益越大，Level 3 的增益高達 33.3%，這表明當任務需要靜態工具包無法涵蓋的複雜多步工具鏈時，工具演化特別有效。
分層資源管理減輕了規劃複雜性：透過將提示詞、工具與環境視為具有明確生命週期管理的 RSPL 資源，AGS 保留了跨代理人邊界的會話關鍵狀態，減少了上下文遺忘。此外，規劃代理人可以呼叫工具生成器動態合成特定功能，繞過了靜態工具包的固定能力瓶頸。
5.3 演算法程式設計基準測試實驗
我們建構了一個 LeetCode 多語言程式設計基準，以評估可執行程式碼在推論時期的自我演化。我們收集了最近發布的 100 道測試題目，以減輕訓練資料污染的影響，並在五種語言（Python3、C++、Java、Go、Kotlin）中進行評估，比較單次生成與具備 3 輪修正預算的自我演化代理人。
結果揭示了四個關鍵發現：
自我演化一致地提高了所有語言的通過率：相對通過率提升範圍從 10.1%（Python3）到 26.7%（Kotlin），編譯語言受益最大。編譯錯誤、執行時期錯誤等阻斷性錯誤顯著減少。
演化提高了執行時期效率，但記憶體影響好壞參半：所有語言的平均執行時間均有所下降，特別是編譯語言下降了 19.8% 至 46.4%。然而，記憶體使用在某些語言中略有增加，可能是因為演化代理人引入了輔助資料結構以確保正確性或提升速度。
演化後的解決方案在與人類提交的比較中變得更具競爭力：在編譯語言中，執行時間擊敗率與記憶體擊敗率均有顯著提升，表示與人類提交相比，競爭力持續提高。
推論內軌跡揭示了複利改進動態：軌跡層級分析顯示，隨著任務累積，演化代理人與基線代理人之間的差距不斷擴大而非停滯，這表明反思驅動的最佳化器在整個評估過程中持續發現可修正的失敗模式。
總結來說，在演算法程式設計基準上的自我演化，在所有五種語言的功能正確性與執行時期效率上帶來了一致的改進。推論內軌跡分析進一步證明，AGP 不僅改善了終端分數，還提供了自我演化何時及如何提供最大效益的細緻可見性。
6. 結論
我們提出了 AGP，一個雙層自我演化協定，將「什麼在演化」與「如何演化」解耦。資源基底協定層（RSPL）將提示詞、代理人、工具、環境與記憶體建模為具有明確生命週期與介面合約的第一類版本化資源。自我演化協定層（SEPL）定義了一個閉迴路運算子代數，用於提出、評估與提交具有可稽核譜系與回溯機制的改進。基於此協定，我們實例化了 AGS，一個在執行期間動態檢索、精煉與演化異質資源的思考與行動代理人。我們相信，這種協定層級的自我演化方法，為建立模組化、可追蹤且能安全改進的代理人系統提供了有原則的基礎。
附錄重點摘要
符號與協定比較：Autogenesis 協定與 Google A2A 及 Anthropic MCP 相比，在代理人與系統能力（如追蹤器、記憶體資源化）、可演化資源管理（如生命週期操作、版本控制與回溯、註冊與檢索、合約生成）以及自我演化機制（如閉迴路演化、運算子化更新、可稽核性）等面向上，提供了更全面的原生支援。MCP 專注於模型對工具的呼叫，A2A 專注於代理人之間的通訊，而 Autogenesis 則聚焦於代理人元件的狀態突變與持久演化，並透過運算子代數確保每一次修改都是受控、可追蹤且可回溯的。
RSPL 詳細機制：資源基底協定層的上下文管理器與伺服器介面進一步定義了資源的管理與存取方式。上下文管理器負責維護資源的活動註冊表與版本化歷史，支援生命週期、檢索、演化與序列化等操作，並能生成合約規範（例如 skills.md 格式），為 LLM 提供穩定的工具描述，減少提示詞的冗餘。伺服器介面則封裝了管理器的內部複雜性，為外部呼叫者提供簡化且一致的 API 端點。
伺服器介面被引入以封裝上下文管理器的內部複雜性，並為外部呼叫者呈現穩定、簡化的介面。它將異質的管理例程封裝在一組具有一致請求/回應語意的統一端點之後，同時將實作細節委派給上下文管理器。這種分離將客戶端與內部設計變更隔離，降低了耦合度，並提供了一個單一控制平台，協定透過該平台調解與 RSPL 資源之間安全且具版本感知的互動。
C.1.4. 基礎架構服務
RSPL 進一步包含了支援可靠演化的跨領域服務，包括可重現性、安全部署與版本化復原：
模型管理器。一個統一的模型 API 層，標準化了跨供應商（例如 OpenAI、Anthropic、Google 與 OpenRouter 等）的呼叫，同時支援路由、備援與成本感知選擇，以在元件演化時保持模型存取的一致性。
版本管理器。維護每個資源的版本譜系，實現回溯、分支與差異比對。版本是在註冊或更新時分配的自動遞增識別碼（例如語意版本），每個版本都參照一個不可變的組態記錄快照與關聯的產出物，以確保可稽核性與可重現性。
動態管理器。處理資源組態的序列化或反序列化，以利持久化與傳輸，實現執行時期的資源安全熱插拔，而無需重啟代理人系統。
表 7. 上下文管理器與伺服器介面的運算子集合。
生命週期與註冊：init（自動發現資源並將資源組態註冊至註冊表）、build（從程式碼與組態建構資源實例）、register（以唯一名稱與版本註冊新的資源實例）、unregister（從活動註冊表與版本歷史中取消註冊資源實例）。
檢索與檢查：get（依名稱從活動註冊表檢索資源實例）、get info（依名稱從活動註冊表檢索資源組態）、list（列出所有已註冊的資源名稱）、retrieve（支援時透過語意搜尋檢索相似資源）、get state（支援時取得資源實例的目前狀態）。
演化與版本控制：update（更新資源實作並產生新版本）、copy（複製資源並選擇性給予新名稱與版本）、restore（依名稱與版本字串復原特定歷史版本）、get variables（將資源程式碼/組態公開為可演化變數）、set variables（更新資源變數並產生新版本）。
執行與合約：run（以結構化輸入執行資源實例）、save contract（將資源實例的合約儲存至檔案）、load contract（從檔案載入資源實例的合約）。
序列化與反序列化：save to json（將組態與版本歷史序列化為 JSON 檔案）、load from json（從 JSON 檔案反序列化組態與版本歷史）。
追蹤器模組。一個捕捉細粒度執行軌跡（輸入、輸出、中間決策、工具互動等）的模組，用於可解釋性與除錯，並作為資料集合成與回顧性改進的訓練訊號。
C.2. 第二層：自我演化協定層
自我演化協定層（SEPL）規範了代理人系統如何透過有原則的閉迴路運算子介面來自我改進。SEPL 將自我改進框架為在異質可演化狀態上的迭代狀態轉換，同時將所有修改透過標準化的 RSPL 介面進行路由，使得更新保持可稽核（版本化）、可逆（可復原），且在建構上即具備安全性。
C.2.1. 概述
SEPL 將持續改進概念化為在結構化可演化狀態空間上的廣義最佳化問題。形式上，SEPL 將演化動態視為由嚴格型別運算子代數管理的狀態轉換，使不同的最佳化策略能共享相同的突變表面與安全/驗證閘門。在我們的系統中，SEPL 容許多種實例化——包含反思驅動最佳化（我們的預設值）、TextGrad、GRPO 與 Reinforce++。我們不在此概述中詳述其完整機制；而是在下面的專用小節中總結它們的變數、運算子與迴路程序。
C.2.2. 可演化變數
SEPL 依賴變數提升，將異質的 RSPL 資源（例如提示詞、工具實作（原生腳本、MCP 工具或代理人技能）與記憶體模組）投影到統一的可演化變數空間。此抽象化為所有演化運算子提供了共同介面，並透過二元可學習性遮罩使可學習子空間變得明確。我們請讀者參閱正文（SEPL，可演化變數，定義「可演化變數集」）以了解 V_evo 與相關可學習性約束的形式化定義。
C.2.3. 運算子代數
SEPL 將演化形式化為在輔助空間上之型別運算子的組合，與迭代最佳化的標準階段（觀察、歸因、提案、驗證與提交）對齊。我們在正文中採用反思驅動的實例化作為標準範例：它指定了一個最小運算子套件 { ρ, σ, ι, ε, κ }（反思/選擇/改進/評估/提交），在軌跡、假設、修改、目標與評估空間 ( Z, H, D, G, S ) 上運作。我們請讀者參閱正文（運算子代數）以了解形式化的運算子簽名及其語意；以下我們除了反思之外，還提供了 TextGrad、GRPO 與 Reinforce++ 特定方法的運算子化。
C.2.4. 反思最佳化器
可演化變數。在反思驅動的實例化中，可演化狀態由正文中引入的提升變數集 V_evo 給定。具體而言，V_evo 包含 RSPL 管理的資源（例如提示詞、工具、記憶體與代理人元件）以及執行產出物（例如產生的答案與推論軌跡）。二元可學習性遮罩指定了哪些變數可被修改，允許最佳化器僅針對授權元件，同時保持不可學習的資源固定。
運算子代數。我們以正文中的標準反思驅動運算子套件來實例化 SEPL。為求完整，我們在下方重述運算子簽名及其預期角色。
Reflect ( ρ )。定義為 ρ : Z × V_evo → ℘(H)，此運算子銜接了原始觀察與最佳化方向之間的差距。它透過將高維度的執行軌跡映射到變數空間中特定、因果的失敗假設，來逼近系統的「語意梯度」。
Select ( σ )。表述為 σ : V_evo × ℘(H) → ℘(D)，此運算子作為生成式策略。它將診斷假設轉換為具體的更新提案，對候選修改 D 進行採樣，旨在約束結構下最小化已識別的錯誤訊號。
Improve ( ι )。突變運算子，ι : V_evo × ℘(D) → V′_evo，執行物理狀態轉換。它透過標準化 RSPL 介面應用離散更新 D，以產生暫定的候選狀態。
Evaluate ( ε )。指定為 ε : V′_evo × G → S，此運算子作為目標函數。它將候選狀態與目標規範映射到評估空間 S（包含量化分數與嚴格的安全不變量）。
Commit ( κ )。作為 κ : V′_evo × S → V_evo 運作，此函式作為條件閘門機制。它利用 S 中的評估訊號來管理狀態轉換，僅在滿足特定成功標準時才接受候選 V′_evo，嚴格執行安全不變量與效能單調性。
演化迴路。這些運算子組合成演算法 2 所示的反思驅動閉迴路程序。從初始提升狀態 V(0)_evo 開始，代理人首先執行以收集觀察軌跡 Z（工具輸出、中間決策、失敗與進度訊號）。反思運算子 ρ 將 Z 映射到一組因果假設 H，然後由 σ 將其轉換為 V_evo 可學習子集上的具體修改原語 D（例如提示詞編輯、工具調整或記憶體更新）。改進運算子 ι 透過 RSPL 介面應用 D 以獲得候選狀態，該狀態由 ε 評估以產生同時捕捉效能指標與安全約束的 S。最後，提交運算子 κ 僅接受滿足預定義標準的候選以作為閘門控制轉換，將每個被接受的變更記錄為具可稽核譜系的版本化資源更新，並在必要時啟用回溯。
演算法 2：反思最佳化器演化迴路。輸入：代理人系統 A，目標 G，預算 T。輸出：最佳化狀態 V*_evo。1. 初始化：V(0)_evo ← VariableLifting(A)（將資源投影至最佳化流形）；Z(0) ← Execute(A, V(0)_evo)（軌跡：工具 I/O、失敗、延遲、進度）。4. 最佳化循環：7. H ← ρ(Z, V_evo)（反思：歸因失敗/低效）；8. D(t) ← σ(V(t)_evo, H(t))（選擇：對可學習變數提出編輯）；9. 階段 2：突變與驗證；10. ~V(t+1)_evo ← ι(V(t)_evo, D(t))（改進：應用提議的更新（候選））；11. S(t+1) ← ε(~V(t+1)_evo, G)（評估：指標 + 安全不變量）；12. 階段 3：閘門與轉換；13. if Accept(S(t+1)) then 14. 接受：安全且非退化；15. V(t+1)_evo ← κ(~V(t+1)_evo, S(t+1))（提交：版本化更新）；16. else 17. 拒絕：回溯 / 保持先前狀態 V(t+1)_evo ← V(t)_evo；18. 階段 4：下一次迭代；19. Z(t+1) ← Execute(A, V(t+1)_evo)（在更新後的資源下重新執行）；21. if Converged(S(t+1)) then break；23. return V_evo。
C.2.5. TextGrad 最佳化器
可演化變數。在 TextGrad 實例化中，可演化變數被限制為標記為可最佳化的提示詞變數子集，並提升為具有明確角色描述的 TextGrad 變數。在我們的實作中，每個可最佳化的提示詞模組都表示為一個 TextGrad 變數，其值為當前提示詞文本，而角色描述則指定了提示詞的功能，使最佳化器能根據其預期語意來調整更新。
運算子代數。TextGrad 以提示詞層級的運算子化來實例化 SEPL，其中「梯度」是由 LLM 評估器產生的自然語言批評，而更新則實作為受約束的提示詞重寫。遵循標準的 TextGrad 觀點，我們用五個核心運算子來表達該方法，即 Execute、Loss、Backward、Improve 與 Commit，其中「梯度」是一段文本（批評）而非數值向量：
Execute ( χ_tg )。χ_tg : (A, V_evo, x, f) → Z 在當前提示詞變數下執行代理人並產生執行軌跡/結果。
Loss ( λ_tg )。λ_tg : Z → G_tg，其中 G_tg 是自然語言批評的空間（文本梯度）。在我們的實作中，λ_tg 由 TextLoss 實現，它查詢評估器 LLM 並返回批評回饋。
Backward ( β_tg )。β_tg : V_evo × G_tg → V_evo 透過將批評（可選擇性地包含上下文）儲存在每個變數的梯度緩衝區中，將文本梯度分配給可最佳化的提示詞變數。在我們目前的實作中，為了穩定性，我們將相同的批評分配給每個可最佳化的提示詞變數。
Improve ( ι_tg )。ι_tg : V_evo → V′_evo 透過文本梯度下降步驟重寫提示詞變數：它從每個變數的角色描述、當前值與累積的文本梯度建構更新指令，然後查詢最佳化器 LLM 並從受約束的輸出格式中提取改進後的變數文本。
Commit ( κ_tg )。κ_tg : V′_evo → V_evo 將更新後的提示詞變數同步回執行中的代理人並清除快取，完成狀態轉換。
演化迴路。演算法 3 以運算子形式呈現了完整的 TextGrad 最佳化循環。在每次迭代中，透過 χ_tg 在當前提示詞變數下執行代理人以獲得軌跡 Z，透過 λ_tg 讓基於 LLM 的評估器產生自然語言批評 g ∈ G_tg，透過 β_tg 將批評作為文本梯度分配給可最佳化的提示詞變數，透過 ι_tg 使用文本梯度下降改進提示詞變數，並透過 κ_tg 提交候選狀態，將更新的提示詞同步回執行中的代理人（並清除快取）以進入下一次迭代。
演算法 3：TextGrad 提示詞最佳化迴路。輸入：代理人系統 A，任務 x，附件 f（可選），預算 K，評估器/最佳化器 LLMs M_eval, M_opt。輸出：更新後的狀態 V*_evo（透過 TextGrad 更新的提示詞變數）。1. 階段 0：設定；2. 將反向引擎設為 M_eval（TextLoss 使用的評估器）；3. V(0)_evo ← VariableLifting(A)（將可最佳化提示詞提升為 TextGrad 變數）；4. 使用 M_opt 初始化文本最佳化器（對提示詞變數進行 TextualGradientDescent）；5. 最佳化循環：for k = 0, 1, ..., K-1 do；7. 階段 1：執行（前向傳播）；8. Z(k) ← χ_tg(A, V(k)_evo, x, f)（使用當前提示詞執行代理人）；9. 階段 2：損失（文本梯度）；10. 從 Z(k) 建構評估指令（以成功/錯誤為條件）；11. g(k) ← λ_tg(Z(k))（TextLoss 產生批評字串）；12. 階段 3：反向傳播（分配梯度）；13. V(k)_evo ← β_tg(V(k)_evo, g(k))（將批評分配至梯度緩衝區）；14. 階段 4：改進（文本梯度下降）；15. ~V(k+1)_evo ← ι_tg(V(k)_evo)（透過文本梯度下降重寫提示詞）；16. 階段 5：提交與下一次迭代；17. V(k+1)_evo ← κ_tg(~V(k+1)_evo)（同步回寫；清除快取）；18. if Converged(g(k)) then break；22. return V(k)_evo。
C.2.6. Reinforce++ 最佳化器
可演化變數。Reinforce++ 最佳化 RSPL 資源的可訓練子集，專注於提示詞變數與工具實作（原生腳本、MCP 工具與代理人技能），並可選擇性地精煉產生的解決方案文本。我們的實作遵循兩階段結構： 更新支配行為的可訓練變數（例如提示詞與工具）， 啟用時更新解決方案本身。
運算子代數。Reinforce++ 的特徵是具有截斷目標與對參考解決方案的明確懲罰，同時使用反思將 RL 訊號轉換為具體的編輯。我們將該方法分組為一小組核心運算子：
Sample ( χ_rpp )。χ_rpp : (A, V_evo, x, f) → Z 在當前資源下採樣一次推演，並產生包含產生答案的執行軌跡。
Reward ( ε_rpp )。ε_rpp : (y(t), y(t-1), y*, y_sft) → (r(t), A(t), J(t), ρ(t)) 從當前解決方案 y(t) 計算 RL 訊號元組。此處 r(t) 是比較 y(t) 與 y* 的任務獎勵，而 ρ(t) 是由文本相似度 η(·,·) 定義的比例代理，ρ(t) ≜ η(y(t-1), y(t))。我們定義對參考解決方案 y_sft 的懲罰為 pen(t) ≜ β || log max(η(y_sft, y(t)), ϵ_0) || 並設定 A(t) ≜ r(t) - pen(t)。截斷的 Reinforce++ 目標為 J(t) ≜ min(ρ(t)A(t), ~ρ(t)A(t))，~ρ(t) ≜ clip(ρ(t), 1-ϵ, 1+ϵ)。
Reflection ( ρ_rpp )。ρ_rpp : (Z, V_train, r(t), A(t), J(t), ρ(t)) → H 產生明確以 RL 指標與執行軌跡為條件的、導向編輯的診斷。
Improve ( ι_rpp )。ι_rpp : (V, H) → V′_evo 將受 RL 資訊引導的編輯應用於 可訓練資源 V_train（如提示詞與工具），或 啟用解決方案精煉時的解決方案變數本身，產生候選狀態。
Commit ( κ_rpp )。κ_rpp : V′_evo → V_evo 將接受的更新應用回 RSPL 資源，完成狀態轉換。
演化迴路。演算法 4 以分階段的形式總結了 Reinforce++ 迴路。每次迭代 計算 Reinforce++ 訊號（透過截斷目標與對參考解決方案的懲罰）， 透過受 RL 條件限制的反思與編輯改進可訓練資源， 可選擇性地改進解決方案文本，以及 應用提前停止評估。
演算法 4：Reinforce++ 最佳化迴路。輸入：代理人系統 A，任務 x，基準真值 y*，參考解決方案 y_sft，預算 T。輸出：最終解決方案 y(t) 與更新後的可訓練資源 V_train。1. 初始化；2. V(0)_evo ← VariableLifting(A)（提升可訓練資源）；3. Z(0) ← χ_rpp(A, V(0)_evo, x, f)（採樣一次）；4. 從 Z(0) 提取解決方案 y(0)；5. y(-1) ← y(0)（初始化前一個解決方案）；6. for t = 0, 1, ..., T-1 do；7. 階段 1：Reinforce++ 獎勵與目標；8. (r(t), A(t), J(t), ρ(t)) ← ε_rpp(y(t), y(t-1), y*, y_sft)（獎勵、懲罰、截斷目標）；9. 階段 2：改進可訓練資源（提示詞與工具）；10. V(t)_train ← GetTrainables(V(t)_evo)；11. H(t)_train ← ρ_rpp(Z(t), V(t)_train, r(t), A(t), J(t), ρ(t))（以 RL 訊號為條件的反思）；12. ~V(t+1)_train ← ι_rpp(V(t)_train, H(t)_train)（將編輯應用至可訓練項（候選））；13. V(t+1)_train ← κ_rpp(~V(t+1)_train)（提交更新）；14. 階段 3：在更新後的資源下重新執行；15. Z(t+1) ← χ_rpp(A, V(t)_evo ∪ V(t+1)_train, x, f)；16. 從 Z(t+1) 提取解決方案 y(t+1)；17. 階段 4：可選的解決方案精煉；18. H(t)_sol ← ρ_rpp(Z(t+1), {y(t+1)}, r(t), A(t), J(t), ρ(t))（反思解決方案品質）；19. ~y(t+1) ← ι_rpp(y(t+1), H(t)_sol)（編輯解決方案文本（候選））；20. y(t+1) ← κ_rpp(~y(t+1))（提交解決方案更新）；21. 階段 5：提前停止；22. if Satisfied(Z(t+1)) then break；25. y(t) ← y(t+1)（推進當前解決方案）；27. return y(t)。
C.2.7. GRPO 最佳化器
可演化變數。GRPO 最佳化 RSPL 資源的可訓練子集，專注於提示詞變數與工具實作（原生腳本、MCP 工具與代理人技能），並可選擇性地精煉產生的解決方案文本。類似於 Reinforce++，我們的實作遵循兩階段結構： 更新支配行為的可訓練變數（例如提示詞與工具）， 啟用時更新解決方案本身。
運算子代數。GRPO 的特徵是在每一步採樣多個候選解決方案，並使用群組歸一化優勢與截斷目標。我們用以下核心運算子將該方法形式化：
Sample ( χ_grpo )。χ_grpo : (A, V_evo, x, f, K) → {Z_i}_i=1^K 在當前資源下採樣 K 個獨立推演，產生 K 個執行軌跡，每個包含一個候選解決方案 y_i。
Reward ( ε_grpo )。ε_grpo : ({y_i}_i=1^K, y*, y(t-1)) → ({r_i}_i=1^K, {A_i}_i=1^K, {J_i}_i=1^K, {ρ_i}_i=1^K) 計算所有 K 個候選的 RL 訊號。對於每個候選 y_i，我們計算比較 y_i 與 y* 的任務獎勵 r_i，使用文本相似度 η(·,·) 的策略比例代理 ρ_i ≜ η(y(t-1), y_i)，以及透過在候選集上歸一化獎勵得出的群組歸一化優勢 A_i：A_i = (r_i - r̄) / σ_r，其中 r̄ 與 σ_r 是 {r_i}_i=1^K 的平均數與標準差。每個候選的 GRPO 截斷目標為 J_i ≜ min(ρ_iA_i, ~ρ_iA_i)，若 A_i ≥ 0 則 ~ρ_i ≜ min(ρ_i, 1+ϵ)，若 A_i < 0 則為 max(ρ_i, 1-ϵ)。
Reflection ( ρ_grpo )。ρ_grpo : ({Z_i}_i=1^K, V_train, {r_i, A_i, J_i, ρ_i}_i=1^K) → H 產生明確以多個候選解決方案及其 RL 指標為條件的、導向編輯的診斷，使最佳化器能夠跨候選識別模式。
Improve ( ι_grpo )。ι_grpo : (V, H) → V′_evo 將受 RL 資訊引導的編輯應用於 可訓練資源 V_train（如提示詞與工具），或 啟用解決方案精煉時的解決方案變數本身，產生候選狀態。
Commit ( κ_grpo )。κ_grpo : V′_evo → V_evo 將接受的更新應用回 RSPL 資源，完成狀態轉換。
演化迴路。演算法 5 以分階段的形式總結了 GRPO 迴路。每次迭代 採樣 K 個候選解決方案， 透過群組歸一化優勢與截斷目標計算 GRPO 訊號， 透過受多候選條件限制的反思與編輯改進可訓練資源， 可選擇性地改進解決方案文本，以及 應用提前停止評估。
演算法 5：GRPO 最佳化迴路。輸入：代理人系統 A，任務 x，基準真值 y*，預算 T，候選數量 K。輸出：最終解決方案 y(t) 與更新後的可訓練資源 V_train。1. 初始化；2. V(0)_evo ← VariableLifting(A)（提升可訓練資源）；3. Z(0) ← χ_grpo(A, V(0)_evo, x, f, 1)（採樣初始解決方案）；4. 從 Z(0) 提取解決方案 y(0)；5. y(-1) ← y(0)（初始化前一個解決方案）；6. for t = 0, 1, ..., T-1 do；7. 階段 1：採樣多個候選；8. {Z(t)_i}_i=1^K ← χ_grpo(A, V(t)_evo, x, f, K)（採樣 K 個推演）；9. 從 {Z(t)_i} 提取候選解決方案 {y(t)_i}；10. 階段 2：GRPO 獎勵與目標；11. ({r(t)_i}, {A(t)_i}, {J(t)_i}, {ρ(t)_i}) ← ε_grpo({y(t)_i}, y*, y(t-1))（群組歸一化優勢，截斷目標）；12. 階段 3：改進可訓練資源（提示詞與工具）；13. V(t)_train ← GetTrainables(V(t)_evo)；14. H(t)_train ← ρ_grpo({Z(t)_i}, V(t)_train, {r(t)_i, A(t)_i, J(t)_i, ρ(t)_i})（以多候選 RL 訊號為條件的反思）；15. ~V(t+1)_train ← ι_grpo(V(t)_train, H(t)_train)（將編輯應用至可訓練項（候選））；16. V(t+1)_train ← κ_grpo(~V(t+1)_train)（提交更新）；17. 階段 4：在更新後的資源下重新執行；18. Z(t+1) ← χ_grpo(A, V(t)_evo ∪ V(t+1)_train, x, f, 1)；19. 從 Z(t+1) 提取解決方案 y(t+1)；20. 階段 5：可選的解決方案精煉；21. H(t)_sol ← ρ_grpo({Z(t)_i}, {y(t+1)}, {r(t)_i, A(t)_i, J(t)_i, ρ(t)_i})（使用多候選上下文反思解決方案品質）；22. ~y(t+1) ← ι_grpo(y(t+1), H(t)_sol)（編輯解決方案文本（候選））；23. y(t+1) ← κ_grpo(~y(t+1))（提交解決方案更新）；24. 階段 6：提前停止；25. if Satisfied(Z(t+1)) then break；28. y(t) ← y(t+1)（推進當前解決方案）；30. return y(t)。