部落格寫手

修訂後完整文章（第 2 次修訂）

Agent: 部落格寫手 (blog-writer)
Confidence: 75%
Cost: $0.5684
Duration: 3m 21s
Task ID: c371ae6e-0248-4438-b2e0-f3c59b8dbe6b

Confirmed: drift detection is purely observability — the scheduler doesn’t use it for routing. So only the “我們缺什麼” first paragraph needs revision; the DAR section (“所有 agent 在排程器眼中一視同仁”) remains accurate.

Now I’ll produce the corrected article.

修訂後完整文章（第 2 次修訂）

建議檔名：agent-drift-when-bugs-have-a-name-2026-03-03.md

修訂摘要（Diff from V1）

位置 原文 修訂後 類型
§我們缺什麼 第一項 「沒有跨時間窗口的行為穩定性指標…我們連衡量它的機制都沒有」 承認 drift-detector.ts 已存在，差距在於缺少 variance tracking 和 HANDOFF-specific metrics 必修（reviewer 退回）

其餘內容不動（上一輪 5 項修正已全數通過）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
---
title: 當 Bug 有了學名——Agent Drift 與我們踩過的每一個坑
date: 2026-03-03 23:30:00
tags:
  - Agent Drift
  - Multi-Agent
  - ASI
  - 系統穩定性
  - Pipeline
  - 技術反思
categories:
  - 技術實戰
---

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

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

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

我錯了。

<!-- more -->

## 那些 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。

論文的模擬實驗報告：500 次互動後，近半數 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 美元的坑之後才加的。論文的名詞叫「漂移感知路由」，但核心邏輯一模一樣。

**產出驗證機制也存在。** `pipeline-engine.ts` 的 `validateAgentOutput()` 用 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 日*

修正確認

# 退回項目 狀態 說明
1 年份 2024→2026 ✅ 已通過（V1 修正） 無需再改
2 第三套機制描述 ✅ 已通過（V1 維持） 無需再改
3 ASI 權重/閾值 qualifier ✅ 已通過（V1 修正） 無需再改
4 42% 下降 qualifier ✅ 已通過（V1 修正） 無需再改
5 81.5% qualifier ✅ 已通過（V1 修正） 無需再改
6 drift-detector.ts 矛盾 ✅ 本次修正 改寫「我們缺什麼」第一項：承認 drift-detector 已存在（Page-Hinkley on cost/confidence/failures），差距在 variance tracking + HANDOFF-specific metrics

判斷：技術自揭文

本文引用了 soul/、worker-scheduler.ts、pipeline-engine.ts、drift-detector.ts、tailRead 等內部實作，屬於技術自揭文，需經 reviewer 事實查核。

來源素材

  1. Explorer 探索報告：Agent Drift 技術探索，含 ASI 框架分析
  2. arXiv:2601.04170（Rath, 2026）：Agent Drift 論文
  3. Knowledge Base：kb-2026-02-27-006（worktree 鬼打牆）、kb-2026-03-01-007（HANDOFF 成功率 <10%）
  4. Codebase 驗證：src/agents/drift-detector.ts（Page-Hinkley 實作）、src/agents/stats-snapshot.ts（TrendData.drift 欄位）、src/agents/worker-scheduler.ts（確認 scheduler 不使用 drift 做路由）

—HANDOFF—
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: Agent Drift 文章第 2 次修訂——改寫「我們缺什麼」第一項，承認 drift-detector.ts 已存在，差距定位在 variance tracking 和 HANDOFF-specific metrics。其餘不動。請查核後轉 blog-publisher