作者：Yanhua
Antonio Gullí 是 Google 的工程總監。他寫了一本 453 頁的書，將 AI Agent 開發拆解為 21 種設計模式。
但這不是一篇書評。我讀這本書的動機很具體：我寫過 Harness Engineering，寫過 Clawdbot 的踩坑經驗，寫過「AI 智能體不是魔法」那篇從燒 Token 到真正好用的七個轉折，每次寫完之後都有一個沒完全想透的問題：這些東西背後有沒有一套可以複用的底層邏輯？
This book gave me the answers, and even deeper than I expected.
你寫的可能根本不是 Agent
書中最犀利的判斷藏在 prologue 裡。
大多數人使用的「AI」只是 Level 0：裸 LLM，沒有工具、沒有記憶、不會行動。你問它 2025 年奧斯卡最佳影片是哪一部，它只能猜。書裡寫得很清楚：Level 0 的東西，不是 Agent。
往上走才是真 Agent：
第 1 級：工具使用者
Agent 開始使用工具：搜尋、API、資料庫。但它不僅僅是「能調用接口」，更要自行判斷何時該調用、調用什麼，以及如何使用結果。書中提供了一個具體的例子：當用戶問「最近有什麼新劇」時，Agent 自行意識到這類資訊不在訓練資料中，因而主動調用搜尋工具查找，並整合結果。關鍵在於「自行意識到」——不是人類告訴它「你去搜一下」，而是它自己判斷需要搜尋。這種判斷能力，是第 1 級的門檻。
第 2 級：戰略思考者
多了兩樣東西：規劃和 Context Engineering。書中定義了 Context Engineering：不是做資訊堆砌，而是精心篩選、裁剪和打包上下文。例子非常巧妙：用戶希望在兩個地點之間尋找咖啡店。Agent 先調用地圖工具獲取一堆數據，然後自行判斷「下一步只需街道名稱」，將地圖輸出裁剪成一個簡短列表，再輸入給本地搜索工具。每一步都在進行資訊降噪。
書中有一句話我反覆看了幾遍：「要讓 AI 達到最高準確率，必須給它短小、聚焦、有力的上下文。」Context Engineering 就是幹這件事的。
到了這個級別，Agent 還能自我反思。幹完活後自己審一遍，發現問題自己改。我後面會細講。
第 3 級：多 Agent 協作
書的立場很明確：別老想著造一個全能 super agent。真正靠譜的做法是像搭團隊一樣，專案經理 Agent + 研究員 Agent + 設計師 Agent + 文案 Agent。書裡舉的例子是新產品發布：一個「專案經理 Agent」做總調度，下發任務給「市場研究 Agent」、「產品設計 Agent」、「行銷 Agent」。關鍵是通信：Agent 之間怎麼傳數據、怎麼同步狀態、怎麼處理衝突。這章畫了六種通信拓撲結構，從最簡單的單 Agent 到最靈活的自定義混合，每種適合什麼場景都有說明。
看完這四個等級，我突然明白為什麼很多人說「我的 Agent 不好用」。模型沒問題，問題是你在把它當聊天機器人用，它可能連 Level 1 都沒到。
Context Engineering：書中被最低估的概念
我寫過一篇 Harness Engineering，講的是賽道的設計比引擎的馬力更重要。看完這本書我發現，Context Engineering 就是 Harness Engineering 在 prompt 層面的映射。
傳統的 Prompt Engineering 只管「你怎么問」。書裡的 Context Engineering 管的是「問之前，Agent 的眼前擺著什麼」。它包括四層資訊：
第一層，system prompt。定義 Agent 是誰、什麼語氣、什麼邊界。大多數人只寫了這一層。
第二層，外部數據。RAG 檢索到的文檔、工具調用的返回值、實時 API 數據。這是多數人卡住的地方：知道要喂數據，但不知道怎麼喂才不會把模型淹沒。
第 3 層，隱式數據。用戶身份、交互歷史、環境狀態。你沒明說但 Agent 應該知道的東西。例如你跟 Agent 說“幫我給 John 發郵件確認明天的會議”，它應該知道你日曆裡明天的會議是什麼、你和 John 是什麼關係。
第 4 級，回饋迴路。Agent 每次輸出後，自動評估品質並調整下一次的上下文策略。書中將此稱為「自動化的 context 優化」，Google 的 Vertex AI Prompt Optimizer 即是此思路的工程化實現。
我讀到這裡時想起之前寫的那篇「AI 智能體不是魔法」，裡面有一條經驗是「你的智能體需要規則，而且是很多規則」。現在回頭看，那些規則本質上就是 Context Engineering 的手工版，書裡把它系統化了。
Reflection：兩個 Agent 真的比一個好
這是全書對我最有實戰價值的一個 Pattern。
Reflection 的核心很簡單：Agent 完成任務後自行審核，發現問題自行修正。但實現方式有講究。書中明確指出：Producer 和 Critic 必須使用兩個不同的 Agent，並給予不同的 system prompt。同一個 persona 審查自己的作品，必然存在盲點。你讓同一個 LLM 先寫代碼再審查自己寫的代碼，它極有可能會說「挺好的」。
The book provides a complete code example.
Producer 的 prompt 是“你是一個 Python 開發者，寫一個計算階乘的函數，處理邊界條件和異常”。
Critic 的 prompt 是「你是一個吹毛求疵的高級工程師，逐行審查代碼，檢查 Bug、風格、遺漏的邊界條件、可改進的地方。如果完美就輸出
CODE_IS_PERFECT，否則列出所有問題」。然後是一個 for 迴圈：Producer 寫代碼 → Critic 審 → Producer 根據意見修改 → Critic 再審 → 直到 Critic 說
CODE_IS_PERFECT或者達到最大迭代次數。
就這麼簡單。但書裡提醒了一個容易被忽略的成本問題：每次反射循環都是一次新的 LLM 調用，迭代次數越多越貴。而且隨著對話歷史膨脹，上下文窗口被前期版本和批評意見占滿，實際可用的推理空間在縮小。所以 Reflection 的最佳實踐是：設一個合理的最大迭代次數（書裡用的是 3），一旦 Critic 滿意就停，不要追求完美。
用途遠不止寫代碼。寫文章、做計劃、總結文檔、解決邏輯題，Producer-Critic 模型全都能套。書裡列了七種應用場景，核心邏輯一樣：先產出，後審查，再修正。
Multi-Agent 並非越複雜越好
我最喜歡這章的六種通信拓撲圖。很多人一上來就搞複雜的，但其實大部分場景三種就夠了：
單 Agent（獨立執行）：任務可拆解為互不依賴的子問題，每個 Agent 自行處理。簡單，易維護。
點對點（Peer-to-Peer）：Agent 之間直接通信，沒有中心控制節點。去中心化，容錯性好，一個 Agent 掛了不影響全局。但協調成本高，容易亂。
監督者（中心調度）：一個 Supervisor Agent 管理一群 Worker Agent，分配任務、收集結果、解決衝突。層級清晰，易於管理。但 Supervisor 是單點故障，也是性能瓶頸。
另外三種（Supervisor-as-Tool、層級式、自定義混合）是前三者的變體和組合。書裡說得很實在：你需要的拓撲結構取決於你的任務複雜度。任務越拆越碎，通信成本越高，到一定程度 Supervisor 模式反而比層級式更有效率。
我的體會是，很多人在搭建 Multi-Agent 時花了 80% 的時間在通信協議上，卻忘了問一個更基本的問題：這個任務真的需要多個 Agent 嗎？ 書裡寫得很清楚，Level 2 的單 Agent + Reflection 往往已經夠用了。Level 3 是為那些單 Agent 確實搞不定的場景準備的。
Memory 三層模型，我之前隱約感覺到了但沒命名
我最能產生共鳴的是 Memory 這一章，因為我在撰寫關於 Obsidian + Claude 的兩篇文章時，一直思索著一個問題：Agent 的記憶該如何分層？
書裡給了答案：
Session（會話層）：當前對話的上下文窗口，這是最短的記憶，對話結束就消失了。長上下文模型只是將這個窗口放大了，但本質上仍是臨時的，而且每次推理都要處理整個窗口，既昂貴又緩慢。
狀態層（State）：任務進行中臨時存儲的數據，例如「正在進行的任務是什麼」、「已完成到哪一步」、「中間產生了哪些數據」。其生命週期比 Session 長，但任務結束後會被清除。書中以 Google ADK 的 State 機制為例，提供了完整示例。
Memory（持久層）：跨會話、跨任務的長期記憶。用戶偏好、學到的經驗、重要的歷史決策，存於資料庫或向量庫中，進行語義檢索。書中強調了一個很重要的觀點：Memory 不只是儲存，還需設計一套完整的策略，決定「存什麼、何時存、如何檢索」。存得太多會增加雜訊，存得太少則不夠使用。
我之前寫 Clawdbot 那篇文章裡提到「狀態文件」和「工作區文檔」，本質上就是在手搓 State 層和 Memory 層，書裡把這件事框架化了。
五種假設，第五個最離譜
書末提出了五個關於 Agent 未來的假設，前四個仍在合理推演範圍內：通用型 Agent 從寫代碼到管理項目、深度個性化主動發現你的需求、具身智能走出螢幕進入物理世界、Agent 成為獨立經濟實體。
第 5 個把我震住了：變形 Multi-Agent。
你只聲明目標，例如「做一個賣精品咖啡的電商生意」。系統自動決定：先創建「市場研究 Agent」和「品牌 Agent」。跑了一輪數據後，自行判斷品牌 Agent 不需要了，拆成三個新的：「Logo 設計 Agent」、「建站 Agent」、「供應鏈 Agent」。如果建站 Agent 成了瓶頸，系統會自動複製出三個並行 Agent 同時處理不同的頁面。整個過程中，系統持續自動調優每個 Agent 的 prompt，不斷重組團隊架構。
書裡管這叫「目標驅動的、自我變形的多 Agent 系統」。它不是在執行你寫的計劃，是在自己生成計劃、自己調整計劃、自己重組執行團隊。
這讓我想起 Karpathy 的 AutoResearch：寫一個 program.md，定義目標、指標、邊界，然後「啟動」。人類在迴圈之外。但這本書推得更遠：連 Agent 團隊如何組建、如何重組，都交由系統自行決定。人類只聲明「要什麼」。
三件可以馬上做的事
讀完這本書，我有三個立刻可以落實的行動：
第一，為你目前的 Agent 添加一個 Critic。無論你使用的是 Claude Code、CrewAI 還是自建框架，請在你現有的 workflow 末尾增加一步：讓另一個 Agent（使用不同的 system prompt）審查上一步的輸出。代碼生成後加上代碼審查，文章撰寫後加上事實核對，計劃制定後加上可行性評審。多一次 LLM 調用，但品質提升往往翻倍。書中的 Producer-Critic 模式是即插即用的。
第二，開始進行 Context Engineering，而不僅僅是 Prompt Engineering。 回頭看看你寫給 Agent 的指令文件，如果全是「你要怎麼做」的規則，卻缺少「你現在面對什麼環境」的上下文，請補上。告訴 Agent 它現在處於哪個項目中、之前做過哪些決定、用戶偏好是什麼。書中關於 Context Engineering 的章節與你的
AGENTS.md是同一件事的兩種表述。第三，別急著上 Multi-Agent。先把你的單 Agent 做到第 2 級：有工具、有 Reflection、有 Memory。書中反覆強調，第 2 級的單 Agent 搭配 Producer-Critic 和 Context Engineering，就能覆蓋絕大多數實際場景。第 3 級是為真正跨領域、多階段、需要並行分工的任務準備的。大多數人的問題不是 Agent 不夠多，而是一個 Agent 都沒調好。
這本書 453 頁，Springer 2025 年出版。代碼範例涵蓋 LangChain/LangGraph、Google ADK、CrewAI、OpenAI API。前言由 Google Cloud AI 副總裁撰寫，並有 Goldman Sachs CIO 的推薦序，出乎意料地好看。
但我推薦它的理由不是「全面」。是你讀完會意識到一件事：你過去半年在 Agent 上踩的坑，都有人整理成模式了。你不需要再去發明 Reflection，不需要再去猜 Memory 該怎麼分層，不需要再去試 Multi-Agent 該用哪種通信拓撲。
Someone has drawn the map for you; all that's left is to walk.
你正在用 AI Agent 做開發嗎？你現在的 Agent 到了 Level 幾？