多數人在談 Agent，會把優化集中在：
- 模型能力（更強的 reasoning）
- 工具能力（更多 tool）
- Prompt engineering
但如果你實際跑過 production 級 Agent，你會發現真正的瓶頸通常不是這些。很少有機會可以看到這麼完整的 agent 設計細節（通常只會看到 API）。但這次剛好有一個案例，幾乎把整個系統攤開，有機會向王者 Claude Code 學習。
而是：
attention 被污染，導致整個系統逐步失控。
這句話如果太抽象，可以這樣理解：
模型不是變笨，而是「注意力被垃圾淹沒」。
系統核心：Attention-Oriented Architecture
這個架構可以用一句話描述：
把 Agent 拆成「認知層」與「執行層」，並對 context 做分段治理。
白話一點：
讓「思考的人」不要被「做事的細節」干擾
讓「做事的人」不要背負整個世界的記憶
我會從 4 個維度拆：
- Execution Topology（執行拓撲）
- Context Lifecycle（上下文生命週期）
- Memory System（記憶體架構）
- Verification Loop（驗證閉環）
1. Execution Topology：為什麼要把 Agent 拆開？
傳統模型（Monolithic Agent）
User → Agent (Plan + Act + Memory + Tools)
這種設計的問題是：
一個大腦同時做所有事
- 一邊想
- 一邊做
- 一邊記
- 一邊 debug
結果會發生什麼？
- 很容易 shortcut（想一點就做）
- context 很快爆掉
- 錯誤會被放大
分層模型（Coordinator / Worker）
你可以把它想像成：
- Coordinator = PM / Architect
- Worker = 工程師
關鍵設計（這裡是精華）
Coordinator「不能做事」
- 不能改 code
- 不能下指令
- 只能思考 + 分配
這其實很反直覺，但非常重要
因為：
一旦可以做事，思考就會偷懶
（人也是一樣）
Worker「不能思考全局」
- 不能再開 agent
- 不能重新規劃
- 只能把任務做完
好處：
不會出現「無限遞迴開 agent」的災難
每個 Worker 都是「全新大腦」
runAgent() → new context
意思是：
每個任務都在一個乾淨的世界裡完成
沒有：
- 上一個任務的干擾
- 無關的對話
- 多餘的資訊
這裡有一個很重要的 insight：
多數 Agent 的錯誤，不是因為「不會做」，而是因為「看到太多不相關的東西」。
2. Context Lifecycle：注意力是怎麼被污染的？
先看問題本身。
(1) Context Snowball（雪球效應）
傳統 Agent：
context = history + logs + file content + reasoning
每做一步就加一點：
最後變成：
- 一堆 log
- 一堆 code
- 一堆錯誤嘗試
但模型每次都要重新讀一遍。
📌 問題在於：
模型沒有「忘記」的能力（除非你幫它）
(2) Auto-Compact：大刀砍掉
當 token 快爆了，就會：
歷史 → summary → 替換
好處：
- 快
- 簡單
壞處：
- 會丟失細節
可以把它想成：
「整理房間，把東西塞進抽屜」
(3) Micro-Compact：精準清理
這是這套設計最關鍵的地方。
它不是 summary，而是：
只刪掉「確定沒用的東西」
例如：
- 300 行的 file read
- npm install log
- 測試輸出
但會保留：
- 為什麼做這件事
- 做了什麼決策
- 發現了什麼問題
這裡的核心哲學：
模型需要「理解過」，但不需要「一直看到」。
白話比喻：
你看過一份文件後：
- 不需要把整份文件一直放在桌上
- 只需要記得重點
(4) Prompt Caching：避免重複思考
這個系統還做了一件很實用的事：
不要每次都重新讀一樣的東西
透過 caching：
- 重複的 context 不用重新算
- 工具結果用 reference
本質：
減少「無意義的注意力消耗」
3. Memory System：為什麼記憶反而會害你？
很多人做 Agent 會覺得：
記憶越多越好
但實際上：
記憶如果沒有控管，會變成另一種 context 污染
雙層記憶架構
Long-term Memory
↓
Session Memory
↓
Context
(1) Session Memory（短期記憶）
這是一個「偷偷運作」的系統：
背景會有一個 agent 幫你寫摘要
內容不是流水帳，而是：
- 現在在做什麼
- 哪些檔案重要
- 哪些方法失敗過
目的只有一個：
防止 context 被壓縮後「失憶」
(2) Long-term Memory（長期記憶）
這裡的設計很反直覺：
限制你「不能存什麼」
不能存：
- code（因為可以再讀）
- log（沒價值）
- git history（可查）
只允許存：
- 使用者偏好
- 決策模式
核心概念：
memory ≠ database
memory = 精華中的精華
4. Planning Control：為什麼要強制停下來？
很多 Agent 會有一個問題：
還沒搞懂，就開始做
Plan Mode（階段鎖）
探索（不能寫）
↓
產出計畫
↓
審核
↓
執行
限制：
- 不能改 code
- 只能讀
這其實在做一件事：
強制「先想清楚」
很像什麼？
- PR review
- 設計文件
5. Verification Loop：為什麼要找自己麻煩？
多數 Agent 的流程是：
寫完 → 覺得可以 → 結束
問題：
模型很容易「自我說服」
Verification Agent（找錯的人）
實作完成
↓
另一個 agent
↓
專門找 bug
而且它被強制：
- 不能改 code
- 一定要執行測試
它的任務不是證明對，而是：
想辦法讓它壞掉
測試方式：
- 同時打很多 request（併發）
- 塞奇怪數值（邊界）
- 重複操作（冪等）
本質：
引入「對立的思考」來對抗 bias
6. Tool Execution：為什麼效率也會影響注意力？
這裡比較偏工程，但其實很好理解。
Streaming Execution
邊生成 → 邊執行
不用等整段 JSON 出來才做事。
Parallel vs Mutex
- 讀檔 → 可以同時做
- 改檔 → 必須排隊
Sibling Abort
第一步失敗 → 後面全部停
為什麼這重要？
因為：
錯誤的步驟如果繼續執行，只會產生更多垃圾 context
7. 總結：這其實不是 Agent 設計，而是「思考系統設計」
這整套架構在解決的，不是單一問題。
而是一整組 attention 問題：
問題解法
想太多（context 爆炸）
compact
想太亂（污染）
isolation
想太快（沒理解）
plan mode
想太自信（bias）
verification
最後：一個更本質的觀點
傳統 Agent 在做的事是：
讓模型更強
但這套設計在做的，是另一件事：
讓思考環境更乾淨
當 attention 是乾淨的：
- reasoning 會變深
- hallucination 會下降
- 成本會變低
- 系統會更穩定
留給你的問題
如果你正在做 Agent，可以問自己：
你的系統，是在優化模型？
還是在優化注意力？
這會是兩條完全不同的路。
