前陣子在跟 AI 協作的過程中，腦中突然冒出一個很單純的念頭：
「欸，我們手上這個 Agent，單獨跑的時候都還有些控制不住的狀況了——如果同時放好幾個出去，然後期待它們互相監督……不是應該更混亂嗎？」
就這樣一個直覺。沒有什麼高深的理論框架，純粹是工程師的本能反應——你一個人寫 code 都會有 bug 了，找五個人一起寫，bug 不會變少，只會變成你不知道是誰寫的 bug。
然後我就開始順著這個念頭往下想。結果越想越覺得不對勁，尤其是對照到最近整個開發者圈燒得最兇的那個話題——Loop Engineering。
先回到原點：單一 Agent 到底有多「不穩定」？
我們不談什麼框架、什麼架構模式。先老實問一個問題：你手上的 AI Agent，跑一個任務的時候，有多少行為是你真的能掌控的？
幻覺（Hallucination）——會的，而且它不會告訴你它在幻覺。脈絡衰減（Context Degradation）——長對話跑到後面，它前面答應你的事會慢慢「忘記」。指令漂移（Instruction Drift）——做著做著，方向就偏了，但它的語氣依然充滿自信。Lost in the Middle——中間段的資訊特別容易被忽略，這不是偶發，是結構性的。
這些不是 bug，是 LLM 的固有行為特徵。頻率有在降低，但沒有被「解決」。
不過在單一 Agent 的工作模式下，這些問題至少還是你看得到的。你在場，輸出在你眼前，你覺得怪就能馬上介入。損害是局部的，因果鏈是短的。
好，那接下來的問題就來了。
Multi-Agent：那我們多派幾個互相盯，不就好了？
這想法其實很自然。Coder Agent 寫的程式碼可能有 bug → 加一個 Reviewer Agent 來 review → 再加一個 Verifier 來確認。就像團隊裡的 code review 流程，合情合理。
大家的期望是——就算單一 Agent 有盲點，讓不同角色的 Agent 互相監督，應該可以「圍堵」這些問題，對吧？
方向沒有錯。在特定的、被明確定義的問題範圍內，圍堵確實有機會縮小問題。
但這裡有一件事很容易被忽略。
你派去做「圍堵」的那個 Agent，它本身也是一個 LLM。它在執行圍堵任務的過程中，同時帶著一整組跟圍堵無關的不可控行為。
什麼意思？
Reviewer Agent 被派去做 code review，review 這件事本身可能做得不錯。但它同時可能因為 Lost in the Middle 效應漏讀了關鍵段落，然後基於不完整的理解給出「通過」判斷。或者它產生了一個幻覺式的 false positive——指出一個根本不存在的 bug——導致 Coder Agent 去「修正」一段原本正確的程式碼。越修越壞。
這不是「review 做得好不好」的問題。這是 Agent 作為 LLM，在執行任何任務時都會帶在身上的行為特徵。你給它一個「Reviewer」的角色名稱，這些特徵不會因此消失。
所以真正的問題結構是：你為了圍堵問題 A 而引入 Agent B，Agent B 對問題 A 確實有圍堵力，但它同時帶進了問題 X、Y、Z——而 X、Y、Z 不在你原本的設計範圍內，甚至可能不在你的觀測範圍內。
每多加一個「監督者」，你就多引入一組新的不可控變數。
撿一塊錢的故事
想到這裡，我腦中浮出了一個畫面。
每個人都看到地上有一塊錢。有人彎下腰去撿——天經地義，誰不撿？但他可能沒注意到，彎腰的時候，褲子在背後撐破了一個洞。
這個畫面有三層。
注意力錯位。 所有人的目光都盯在那一塊錢上（已知的 bug），所以「彎腰去撿」（派 Agent 去處理）這個動作完全不會被質疑。一塊錢在那裡嘛，不撿才怪。
代價發生在觀測範圍之外。 褲子破在背後，彎腰的人自己看不到。Agent 的幻覺、脈絡衰減、指令漂移，不會出現在它交回來的 review report 裡面。它回報的是「一塊錢撿到了」，至於過程中破了什麼，它自己也不知道。
損益不對稱。 一塊錢是確定的小收益，但褲子的修補成本可能遠超一塊錢。
然後——如果我們照 multi-agent 互相監督的邏輯繼續推演呢？
你發現前面那個人褲子破了，派第二個人去幫他補。但第二個人彎下腰補的時候，自己的褲子也破了。
然後你再派第三個人……
到最後，地上那一塊錢早就撿起來了，但所有人都在互相補褲子。
（有點像醫學上的「醫源性疾病」——治療本身產生新病症。吃藥治感冒，副作用傷胃；吃胃藥，副作用傷肝。每一步治療在目標上可能都有效，但副作用的累積是另一條不受控的因果鏈。）
那，數據怎麼說？
2025 年一個跨機構團隊跑了 180 組對照實驗，結論非常直接：
| 架構模式 | 錯誤放大倍數（相對單一 Agent） |
|---|---|
| 去中心化 multi-agent（各自跑，無協調） | 17.2 倍 |
| 中央協調式 multi-agent（orchestrator + sub-agent） | 4.4 倍 |
| 單一 Agent + 人類介入 | 1 倍（基準） |
17.2 倍。不是百分比。倍。
那自己跟自己跑呢？
前面講的是多個 Agent 之間的錯誤傳播。但你如果再想一層——其實最極端的放大，不是發生在 Agent「之間」，而是發生在同一個 Agent 對自己的輸出反覆迭代的時候。
為什麼？因為那是一個完全封閉的迴路。
同樣的偏差模式、同樣的幻覺傾向、同樣的盲點，在每一輪自我迭代中不但不會被修正，反而會被強化。它把自己上一輪的錯誤當成「已確認的事實」繼續推演，越跑越確信自己是對的。Multi-agent 之間至少還有一點異質性——不同的 prompt、不同的 context，偶爾能因為「看法不同」而碰撞出修正。但純自我迭代，連這個機會都沒有。
如果排個序的話：
錯誤放大程度：
純自動迭代（封閉迴路） ＞ multi-agent 無人監督 ＞ multi-agent 有人類協調
差異的關鍵變數只有一個：有沒有一個跳脫出 LLM 運作邏輯的外部判斷點。
好，記住這個結論。然後我們來看看最近最紅的那個東西。
Loop Engineering：最紅的方向，最高的放大倍數
2026 年 6 月，Boris Cherny（Claude Code 負責人）說了一句在開發者圈瘋傳的話：「我不再寫 prompt 了。我有 loop 在跑，它們在替我 prompt Claude 並決定要做什麼。」Peter Steinberger 跟著喊話，Addy Osmani 把概念正式命名，整件事幾天內燒遍社群。
聽起來很帥，對吧？
但用我們前面的框架來看，loop engineering 被推崇的核心主張——「設計一個系統，讓 Agent 自己找工作、自己做、自己驗證、自己記住做了什麼，without me in the loop at all」——這個 without me in the loop at all，本質上是什麼？
就是我們剛才分析出錯誤放大倍數最高的那個模式：Agent 對自己的輸出進行反覆迭代的封閉迴路。
（等等，所以現在業界最興奮的方向，剛好是數據上最危險的模式……？）
Loop 的支持者會說：「我們有 verifier、有 exit condition、有 test suite 當檢查點。」沒錯。但這些機制能涵蓋的，只有可量化、可二元判斷的東西——test 有沒有過、type 有沒有對、linter 有沒有通過。
一旦目標帶有主觀性、模糊性、需要判斷力——像「這個架構設計合理嗎」「這段程式碼三個月後還維護得動嗎」——Agent 就沒有辦法計算準確的停止點。而且就算通過了所有自動化測試的程式碼，也可能在架構層、可維護性、邊界情境上埋了你看不到的問題。
測試只能驗證你想到要測的東西。你沒想到的，它不會替你想。
有意思的是，連推 loop engineering 最力的人，結論都在幫我們做修正。Addy Osmani 那篇定義文的結語寫的是：「The loop changes the work, it does not delete you from it.」（loop 改變了工作方式，但它沒有把你從工作中刪除。）
Langfuse 團隊更直接，造了一個詞叫「Agent Slop」——由 AI agent 大量生產的低品質 AI agent。他們的警告是：如果你只讀 agent 或 evaluator 標記給你看的 trace，你就只會看到它已經被告知要看的那個切面。要抓住會漏掉的問題，你得自己去抽樣和閱讀。
簡單來說：你以為你設了哨兵，但哨兵只看得到你告訴它要看的方向。背後來的，它不知道。
所以現在到底是什麼情況？
把上面這些拼在一起看，現在的局面是一個蠻荒謬的結構性矛盾：
產業敘事畫了一條漂亮的升級路徑——Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering——每一層都在宣告「你可以做得更少，AI 可以做得更多」。
但實證數據告訴我們的是：人類退出迴路的程度，跟系統的錯誤放大率，是正相關的。
這兩條線是反著走的。
不是 loop engineering 本身有問題。重複性高、驗證條件明確的任務交給 loop 確實高效。問題在於敘事的包裝——業界把技術進展包裝成「你應該退到更後面」的故事，而不是「你應該站在更精準的位置」的故事。
「I don’t prompt Claude anymore」（我不再對 Claude 下任何提示詞）聽起來比「I now focus on the three critical verification points that only I can judge」（我現在會把注意力放在，只有我自己能夠裁決的三個關鍵驗證點上）性感太多了。但後者，才是那些真正用得好的人在做的事。
而且這裡有一個更殘酷的現實：那些有足夠經驗和判斷力、真的能設計好 loop 的開發者，他們用什麼方法都不會太差。真正會受傷的，是聽了「交給 loop 就好」之後、以為可以跳過建立 AI 直覺那個階段的人。
人類不是瓶頸，人類是斷路器
那人類到底該站在哪裡？
答案其實只有兩個字：驗證與協調。
人類在這個位置的不可替代性，不是因為人類比 AI 聰明——很多具體任務上 AI 確實做得比我們快也比我們好（這點老實承認）。
人類的價值在於：人類的認知系統跟 LLM 的認知系統是異質的。
LLM 的盲點有系統性的規律，人類的盲點跟它不重疊。當你需要的是「打破封閉迴路」的時候，重點不在驗證者有多強，而在驗證者跟被驗證者不是同一種東西。
就像電路裡的斷路器。它的功能不是讓電流跑得更快，而是在電流異常的時候切斷迴路，防止整個系統燒掉。人類在 AI 工作流中的角色，就是這個異質的斷路器。
拿掉斷路器來追求速度，就像拔掉保險絲來追求更大的電流。
短時間內確實跑得更快。
但你知道接下來會發生什麼事。
（提示：通常伴隨著一股焦味，然後是一段很長的沉默，最後是一句「……WTF，deploy 了嗎？」）
參考資料：
- Yubin Kim et al., “Towards a Science of Scaling Agent Systems”（2025.12）— 180 組實驗，multi-agent 錯誤放大率 4.4x–17.2x
https://arxiv.org/abs/2512.08296 - METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”（2025.07）— 自認快 20%、實際慢 19%
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ - Addy Osmani, “Loop Engineering”（2026.06）
https://addyosmani.com/blog/loop-engineering/ - Xinkui Zhao et al., “ProMAS: Proactive Error Forecasting for Multi-Agent Systems Using Markov Transition Dynamics”（2026.03）
https://arxiv.org/abs/2603.20260 - Langfuse, “AI is eating the AI engineering loop”（2026.06）—「Agent Slop」概念
https://langfuse.com/blog/2026-06-09-ai-is-eating-ai-engineering - Tianxiang Fei et al., “CodeDelegator: Mitigating Context Pollution via Role Separation in Code-as-Action Agents”（2026.01）— 脈絡污染正式學術定義
https://arxiv.org/abs/2601.14914
