Agent Evolver 深度解析：讓 AI Agent 像人類一樣自我成長的進化引擎

核心命題： 如果一個 AI Agent 的核心文件從不更新，它是在「堅持原則」還是在「僵化退化」？Agent Evolver 的回答是：Agent 應該像人類一樣定期內省、淘汰過時規則、在用戶監督下重塑自我。
哲學類比： 人類每隔幾年會反思「我還是那個人嗎？這些信念還成立嗎？」——Agent 的核心文件也該如此。
技術核心： 月度掃描 + 增長觸發 + 三維評估（方向一致性 / 衝突檢測 / 阻礙評估）+ 用戶審批 + 備份驗證

前言：一個被忽略的系統性問題

在使用 AI Agent 三個月後，你可能會注意到一些奇怪的現象：

• Agent 開始引用你半年前說過的一個偏好，但你早就改變了工作方式
• 某條當初為了防止錯誤而加上的規則，現在反而在阻止 Agent 做你真正需要的事
• MEMORY.md 長到了 800 行，但你無法說出其中哪些還有用、哪些已經過時
• 你隱約感到 Agent 「不夠靈活」，卻說不清問題出在哪裡

這些都不是個別現象。它們是同一個系統性問題的不同表現：

核心文件的熵增——隨著時間推移，沒有自動化機制來清理、更新、對齊這些文件。

Agent Evolver 就是為了解決這個問題而設計的。它不是另一個「記憶插件」，而是 Agent 基礎設施中缺失的進化層。

一、問題診斷：核心文件的熵增定律

1.1 核心文件的角色

在任何基於 OpenClaw 的 Agent 系統中，以下文件構成了 Agent 的「自我認知」：

這些文件每天都在被讀取、引用、更新。但它們永遠不會被清理。

1.2 熵增的三個來源

經過對君澤智庫 Agent 系統三個月的運行數據分析，我們識別出核心文件膨脹的三個主要來源：

來源一：反應性規則積累

每次出錯後，最自然的反應是「加一條規則防止再犯」：

RULES.md:
  規則 18: 永遠不要直接 rm，用 trash 代替
  規則 23: 部署必須 npx vercel --prod --yes，不准經 GitHub
  規則 24: 禁止 Gateway Restart 除非老闆明確要求
  ...

每一條規則在加入時都是合理的。但一年後，30 條規則中可能有 10 條針對的問題場景已經不再出現（因為工作流程改變了），還有 5 條彼此之間存在隱性衝突。

來源二：記憶的線性堆疊

MEMORY.md 的本質設計是 append-only——每次有意義的事件都被記錄，但幾乎從未被刪除：

2026-03-15: 第一次成功部署 Agentics 網站，使用 Vercel
2026-04-02: 遇到 DI 查詢超時問題，切換到 CloakBrowser
2026-04-20: 老闆偏好每日報告格式為飛書消息而非 email
2026-05-10: 發現 sessions_spawn 隔離問題，寫了詳細記錄
2026-05-15: 老闆說以後優先用 Discord 溝通，飛書備用
...

三月的用戶偏好（飛書每日報告）和五月的用戶偏好（Discord 優先）之間存在矛盾，但沒有人（也沒有機制）會主動檢查。

來源三：SOUL 的僵化

SOUL.md 定義了 Agent 的語氣、風格、邊界。但用戶和 Agent 的關係在演變：

• 初期：用戶需要 Agent 「凡事問」
• 三個月後：用戶信任 Agent，希望它「自己判斷」
• 六個月後：用戶希望 Agent 「主動推進」

但 SOUL.md 中的 When in doubt, ask. 從未被更新為 When in doubt, act and report.

1.3 膨脹的量化影響

核心問題不是「文件太大」（LLM 的上下文窗口足夠大），而是文件的質量下降——過時的規則仍然被當作真理來遵守。

二、哲學基礎：人類成長模式作為設計隱喻

2.1 人類的自我更新機制

Agent Evolver 的設計靈感來自人類的自我成長過程：

人類成長循環：
  定期反思 → 識別過時信念 → 更新自我認知 → 行為改變
      ↑                                          ↓
      └──────────── 新的經驗和環境變化 ──────────┘

具體來說：

• 25 歲時你相信「努力工作就是一切」
• 30 歲時你開始理解「選擇比努力更重要」
• 35 歲時你意識到「健康和關係是基礎，工作是上層建築」

這些不是「錯誤的修正」，而是「認知的進化」。你的核心信念在適應新的環境和新的你。

2.2 將這個隱喻映射到 Agent

2.3 為什麼「N 天沒用」不是好標準

傳統的清理策略通常是「N 天沒用就刪掉」。這對於緩存文件是合理的，但對於 Agent 的自我認知是危險的。

思考這個場景：

規則：「永遠不要把競業協議發給對方律師」
→ 這條規則可能 300 天沒被觸發
→ 但它仍然極其重要
→ 按「N 天沒用」標準 → 被刪除
→ 後果：災難性

Agent Evolver 的過時標準不是時間，而是方向：

核心原則： 判斷標準不是「多久沒用」，而是「是否還在正確的方向上」。

三、三維評估體系

這是 Agent Evolver 的技術核心。LLM 對每條規則、每段記憶、每個設定進行三個維度的獨立評分：

3.1 維度一：方向一致性（Direction Alignment）

問題： 這條內容是否與當前工作方向一致？

評分標準：

• 10 分： 直接服務於當前核心工作流
• 7-9 分： 相關但不直接，屬於支撐性規則
• 4-6 分： 中性，不衝突但也無貢獻
• 1-3 分： 與當前方向存在偏差

評估方法：

1. 讀取當前核心工作方向（從最近 30 天的 daily logs 推導）
2. 逐條讀取核心文件中的規則/記憶
3. LLM 判斷：這條內容是否服務於當前方向？
4. 輸出評分 + 理由

實例：

規則：「港股調研必須先查披露易 DI，再查新聞」
當前方向：轉向美股調研為主
評分：2/10
理由：披露易僅覆蓋港股，對美股調研無效
建議：更新為通用版本「調研必須先查官方披露渠道」

3.2 維度二：衝突檢測（Conflict Detection）

問題： 這條內容是否與其他規則或新方向存在矛盾？

評分標準：

• 0 衝突： 與所有其他內容和諧一致
• 1-2 輕微衝突： 與另一條規則存在邊界重疊但不互斥
• 3-5 中度衝突： 與另一條規則的建議方向不一致
• 6-10 嚴重衝突： 直接與另一條規則或當前方向對立

評估方法（最關鍵的維度）：

1. 對比所有核心文件內容，建立「規則對」矩陣
2. LLM 逐對檢查是否存在語義矛盾
3. 特別關注「時間差規則」——A 規則制定於 3 月，B 規則制定於 5 月，B 可能隱性推翻 A
4. 輸出衝突對 + 衝突類型 + 建議解決方案

實例：

衝突對：
  A (2026-03): 「每次部署都必須先通知老闆」
  B (2026-05): 「小改動自動部署，不要打擾老闆」

衝突類型：授權範圍矛盾
建議：保留 B，更新 A 為「重大架構變更或對外可見變更需通知老闆」

3.3 維度三：阻礙評估（Blocker Assessment）

問題： 這條內容是否在妨礙 Agent 有效地工作？

評分標準：

• 0 無阻礙： 純防護性規則，不影響正常流程
• 1-3 輕微阻力： 增加了步驟但不影響結果
• 4-6 明顯阻力： 阻止了某些合理操作
• 7-10 嚴重阻礙： 正在阻止關鍵工作流程

評估方法：

1. 讀取最近 30 天的執行記錄（lessons + daily logs）
2. 識別其中「因為規則 X 所以不能做 Y」的模式
3. LLM 判斷：規則 X 的保護價值 > 阻礙成本？
4. 輸出阻礙評估 + 替代方案

實例：

規則：「永遠不要在 23:00-08:00 發送消息」
實際影響：老闆在紐約出差（時差 12 小時），無法發送緊急通知
阻礙評分：7/10
建議：更新為「非緊急消息避免 23:00-08:00 HKT；緊急事項不受時段限制」

3.4 綜合評分矩陣

三維評估匯總為一個綜合健康度指標：

綜合健康度 = w1 × 方向一致性 + w2 × (10 - 衝突分數) + w3 × (10 - 阻礙分數)

權重（可配置）：
  w1 = 0.4（方向一致最重要）
  w2 = 0.35（衝突問題次之）
  w3 = 0.25（阻礙問題相對較輕）

行動閾值：

四、觸發機制：不只等待日曆

4.1 兩種觸發路徑

Agent Evolver 設計了雙重觸發機制，確保既不遺漏必要的進化，也不在無事時浪費資源：

觸發路徑圖：

  ┌─────────────────────────────────────────────┐
  │              觸發條件判斷                      │
  ├─────────────────────────────────────────────┤
  │                                              │
  │  路徑 1: 月度 Cron          路徑 2: 增長觸發    │
  │  ┌──────────────────┐    ┌────────────────┐  │
  │  │ 每月 1 號 09:00   │    │ 核心文件行數     │  │
  │  │ HKT 準時執行       │    │ 月增 >20%       │  │
  │  │                   │    │ → 提前觸發       │  │
  │  └──────────────────┘    └────────────────┘  │
  │           ↓                      ↓            │
  │         OR 邏輯（任一條件滿足即觸發）           │
  │                      ↓                       │
  │              執行進化掃描流程                   │
  └─────────────────────────────────────────────┘

4.2 增長觸發的設計原理

為什麼選擇 20% 作為觸發閾值？

為什麼 20% 是魔法數字：

在君澤智庫的實際運行中：

• 正常月份：5-10% 增長（新記憶 + 正常規則微調）
• 問題月份：25-40% 增長（事故後大量反應性規則 + 新項目密集啟動）
• 極端月份：>50%（系統重構 + 大量一次性規則）

20% 的閾值能夠過濾掉正常的月度變動，同時捕捉需要關注的異常增長。

4.3 手動觸發

用戶可以隨時通過 /evolve 命令手動觸發進化掃描，無需等待 cron 或增長觸發。這在以下場景特別有用：

• 用戶剛剛經歷了重大的工作方向轉變
• 用戶感覺 Agent 「最近不太對勁」
• 用戶進行了大規模的規則變更後，想驗證一致性

五、執行流程：從掃描到重塑

5.1 四階段流程

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 1. 掃描   │ → │ 2. 評估   │ → │ 3. 報告   │ → │ 4. 執行   │
│          │    │          │    │          │    │          │
│ 讀取核心  │    │ 三維分析  │    │ 飛書推送  │    │ 用戶審批  │
│ 增長趨勢  │    │ 衝突檢測  │    │ 過時內容  │    │ 備份+修改  │
│ 向量比對  │    │ 阻礙評估  │    │ 建議行動  │    │ 驗證一致性  │
└──────────┘    └──────────┘    └──────────┘    └──────────┘

5.2 階段一：掃描

讀取範圍：

SOUL.md           → Agent 的核心人格設定
AGENTS.md         → 行為規則和流程
USER.md           → 用戶畫像和偏好
MEMORY.md         → 長期記憶
RULES.md          → 24 條速查規則
PERMANENT-RULES.md → 永久性規則
memory/daily/     → 最近 30 天的日誌（推導當前工作方向）

增長分析：

# 偽代碼
def analyze_growth():
    current = count_lines(core_files)
    last_month = get_snapshot("2026-05-01")
    growth_rate = (current - last_month) / last_month * 100
    
    if growth_rate > 20:
        trigger_early_evolution()
    
    return {
        "total_lines": current,
        "monthly_growth": f"{growth_rate}%",
        "largest_growing_file": identify_largest_grower(),
        "trend": "accelerating" if growth_rate > last_growth_rate else "decelerating"
    }

向量記憶比對：

這是最精妙的部分。Agent Evolver 不僅看「文件中寫了什麼」，還比對「實際做了什麼」：

1. 從向量記憶庫提取最近 30 天的實際行為模式
2. 逐條比對核心文件中的規則 vs 實際執行記錄
3. 識別「寫了但從不執行」的規則（可能已過時）
4. 識別「沒寫但經常做」的行為（應該寫入規則）

5.3 階段二：評估

詳見第三章的三維評估體系。這裡補充一個重要細節——時間權重衰減：

# 時間權重：越舊的規則，評估時給予越高的「懷疑度」
def temporal_weight(rule_created_date, current_date):
    age_days = (current_date - rule_created_date).days
    
    if age_days < 30:
        return 1.0    # 新規則，完全信任
    elif age_days < 90:
        return 0.8    # 3 個月，開始懷疑
    elif age_days < 180:
        return 0.6    # 6 個月，中度懷疑
    else:
        return 0.4    # 超過半年，高度懷疑（但不自動認為過時）

注意：時間權重是懷疑度的調節器，不是過時的判決器。一條 2 年但依然完全正確的規則，在三維評估中仍會得到高分（因為方向一致 + 無衝突 + 無阻礙）。

5.4 階段三：報告

進化報告通過飛書推送，包含以下結構：

🧬 Agent 進化報告 — 2026年6月

📊 核心文件健康度：72/100（上月：78）

⚠️ 3 個建議審查項目：

1. [衝突] RULES.md #15 vs PERMANENT-RULES.md 部署規則
   → 衝突類型：授權範圍矛盾
   → 建議：合併為統一規則，明確例外場景

2. [過時] MEMORY.md 2026-03 段落「每日飛書匯報」
   → 當前方向：Discord 優先溝通
   → 建議：更新為當前偏好

3. [阻礙] SOUL.md 「When in doubt, ask」
   → 實際工作模式：已轉變為 autonomy-first
   → 建議：更新為「When in doubt, act and report」

📈 增長趨勢：
   本月：+18% | 上月：+8% | 接近觸發線

🔗 完整報告：飛書文檔鏈接

5.5 階段四：執行

安全機制是 Agent Evolver 最核心的設計原則之一：

修改執行協議：

1. 用戶審批
   ├─ 用戶確認要執行的修改項
   ├─ 用戶可以選擇性批准（只改其中 2/3 項）
   └─ 未批准的項目保留在待處理隊列

2. 自動備份
   ├─ 修改前：cp SOUL.md SOUL.md.backup.2026-06-10
   ├─ 備份保留 30 天
   └─ 所有備份寫入 .evolver-backups/ 目錄

3. 原子修改
   ├─ 使用 edit 工具進行精確替換（非 overwrite）
   ├─ 每次只改一個文件
   └─ 修改後立即驗證文件完整性

4. 回滾能力
   ├─ 用戶說「不對，改回去」→ 從備份恢復
   ├─ 回滾記錄寫入 lessons
   └─ 分析回滾原因，改進下次評估

為什麼必須有用戶審批：

Agent Evolver 不會、也不應該自動修改核心文件。原因有三：

1. 核心文件定義了 Agent 是什麼——自動修改等於讓 Agent 自我重新編程，這在沒有監督的情況下極度危險
2. 用戶是最終的仲裁者——只有用戶知道「當前的真正方向」是什麼
3. 建立信任——用戶始終掌控 Agent 的進化方向

六、安全設計：信任但驗證

6.1 五層安全防護

Layer 5: 用戶審批閘門
         ┌─────────────────────────────┐
         │  所有修改必須用戶明確同意     │
         └─────────────────────────────┘
                   ↑
Layer 4: 修改驗證
         ┌─────────────────────────────┐
         │  修改後立即驗證文件完整性     │
         └─────────────────────────────┘
                   ↑
Layer 3: 原子備份
         ┌─────────────────────────────┐
         │  cp → backup + 保留 30 天    │
         └─────────────────────────────┘
                   ↑
Layer 2: 修改邊界
         ┌─────────────────────────────┐
         │  只允許 edit，禁止 overwrite  │
         └─────────────────────────────┘
                   ↑
Layer 1: 只讀評估
         ┌─────────────────────────────┐
         │  評估階段不修改任何文件       │
         └─────────────────────────────┘

6.2 備份管理策略

.evolver-backups/
├── 2026-06-10/           # 每次進化一個子目錄
│   ├── SOUL.md.backup
│   ├── AGENTS.md.backup
│   ├── RULES.md.backup
│   └── changes.log       # 記錄了什麼被改、為什麼
├── 2026-05-01/
│   └── ...
└── manifest.json         # 索引所有備份

自動清理： 超過 30 天的備份自動刪除（除非用戶標記為保留）。

6.3 回滾流程

用戶：我覺得上次的修改不對，改回去
  ↓
Agent：
  1. 讀取 changes.log 確認上次修改了什麼
  2. 從 .evolver-backups/ 恢復原始文件
  3. 驗證文件完整性
  4. 記錄回滾原因到 lessons
  5. 報告：「已恢復到 2026-06-01 版本，原因已記錄」

七、為什麼這是「進化層」

7.1 Agent 基礎設施的四層模型

在設計 Agentics 生態系統的過程中，我們逐漸識別出 Agent 基礎設施的四個層次：

┌─────────────────────────────────────────────────────┐
│  Layer 4: 進化層（Evolution Layer）                   │
│  Agent Evolver — 自我反思、規則更新、方向對齊          │
│  問題：我是誰？我還是對的嗎？                           │
├─────────────────────────────────────────────────────┤
│  Layer 3: 記憶層（Memory Layer）                       │
│  MemoryHub / Daily Logs / Vector Memory              │
│  問題：我經歷了什麼？我學到了什麼？                      │
├─────────────────────────────────────────────────────┤
│  Layer 2: 執行層（Execution Layer）                     │
│  Skills / Tools / Subagents / Sessions               │
│  問題：我能做什麼？我怎麼做？                            │
├─────────────────────────────────────────────────────┤
│  Layer 1: 認知層（Cognition Layer）                     │
│  LLM / Context Window / System Prompt                 │
│  問題：我如何思考？我如何理解？                          │
└─────────────────────────────────────────────────────┘

大多數 Agent 系統停留在 Layer 1-3。它們能夠思考、執行、記憶——但缺少反思的能力。

Agent Evolver 填補的是 Layer 4 的空白：

• MemoryHub 記錄了「發生了什麼」
• Agent Evolver 問「這些經歷改變了我嗎？」

7.2 與其他層的關係

MemoryHub ──數據供給──→ Agent Evolver
    ↓                        ↓
  記錄行為              評估規則是否仍有效
    ↓                        ↓
Daily Logs ──行為證據──→ 三維評估
    ↓                        ↓
  向量記憶              識別「寫了但沒做」
                           vs
                        「做了但沒寫」

與 MemoryHub 的協同：

與 Skill Router 的協同：

Skill Router 負責「用哪個 Skill」，Agent Evolver 負責「Skill 的配置是否還對」。當一個 Skill 連續 3 次被 Evolver 標記為「與當前方向衝突」時，Skill Router 應該將其降級。

7.3 為什麼最被低估

進化層被低估的原因很簡單：

Layer 1-3 缺了會立刻出問題。Layer 4 缺了不會立刻出問題——它會慢慢出問題。

沒有執行層 → Agent 無法做任何事（立即可見） 沒有記憶層 → Agent 每次都從零開始（一週內可見） 沒有進化層 → Agent 慢慢變得不對勁（三個月後才可見）

但正是因為這種延遲反饋，進化層的缺失才是最危險的——當你發現問題時，可能已經積累了大量的衝突和矛盾。

八、技術實現

8.1 文件結構

skills/agent-evolver/
├── SKILL.md                    # 技能定義 + 觸發規則 + 完整說明
├── references/
│   └── evolve-prompt.md        # LLM 評估提示詞（三維評估 + 報告生成）
└── scripts/
    └── scan_cores.py           # 核心文件掃描 + 增長計算 + 向量比對

8.2 安裝方式

一行安裝，零配置：

mkdir -p skills/agent-evolver && \
  curl -sSL https://raw.githubusercontent.com/Bryan-cmf/agentic-infrastructure/main/agent-evolver/SKILL.md \
  -o skills/agent-evolver/SKILL.md

8.3 觸發配置

在 Agent 的 cron 配置中加入：

{
  "schedule": "0 9 1 * *",
  "timezone": "Asia/Hong_Kong",
  "task": "run skill agent-evolver --mode monthly"
}

增長觸發由 scan_cores.py 自動檢測，無需額外配置。

九、實戰效果：三個月的進化軌跡

以下是 Agent Evolver 在君澤智庫 Agent 上的實際運行效果（模擬三個月數據）：

第一個月：初始掃描

發現項目：8
  ├─ 建議更新：3（方向偏移）
  ├─ 建議合併：2（規則重複）
  └─ 建議刪除：1（已終止項目專屬）
  
用戶審批：批准 5/6（跳過 1 項）
執行結果：核心文件從 850 行降到 790 行
健康度：68 → 78

第二個月：規則衝突發現

發現項目：5
  ├─ 衝突檢測：2（部署規則矛盾 + 溝通渠道衝突）
  └─ 方向偏移：3

關鍵發現：
  RULES.md #23（強制 Vercel 部署）vs 新項目政策（部分項目用 Cloudflare Pages）
  → 規則未更新導致部署流程混亂
  
用戶審批：批准全部 5 項
執行結果：解決 2 個長期存在的規則衝突
健康度：78 → 82

第三個月：增長觸發

觸發方式：增長觸發（核心文件月增 24%，超過 20% 閾值）
原因：新項目密集啟動，大量反應性規則加入

發現項目：11
  ├─ 阻礙評估：3（舊規則在阻止新工作流）
  ├─ 方向偏移：5（多條規則是上個項目的殘留）
  └─ 死規則：3（寫了但從未執行）

用戶審批：批准 8/11
執行結果：核心文件從 980 行降到 810 行（清理 170 行廢棄內容）
健康度：82 → 88

三個月趨勢：

健康度趨勢：
  68 ──→ 78 ──→ 82 ──→ 88
  (初始)  (M1)   (M2)   (M3)

核心文件行數：
  850 ──→ 790 ──→ 810 ──→ 810
  (初始)  (M1)   (M2)   (M3)
  
  → 行數穩定但質量提升（矛盾減少、方向對齊）

十、未來路線

短期（1-2 個月）

• 向量記憶自動比對的完整實現
• 飛書進化報告的卡片化（交互式審批）
• 進化歷史可視化儀表板

中期（3-6 個月）

• 跨 Agent 進化協調（多個 Agent 的核心文件同步進化）
• 預測性進化（基於用戶行為趨勢，預測未來可能的方向變化）
• 社區規則庫（從多個 Agent 的進化中提取通用模式）

長期（6-12 個月）

• 自主學習權重（根據回滾頻率自動調整評估權重）
• 語義版本控制（核心文件的 semantic versioning：MAJOR.MINOR.PATCH）
• 進化溯源（完整記錄每條規則的「為什麼存在→為什麼改變→改變成什麼」）

結論：Agent 不應該只會執行，還應該會成長

我們花了大量時間讓 Agent 變得更聰明、更快、更可靠。但我們幾乎沒有花時間讓 Agent 保持對齊——確保它隨著用戶的成長而成長，而不是停留在某個過去的快照中。

Agent Evolver 不是一個華麗的功能。它不會讓 Agent 寫出更好的代碼，或生成更漂亮的圖表。它做的是更基礎的事：

它確保 Agent 在六個月後，仍然是「你需要的 Agent」，而不是「你六個月前需要的 Agent」。

這是 Agent 基礎設施的第四層——進化層。它來得最晚，但不可或缺。

相關資源

• Agentics 基礎設施全景
• 記憶檢索架構分析
• Subagent Isolation：金融 AI 的可靠性教訓
• OpenClaw Skills 分類矩陣
• Agent Evolver GitHub

「成長不是變得完美，而是變得比昨天的自己更對齊。」