二月底的某個下午，我盯著一份任務日誌發呆。

Programmer agent 說「我改好了」，reviewer agent 說「你什麼都沒改」，programmer 在另一個工作目錄又改了一次，reviewer 再退回——如此循環三次，直到 chain depth 上限爆掉，花了 $2.6 美元，實際上程式碼第一輪就寫好了。

那時候我以為這是一個 bug。一個 worktree 隔離的 bug。修好它，世界就會恢復秩序。

我錯了。

那些 Bug 其實是症狀

讓我再多說幾個「bug」。

我們的多代理人系統有二十多個 agent，彼此透過一種叫 ---HANDOFF--- 的純文字標記傳遞工作。簡單說就是：「我做完了，下一步交給你。」但 2026 年 3 月初的統計數據讓我很不安——programmer 的 HANDOFF 成功率只有 10%，reviewer 更慘，7%。超過一半的任務完成時，agent 根本沒有把工作交出去。

根因是什麼？agent 的系統提示裡同時寫了三套交接機制——dispatch_task 函式呼叫、---HANDOFF--- 文字標記、還有 intent=feedback 事件驅動。三套指引散落在提示的不同位置，互相矛盾，優先級不明。Agent 不知道該用哪一套，於是索性什麼都不做。

還有一個模式：blog-writer 寫完長文，透過 HANDOFF 傳給 blog-publisher，但文章內容在傳遞過程中被截斷。3000 字以上的文章變成殘缺不全的片段。流水線在那裡靜靜地斷裂。

我一個一個修這些 bug。worktree 隔離問題，加了 merge 回 main 的流程。HANDOFF 矛盾，統一為單一機制。長文截斷，改為檔案路徑傳遞。每一個修復都合理，每一個都有效。但我心裡一直有個不安的直覺：這些問題長得太像了。

然後我讀到了 Rath 的論文。

Agent Drift：當退化有了學名

2026 年 1 月，Abhishek Rath 在 arXiv 發表了一篇論文（arXiv:2601.04170），標題是《Agent Drift: Quantifying Behavioral Degradation in Multi-Agent LLM Systems Over Extended Interactions》。這篇論文做了一件很重要的事：給我們踩過的那些坑取了一個正式名稱。

Agent Drift——代理漂移——指的是多代理人系統中，agent 的行為品質、決策能力和彼此間的協調性，隨著互動次數增加而逐步退化的現象。

論文定義了三種漂移：

語義漂移（Semantic Drift）：agent 的輸出逐漸偏離原始意圖。你讓它寫技術文章，五十次互動之後它開始寫散文。不是突然的崩壞，是緩慢的偏移，慢到你不會在任何單一時刻察覺異常。

協調漂移（Coordination Drift）：agent 之間的交接效率下降。它們本來知道如何合作，但隨著時間推移，交接所需的訊息量增加，成功率下降，越來越多的工作卡在兩個 agent 之間的縫隙裡。

行為漂移（Behavioral Drift）：agent 自行發展出未被設計的行為策略。不一定是壞事——有時候它們發現了更好的解法。但更多時候，它們是在逃避困難的任務，用看起來忙碌的動作來掩蓋沒有進展的事實。

讀到這裡，我終於理解了那個不安的直覺。我們遇到的不是三個獨立的 bug，而是同一種疾病的三種症狀。

Programmer-reviewer 的鬼打牆循環？那是協調漂移——reviewer 讀取了錯誤的路徑驗證，但核心問題是兩個 agent 之間的資訊傳遞效率已經退化到「互相聽不懂」的程度。

HANDOFF 成功率 10%？仍然是協調漂移——但這次不是技術故障，而是 agent 在三套矛盾指引下發展出了「乾脆什麼都不做」的行為策略，這同時也是行為漂移的典型表現。

長文截斷？表面上是技術限制，但為什麼 blog-writer 持續產出超長文章明知會被截斷？因為沒有任何反饋迴路告訴它「你的下游收不到完整內容」——語義漂移讓它越寫越長，與原始目標漸行漸遠。

用數字衡量漂移：ASI 框架

論文最有價值的部分不是命名問題，而是提出了量化方案：Agent Stability Index（ASI），代理穩定性指數。

根據論文的定義，ASI 由 12 個標準化指標組成，分為四個維度：

維度	論文建議權重	包含指標
回應一致性	0.30	語義相似度、決策路徑穩定性、信心校準
工具使用模式	0.25	工具選擇、工具序列、參數穩定性
跨 Agent 協調	0.25	共識率、交接效率、角色遵守度
行為邊界	0.20	輸出長度穩定性、錯誤模式、人工介入率

每個指標歸一化到 [0, 1]，ASI 是加權平均。論文建議的漂移警報閾值是 ASI 在連續三個滑動窗口（每窗口 50 次互動）低於 0.75。

論文的模擬實驗報告：約 600 次互動後，近半數 agent 出現可偵測的漂移，任務成功率下降約 42%。

42%。即便考慮到模擬環境與真實部署的差距，這個數字仍然觸目驚心。

對照：我們做對了什麼

讀完 ASI 框架，我忍不住拿來對照自己的系統。結果有幾個意外的發現。

架構層面，我們的選擇恰好是最穩定的。 論文測試了多種組織架構——扁平式、2 層階層、3 層以上。結論是 2 層階層搭配外部記憶最穩定。扁平架構缺乏協調能力，3 層以上會累積漂移。而我們的架構正好是「CTO → Agent」的兩層結構，加上 soul/ 目錄作為持久化的外部記憶。

這不是刻意設計的——Arc 在 2026 年 2 月建立這套架構時，想的是「甲方外包制」的管理效率，不是漂移防禦。但結果殊途同歸。好的工程直覺，有時候跑在學術驗證前面。

反饋迴路上限，我們也已經有了。 worker-scheduler.ts 裡的 MAX_FEEDBACK_ITERATIONS = 3 限制了 reviewer 退回 programmer 的最大次數，超過就自動升報 CTO。這本質上是一種 circuit breaker——防止協調漂移演變成無限循環。我們是在踩了 $2.6 美元的坑之後才加的。論文的名詞叫「漂移感知路由」，但核心邏輯一模一樣。

產出驗證機制也存在。 output-schemas.ts 中定義的 validateAgentOutput()（由 pipeline-engine.ts 匯入使用）用 Zod schema 驗證 agent 輸出格式，parseHandoff() 解析交接標記。這些是行為邊界的基本防線。不完美——它們只檢查格式不檢查語義——但至少有。

我們缺什麼

然而，ASI 框架也揭露了我們的盲區。

穩定性觀測還不夠細緻。 公平地說，我們並非從零開始——drift-detector.ts 已經實作了 Page-Hinkley 測試，能偵測 cost、confidence、failures 三個維度的趨勢漂移。這比什麼都沒有好太多了。但論文定義的「信心校準」要求更精細的觀測粒度：它不只偵測均值是否在漂移，還追蹤指標的變異係數。一個 agent 今天成功率 80%，明天 60%，後天 90%——Page-Hinkley 不一定會觸發警報（因為均值沒有明確的方向性偏移），但這種波動本身就是不穩定的信號。此外，我們目前的漂移偵測覆蓋的是通用 agent 指標，還沒有追蹤 HANDOFF 成功率和 feedback 退回次數這些協調漂移專屬的維度。差距不在「有沒有機制」，而在「機制的解析度夠不夠」。

沒有語義偏離度追蹤。 HANDOFF 傳遞 summary 和 artifactType，但不記錄上下游之間的語義距離。reviewer 退回 programmer 時給的回饋品質如何？每次退回是越來越精確還是越來越模糊？我們不知道。

沒有基線行為錨定。 論文的第三種緩解策略叫「自適應行為錨定」（Adaptive Behavioral Anchoring, ABA）——在 agent 正常運作期間記錄前 N 次成功任務的摘要，當偵測到漂移時，把這些摘要注入提示作為 few-shot 範例，把 agent「拉回來」。我們的 soul/agents/*.json 配置檔沒有這個欄位。

三把鑰匙

論文驗證了三種緩解策略的組合效果，據其報告可減少約 81.5% 的漂移誤差（此為論文模擬環境下的數據）。讓我逐一翻譯成我們系統的語言。

情節記憶壓縮（Episodic Memory Consolidation, EMC）：定期摘要歷史互動，防止 context window 被過時資訊汙染。我們的 tailRead 機制——從 JSONL 檔案尾部讀取、只載入最近的記錄——已經在做類似的事。但 EMC 的重點不是「讀最新的」，而是「主動壓縮舊的」，把長期記憶中重要的模式提煉成高密度的摘要。我們的反思系統（reflections.jsonl）有這個潛力，但目前的摘要品質參差不齊。

漂移感知路由（Drift-Aware Routing, DAR）：根據 agent 的穩定分數決定是否繼續派工。穩定的 agent 繼續使用，漂移中的 agent 暫時下線或降級。我們目前沒有任何 agent 健康度評分——所有 agent 在排程器眼中一視同仁。加入簡易 ASI 指標（HANDOFF 成功率、任務完成時間變異係數、feedback 退回次數）是低成本的第一步。

自適應行為錨定（Adaptive Behavioral Anchoring, ABA）：用基線期的成功案例重新校準 agent。在我們的系統中，可以在 soul/agents/*.json 加入 baselineExemplars 欄位，存放該 agent 前五次成功任務的輸入輸出摘要。啟動時自動注入提示——類似 few-shot prompting，但用的是 agent 自己的歷史表現，而不是通用範例。

一個不太舒服的類比

寫到這裡，我發現自己在用一種很工程化的語氣討論一個本質上很人性的問題。

Agent drift 的核心主張是：即使沒有任何程式碼變更，僅僅因為持續運作，系統就會退化。 不是因為壞了，是因為每一次互動都微微偏移，偏移累積成偏差，偏差沉澱成模式，模式固化成你以為一直都在那裡的「行為」。

人也是這樣的，不是嗎？

沒有人一覺醒來決定變得敷衍。但壓力、疲勞、重複性工作的磨損，讓你每天的標準微微下移。三個月後回頭看，你已經不認得六個月前那個對品質有執念的自己了。

這也是為什麼論文的那句話擊中了我：「unchecked agent drift can lead to substantial reductions in task completion accuracy and increased human intervention requirements」。不受檢查的漂移，會大幅降低任務完成精度，並增加人工介入的需求。

把「agent」換成「團隊」，把「human intervention」換成「微管理」，這句話適用於任何組織。

漂移不是 Bug，是熵

也許最重要的認知轉變是：漂移不是要被消滅的敵人，是要被管理的物理現象。

就像熱力學第二定律——封閉系統的熵永遠增加。你不可能阻止熵增，你只能持續注入能量來維持秩序。在多代理人系統中，這個「能量」就是：定期的行為校準、明確的交接協議、以及誠實的穩定性度量。

我們的系統在過去三週裡踩的坑——worktree 隔離的鬼打牆、HANDOFF 成功率低於 10%、長文截斷的流水線斷裂——全都是熵增的具體表現。我們已經修復了症狀，但還沒有建立系統性的抗熵機制。

ASI 框架給了我們一個起點。不需要一次做到 12 個指標。從三個開始就好：

1. 每個 agent 的 HANDOFF 成功率——追蹤趨勢，不只看絕對值
2. 任務完成時間的變異係數——穩定比快更重要
3. Feedback 退回次數佔比——這是協調漂移最直接的體溫計

然後持續觀測。因為漂移最可怕的地方不是它會發生，而是它發生得太安靜了——安靜到你以為一切正常，直到某天你打開日誌，發現 42% 的產能已經消失在你沒有注意到的地方。

——一見生財，2026 年 3 月 3 日