你的 AI 代理寫程式碼的速度比你閱讀的速度還快

上週二，我的自主編碼代理在 9 分鐘內完成了一次涵蓋 47 個檔案的重構。測試通過了。程式碼檢查通過了。品質閘門零違規。我合併了 PR、部署上線，然後繼續處理下一件事。三天後，一位同事問為什麼支付服務的重試邏輯從指數退避改成了固定間隔輪詢。我完全不知道它被改了。代理的提交訊息寫著「refactor: standardize retry patterns across services」。這個變更在技術上是正確的。我從來沒有讀過第 31 個檔案的第 847 行。

已上線的程式碼與我理解的程式碼之間的落差，就是認知債務。

TL;DR

五個獨立研究團隊在同一週內發表了關於同一結構性問題的研究：編碼代理產出的速度超過了開發者驗證、理解和維護的能力。Margaret-Anne Storey 將這種模式命名為「認知債務」。Microsoft、ETH Zurich 及多所大學的研究人員正在建構系統來偵測代理的異常行為、讓工具呼叫具備交易性，以及評測代理如何透過互動進行學習。這種研究趨勢的匯聚之所以重要，是因為它顯示學術研究社群正在追趕實務工作者一直以來用臨時品質閘門解決的問題。代理可靠性問題現在有了名稱、分類法和五種競爭方案。以下內容涵蓋：研究論文、如何在您自己的工作流程中偵測認知債務，以及一個您今天就能實施的最小可行介入方案。

五篇論文、一週時間、一個問題

2026 年 2 月 15 日至 2 月 21 日之間，五個獨立團隊發表了針對 AI 編碼代理同一結構性缺陷的研究。他們互未引用。每一組從不同角度切入問題。所有人得出了相同的結論：代理輔助開發的瓶頸不再是程式碼品質。瓶頸是人類的理解能力。

Margaret-Anne Storey 提出了「認知債務」的概念，用以描述當代理產出的程式碼可能是乾淨的、經過測試的、結構良好的，但開發者卻逐漸失去對程式碼實際行為的掌握時所累積的東西。¹ 技術債存在於程式碼庫中。認知債存在於開發者的腦中。Storey 的框架將代理可靠性問題從「程式碼能不能運作？」轉移到「開發者理不理解這段程式碼？」

Microsoft 的 Nanda 等人發表了 Wink，一個自動偵測和復原編碼代理異常行為的系統。² 他們的分類法識別了三種失敗模式：指令偏離（代理做了與您要求不同的事情）、重複迴圈（代理反覆嘗試相同的失敗方法）、以及工具誤用（代理呼叫了錯誤的工具或傳入錯誤的參數）。Wink 即時監控代理行為，在異常行為加劇前進行干預。

ETH Zurich 的 Mohammadi 等人提出了 Atomix，一個將代理工具呼叫包裝在交易中的執行環境。³ 當代理的多步驟計畫在中途失敗時，Atomix 會回滾副作用。核心洞察：代理會對外部系統（資料庫、API、檔案系統）執行操作，而這些操作的後果在沒有明確回滾基礎設施的情況下是無法撤銷的。

Hallinan 等人建立了 OpaqueToolsBench，一個衡量代理如何透過互動而非文件來學習工具行為的評測基準。⁴ 現實世界的工具文件往往不完善。該評測基準測試代理是否能透過反覆嘗試來發現失敗模式、最佳實踐和邊界情況。研究發現：獨立探索工具行為的代理比那些獲得完美文件卻從未驗證的代理表現更好。

Deng 等人評估了 28 個基於 LLM 的滲透測試系統，並識別出兩個不同的失敗類別。⁵ A 類失敗源於能力缺失（錯誤的工具、不良的提示），工程手段即可修復。B 類失敗無論工具如何改進都持續存在，因為代理缺乏評估自身發現的判斷力。B 類就是認知債務問題以資安風險的形式呈現：代理找到了七個漏洞中的六個，但自信地報告系統是安全的。

研究趨勢的匯聚比任何單篇論文都更重要

一篇關於代理可靠性的論文很有趣。一週內五篇來自無關團隊的論文是一個訊號。研究社群正在獨立地得出與實務工作者透過生產環境故障所發現的相同結論。

我從 2025 年 5 月開始建構 Jiro 品質系統。該系統強制執行一個 7 步驟品質迴圈、一個 6 項標準的證據閘門，以及 7 個命名失敗模式，這些直接對應到這些論文所描述的模式：

時間線很重要。在生產環境中經過九個月的反覆除錯，一次又一次地建構品質閘門，最終形成的架構正是五篇研究論文現在獨立形式化的成果。結構性問題是真實的。臨時解決方案是有效的。研究正在透過框架、分類法和評測基準追趕上來，使這些解決方案可以被複製。

認知債務的三大定律

Storey 的框架準確地歸納了我在 11 個月的自主代理開發中觀察到的現象。無論模型、工具或領域如何，三種模式始終成立：

1. 認知債務隨速度複利增長。 我的代理在重構期間平均每分鐘產出 140-200 行有意義的程式碼變更（從 git diff 測量，排除空白行）。專注的人類開發者在積極編碼期間大約每分鐘產出 20-40 行。⁸ 以每小時 10 美元運行 Claude 的 Ralph 迴圈並不是產生人類開發者 5 倍的認知債務。它產生的遠遠更多，因為人類開發者的打字速度與其思考速度是耦合的。代理的輸出速度與您的理解速度毫無關聯。輸出加倍；理解保持不變；債務複利增長。

2. 測試通過不等於償還認知債務。 本週這批論文中的每一篇都將測試通過視為必要但不充分的訊號。Deng 等人的 B 類失敗通過了所有自動化檢查。Wink 的異常行為分類法包括代理產出能運作但不符合意圖的程式碼。我的證據閘門在「測試通過」之外還要求六項標準，而最難驗證的標準仍然是「開發者是否理解了什麼被改變了？」⁶

這裡有一個具體的例子。我的代理將一個資料庫查詢從子查詢重構為 CTE（通用表格運算式）。兩種方法返回完全相同的結果。測試通過了。CTE 版本在我們的資料集上運行速度慢了 3 倍，因為查詢規劃器無法將謂詞推入 CTE 中。我在兩週後的例行 EXPLAIN ANALYZE 檢查中才發現這個問題。代理的測試驗證了正確性。測試套件中沒有任何東西驗證效能特性。認知債務不是「程式碼寫得差」。認知債務是「我不知道執行計畫已經改變了」。

3. 認知債務在爆發之前是隱形的。 技術債會透過緩慢的建構、不穩定的測試和合併衝突來宣告自己的存在。認知債是沉默的，直到有人問「為什麼支付服務使用固定間隔輪詢？」而沒有人知道答案。Storey 的貢獻在於給這個隱形問題一個名字。

認知債務正在累積的五個警告信號

在修復問題之前，您需要先看到它。這五個信號會在生產事故之前出現：

1. 不重新閱讀就無法解釋上一次代理的 PR。 打開您的代理最近建立的 PR。不看 diff，描述什麼被改變了以及為什麼。如果您做不到，代表您合併了自己不理解的程式碼。我透過在審查流程中加入一行「摘要檢查」來追蹤這件事：在批准之前，我在 PR 評論中寫一句話的解釋。如果我寫不出那句話，代表我審查得還不夠。

2. 您的 git log --stat 顯示每次作業觸及 20 個以上的檔案。 現在就執行這個指令：

git log --stat --since="1 week ago" --author="$(git config user.name)" | \
  awk '/files? changed/ {files+=$1} END {print files, "files changed this week"}'

將這個數字與您能憑記憶描述的檔案數量進行比較。差距就是您的認知債務積壓。

3. 您審查 diff 是用滾動，而不是閱讀。 滾動是模式匹配：「看起來沒問題。」閱讀是理解：「這裡把重試間隔從指數改為固定，這代表下游服務將看到不同的流量模式。」如果您的審查每 100 行 diff 花不到一分鐘，那您只是在滾動。

4. 您的提交訊息描述了「做了什麼」，而不是「為什麼」。 「Refactor: standardize retry patterns」描述了代理做了什麼。「Fix: exponential backoff caused thundering herd after service restart」描述了為什麼。如果您的代理提交訊息讀起來像第一個例子而您沒有重寫，沒有人（包括未來的您）會知道變更背後的原因。

5. 您感覺很有生產力但說不出什麼改變了。 在使用代理工作一天結束時，憑記憶寫下三個最重要的程式碼變更。如果您覺得困難，代表代理很有生產力。您不是。債務在您感覺高效的同時悄悄累積。

從這裡開始：三檔案協議

您不需要 95 個鉤子、7 個命名失敗模式或多代理審議系統就能開始管理認知債務。從一條規則開始，逐步建構。

規則： 每次代理作業結束後，完整閱讀三個檔案。不是瀏覽。不是滾動。閱讀 diff 最大的三個檔案的每一行。

為什麼是三個？因為三個檔案是可行的（您真的會去做）而且具有診斷性（您會發現代理的變更是否與您的心智模型一致）。如果一致，您的債務是可管理的。如果不一致，您就有了一個領先指標，表明該次作業中其餘的變更也偏離了您的理解。

實施方法

代理完成後，執行：

# Show the 3 files with the largest diffs from the last commit
git diff HEAD~1 --stat | sort -t'|' -k2 -rn | head -3

然後閱讀這三個檔案。不是 diff。是完整的檔案。脈絡很重要：diff 顯示什麼改變了，但檔案顯示這個變更在脈絡中意味著什麼。

升級路徑

一旦三檔案協議成為習慣（大約一週），每次加入一個層級：

每個層級償還一個特定類別的認知債務。三檔案閱讀捕捉理解落差。PR 摘要捕捉意圖不一致。查詢檢查捕捉我上面描述的 CTE 事件。提交訊息重寫保留了否則會蒸發的推理過程。命名失敗模式防止重複犯錯。

研究提出的方案（以及實際有效的做法）

這五篇論文指向四種結構性介入方案。四種方案都以某種形式存在於我的 Claude Code 工具鏈中，在論文發表之前建構，由論文描述的相同模式驗證。

獨立驗證。 Wink 將代理行為與聲明的意圖進行對照監控。我的品質迴圈要求重新閱讀每一行寫出的程式碼，明確禁止幻影驗證失敗模式（聲稱測試通過但未在當前作業中執行）。⁷ 修復方案是結構性的：驗證必須由與產出輸出不同的流程執行。

在實務中，我透過一個後續作業鉤子來強制執行，該鉤子獨立運行測試套件，而不是信任代理的報告：

# Post-session verification hook (simplified)
# Agent says "tests pass" — verify independently
cd "$PROJECT_DIR"
test_output=$(python -m pytest --tb=short -q 2>&1)
exit_code=$?

if [ $exit_code -ne 0 ]; then
  echo "AGENT CLAIMED TESTS PASS. INDEPENDENT RUN FAILED:"
  echo "$test_output"
  exit 1
fi

代理報告「所有測試通過」而且是認真的。獨立運行捕捉環境差異、缺少的 fixture，以及透過副作用而非正確性而通過的測試。在運行這個鉤子的 11 個月中，它捕捉了代理自我報告中的 23 個偽陽性。⁹

交易邊界。 Atomix 將工具呼叫包裝在具有回滾功能的交易中。我的審議系統在不可逆操作前設置由多個獨立代理共識把關的閘門。兩種方法都在錯誤代價最高的節點為代理執行增加阻力。對大多數團隊來說，實用的版本是：在代理發起的任何資料庫遷移、部署或外部 API 呼叫之前，要求手動批准步驟。

行為分類法。 Wink 的三種失敗模式（偏離、迴圈、工具誤用）和我的七種命名失敗模式（捷徑螺旋、信心幻象、夠好高原、隧道視野、幻影驗證、延遲債務、空洞報告）服務於相同目的：透過命名讓隱形的失敗變得可見。⁷ 一個能說出「代理正在展現隧道視野」的開發者可以在債務加劇之前進行干預。先為您團隊最常見的三個代理錯誤命名。名稱比分類法更重要。

選擇性關注。 Deng 等人的 A 類/B 類區分以及我審議系統中的信心模組都編碼了相同的洞察：並非每個代理輸出都值得相同程度的審查。一個實用的經驗法則：

尚無人回答的問題

五篇論文都描述了問題。Wink、Atomix 和 OpaqueToolsBench 提出了部分解決方案。但沒有一篇回答了最關鍵的問題：如何衡量認知債務？

技術債有代理指標：循環複雜度、測試覆蓋率、相依套件年齡。認知債沒有對等的度量標準。我的證據閘門問的是「開發者是否理解了什麼被改變了？」但透過自我報告來強制執行答案，而這恰恰是信心幻象失敗模式所利用的驗證方法。

一個有用的度量標準應該追蹤代理改變的內容與開發者能解釋的內容之間的差距。檔案數量是一個粗略的代理指標。Diff 複雜度（不是行數，而是語意變更密度）更好。理想的度量標準應該與因對代理生成程式碼的誤解而導致的生產事故機率相關。目前還沒有人建構出這個度量標準。上方的互動計算器近似了這個比率，但比率不是閾值。我們還不知道「可管理的債務」與「等待發生的事故」之間的界線在哪裡。

在有人建構出那個度量標準之前，實用的答案與 AI 代理出現之前一樣：閱讀程式碼。代理的速度使得逐行閱讀變得不切實際。三檔案協議、行為分類法和交易邊界減少了需要人類關注的程式碼量。經過這些過濾器後剩餘的認知債務，才是真正重要的債務。

重點摘要

• 五個獨立研究團隊在一週內匯聚於同一個問題。 當無關的團隊同時得出相同的結論，底層問題是結構性的，而非理論性的。
• 認知債務是瓶頸，而非程式碼品質。 代理產出正確程式碼的速度超過開發者理解它的速度。測試、程式碼檢查和品質閘門減輕了問題，但無法消除它。
• 從三檔案協議開始。 每次代理作業結束後，完整閱讀 diff 最大的三個檔案。每週增加一個層級（PR 摘要、查詢檢查、提交訊息重寫、命名失敗模式）。
• 命名失敗模式。 Wink 的分類法和 Jiro 的命名失敗模式服務於相同目的：讓隱形問題變得可見。如果您的代理系統沒有為其失敗模式命名，您就無法偵測它們。
• 在不可逆邊界增加阻力。 交易性工具呼叫（Atomix）和多代理共識（審議）都在錯誤代價最高的節點增加成本。這個成本是值得的。

常見問題

參考文獻