通用 · AI Agent · 解體新書
前三卷各拆了一具具體的東西 — Claude Code（CLI）、Agent SDK（函式庫）、Claude API（協定）。三具都姓 Anthropic。本卷的對象不是任何一具，而是 「代理人」這個物種本身。它存在於所有廠商的所有實作之上：Claude / GPT / Gemini / Llama / Grok / 你自己訓練的小模型 — 只要有 LLM、有迴圈、有工具，就有 agent，就適用同一套原理。
本卷不討論「呼叫哪個函式」、不討論「設哪個欄位」。它討論的是：迴圈為什麼是迴圈、記憶為什麼分四層、計畫為什麼有反應式與審慎式之分、多 agent 為什麼常常做了反而更糟、評估為什麼比寫代碼更難。這些問題你選哪家廠商都會遇到，答案也大多通用。
十回章節由內而外：先定義 agent、拆認知迴圈，再講工具、記憶、計畫、反思這四個內部能力，接著放大到群體與護欄，最後落到評估與部署的工程現實。把這層打通，前三卷的選型就會從「死記名字」進化成「依原理推導」。
何謂代理人
What is an agent · drawing the line「Agent」這個詞被用得太鬆 — 任何用了 LLM 的東西都自稱 agent。本章先把線畫清楚：純 LLM 不是 agent、RAG 不是 agent、scripted workflow 不是 agent、chatbot 不是 agent。Agent 的最小定義 = LLM + 自主迴圈 + 工具。三樣缺一不可。其餘只是 LLM 的應用。
認知迴圈
The cognitive loop · perceive → reason → act → observe所有 agent 的內核都是同一個四站迴圈。它早於 LLM — 1980 年代的 BDI 認知架構、1990 年代的 robotics 控制理論、2000 年代的 reinforcement learning，全都用同一個框架：感知（perceive）→ 推理（reason）→ 行動（act）→ 觀察（observe）。LLM agent 只是把「推理」這一站換成了 next-token prediction，其他三站的位置不變。看懂這一個迴圈，你就看懂了所有 agent 框架。
工具之介面
Tool interface · function calling across vendors
所有現代 LLM 都用同一套抽象 — function calling：開發者宣告函式（name、description、input schema），模型在輸出中產生 {name, arguments} 物件。差別只在 wire format。本章把 OpenAI、Anthropic、Gemini 三家的格式並排，讓你一眼看出它們其實只是同一個概念的三種編碼。
function、Gemini 把 type 寫成大寫並用 OpenAPI 子集 — 但概念完全相同。type · properties · required · enum · description。記憶四界
Four realms of memory · cognitive science meets agents認知心理學自 Tulving 1972 之後把記憶分成四類：working、episodic、semantic、procedural。出乎意料地，這個分類在 LLM agent 上完全成立 — 對應 context window、過去 session、知識庫、工具/skill。本章把這個四象限攤開：每一界活在哪、怎麼讀、怎麼寫、會不會失效。看清楚你需要哪幾界，避免把東西塞錯地方。
常見錯誤 · 把東西塞錯界
把使用者偏好（episodic）塞進 system prompt（procedural）→ 每次都讀，浪費 token；把產品文件（semantic）全塞進 context（working）→ context 爆且查不準；把 skill 描述（procedural）放到 vector DB（semantic）→ 模型查不到也用不到。放錯地方比沒記憶更糟。
讀寫策略 · 不對稱
四界的「寫入頻率 vs 讀取頻率」差很大。working：寫多讀多；episodic：寫少讀少（但重要時刻要讀）；procedural：寫極少讀極多；semantic：寫批次讀按需。設計記憶系統時先畫出「誰會寫、誰會讀、何時」的矩陣再開工。
計畫之術
Planning · reactive ↔ deliberative spectrumAgent 要不要先擬一份計畫？這個問題沒有單一答案 — 它是一條光譜：左端是純反應式（每步現想），右端是純審慎式（先寫完整計畫再執行）。實務上多數成功 agent 落在中間：plan-and-execute（先擬中間粒度的計畫，執行時可修訂）。本章拆光譜兩端與中間幾種典型模式。
TaskCreate / TaskUpdate 工具讓它寫 todo — 把計畫物件化、可追蹤。Claude Code 的 TaskCreate 即此模式。反思之鏡
Reflection · self-critique & the Reflexion patternLLM 的第一答常常是錯的、第二答常常更好。這個觀察催生了一整套「自我修正」模式 — 從最簡的 self-critique 到 Reflexion (Shinn et al. 2023) 的記憶式反思、到外部 verifier 的客觀檢查。本章拆四種反思結構與它們各自的適用情境。反思不是萬靈丹：用對地方加分、用錯地方只是燒 token 走原路。
群體智慧
Multi-agent · topologies, protocols, & when NOT to多 agent 系統聽起來很性感 — 多個 specialist 彼此協作就像團隊 — 但實踐上最常見的結局是：成本爆炸、context 不同步、決策推卸責任、整體比單一 agent 更糟。本章畫三種主流拓撲，並更重要地：列出 「不該用 multi-agent 的紅燈情境」。
parallel ≠ multi-agent · 區分概念
單一 agent 可以同時派出多個工具呼叫（parallel tool use）— 這已經能拿到「並行」的好處，不需要 multi-agent 架構。Multi-agent 的「不同 system prompt / 不同 context」才是它真正的差別 — 但大多數任務不需要這個差別。
協調協議 · communication
multi-agent 的對話需要協議 — 純自然語言會發散且不可解析。實務上採用「結構化訊息」（JSON / 函式呼叫式）配合「明確的角色 prompt」。Anthropic 的「research 多 agent」與 Microsoft 的 AutoGen / Magentic 都用此模式。
護衛之圍
Guardrails · defense in depthAgent 會自主行動 — 這是它的力量也是它的危險。靠單一防線（例如「我寫了個好 system prompt」）不夠 — 任何單層防禦都會被繞過。安全的 agent 系統用縱深防禦：五層由內而外的護欄，每一層都假設前一層已被攻破。本章畫這五層的邊界與職責。
試煉之地
Evaluation · the testing pyramid for agents「你怎麼知道你的 agent 變好了？」這是 agent 工程裡最難回答的問題。傳統軟體可以靠單元測試 — agent 的非確定性讓單元測試只能驗證「沒崩潰」而非「答對了」。本章畫出 agent 評估的五層金字塔：從便宜快速但表淺的單元測試，到昂貴慢但有信度的人類審查。
LLM-as-judge 陷阱 · 自我評分
用 LLM 評另一個 LLM 的輸出很方便 — 但 judge 模型有偏見：偏好較長答案、偏好較複雜措辭、偏好它自己會寫的風格。當你要證明「新版比舊版好」時，至少做雙盲（隨機交換 A/B 順序）並用人類抽樣校準 judge 的判斷。
regression 監控 · 防退化
agent 的可怕之處：改 prompt 改一個字、換模型版本、加一個 hook — 都可能讓某些任務從通過變失敗。你需要 固定的 eval set + 自動回歸跑分，每次發版前對照歷史曲線。沒這個，就是憑感覺發版。
部署實戰
Deployment · observability, cost, latency, ops原型 agent 跑通是一回事，把它送上生產又是另一回事。Agent 的 ops 跟一般 web 服務有共通之處（監控、scaling、deploy），但也有自己的怪癖（單次請求可能跑 5 分鐘、成本不可預測、失敗可能是「答得不好」而非「拋例外」）。本章列出生產 agent 必備的五大 ops 能力。