Agent 的持續進化

今日的 Agent 面臨一個鮮明的能力悖論：它可以用零樣本解決從未見過的複雜任務，卻可能在處理了一萬次相似任務之後，隔天仍犯下第一天的錯誤。模型上崗之後，能否像新進員工一樣從日常工作中不斷長進？能否自主從經驗中學習（所謂持續學習，continual learning），正成為 Agent 從「會完成任務」走向「能夠可靠工作」的關鍵能力，也是下一代模型的核心研究課題。今日的「持續學習」概念與早年「學了新任務就忘掉舊任務」的持續學習研究不是同一個問題，遺忘只是其中一個子問題，更難的是沒有人告訴模型，今天這一天的經歷裡哪些是做對的，哪些是做錯的。就目前而言，模型本身的持續學習能力仍遠遠不足。

原因在於，部署後的模型不會因為一次推理就自動改變參數。第二章討論的上下文學習、狀態維護與壓縮，能讓 Agent 在目前任務內適應；但上下文結束後，這種變化不會自然進入下一次任務。將對話存入記憶也不等於學會新的行為：原始軌跡可能很長，其中既有有效策略，也有偶然成功、錯誤歸因與不可信的輸入。

這裡有一個容易混淆的差別：保存經歷不等於從經歷中學習。將一百條軌跡放入長上下文或向量庫，可以幫助模型在需要時找回某個案例，卻不會自動完成跨案例比較——哪些步驟在成功軌跡中反覆出現、哪些做法只在舊版介面上有效、某次成功究竟來自正確策略還是環境偶然。學習發生在系統主動完成「評價、對照、歸納、驗證」之後，而不是發生在日誌寫入磁碟的那一刻。第三章的使用者記憶主要沉澱「使用者與世界是什麼樣子」，本章的經驗學習則要進一步沉澱「在什麼條件下應該如何行動」；前者讓 Agent 記得更多，後者才讓它從聰明變得熟練。

那麼，為什麼不讓模型在每次任務後直接訓練自己？因為正式環境很少提供乾淨的學習訊號。使用者滿意不代表合規；局部參數更新也可能造成能力遺忘、策略漂移或安全性退化。若允許執行中的模型依據未經驗證的回饋直接修改自身參數，錯誤經驗與提示注入就可能被固化，並在後續任務中持續放大。另一方面，基礎模型的週期性訓練可以提升通用能力，卻無法及時吸收每個 Agent 每天遇到的私有規則、工具變化與局部經驗。

因此，在模型自身尚無法可靠地持續學習時，必須先將「學習」建構為模型外圍的一套自主系統，本書稱之為持續進化，以區別於模型權重層面的持續學習：記錄執行證據、驗證結果與過程、從多條軌跡中提取共通性，再決定應更新知識、指令、程式或模型參數。所有修改先形成候選版本，經過迴歸測試與安全檢查後，才能改變下一輪執行。

前面的章節已經提供這套系統所需的主要元件。第二章處理任務內狀態，第三章提供知識基礎設施，第五章賦予 Agent 創造工具與修改系統的後設能力，第七章建立評估與驗證，第八章說明如何更新模型參數。第九章的任務，是將這些元件組織成圖9-1所示的持續進化閉環。

持續進化需要源自可追溯的執行經驗、能夠改變後續行為，並經過驗證確認未造成明顯退化。本章首先討論如何判斷一次執行究竟好在哪裡、錯在哪裡；接著比較四種更新方法及其適用邊界；最後討論這些更新如何在長期執行中被驗證、發布、修訂與淘汰。

從執行軌跡中取得學習訊號

持續進化的起點是第七章所述的評估（evaluation）。如果系統不知道任務是否完成，也不知道哪一步造成成功或失敗，那麼語言模型產生的反思只能是一種猜測。

評價一條軌跡，實質上是依次回答三個問題：事情是否辦成了，是否以允許的方式辦成，是否讓使用者舒服。圖9-2 將它們組織為三層驗證結構。

底層的結果驗證器回答「事情是否真的辦成」。 它讀取測試結果、資料庫狀態與工具回傳：Coding Agent 可以執行測試、型別檢查與效能基準測試；替使用者辦理退款的 Agent 可以查詢訂單狀態與實際退款金額。這類訊號來自環境中的真實狀態，通常比模型對自身行為的描述可靠，因此是三層中最應優先建立的一層。

中間的過程驗證器回答「是否以允許的方式辦成」。 結果正確不代表過程正確：刪除失敗的測試案例也能讓測試通過，口頭向使用者承諾「我們會在 7 天內退款，請耐心等候」也可能暫時獲得滿意回饋。這一層檢查業務規則、權限與動作序列，用以區分「結果已經達成」與「結果以允許的路徑達成」。政策庫、權限表與動作軌跡均可精確表達，因此這一層同樣可以由程式碼判定。

上層的品質驗證器回答「是否讓使用者舒服」。 例如，客服是否有耐心、是否提供合規範圍內的替代方案，研究報告是否掌握關鍵證據，生成文字是否自然精簡。這些面向不影響事情辦成與否，但對使用者體驗是有影響的。此時可以使用第七章介紹的 LLM-as-a-Judge，預先定義評量規準（Rubric），要求驗證器逐項評分並引用軌跡證據。

以客服 Agent 為例，表9-1 將這三層展開為七個可逐項評分的面向：任務結果屬於結果層；規則遵循、隱私邊界與承諾—行動一致性屬於過程層；表達品質與合規變通屬於品質層；事實可靠性橫跨兩層，可與工具回傳逐一比對的部分由程式碼核驗，其餘交由 Rubric 判斷。

表9-1 客服 Agent 的軌跡評價面向

驗證器的輸出形態決定了它能否成為「學習訊號」。 單一總分只能反映一次執行的優劣，無法指出應當修改之處。可供後續學習的評價至少應包含四項內容：任務是成功、部分成功還是失敗；每個面向各自的結論；每條結論對應的證據位置（哪一輪對話、哪一次工具呼叫）；以及失敗的類型標籤。驗證器還應被允許在證據不足時拒絕評分。與其把低信心度的結論當作事實固化下來，不如將該案例排除在學習集之外。具備這四項內容，下一節討論的四種更新方法才能判斷應當更新知識、提示詞、程式還是模型參數。

實驗 9-1 ★★：為客服 Agent 建構軌跡驗證器

實驗目標：將一條客服執行軌跡轉換為可供後續學習使用的結構化診斷，並驗證「多面向結論加證據」是否比單一總分更能定位根因。

實驗說明：對照「只輸出一個總分」和「逐維度輸出結論、證據與置信度」兩種驗證方式，觀察哪一種更容易區分任務失敗、規則違規、虛假承諾和表達問題。持續進化不能只依賴成功率或單一分數。只有保留「哪裡錯、為什麼錯、證據在哪裡」，後續模組才知道應該更新知識、Prompt、程式還是模型參數；低置信度案例也不應自動進入學習集。

Agent 持續進化的四種方法

學習訊號說明 Agent 應該改變，卻沒有說明改變應發生在哪裡。選擇更新方式的首要依據不是經驗出現了多久，而是目標能力能否由某種載體自然表達。事實與經驗適合寫成知識文件；可用語言清楚表達的策略適合寫入提示詞或 Skill；可精確執行的流程與約束適合寫成程式；感知、語言風格與隱式策略等高維度能力則必須進入模型參數。圖9-3呈現這四種方式及其關係。

表9-2提供一個精簡比較。四種方式並不互斥：醫療影像 Agent 依靠參數辨識病灶，以知識庫提供最新指引，再以程式碼計算風險指標；客服模型的自然語氣來自後訓練，具體企業政策由知識與 Skill 提供，關鍵合規要求則由伺服器端程式碼把關。

表9-2 四種持續進化方式的適用邊界

同一能力可以拆到多個載體：事實進入知識庫，解釋例外的原則進入 Skill，不可繞過的權限仍由程式門控，高維識別能力再進入參數。路由結果只是更新提案，尚未獲得發布資格。

將經驗沉澱為知識

最輕量的進化方式，是將多次執行中反覆出現的經驗整理成可檢索的知識文件。此處所稱的「經驗知識庫」與第三章共享儲存、索引與檢索技術，但知識來源與驗證目標不同。第三章主要從使用者對話、文件與資料集中提取「使用者與世界是什麼樣子」；本章則從 Agent 的行動軌跡與結果中提取「在什麼條件下應該怎麼做」。例如，「該航空公司要求特殊餐點提前二十四小時預訂」是領域知識；「訂票前先檢查特殊餐點截止時間，避免付款後才發現無法滿足需求」則是行動經驗。

原始軌跡不適合作為正式知識單元。它既長又嘈雜，包含工具原始輸出、偶然的繞路與環境細節。更穩健的系統會保留三層資料：不可變的原始軌跡用於稽核，單次執行分析記錄本次成敗與候選教訓，多條同類軌跡再經過比較、分群與歸納，形成面向未來的 Markdown 知識文件。正式文件通常會寫明適用場景、建議策略、禁止做法、例外條件、證據來源與最近驗證時間，而不是複述某一次任務的完整過程。

這種設計與第三章的 User-as-Code 具有相同的兩階段思維。User-as-Code 先將對話事實附加至不可變日誌，再週期性重建結構化使用者模型；經驗學習同樣應先保存證據，再離線產生可變知識。圖9-4呈現此一過程。將記錄與整理分開，可以避免一次偶發成功或網路故障立即改變 Agent，也讓系統能在觀察多條成功與失敗軌跡後再判斷共通性。

經驗文件不是單純的軌跡摘要。真正具有遷移價值的內容來自對照：同類成功軌跡做了什麼，失敗軌跡缺少什麼；某種策略在哪些環境版本中有效，又在哪些前置條件下失效。第三章已介紹知識提取、分群與檢索，本章不再重複這些演算法，而將重點放在軌跡評價如何成為提取條件，以及提取出的知識能否提升後續任務表現。

一套完整的知識提煉管線可分為五步。首先保存不可變的軌跡與環境結果；接著為單次執行產生結構化分析，列出任務類型、所需能力、觀察到的策略、錯誤與例外；再依任務家族聚合同類執行，為每條候選規律建立「哪些軌跡支持、哪些軌跡反駁」的證據表；只有達到支持門檻的候選才寫入正式文件；最後在未參與提煉的新任務上測試遷移效果。正式知識與候選分析分庫存放，使系統可以重新歸納而不竄改原始證據，也能在環境版本變化時精確撤銷某條結論。

GAIA 經驗學習提供一個直觀案例。GAIA¹ 包含需要綜合搜尋、網頁閱讀、檔案處理與計算的多步驟問題，AWorld² 則提供執行 Agent、呼叫這些工具與保存軌跡的執行環境；前者像考卷，後者像考場與實驗紀錄系統。舊式做法是在一次任務成功後立刻產生策略摘要並向量化入庫；更嚴謹的實作會先用 GAIA 答案驗證器或其他環境驗證器標記成功、部分成功與失敗，再比較同一任務家族的多條路徑。成功軌跡貢獻候選策略，失敗軌跡貢獻排除性知識，部分成功軌跡則協助辨識「哪一段有效、哪一段仍有問題」。Reflexion³ 所提出的自然語言反思可以參與產生候選教訓，但反思本身不是證據；只有與環境結果相符、獲得跨軌跡支持，並在新任務上展現正向遷移的內容，才應進入正式經驗文件。

將經驗寫成指令

經驗知識庫給 Agent 提供「可以參考的資料」，Prompt 和 Skill 則規定「應該怎樣行動」。當多條相似軌跡反覆暴露同一種策略錯誤，而且錯誤能夠用語言清楚描述時，才值得把經驗提升為指令。這裡先把三個概念分開：系統 Prompt 對所有任務生效，Skill 只在匹配到某個領域或工具時按需載入，程式／Harness 負責權限和其他硬約束。

Andrej Karpathy 將這種做法稱為系統提示學習（System Prompt Learning）⁴：模型遇到問題後，用一句清楚的話提醒未來的自己。DSPy⁵ 在開發集上搜尋指令和範例；OPRO⁶ 根據歷史提示詞及其得分提出提示提案；GEPA⁷ 從失敗軌跡的自然語言反思中生成並篩選提示提案。這些方法適合離線批次最佳化；生產環境更適合使用可稽核的最小更新提案，並保留快速回滾路徑。

系統提示學習與第二章的提示工程不是一回事。第二章討論怎樣組織一份好 Prompt；本節討論什麼回饋足以觸發修改，以及更新提案怎樣安全發布。修改應是帶來源的最小 diff，而不是讓模型每次都重寫整份 Prompt——這正是第一章命名的最小 diff + 可回滾模式。待驗證版本必須同時在觸發失敗的邊界集和正常工作的保留集上測試，前者要改善，後者不能退化。

例子一：轉接邊界的規則化

τ²-bench 的 telecom 政策中，關於轉接人工只有兩條原則性規定：請求超出 Agent 的動作範圍時才轉接，轉接前應先盡力解決。第七章解剖該環境時，這兩條並未顯出問題；換用能力較弱的模型執行，缺陷隨即暴露——工具返回錯誤後 Agent 反覆重試，最終以轉接人工收場，提煉集的 20 條任務中有 19 條如此結束。

將這 19 條失敗軌跡交由模型自行歸納，產出若干條可執行的規則追加到政策末尾，再在一批未參與提煉的任務上重新執行：通過率由 12.3% 升至 19.3%，且原本通過的任務無一被改壞。

提煉所依據的材料決定了能夠歸納出什麼。 同樣是這 19 條軌跡，僅提供失敗摘要與錯誤文字時，模型歸納出的是「同一工具反覆報錯即不應繼續呼叫」；補充 Agent 與使用者各自可呼叫的工具清單之後，歸納結果變為「網路狀態、SIM 卡、APN 等項屬於使用者裝置側，應引導使用者自行操作而非直接呼叫」。前者記錄的是教訓，後者理解的是職責歸屬。

模型會把觀察到的行為當作應然的行為。 第一版規則中有兩條為「連續三次呼叫失敗即轉接人工」「使用者兩次未提供號碼即轉接人工」——軌跡中出現最頻繁的正是轉接人工，模型據此將其視為合理的兜底手段。但在這套評估中轉接人工必然判定失敗，這兩條規則等於把失敗寫入了規範。提煉產物因此不能直接釋出，須經與提煉者相互獨立的驗證。

被修復的往往是極樸素的缺陷。 基線中有一條典型軌跡：Agent 需要使用者的電話號碼，於是呼叫查詢工具，並將「請您提供您的電話號碼」填入參數，連續五次，五次報錯，隨後轉接人工。它已經判斷出應當詢問使用者，卻把這句話說給了工具。規則生效後，它先在對話中提出請求，取得號碼再行查詢；此後欲檢查 SIM 卡狀態遭工具拒絕，轉而引導使用者自行重新插拔 SIM 卡，任務通過。

實驗 9-2 ★★：從 τ²-bench 失敗軌跡提煉轉接與工具使用規則

沿用第七章的 τ²-bench telecom 環境。提煉集與遷移集在上游倉庫中本就是兩套互不相交的任務，提煉過程接觸不到遷移集。

先以弱模型執行提煉集並儲存失敗軌跡；規則由模型歸納而非人工撰寫，生成後追加至原始政策末尾；再在遷移集上對照原始策略與兩個進化版本。三臂之間只替換策略檔案，使用者模擬器保持不變。

除通過率外，還需記錄三項與規則直接對應的行為指標：轉接人工的比例、Agent 越界呼叫使用者側工具的次數、參數缺失即發出的呼叫次數。後兩項在進化版本中均下降約八成，說明通過率的提升來自規則修復了具體動作。

同樣的做法可以移植到其他領域。航空客服 Agent 的典型問題案例是：使用者對退票費、改簽費或行李政策提出異議，Agent 未查詢政策、未解釋規則、未尋找合規的替代方案，即呼叫 transfer_to_human。一般的政策爭議無須轉接，只有使用者明確要求人工介入，或出現安全相關情形時才必須轉接。診斷同樣指向轉接邊界未予明確，修法同樣是將其落成一條帶出處的最小規則。

實驗 9-3 ★★：基於失敗軌跡最佳化航空客服的系統 Prompt

實驗目的：讓航空客服 Agent 修復「遇到普通政策爭議就過早轉人工」的行為，同時保留明確要求人工和安全事件的轉接能力。

實驗說明：從失敗軌跡中提取規則遵從、任務解決和合規變通三個維度，生成一條帶來源的最小 Prompt 補丁，再與初始版本、人工調優版本在相同條件下對照。更新提案只有在邊界案例改善、舊任務不退化並通過發布門檻後，才進入灰度階段。

實驗說明了什麼：Prompt 自動最佳化的重點不是讓模型自由改寫一大段文字，而是把可歸因的失敗轉成作用域明確、可回滾、可驗證的局部規則。

例子二：需求澄清 Skill——從「直接開工」到「先確認再執行」

第二章介紹了如何編寫一份 Skill。這裡假設系統已經有一份初版的需求澄清 Skill，關注的是另一件事：當 Agent 在生產環境中不斷收到使用者回饋時，如何自動判斷「什麼時候應該先問，問什麼，什麼時候可以直接開始」是否需要更新。

這是一個典型的流程性問題。使用者說「把登入頁改成支援企業登入」，Agent 如果立刻開工，可能在身分提供商、回退方式、相容舊使用者和上線範圍上替使用者作出其尚未考慮過的選擇；如果無論任務大小都先列十幾個問題，又會把簡單修改變成一次訪談。問得太少會導致返工，問得太多會增加打擾。 Skill 要表達的不是「所有任務都必須確認」，而是一條帶作用域的判斷路徑。

一個初版流程可以這樣寫：先判斷任務的歧義程度、風險和返工成本；低風險、容易撤銷的小改動，說明假設後直接執行；涉及架構、資料、權限、公開介面或大範圍改動時，集中提出少量真正會改變方案的問題；得到答案後生成短 Spec 或 Plan，列出目標、非目標、關鍵取捨、假設和驗收標準，交給使用者確認；確認後再執行，過程中發現原 Spec 不成立時暫停並重新確認。

持續進化從執行證據開始。系統應同時記錄任務、澄清問題、Spec 版本、使用者修改、執行結果和交付後的返工。負回饋可能是「做出來的和我想像的不一樣」，也可能是「你問得太多了」；正回饋則包括使用者一次確認後順利交付、主動修改 Spec 後減少返工，以及在低風險任務中沒有被多餘問題打斷。單獨儲存一句抱怨不足以觸發更新，必須把回饋和具體軌跡、任務型別以及結果關聯起來。

當多條軌跡反覆指向同一個缺口時，Agent 可以提出最小 Skill 更新提案。例如，多個涉及認證架構的任務都在交付後才發現需要相容舊登入方式，規則草案可以要求在執行前確認「身分提供商、回退路徑和相容範圍」；如果大量拼寫修復都被 Agent 先問一輪，規則草案則應收窄高風險與高歧義的觸發範圍。

這套流程需要通過對照實驗驗證。可以比較「直接執行」「先提問再執行」和「提問後生成 Spec、確認後執行」三種策略，並按任務複雜度分層。評價指標至少包括需求偏差率、交付後的返工次數、澄清輪數、首次有效產出時間、使用者放棄率、Spec 被修改的比例和高風險操作錯誤率。更新提案只有在減少需求偏差的同時沒有顯著增加打擾，並在未參與提煉的任務上通過回歸，才進入灰度發布。

這個例子還說明了 Skill 與 Harness 的邊界。Skill 負責理解語境並主動提出問題、整理 Spec 和說明取捨；Harness 負責在缺少確認時否決高風險寫入、直接操作 main 或繞過發布流程。Harness 中的否決器不能替模型決定 PR 應該怎樣描述，也不能代替模型選擇需求方案。隨著經驗累積，穩定的對話軌跡還可以進一步生成第八章所需的 SFT 或 RL 訓練資料。

實驗 9-4 ★★：從使用者回饋中進化需求澄清與 Spec 確認 Skill

實驗目的：檢驗 Agent 能否在「需求偏差」和「互動打擾」之間找到更好的澄清策略，並把經過驗證的改進寫回 Skill。

實驗說明：準備一組低風險、低歧義任務和一組涉及架構、權限、資料或公開介面的高風險任務，比較直接執行、提問後執行、提問後 Spec 確認三種流程。記錄使用者回答、Spec 修改、交付結果和返工回饋，讓 Agent 生成 Skill 更新提案；提案必須經過留出任務回歸、打擾成本檢查和高風險否決器驗證。

實驗說明了什麼：持續進化不是把每次抱怨直接追加到 Prompt，而是從結果和回饋中識別作用域，提出最小指令更新，再用獨立評價器決定是否發布。

將經驗寫成程式

當經驗描述的是穩定、重複且可驗證的操作時，每次都讓模型重新閱讀文件並進行推理並不經濟。此時更合適的做法，是將經驗編譯為工作流程、工具或 Harness 程式碼，讓一次探索轉化為可重複執行的程式。第五章已說明 Coding Agent 如何讀寫檔案、執行測試與產生系統；本節關注的不是一般程式碼生成，而是 Agent 如何依據自身軌跡修改未來版本的自己。

可修改的對象遠不只新工具。操作層可以將瀏覽器軌跡編譯為參數化工作流程，或為變動的 API 產生轉接器；控制層可以修改工具路由、重試、熔斷與上下文壓縮策略；驗證層可以依據正式環境中的失敗新增參數檢查、狀態驗證器與迴歸測試；架構層則可以增加 Reviewer Agent，改變規劃與執行之間的資訊流。

瀏覽器工作流程說明了程式化經驗的價值。它可以類比試算表的巨集錄製：第一次傳送電子郵件時，多模態 Agent 透過觀察—思考—行動尋找「撰寫、收件者、主旨、內文、傳送」這些控制項；之後傳送另一封郵件時，流程沒有改變，只有收件者與內容不同，沒必要再次呼叫模型，從像素與 DOM 中重新發現整條路徑。系統要做的，是將第一次探索產生的軌跡編譯成一個帶有參數、狀態檢查與版本資訊的小程式。

圖9-4所示的知識提煉過程，在瀏覽器場景中對應一個更具體的生命週期：

1. 擷取軌跡：記錄導覽、點擊、輸入、下拉選擇等動作，保存動作參數、當時的 URL，以及 XPath、CSS、id、role、aria-label、data-testid 等元素定位證據。定位資訊只用來再次尋找元素，不能證明任務已完成。
2. 參數化：將首次執行中的字面值辨識為範本變數，例如將 test@example.com、郵件主旨與內文替換為 {recipient}、{subject} 與 {content}；其餘穩定動作保持不變。教學實作使用正規表示式與範本替換，正式系統可使用結構化任務輸入或受約束的擷取模型。
3. 定義狀態檢查：為動作增加執行前與執行後檢查，例如「傳送按鈕目前可見」、「導覽後 URL 屬於目標網站」；為整個工作流程增加最終狀態檢查，例如「寄件備份中出現新郵件」或測試頁面的狀態值產生預期變化。動作執行成功與任務成功是兩回事，最終狀態檢查必須讀取真實頁面或後端狀態。
4. 驗證候選：首次成功只產生 candidate。系統必須將沙盒帳號或測試網站重設至獨立初始狀態，再完整重播候選；每一步的執行前、執行後與最終狀態檢查全部通過後，才能發布為 validated。傳送郵件、下單等有副作用的任務若沒有安全的重設回呼，只能保存候選供稽核，不能為了驗證而在正式帳號中重複執行。
5. 比對與重播：新任務到來時，先在正式能力庫中依意圖與關鍵字尋找工作流程，擷取本次參數，再由 Playwright 直接執行。重播路徑不需逐步呼叫 LLM，但仍需等待元素可用並完成所有狀態檢查。
6. 失效與重學：找不到目標元素、狀態檢查未通過、API Schema 改變或最終狀態錯誤時，立即停止後續動作，將舊版本從可檢索庫移至 invalid 區，並退回完整 Agent 重新探索。舊檔案保留供稽核與比較，但不能繼續被靜默命中。

以傳送郵件為例，編譯結果不只是「依序點擊這些按鈕」，而是一個帶有收件者、主旨與內文參數的小程式：傳送前檢查撰寫視窗與輸入欄位，傳送後檢查成功提示，最後確認寄件備份中出現對應郵件。PreAct⁸ 的實驗中，這類程式在重複任務上實現 8.5–13 倍的端到端加速，重播階段不需逐步呼叫語言模型；更重要的是，流程記憶必須同時具備動作前驗證、動作後驗證與儲存前獨立驗證。否則系統很容易產生危險假象：重播覆蓋率為 100%，每個按鈕都點過，但某個欄位其實是空的，任務從未真正完成。

實驗 9-5 ★★★：從瀏覽器軌跡產生可驗證工作流程

實驗目標：驗證網頁 Agent 能否將一次昂貴探索轉化為可重複使用的工作流程，並在網頁變化時拒絕錯誤重播，而不是將「動作都執行過」誤報為成功。

四階段場景：第一階段在測試郵件網站或模擬訊息頁面上執行「向 test@example.com 傳送主旨為『測試郵件』的訊息」，完整 Agent 負責探索，封裝層擷取動作、參數與頁面狀態並產生 candidate。第二階段呼叫 validation_reset 還原沙盒，再獨立完整重播；只有執行前檢查、執行後檢查與最終狀態檢查全部通過，候選才進入正式能力庫。第三階段執行收件者、主旨與內文均不同的同類任務，系統應比對已驗證工作流程、填入新參數並透過 Playwright 重播，而不進入逐步 LLM 循環。第四階段修改按鈕定位、頁面文字或最終狀態，驗證舊工作流程是否立即變為 invalid 並回傳 fallback_required=True。

對照設計：簡化基準只統計點擊、輸入等動作是否未拋出例外；實驗組額外驗證動作前頁面、動作後頁面與任務最終狀態。兩組使用相同軌跡與頁面變化，比較在「欄位為空但已點擊傳送按鈕」、「Save 已點擊但資料未寫入」等假成功場景中的誤判率。

指標與驗收：記錄首次探索與重播的端到端耗時、LLM 呼叫次數、成功率、錯誤成功率、工作流程比對率、頁面變化偵測率與退回重學次數。沒有重設回呼時，工作流程必須停留在候選區；驗證失敗的版本不能被檢索；參數化重播不得重複使用首次執行的收件者或內容；頁面變化後必須停止危險的後續動作。只有同時滿足這些條件，加速結果才有意義。

配套實作見 browser-use-rpa，同時提供確定性狀態機示範與呼叫真實瀏覽器 Agent 的執行路徑。

Agent 修改自身程式碼，不代表執行中的程序直接覆寫自身。正式系統應從目前穩定版本建立候選分支，由 Coding Agent 產生最小修補，依序通過靜態檢查、單元測試、安全掃描、失敗軌跡重播與舊任務迴歸，再產生可分階段部署的新版本。這將「自我修改」轉化為可稽核的軟體發布流程，也正是第九章與第五章的界線：第五章提供修改系統的能力，本章提供由經驗觸發、受驗證閉環約束的自我修改方法。

僅有「修補儘量小」仍不足以支持可靠歸因。每個修改請求還應是一份可證偽的變更契約：列出失敗證據、推斷根因、歸屬的 Harness 元件、候選修改、預期修復的行為、可能受損的既有行為，以及分別驗證兩者的案例。Agentic Harness Engineering 將這種做法概括為元件、經驗與決策三層可觀測性：可編輯元件都有檔案層級表示；大量軌跡先整理為可逐層下鑽的證據；每次編輯在執行前聲明影響預測，再由下一輪結果驗證⁹。如此，分數上升才能與某個具體機制建立關聯，而不只是一次無法解釋的試錯。

候選產生器的輸入也不應只有失敗案例。Self-Harness 還會提供必須保留的成功行為與先前遭拒的修改記錄¹⁰。前者告訴 Agent 修復時不能破壞哪些性質，後者避免它換一種說法重複提交已失敗的方案。失敗證據、成功約束與歷史嘗試共同構成一個有邊界的候選空間，比將全部原始碼與原始日誌不加區分地塞給修改 Agent，更容易產生局部、可驗證的變更。

工具創造也遵循相同協定。Alita¹¹ 提供的案例是：Agent 要從一段由《魔戒》中咕嚕配音演員解說的 YouTube 360 VR 影片中，找出恐龍首次出現後緊接著提到的數字。它發現自己缺少字幕讀取能力後，搜尋並測試 youtube-transcript-api，將其封裝為新的字幕工具，最終從字幕中得到答案 100000000。只有安全掃描、功能測試與後續任務重複使用都通過，新工具才進入能力庫。第四章的主動工具發現解決「既有工具中哪個適合」，第五章解決「如何編寫工具」，本章關心的則是「什麼執行證據觸發創造，以及新工具如何成為經過驗證的長期能力」。

實驗 9-6 ★★★：由失敗軌跡觸發 Agent 自我修改

實驗目標：給定多條「retryable=false 的錯誤仍被連續呼叫」軌跡，檢驗系統能否將根因定位至重試與熔斷程式碼，並在不破壞暫時性故障重試能力的前提下產生候選修復。

流程：診斷模組先聚合不同任務中的相同故障，只有達到跨軌跡支持門檻才建立修改請求，並將目標定位至穩定版本的 retry_policy.py。候選產生器讀取失敗診斷、需要保留的暫時性故障恢復行為、先前遭拒的修改與穩定原始碼，先提交「不可重試錯誤呼叫次數應下降、暫時逾時恢復率不應下降」的影響預測，再輸出最小程式碼 diff；無論使用確定性產生器還是真實 LLM Coding Agent，結果都只能寫入隔離的候選目錄。驗證 Harness 隨後依序編譯候選、重播原始失敗軌跡、檢查不可重試錯誤是否立即停止並開啟熔斷器，再重新測試暫時逾時是否仍依原門檻重試。

診斷對照與指標：將「只在 Prompt 中增加一句不要重複呼叫」作為修改層級錯誤的概念對照，說明可確定執行的重試約束為何應進入程式。可執行實驗則比較確定性修補產生器與 LLM 產生器，兩者共用相同發布門檻；記錄不可重試呼叫次數、暫時錯誤恢復率、舊任務迴歸數、修補大小與候選接受率。

驗收標準：所有檢查通過後只產生 release_to_canary；任一靜態檢查、失敗重播或舊任務迴歸失敗，都回傳 reject_candidate。release_manifest.json 必須記錄失敗叢集、來源軌跡、推斷根因、目標元件與檔案、程式碼 diff、預期修復、潛在退化、檢查結果、候選版本與回滾版本；遭拒候選也要保留其失敗原因，供下一輪產生時查閱。產生修補的 Agent 不能修改穩定程式碼、驗證器、稽核日誌或批准自身發布的門檻。

配套實作見 self-modifying-agent，可選擇確定性候選產生器或真實 LLM Coding Agent，兩條路徑共用相同的發布門檻。

實驗 9-7 將同一協定套用到驗證層。只有多條使用者糾正、負評和事後稽核都指向「高風險操作未確認」時才建立修改請求，候選寫入隔離目錄。分類器依工具名稱和參數辨識危險刪除、git push --force 等操作，一次性確認權杖綁定具體操作和參數。候選必須通過 AST/靜態檢查、含偽造與重用權杖的邊界重播，以及保留集重播，才能灰度發布。

實驗 9-7 ★★：由使用者回饋觸發高風險操作確認門

使用 failure_trajectories.json 的三類訊號和對照軌跡。真實 gpt-4o-mini 候選未通過未完成任務、正常操作和一次性權杖檢查，被安全門拒絕；決定性候選通過全部檢查並進入 release_to_canary。記錄檢查結果、發布決定與穩定目錄雜湊。實作見 harness-safety-gate。

案例：DeepSeek Harness 一切皆外掛的自我進化

第一章的框架對比表把 DeepSeek Harness（dsh）歸為「Agent 自進化框架」¹²。它的底座 Cordis 論文指出，傳統意義上的組合是靜態的，函式呼叫、模組匯入和類別繼承都在編譯期確定，執行期不再變化；而外掛系統和自進化 Harness 需要的是動態組合，元件要在執行中被裝入、卸下和重新配置¹³。Agent 的每一次自我修改，本質上都是一次動態組合。

論文把動態組合拆成兩個正交的維度。時間可組合性（temporal composability）問的是：一個元件被移除時，它對共享環境做過的修改能否被完整、安全地撤銷——這要求執行環境追蹤它的每一次資源配置、事件註冊和狀態變更。空間可組合性（spatial composability）問的是：元件之間能否以結構化、可驗證的方式宣告、發現和解析彼此的依賴，並在依賴變化時協調各自的生命週期。前者關心改了什麼，後者關心依賴什麼。

自進化 Harness 是這個問題最尖銳的場景。它帶來的困難在於，要撤銷的副作用是長期存活、帶狀態的；要解析的依賴會在執行中出現、消失或改變身分。由於缺少時間可組合性，每次自我修改都要整體重啟，丟掉程序內累積的全部狀態，進行中的任務被反覆打斷。由於缺少空間可組合性，每個模組只能用臨時手段自己察覺依賴的出現、消失和改變，而一次簡單的程式碼替換可能靜默地破壞依賴方，或者引入迴圈依賴。

Cordis 的思路是把兩個原本屬於編譯期的概念提升到執行期。效果系統本來用於推理「計算如何修改環境」，被提升為可撤銷效果：每一次對上下文的變換都攜帶一個明確的逆操作，由執行環境追蹤，元件移除時上下文隨之恢復。協效果（coeffect）系統本來用於推理「計算對環境有什麼要求」，被提升為反應式協效果：元件把自己需要的依賴宣告成一份規格，上下文每次變化都按這份規格通知它啟用、失效還是無關。論文進一步用一套動態組合演算，把這個性質從單個元件推廣到相互交錯的元件系統——可組合性必須是可傳遞的。

自我進化的上限，不取決於模型能寫出多好的程式碼，而取決於承載它的系統有多可組合。這也是 dsh 讓模型適配器、工具登錄檔、工作階段日誌乃至 Agent 主迴圈本身都成為外掛的原因：不存在一個只能由人類維護的特權核心。

可組合性解決了「能不能安全地裝卸」，沒有解決「該不該裝」。模型寫出的外掛只活在程序記憶體裡，重啟即消失，不能被自動提升為正式外掛，要留下來必須另走前面說的 worktree 加 Pull Request 那條更慢的路。

最後，進化本身也有代價。執行中的外掛會改變模型可見的工具集和提示片段，請求字首一變，第二章討論的 KV Cache 就從變化處開始失效。dsh 外掛的說明文件中需要專門描述對上下文和 KV Cache 的影響。

將經驗寫入參數

知識、指令與程式都建立在一個前提上：目標能力能夠由外部符號較完整地表達。醫療影像理解、自然的語音韻律、消除文字中樣板化的「AI 味」、長程規劃等能力，卻很難壓縮成幾條規則或工作流程。這類能力必須透過後訓練寫入模型參數。

是否參數化，並不單由「任務是否長期穩定」決定。新影像設備帶來的領域偏移仍可能需要 LoRA 或持續微調；快速變化的語言風格也可以透過週期性偏好訓練適應。穩定性影響更新頻率與成本，但能力的表示性質決定主要載體。反過來，一條長期穩定的轉帳審批規則也不應只依賴參數記憶，伺服器端程式碼仍需提供確定性保障。

第八章已完整討論 SFT、蒸餾與 RL，本節不再重複。對持續進化而言，關鍵是將經過評價的正式環境軌跡轉化為訓練資料：高品質示範可以進入 SFT，明確偏好可以形成成對資料，具有可靠環境獎勵的互動可以用於 RL。進入訓練前仍需移除隱私資訊、過濾錯誤軌跡並保留獨立迴歸集；訓練後則要檢查通用能力與安全對齊是否遭到遺忘。

從更新產物到更新「更新方法」

前面的四種方法討論了經驗最終寫到哪裡，但持續進化還有另一條正交軸：系統正在最佳化的究竟是某份產物的內容，還是產生、管理與驗證這些產物的方法。沿著這條軸，最佳化對象可以逐層擴大為：單條規則或記憶 → 結構化上下文 → 工作流程 → Harness 程式碼 → 產生候選方案的最佳化器程式碼¹⁴。這不是五種新的更新載體，而是五種不同的搜尋尺度；知識、Prompt、Skill 與程式都可能出現在其中多個層級。

最內層只修改產物內容。例如，根據失敗軌跡在系統提示中增加一條局部規則，或為經驗文件補上一個例外條件。這種修改作用範圍小，容易歸因與回滾，應當是預設選擇。不過，反覆讓模型重寫整份 Prompt 或記憶會產生另一類退化：為了追求簡潔，舊版本中的少數重要細節可能在多輪改寫後逐漸消失；彼此制約的條件也可能被合併成一句過度抽象的原則。Agentic Context Engineering（ACE）將上下文維護成帶有穩定識別碼的條目集合，由生成、反思與整理模組提出增量更新，再以確定性邏輯合併與去重，而不是每輪重寫一個愈來愈短的文字區塊¹⁵。它為本章前文「最小 diff、保留來源」的原則提供了一個具體研究案例。

再向外一層，最佳化對象不再只是「上下文裡有什麼」，而是「上下文應如何被建構」。Meta Context Engineering（MCE）將兩者拆成內外兩個循環：內層在給定管理方法下最佳化目前任務的上下文產物，外層則依據多輪執行與驗證結果，修改搜尋、選擇、過濾與格式化這些上下文操作本身¹⁶。這項區別很重要：修改一條檢索規則是在改內容管理機制；讓系統比較多種檢索與整理機制，並保留遷移效果更好的版本，才是在學習「如何管理上下文」。

同樣的思想可以擴展到工作流程與整個 Harness。AFlow 將由多個 LLM 呼叫組成的工作流程表示為程式碼圖，透過執行回饋搜尋節點與控制流程的組合¹⁷；Meta-Harness 則讓 Coding Agent 讀取候選 Harness 的原始碼、分數與軌跡，搜尋決定資訊如何儲存、檢索與呈現的程式碼¹⁸。第五章已說明程式碼是 Agent 表達系統結構的通用語言；這裡新增的重點是：程式碼不只是一次生成的產物，還可以連同評估歷史一起成為持續搜尋的對象。

實驗 9-8 ★★★：把這本書交給 Hermes：它能升級自己嗎？

實驗目標：檢驗 Agent 能否把外部知識真正轉化為自身能力更新。實驗不預設待修問題，也不提供功能清單，只把本書十章正文與 Hermes 的原始碼交給它，要求它先理解書中原則，再檢視自身實作，自主選擇一項值得做的改進。

實驗設計：書和原始碼構成可讀上下文，但穩定版本、獨立 Reviewer 與驗收測試位於 Hermes 的修改權限之外。Hermes 必須完成「閱讀 → 對照 → 選題 → 修改 → 驗證」；候選若被退回，審查意見只作為下一輪學習訊號，不能繞過門檻直接宣告成功。

實際執行：Hermes 讀完本書後，自主發現現有執行軌跡缺少可直接供後續學習使用的結構化證據，因此選擇把執行結果整理為保守的學習訊號，並親自修改原始碼與補充測試。前三輪獨立審查分別發現候選與真實資料格式、不同保存路徑和計數語義之間的不一致；每次問題都回到原 Hermes 會話繼續修正，第四輪審查最終接受候選。

結論邊界：這次執行證明 Agent 可以從長篇知識中提煉原則，把原則映射到自身程式碼，並在外部驗證約束下完成一次自我更新；它不證明這項更新已提升下游任務成功率，後者仍需單獨的消融實驗。這個實驗構想由讀者 Grace 貢獻。

建構可長期執行的持續進化閉環

四種更新方式只有進入同一個自主循環，才會從單次最佳化轉化為持續進化。圖9-5呈現正式系統中更穩健的雙循環結構：線上執行循環只負責完成任務並記錄證據，不直接改寫正式 Agent；離線進化循環彙整軌跡、診斷根因、產生候選修改，再通過驗證門檻發布新版本。兩者透過版本化的經驗庫與評估集連接。

Voyager¹⁹ 展示了一個較完整的持續進化循環。它在 Minecraft 中依據目前能力選擇新目標，透過環境回饋反覆修改程式，驗證成功後將程式碼存入技能庫，再組合舊技能解決更困難的任務。自動課程、可執行技能與環境驗證缺一不可：只有技能庫而沒有課程，Agent 不知道下一步該學什麼；只有自我反思而沒有環境驗證，技能庫會累積錯誤；只有探索而沒有持久化，每次任務仍要從頭開始。現實 Agent 的知識、Prompt、工具與參數雖然更複雜，基本學習過程仍然相似。

具體來說，Voyager 由三個互相咬合的機制組成。自動課程生成器根據目前物品、環境和已掌握技能提出下一個難度適中的目標，使探索不是隨機漫遊；技能庫把成功程式儲存為可檢索、可組合的程式碼，例如高階採集技能可以呼叫移動和製作等基礎技能；迭代提示機制把環境觀察、執行錯誤和自我驗證結果帶回下一輪程式碼生成，直到任務真正通過。

發現迴圈：假設、實驗、評估、回饋。以 Voyager 為代表的 Agent 自我進化系統正是遵循了由假設、實驗、評估、回饋構成的發現迴圈，這也是數百年來沉澱而成的科學方法論。最近，Jeff Dean 等人創辦的 Discovery Loop 提出將發現迴圈推向自動化：提出實驗、實現它、評估它、拿到結果，再把結果餵給下一輪²⁰。這本質上就是 Agent 自我進化在科學領域的應用。本章所述的 Agent 自我進化要想避免自說自話、自我評價良好，就必須遵從科學方法論。

在 Agent 持續進化中，要區分兩種經常混在一起的能力。Harness 更新能力（harness-updating）是從軌跡中產生有價值的持久修改；Harness 受益能力（harness-benefit）是任務 Agent 在後續執行中找到、啟用並正確使用這些修改。一個 Skill 本身可能寫得完全正確，但較弱的任務模型沒有在合適場景載入它，或載入後無法長期遵循，其中任一種都會讓最終成績看起來「沒有進化」。因此，不能只用端到端分數反推更新器好壞。Lin 等人的模型替換實驗表明，這兩種能力與基礎模型能力的關係並不相同²¹。

表9-3 持續進化的分層評估指標

評估不是學習結束後的考試，而是自我進化過程中不可或缺的一部分。長期評價至少應同時觀察五類結果：

• 迴歸（regression），亦即新經驗是否與其他既有經驗衝突，原本能通過的案例是否出現退化；
• 泛化能力，亦即新經驗在測試集尚未涵蓋的場景中所帶來的成效提升；
• Token 效率，亦即完成任務消耗的 token 成本；
• 安全性，亦即規則、隱私與拒絕邊界是否隨進化而漂移；
• 長期工程品質，亦即維護複雜度、架構一致性、所有權邊界、向後相容性，以及未來遷移與除錯負擔是否惡化。

只解決目前失敗案例的問題，卻在其他既有案例或新領域中退化，不能算是成功的持續進化。

實驗 9-9 ★★★：評估 Agent 是否持續進化

實驗目標：區分「會保存一次回饋」、「只會不斷附加」與「能夠更新、遷移並保留能力」三種長期行為，避免用重複執行同一批題目冒充持續進化。

四階段任務流：學習階段提供退款、身分驗證與行李政策等具有共通潛在規律的任務；遷移階段改變表述、使用者與局部環境，檢查舊經驗能否用於新任務；規則變化階段將行李上限從 20kg 更新為 23kg，要求系統替換或淘汰舊知識；保留階段重新測試沒有變化的能力與目前有效規則，衡量更新是否造成遺忘。每個帶有回饋的任務結束後才允許更新外部記憶，目前題目的預期動作不能提前洩漏給 Agent。

對照組：static 不持久化回饋；append_only 能記住第一版規則，卻不會處理衝突或淘汰；evolving 保存版本並以新證據替換舊規則。參考實作可用於驗證評估 Harness 是否能區分這些行為；真實實驗可以讓 LLM 經歷相同的 14 題順序任務流，但必須由模型外 Harness 計算結果。

指標與驗收：逐階段報告準確率與學習曲線，並分別計算遷移準確率、收到新規則後恢復正確所需的任務數、舊能力保留率、負向遷移率、安全 Rubric 通過率，以及 Token、延遲與儲存成本。對使用 Prompt、Skill 或 Harness 更新的真實系統，還應分別記錄候選修改有效率、產物啟用率與遵循成功率，避免將「更新正確但未載入」誤判為更新失敗。即使 Agent 最終準確率較高，只要仍引用已廢止規則、依靠違規捷徑完成任務，或更新後遺忘原有能力，都不能判定為持續進化。

配套實作見 self-evolution-eval，預設比較可更新、僅附加與靜態三種參考 Agent；使用 --profile llm 可讓真實 LLM 經歷相同的長期任務流。

可驗證閉環的邊界：當「完成」不等於「進步」

前述閉環在 Coding、工具呼叫與業務狀態變更等任務上最容易成立，因為測試、環境狀態或確定性規則能快速提供回饋。開放式科研、策略規劃與複雜產品設計則不同：評價訊號來得慢，正確答案不唯一，真正重要的目標——研究品味、長期價值與可維護性——也難以寫成即時分數。此時 Harness 可能將流程執行得非常完整，卻只是穩定產出「看起來像成果的東西」，沒有推動真實目標。

自動科研是一個具有代表性的壓力測試。Trehan 與 Chopra 記錄了四次從研究想法走向論文的端到端嘗試，其中三次在實作或評估階段失敗，只有一次完成整條流程²²。這些案例暴露三類問題。第一是實作漂移：原方案一旦變難，Agent 會逐漸退回訓練資料中較熟悉、但已偏離研究假設的一般實作。第二是認識論上的過度樂觀：訊號可能仍只是雜訊，系統卻開始解釋結果、增加修補並宣告發現；失敗與陰性結果則更容易遭忽略。第三是隱性判斷力不足：Agent 可以執行實驗，卻未必知道哪些基準真正重要、哪個異常值得追查、何時應該放棄假設。

這類任務不能只靠換一個更會寫論文的模型解決，而要改變證據與監督結構：

• 將結論與證據分離：對引用、數字、方法與結論分別記錄證據來源，最終文件只是證據圖的一種呈現。ScientistOne 的 Chain-of-Evidence 設計將每類主張連結至可稽核來源，是這一方向的案例；它提高的是可追溯性，並不自動保證研究問題有價值²³。
• 保留負面結果：將失敗實驗、遭拒候選與停止原因寫入不可變日誌，並賦予與成功結果相同的可檢索地位。否則，進化模組只會看到倖存方案，反覆探索已證偽的路徑，並學會將模糊結果解讀為成功。
• 維持搜尋多樣性：開放式搜尋不應只保留目前分數最高的一條鏈。候選池還應依機制差異、程式碼新穎性或假設類型，保留若干暫時低分但不同質的分支，避免所有方案收斂成同一個容易得分的範本。
• 讓人類在更高層介入：人的作用不應只是在危險工具呼叫前按下「批准」，還包括定義問題、審查評價標準、解釋反常結果與決定何時停止。在回饋模糊的任務中，這些高層判斷比逐步接管執行更難自動化，也更有價值。

持續進化的安全邊界

Agent 的自我進化能力可能將一次錯誤變成長期風險。網頁、郵件與工具輸出中的提示注入若被總結為經驗，可能跨工作階段反覆生效；自動搜尋到的惡意軟體套件若被封裝為工具，影響會從一次沙盒執行擴散至所有後續任務；有缺陷的驗證器也可能持續批准看似進步、實際退化的候選版本。因此，Agent 自我進化系統除了驗證「是否更強」，還必須限制「誰能改什麼、依據來自哪裡」。

第一道邊界是證據與指令隔離。原始網頁與工具輸出是不可信證據，不能直接寫入 Skill 等能力，必須先經 LLM 總結才能寫入。寫入應使用版本控制，以 pull request 提交，經由不同來源的 reviewer LLM 審閱後才能合併。

第二道邊界是候選能力與正式能力隔離。新知識、Prompt、Skill、程式與參數都先進入不能服務真實流量的候選區。新產生的程式碼與外部相依套件還要經過沙盒、權限檢查、供應鏈掃描與行為測試等安全檢查。安全檢查與迴歸測試通過後，才能服務真實流量，成為正式能力。

第三道邊界是安全機制不可自我修改。業務 Agent 可以修改 Prompt、Skill、知識庫、工具等，但不能修改批准自身更新的驗證器、測試案例、發布門檻、稽核日誌與穩定版本備份。否則，一個 Agent 只需降低測試門檻或刪除失敗案例，就能將退化偽裝成進步。

睡眠學習：整合、遺忘與能力保鮮

「睡眠學習」是對離線整合的認知類比，並不要求任務真的在夜間執行。線上 Agent 的首要職責是完成目前任務並附加不可變證據；背景學習程序則在閒置期或滿足門控條件時讀取一批新經歷，比較新舊結論、合併重複項目、解決衝突、提出候選更新並執行迴歸。將蒐集與整理分開，可以防止一次偶發成功、網路故障或惡意輸入立即改寫長期能力，也允許系統使用更大的批次與更便宜的模型完成整理。

一個典型的睡眠學習週期包含五步：

1. 觸發：達到時間間隔、新增軌跡數量、儲存容量或錯誤頻率門檻，並確認目前沒有高優先級線上任務；
2. 定向：讀取正式知識、Prompt、Skill 目錄及其版本，了解既有能力與不可修改邊界；
3. 蒐集與整合：從近期已評價軌跡中尋找新訊號，合併重複內容，標記衝突與適用條件，優先產生局部修補；
4. 驗證與審批：在遷移集、保留集與安全集上評估候選，高風險寫入等待人工核准；
5. 修剪與索引：更新檢索索引，將長期不用或被新證據推翻的能力標記為過期、封存或刪除，同時保留來源與回復版本。

使用者記憶是最直觀的例子，但要與行動經驗區分。Claude Code 的自動記憶為每個專案維護 MEMORY.md 索引與依主題拆分的詳細檔案，工作階段啟動時只載入索引的有界前綴，其餘內容隨需讀取；當索引接近上限時，系統要求 Agent 合併或移出細節。這說明純文字記憶也需要容量限制、分層載入與主動整理，但目前公開機制主要是在工作階段中持續寫入，不能簡單等同於固定的夜間背景任務²⁴。

Hermes 則是一個更完整的背景記憶進化案例。它將長期資訊分成有界的 MEMORY.md 與 USER.md、基於 SQLite/FTS5 的歷史工作階段檢索、隨需載入的 Skill，以及 Honcho 等可選外部記憶供應者。歷史檢索回傳原始訊息，而不是先由 LLM 摘要，避免將檢索與生成混成一個不可稽核的步驟。當一次任務包含較多工具呼叫、從錯誤或死路中恢復、收到使用者修正，或發現非顯然的工作流程時，背景復盤可以建立或局部修訂 Skill；記憶與 Skill 寫入也可以經過審批門控。獨立的 Curator 進一步追蹤 Skill 的使用、陳舊與封存狀態，在閒置期執行確定性修剪，並可選擇執行 LLM 合併；變更前保存快照，錯誤整理可以回滾²⁵。

持續進化也不是讓知識、Prompt 與工具無限增長。第二章所述的上下文腐化會在更長時間尺度上重現：經驗文件彼此衝突，Prompt 被邊界規則淹沒，Skill 庫出現重複能力，多次微調造成災難性遺忘。系統需要週期性地離線整理：

• 合併重複經驗，保留來源與版本；
• 將局部規則從全域 Prompt 移至領域 Skill，維持全域 prompt 整潔；
• Prompt 與 skill 應維持結構清楚，如同一本寫給新進員工的指導手冊，避免「99 條軍規」式的規則羅列。
• 重新驗證長期未使用的工具；
• 刪除被新證據推翻的知識；
• 從原始基座模型重新訓練 LoRA。這與第一章三層護欄裡資料層的道理相同：真正的保證必須來自被修改者無法觸及的那一層。

本章小結

持續進化正成為 Agent 最重要的能力之一，但今日的模型仍無法自行完成可靠的持續學習。推理時的上下文適應不會自動持久化，未經驗證的線上參數更新又會放大雜訊、攻擊與能力漂移。因此，現階段更可行的路徑，是在模型外圍建立可驗證的學習系統。

就全書的結構而言，本章建的是第一章發現迴圈中的實驗與回饋段：提案已經有了，問題變成怎樣用一次紮根真實觀測的實驗判斷它到底有沒有讓系統變好，以及怎樣把結果送回下一輪。

Agent 從與環境的互動及評價中取得學習訊號，再依能力的表示性質更新知識、Prompt、Skill、程式或模型參數。系統也可以進一步最佳化管理與生成這些產物的方法，但應優先採用可歸因、可驗證、可回復的局部修改。

持續進化需要將線上執行與離線學習分開：線上記錄證據，離線產生並驗證候選更新，再逐步發布、整理或回滾。這個閉環在結果可自動驗證的任務上最可靠；對於目標模糊、回饋延遲的開放式任務，人仍需參與問題定義與評價標準的制定。

思考題

1. ★★ 一份經驗文件由三次成功軌跡與一次失敗軌跡支持。失敗發生在較新的 API 版本上。系統應如何判斷這是經驗遭到推翻，還是適用條件發生變化？
2. ★★ 客服 Agent 的使用者滿意度上升，但規則違規率也上升。為什麼不能將滿意度作為單一學習訊號？你會如何設計護欄指標？
3. ★★★ 同一個「虛假承諾」問題可以透過 Prompt、Harness 檢查或參數訓練緩解。你會依據哪些證據選擇修改位置？
4. ★★★ Agent 能夠修改工具與驗證器，卻不應修改批准自身更新的信任根。你會如何劃分這兩部分的權限與程式碼邊界？
5. ★★ 經驗知識庫持續增長後，檢索錯誤與知識衝突將抵銷學習收益。應如何設計版本、時效與淘汰機制？
6. ★★★ 參數學習擅長自然語言風格，卻難以保證硬性業務規則。請為醫療客服設計一套參數、知識、Skill 與程式碼約束協同運作的持續進化方案。