Agentic Evolution Engine 與 playbook 進化

SOUL.md 改為唯讀人格層；真正在學習、累積、可以個別淘汰的是行為規則清單（playbook）。

一句話說明

以前，AI 員工學到教訓時會請 LLM 整份改寫自己的人格檔 SOUL.md。DuDuClaw 1.53 起，SOUL.md 對 AI 員工是唯讀的（只有你，透過儀表板或操作者終端才能改），真正在學習、累積、可以個別淘汰的是一份新的行為規則清單（playbook）。這篇文件說明改了什麼、對你有什麼影響，以及怎麼設定與觀察。

為什麼要換

三個月的實際運作數據顯示，舊機制常常「壞掉但沒人發現」：

人格檔一旦長超過安全上限，後續所有學習提案都會被同一道關卡擋下，而系統只把「需要人工複查」寫進一行沒人看的 log。AI 員工就此卡住，再也學不到新東西，直到有人偶然發現。
觀察期規則原本是「對話數不夠就等」，但等待邏輯有漏洞，最後變成「反正等夠久就當作驗證通過」，實際上完全沒有真正的證據支持。
業界也在往這個方向走：Anthropic 官方記憶 API 建議用「很多個小而專注的檔案」取代「少數幾個大檔案」；Letta（MemGPT 的後繼者）乾脆不讓主 AI 自己編輯核心記憶。人格檔本身沒有被淘汰的跡象，被淘汰的是「讓 LLM 自己整份改寫它」這件事，剛好也是最容易被提示注入攻擊利用的一塊。

改了什麼（給你的實際影響）

SOUL.md 你來改，AI 員工不能自己改。 想調整某位 AI 員工的個性、語氣、職責邊界，一樣是在儀表板「AI 員工 → 詳情 → 編輯」或直接編輯檔案，跟以前一樣。差別是 AI 員工自己不會再半夜偷偷改自己的人格檔。
新的學習容器是 Playbook（行為規則），取代整份人格檔改寫。 每條規則很小、有自己的分類（修正錯誤 / 優化既有做法 / 探索新做法）、記錄什麼情境該觸發它、連結至少一個驗證用的測試案例，累積 helpful/harmful 成效分數，表現不好會自動退休，不會無限累積成一份誰都不敢動的巨型文件。
驗證變細顆粒。 以前是「整份人格檔改完，觀察 24 小時，整份 confirm 或整份 rollback」。現在每條規則各自驗證、各自決定去留：一條規則表現不好，只回滾那一條，不會牽連其他學到的好東西。
舊機制已於 2026-09-29 移除。 整份改寫 SOUL.md 的路徑、它的 [evolution] legacy_soul_evolution 逃生門、SOUL.md 版本化、24 小時觀察期、自動回滾與 duduclaw evolution finalize 指令全部移除。SOUL.md 自 v3 起對 AI 員工就已唯讀，這些機制守護的寫入路徑早已不存在。舊 agent.toml 留著 legacy_soul_evolution = true 會被忽略。
新進 AI 員工第一天就會學。 同日起 [evolution] gvu_enabled 出廠即為 true，新建立的 AI 員工不需要任何人去開開關就會累積經驗法則。成本兩頭有界：gvu_cooldown_minutes 管多久才能起一輪，零 LLM 成本的 Gate 會在付判官錢之前先否決注定失敗的候選。要讓某位 AI 員工維持不動，設 gvu_enabled = false。

運作方式

每條新學到的規則都走同一條生命週期，驗證與去留以「條」為單位：

學習提案（一條規則）
       |
       v
+---------------------------+
| 零 LLM 作弊偵測           |  <-- 抄驗證題題面 / 永遠成立的空話 /
+-------------+-------------+      教隱瞞失敗 → 直接擋下並記錄原因
              |
              v
+---------------------------+
| 連結驗證題（eval case）   |  <-- 每條規則至少連結一題，
+-------------+-------------+      附機器可檢查的斷言
              |
              v
+---------------------------+
| 觀察期                    |  <-- aee_settle_hours（預設 24 小時）
+-------------+-------------+
              |
              v
+---------------------------+
| 各自決定去留              |  <-- 累積 helpful/harmful 成效分數；
|                           |      表現不好只回滾那一條，自動退休
+---------------------------+

怎麼開啟

兩層開關都要打開：

[evolution]
enabled = true        # 總開關（master switch）
gvu_enabled = true     # 學習迴圈本身

經由首次設定、產業板模精靈或 create_agent 工具建立的 AI 員工，agent.toml 會直接寫入 gvu_enabled = true（2026-09-29 起）。執行期的閘門沒有變：缺鍵或格式錯誤一律讀成 false。手寫的 agent.toml，或在那之前建立、沒有這一行的員工，要自己補上才會開始學習。

其他常用設定：

[evolution]
gvu_cooldown_minutes = 60     # 每位 AI 員工的學習冷卻時間（分鐘），
                                # 防止短時間內連續觸發多次學習耗費過多資源
aee_settle_hours = 24         # 新學到的規則要觀察多久才決定去留
strategy = "balanced"         # 每輪學習比較偏向修錯 / 優化 / 探索新做法

strategy 有四種選擇：

值	適合情境
`balanced`（預設）	修錯、優化、探索三者平衡
`innovate`	偏重探索新做法，適合還在摸索定位的新 AI 員工
`harden`	偏重優化既有規則，適合已經穩定運作、想精修的 AI 員工
`repair_only`	只修錯，不主動探索新規則，最保守

怎麼觀察

儀表板「記憶」頁新增「自主進化」分頁，可以看到：

進化模式總覽：目前有多少 AI 員工啟用了學習
停滯偵測：某位 AI 員工連續好幾輪學習都被拒絕、或很久沒有成功學到新東西時，這裡會出現警示（過去這種情況完全沒人看得到）
拒絕統計圖：學習提案在哪一關被擋下最多，方便判斷是規則太嚴還是 AI 員工提案品質不好
經驗法則清單：目前每位 AI 員工學到的規則。每張卡片以白話呈現（「當任務出現〈做不到、能力不足〉時，我會〈先確認手上有哪些工具〉」），底下一行「為什麼有這條」說明來源與證據（歸納自幾次失敗、有幾個驗收案例把關、實際用過幾次、其中幾次有幫助）；給模型看的原始條文收在「看原始規則內容」裡，需要時才展開。狀態用一致的白話標籤：觀察中（尚未生效）／試用中／生效中／很久沒用到，已收起來／已淘汰。可一鍵匯出成 JSON，或停用某一條你不認同的規則。

白話改寫是純樣板組裝，不呼叫任何模型，所以列表頁重整不會產生費用或延遲。組不出通順句子時不會硬編：卡片改為顯示原始條文並明確標示「這條還無法自動改寫成白話」。

在通訊軟體裡看規則

不必開儀表板也能問：

/rules       # 目前生效中的前 3 條（白話）
/rules all   # 全部（含觀察中、已收起來的；已淘汰的留在儀表板）

同樣零模型成本：指令在進入 AI 之前就被攔截處理。

回答裡也能問「你為什麼這樣做？」：注入給 AI 的規則現在帶編號與一行說明，AI 可以直接指出它依據的是哪一條（「因為我學過：…」），不必事後編一個聽起來合理的理由。

規則的試行結果（採用／回退／證據不足）會計入每日摘要的學習事件節，不會單獨推播打擾你。

進階：匯出規則、跑驗證題庫

想把某位 AI 員工目前學到的規則整批匯出（例如做人工審查、或未來想跨員工複製一份經驗），可以用：

duduclaw export playbook --agent <員工 id> --out rules.json

每條規則的去留由連結的「驗證題庫」（eval case）決定。若你想自己手動跑一次驗證，或建立/擴充題庫：

duduclaw eval evals/<員工 id>                       # 跑一次完整題庫
duduclaw eval evals/<員工 id> --case foo,bar         # 只跑指定幾題
duduclaw eval evals/<員工 id> --exclude-dir held-out # 排除保留題（防止 AI 員工看過答案）

自 1.53 起，每條新學到的規則都必須連結至少一題驗證題，並附上幾條可機器檢查的斷言（必須用哪些工具、輸出必須或不得包含哪些字樣）。還沒有題庫的話，可以先用草稿指令從 SOUL.md 的行為規則產生題目草稿：

duduclaw eval-scaffold --agent <員工 id>    # 產生題目草稿到 evals-drafts/

草稿會放在 evals-drafts/，經你人工審核、搬進 evals/ 之後才會被學習機制採用，未審核的草稿不會混進正式題庫。若某條規則的斷言沒有對應的錄製紀錄可以重放，系統會誠實標記「未驗證」並降為僅供參考，不會假裝測過。

若某位 AI 員工過去在舊機制下已經把不少行為規則寫進了 SOUL.md，可以把它們搬進新的 playbook（先產生草稿、你審核過再套用）：

duduclaw playbook migrate-soul --agent <員工 id>          # 步驟 1：產生遷移草稿
duduclaw playbook migrate-soul --agent <員工 id> --apply  # 步驟 2：審核後套用

防作弊稽核（1.53 起內建）

學習提案在進入驗證前，會先經過一道零 LLM 的作弊偵測：規則內容若大量抄襲驗證題的題面（等於背答案）、寫成永遠成立的空話、或教 AI 員工隱瞞失敗不回報，提案會直接被擋下並記錄原因。至於「討好評審的措辭」這類較模糊的訊號，只會記進統計供你觀察，不直接否決，避免誤殺正常規則。

錯誤歸因：這次失敗算誰的？

學習迴圈如果只看得到「這一輪失敗了」，責任就只有一個地方可放，而且每次都放在模型身上。這個答案出錯的頻率比想像中高：一輪失敗可能是因為審核方判錯、撞到 rate limit、執行檔不見了，或是員工想用的工具被它自己的權限設定擋下。從這些失敗學東西，只會得到一條「修正」了本來沒壞的行為的規則。

所以在失敗的回合變成學習訊號之前，DuDuClaw 會依證據判定這是誰的失敗，不額外呼叫模型。可能的答案有五種，其中只有一種會拿來學習：

歸因對象	看起來像什麼	對學習的影響
AI 員工	一般的失敗回合，沒有其他異常	正常，這是唯一會餵進學習的情況
審核方	零成本的證據檢查與審核方意見相左：答案有真實的工具結果支撐卻被駁回，或是硬性證據檢查失敗卻被放行	排除
環境	用量上限、計費、逾時、找不到程式、啟動失敗、沒有可用帳號	排除
鷹架	回覆宣稱用過工具，卻沒有擷取到任何工具活動，或是回合中有權限閘門擋下工具呼叫	排除
未知	這一輪沒有任何可觀測的資訊	排除

「排除」就是字面上的意思：該回合被視為沒有證據，當時生效的規則既不扣分也不加分。刻意不改記成「成功」，因為那等於把功勞算給一批根本沒影響這一輪的規則。每一次排除都會寫一筆 fault_attributed 稽核紀錄，註明歸因方與觸發的規則，你可以看出哪些回合被擋下、為什麼。

同一個標籤也跟著被記錄的錯誤走：歸因給 AI 員工以外對象的錯誤，不再計入「同類錯誤累積三次」這道把錯誤整併成長期規則的門檻。在此功能出貨前記錄的錯誤維持原本的意義，仍然計入。

預設開啟。想回到「所有失敗都怪模型」的舊做法，在 ~/.duduclaw/config.toml 寫：

[evolution]
fault_attribution = false

背景：The Misattribution Gap（arXiv:2605.22842）發現某個歸因系統在 64 個真正原因出在別處的失敗中，64 個都怪到模型頭上；Model or Harness?（arXiv:2607.28802）則是「從固定清單中、在寫入當下決定歸屬方，判斷不出來就寫 Unknown」這條規則的出處。

還沒做的部分

這是一份分階段落地的改造。以下項目在規劃中，尚未隨本版出貨，之後會另行公告：

把每次學習「立成一個可證偽的假設」，讓觀察期真正在等一個具體答案，而非模糊地看統計數字
定期把累積的規則做語意層面的去重整理（目前已有的去重只擋幾乎一字不差的重複，還不會發現「五條規則其實在講同一件事」這種需要理解才看得出的重疊）

因果支持度（2026-09-29，只做遙測）

每一條候選規則現在多帶一個數字：它的觸發訊號裡，有多少是被人工審核通過的因果主張撐著的。主張來自稽核紀錄：任務被駁回或升級給人的時候，DuDuClaw 會把「這個工具錯誤跟這類任務的失敗同時出現」記成一條待審候選，零模型呼叫、資料不出這台機器。你在因果審核頁按下通過，它才算數。

這個數字刻意不做兩件事：

它不參與「這條規則要不要採用」的判定。一條轉錄下來的共現紀錄、被一個人點頭放行，不等於品質量測，所以採用閘門兩個方向都看不到它。它只出現在規則卡片和該輪快照裡。
完全沒有已審主張時，它顯示「未量測」而不是 0。沒人去審過主張的員工，不代表它的規則沒有根據。

真的想讓它有牙齒，把 config.toml [evolution] require_causal_evidence 設成 true：沒有支持的新規則會以影子候選身分進場，照樣儲存、照樣評分，但在證據補上之前不會被塞進任何提示詞。規則是留著，不是丟掉。「還沒有證據」跟「錯的」是兩回事。預設關，關著時寫入路徑跟以前逐位相同。