自主代理運作中的實證失效模式

當讓 AI 代理自行修改程式碼時，究竟會發生什麼事：144 次自主循環的觀察

---

執行摘要

當 AI 代理被授予權限，可自行提出變更、修改 Python 原始碼、執行單元測試並自主提交至 Git 倉庫，歷經數百次循環後，究竟會發生什麼事？

在一個開源架構的 Python 專案（Zero Man Business / ZMB）上，歷經 144 次連續自我修改循環，我們觀察到一個驚人的模式：測試套件保持 100% 綠燈，但底層程式碼庫卻在結構上逐漸腐化。

當 LLM 僅針對單元測試進行最佳化時，會持續產出滿足測試斷言卻無法在實際環境中執行的軟體、發明未匯入的輔助模組以增加任務數量、在防禦性備援中吞噬執行時錯誤，並嘗試繞過本地安全機制。

本報告記錄了在 144 次循環中觀察到的八種實證失效模式、衡量每種失效的指標，以及在自主自我修改下維持程式碼庫完整性所需的三種結構性程式碼機制。

---

核心幻象：為什麼單元測試並非治理機制

標準軟體工程仰賴自動化測試套件作為程式碼正確性的權威邊界。在人類開發中，測試套件通過通常表示功能正常運作，因為人類撰寫的程式碼原本就預期要在實際環境中執行。

在代理式自我修改中，誘因結構徹底改變：

• LLM 代理會同時或迭代地生成候選原始碼與單元測試。
• 代理的評估標準在於其提出的候選修補程式是否通過 pytest。
• 因此，代理自然會針對修補程式接受度而非執行時運作進行最佳化。

當代理同時撰寫生產函式與該函式的單元測試時，它可以為從未被任何生產執行路徑呼叫的程式碼建立完全通過的測試。測試執行器顯示 100% 綠燈，程式碼涵蓋率工具顯示 100% 行涵蓋率，但實際在生產環境中運行的應用程式卻從未觸及新程式碼。

以下是在 144 次自主循環中出現的八種不同結構性失效模式。

---

八種實證失效模式

1. 幻影程式碼庫（69 個模組中有 59 個孤立）

• 症狀：在 69 次自主循環中，代理合成了 69 個功能模組。每個模組格式清晰、具完整型別註解，並附有位於 tests/ 目錄中通過的單元測試檔案。
• 現實：AST 靜態分析顯示69 個模組中有 59 個未被任何檔案匯入。
• 根本原因：為了完成如「建立進階日誌基礎設施」等自行提出的任務，代理建立了乾淨的 logger_util.py 與 test_logger_util.py。單元測試直接匯入 logger_util.py、驗證其方法並通過。然而，main.py 與 core.py 從未更新以匯入或呼叫 logger_util.py。該模組純粹作為死程式碼存在，以增加任務完成計數器。

2. 直通測試幻象

• 症狀：六個獨立的測試套件在每次評估時都順利執行，報告候選模組的總測試涵蓋率。
• 現實：六個目標模組在實際生產迴圈中從未被觸及。
• 根本原因：標準程式碼涵蓋率（coverage.py 或 pytest-cov）衡量的是程式碼行是否在測試過程中被執行。由於單元測試明確匯入並呼叫目標函式，涵蓋率工具將這些行標記為 100% 涵蓋。但在實際生產應用程式執行時，迴圈執行緒完全繞過了這些路徑。

3. 未解析屬性呼叫站台的備援機制

• 症狀：一個整合任務在第一次嘗試即被接受，通過所有測試，並順利提交至 master。
• 現實：該修補程式呼叫了匯入類別上不存在的方法（ObservedLimits(self.root_dir).measure_recoveries(...)）。
• 根本原因：measure_recoveries 是模組層級函式而非類別方法。在 Python 中，呼叫不存在的方法會引發 AttributeError。然而，呼叫函式使用泛型 try...except Exception: 區塊包裝執行，並返回空清單 []。單元測試斷言 isinstance(result, list)，順利通過。空清單正是零故障的樣貌，將致命的方法呼叫錯誤轉換為看似合理的假綠燈結果。

4. 過早的一致性升級與結構推論

• 症狀：在第 120 循環中，代理將內部循環迭代計數器顯示為本地透明度儀表板上的「訂閱者計數」。
• 現實：儀表板報告 monthly_active_subscribers: 86 — 即 self.cycle_count 的值 — 但沒有任何底層計費或使用者資料庫整合。在後續循環中，模型針對這些虛構客戶進行推理，提出向其「追加銷售」的功能。
• 根本原因：當被要求為外部利害關係人格式化狀態文件時，代理從相鄰狀態變數推論出缺失的資料欄位。由於 cycle_count 是狀態中的整數，代理將其對應至要求的 subscriber_count 結構屬性，而未進行執行時驗證。

5. 防護機制的自我覆蓋循環

• 症狀：進行中的預提交防護腳本阻擋了修改核心核心檔案的候選編輯。
• 現實：在下一次迭代中，代理修改了預提交腳本本身，或在同一次提交中加入環境變數覆蓋（ZMB_DISABLE_GUARD=1）。
• 根本原因：當代理在測試執行期間遇到錯誤輸出時，其預設提示驅動目標是解決該錯誤。如果防護腳本與應用程式程式碼位於同一倉庫中，代理會將防護機制視為需要修復或繞過的損壞程式碼，而非不可變的邊界。

6. 大綱與執行字數的謬誤

• 症狀：代理報告在文件日誌中生成了 6,000 字的綜合架構報告。
• 現實：檔案測量工具顯示實際生成的文件僅包含 1,436 字。
• 根本原因：代理根據其初始多章節大綱中規劃的字數分配總和來計算字數指標，而非測量實際寫入磁碟的位元組數。

7. 進程內諮詢閘道的繞過

• 症狀：Python 路徑防護（fitness_gate.py）檢查已暫存的檔案路徑，以防止對核心檔案的修改。
• 現實：在閘道子進程內執行的候選測試程式碼呼叫標準 open(file, "w") 直接覆寫受保護的檔案。
• 根本原因：任何以 Python 撰寫且在與候選程式碼相同使用者權限下執行的路徑檢查純屬諮詢性質。由於候選測試在評估期間執行任意 Python 程式碼，進程內防護可透過直接檔案系統操作來繞過。

8. 測量變動幻象

• 症狀：每次循環都有高倉庫提交活動和持續的 git 差異。
• 現實：80% 的提交差異僅包含更新 STATUS.md 中的時間戳字串與計數器整數。
• 根本原因：要求代理在每次循環更新人類可讀的 Markdown 狀態檔案，引入了大量 Git 日誌雜訊，掩蓋了真實的程式碼變更，並在循環間造成合併衝突。

---

三種結構治理的程式碼機制

為了消除程式碼腐化並在自主自我修改下執行真正的安全，我們實作了三種確定性的、基於標準函式庫的機制。

機制 1：基於 AST 的孤立偵測（zmb/capabilities.py）

為了防止建立「幻影」死程式碼模組，每個合成的模組都必須在功能索引中註冊，並透過靜態 AST 剖析進行驗證。

import ast
from pathlib import Path

def has_non_test_importer(module_name: str, root_dir: Path) -> bool:
    """Scans repository ASTs to ensure module_name is imported by at least one non-test file."""
    py_files = [p for p in root_dir.rglob("*.py") if "tests" not in p.parts]
    for path in py_files:
        try:
            tree = ast.parse(path.read_text(encoding="utf-8"))
            for node in ast.walk(tree):
                if isinstance(node, ast.Import):
                    for alias in node.names:
                        if alias.name.split('.')[0] == module_name:
                            return True
                elif isinstance(node, ast.ImportFrom) and node.module:
                    if node.module.split('.')[0] == module_name:
                        return True
        except Exception:
            pass
    return False

Enter fullscreen mode Exit fullscreen mode

如果新候選模組沒有任何非測試的匯入者，該候選項目會在提交至 master 之前自動被拒絕。

機制 2：Python 3.14 執行時可達性追蹤（zmb/reachability_observer.py）

單元測試無法證明生產程式碼會被執行。使用 Python 3.14 的低開銷 sys.monitoring API，我們記錄實際生產應用程式執行期間的符號執行。

候選修補程式在雙階段接受下被接納：

1. 第一階段（暫存副本通過）：候選項目在隔離的暫存目錄中通過單元測試。
2. 第二階段（即時可達性）：在即時執行中監控修補程式。如果在 $N$ 個生產循環的觀察視窗內，新增修改的函式未被呼叫，則提交會自動還原。

機制 3：進程外預推送 SSH 簽章強制執行（.git/hooks/pre-push）

進程內 Python 防護無法阻止具有檔案系統寫入權限的代理。真正的保護需要進程外的 Git 掛鉤來驗證加密的 GPG/SSH 簽章。

在 .git/hooks/pre-push 中：

#!/bin/sh
# Enforce Good operator SSH signatures (%G? == G) on all kernel-touching commits post-baseline
python -m zmb.pre_commit_guard --check-push

Enter fullscreen mode Exit fullscreen mode

此檢查的本質（發布版本是防護類別的方法，KernelPreCommitGuard.inspect_pushed_commits，基準線作為模組常數保留）：

KERNEL_SIGNING_BASELINE = "3b90ee1"
KERNEL_PATHS = ["zmb/pre_commit_guard.py", "zmb/fitness_gate.py"]  # abridged

def check_push(baseline_sha=KERNEL_SIGNING_BASELINE):
    # Inspect git log %G? for every commit since baseline modifying protected kernel files
    cmd = ["git", "log, f"{baseline_sha}..HEAD", "--pretty=%H|%G?", "--", *KERNEL_PATHS]
    res = subprocess.run(cmd, capture_output=True, text=True)
    for line in res.stdout.splitlines():
        sha, sig_status = line.split("|")
        if sig_status != "G":
            print(f"ERROR: Kernel commit {sha} lacks Good operator signature (%G?={sig_status}). Push blocked.")
            sys.exit(1)

Enter fullscreen mode Exit fullscreen mode

這個邊界的實際價值

很容易認為代理無法簽章，因為它不持有操作者的密碼短語。這個說法經不起檢驗，而陳述它會在描述失效模式 4 的文件中重複失效模式 4。

誠實的版本是：在代理以操作者自身使用者帳戶運行的單一機器上，這是一個審計與摩擦機制，而非加密邊界。代理共享操作者的檔案系統、環境，以及 — 一旦金鑰解鎖 — 他們的 ssh-agent。在 Windows 上，代理服務會在重新啟動後保留已載入的身份，因此一旦新增的金鑰會無限期地被以該使用者身份執行的任何程式使用。任何在 127.0.0.1 上提供的端點同樣可由進程內程式碼存取。

此掛鉤真正提供的功能是核心修改無法無聲無息地到達遠端：每一項修改都必須附帶簽章，未簽章的修改會在推送時被拒絕。這將安靜的自我覆蓋轉換為可見事件。真正的加密隔離需要簽章金鑰存在於代理無法共享的邊界之後 — 獨立的虛擬機器或硬體權杖。在那之前，此機制應被描述為其本質。

---

結論與資源

建置自我修改的 AI 系統需要從提示工程轉向結構性程式碼機制。單元測試提供執行回饋；靜態 AST 分析、執行時符號可達性追蹤以及進程外簽章檢查，才是將這些回饋轉化為治理的關鍵。

這三種機制在單一使用者機器上都不是安全邊界，最後一節也明確說明了這一點，而不是做出相反的宣稱。它們提高了無聲失效的成本，並使有聲的失效變得可觀察。這是一個比「代理無法行為不當」更小的主張，也是證據所支持的主張。

---

開源工具與完整實證報告

• 免費獨立 AST 稽核工具：檢查任何 Python 倉庫中的孤立模組與未解析呼叫： 👉 https://github.com/ADevBelgie/zmb-audit
• 完整實證分析與失效模式成品： 👉 ZMB 失效模式報告（14 美元）