# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Yanhua (@yanhua1010) · 平台：X (Twitter) · 日期：2026-05-25

> 原始來源：https://x.com/yanhua1010/status/2058552177912947044

## 中文摘要

# Agentic Design Patterns：一本讓我重新理解「Agent 到底是什麼」的書

Antonio Gullí 是 Google 的工程總監。他寫了一本 453 頁的書，把 AI Agent 開發拆解成了 21 種設計模式。

但這不是一篇書評。我讀這本書的動機很具體：我寫過 Harness Engineering，寫過 Clawdbot 的踩坑經驗，寫過「AI 智慧體不是魔法」那篇從燒 token 到真正好用的七個轉折，每次寫完之後都有一個沒完全想透的問題：這些東西背後有沒有一套可以複用的底層邏輯？

這本書給了我答案，而且比我想的更深。

## 你寫的可能根本不是 Agent

書裡最狠的判斷藏在 prologue 裡。

大多數人在用的「AI」，只是 Level 0：裸 LLM，沒有工具、沒有記憶、不會行動。你問它 2025 年奧斯卡最佳影片是哪部，它猜。書裡說得很直白：Level 0 的東西，不是 Agent。

往上走才是真 Agent。

Level 1：工具使用者。Agent 開始用工具了：搜尋、API、資料庫。但它不光是「能呼叫介面」，更要自己判斷什麼時候該呼叫、呼叫什麼、結果怎麼用。書裡給了一個很具體的例子：使用者問「最近有什麼新劇」，Agent 自己意識到這條資訊不在訓練資料裡，主動呼叫搜尋工具去找，然後合成結果。關鍵一步在「自己意識到」。不是人類告訴它「你去搜一下」，是它自己判斷需要搜。這個判斷能力，是 Level 1 的門檻。

Level 2：戰略思考者。多了兩樣東西：規劃和 Context Engineering。書裡定義了 Context Engineering：不做資訊堆砌，做的是精心篩選、裁剪、打包上下文。例子很妙：使用者要在兩個地點中間找咖啡店。Agent 先呼叫地圖工具拿到一堆資料，然後自己判斷「下一步只需要街道名稱」，把地圖輸出裁剪成一個短列表，再餵給本地搜尋工具。每一步都在做資訊降噪。書裡有一句話我反覆看了幾遍：「要讓 AI 達到最高準確率，必須給它短小、聚焦、有力的上下文。」Context Engineering 就是在做這件事。

到了這個級別，Agent 還能自我反思。幹完活後自己審一遍，發現問題自己改。我後面會細講。

Level 3：多 Agent 協作。書的立場很明確：別老想著造一個全能 super agent。真正靠譜的做法是像搭團隊一樣，專案經理 Agent + 研究員 Agent + 設計師 Agent + 文案 Agent。書裡舉的例子是新產品發布：一個「專案經理 Agent」做總排程，下發任務給「市場研究 Agent」、「產品設計 Agent」、「行銷 Agent」。關鍵是通信：Agent 之間怎麼傳資料、怎麼同步狀態、怎麼處理衝突。這章畫了六種通信拓撲結構，從最簡單的單 Agent 到最靈活的自訂混合，每種適合什麼場景都有說明。

看完這四個等級，我突然明白為什麼很多人說「我的 Agent 不好用」。模型沒問題，問題是你把它當聊天機器人用，它可能連 Level 1 都沒到。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526405-iaHJFvrmWasAAukQajpg.jpg)

## Context Engineering：書裡最被低估的概念

我寫過一篇 Harness Engineering，講的是賽道設計比引擎馬力更重要。看完這本書我發現，Context Engineering 就是 Harness Engineering 在 prompt 層面的映射。

傳統的 Prompt Engineering 只管「你怎麼問」。書裡的 Context Engineering 管的是「問之前，Agent 的眼前擺著什麼」。它包括四層資訊：

第一層，system prompt。定義 Agent 是誰、什麼語氣、什麼邊界。大多數人只寫了這一層。

第二層，外部資料。RAG 檢索到的文件、工具呼叫的回傳值、即時 API 資料。這是大部分人卡住的地方：知道要餵資料，但不知道怎麼餵才不會把模型淹沒。

第三層，隱式資料。使用者身分、互動歷史、環境狀態。你沒明說但 Agent 應該知道的東西。比如你跟 Agent 說「幫我給 John 發 email 確認明天的會議」，它應該知道你日曆裡明天的會議是什麼、你和 John 是什麼關係。

第四層，回饋迴路。Agent 每次輸出之後，自動評估品質、調整下次的上下文策略。書裡把這叫「自動化的 context 優化」，Google 的 Vertex AI Prompt Optimizer 就是這個思路的工程化實現。

我讀到這裡的時候想起之前寫那篇「AI 智慧體不是魔法」，裡面有一條經驗是「你的智慧體需要規則，而且是很多規則」。現在回頭看，那些規則本質上就是 Context Engineering 的手工版，書裡把它系統化了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526538-diaHJFxJJawAAA6G0jpg.jpg)

## Reflection：兩個 Agent 真的比一個好

這是全書對我最有實戰價值的一個 Pattern。

Reflection 的核心很簡單：Agent 幹完活後自己審一遍，發現問題自己改。但實現方式有講究。書裡明確說了：Producer 和 Critic 必須用兩個不同的 Agent，給不同的 system prompt。同一個 persona 審自己的東西，一定有盲區。你讓同一個 LLM 先寫程式碼再審查自己寫的程式碼，它大概率會說「挺好的」。

書裡給了一個完整的程式碼範例。Producer 的 prompt 是「你是一個 Python 開發者，寫一個計算階乘的函數，處理邊界條件和異常」。Critic 的 prompt 是「你是一個吹毛求疵的高級工程師，逐行審查程式碼，檢查 Bug、風格、遺漏的邊界條件、可改進的地方。如果完美就輸出 CODE_IS_PERFECT，否則列出所有問題」。然後是一個 for 迴圈：Producer 寫程式碼 → Critic 審 → Producer 根據意見改 → Critic 再審 → 直到 Critic 說 CODE_IS_PERFECT 或者達到最大迭代次數。

就這麼簡單。但書裡提醒了一個容易被忽略的成本問題：每次反射迴圈都是一次新的 LLM 呼叫，迭代次數越多越貴。而且隨著對話歷史膨脹，上下文視窗被前期版本和批評意見佔滿，實際可用的推理空間在縮小。所以 Reflection 的最佳實踐是：設一個合理的最大迭代次數（書裡用的是 3），一旦 Critic 滿意就停，不要追求完美。

用途遠不止寫程式碼。寫文章、做計畫、總結文件、解決邏輯題，Producer-Critic 模型全都能套。書裡列了七種應用場景，核心邏輯一樣：先產出，後審查，再修正。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526608-iaHJFxDFRaUAAfmRLjpg.jpg)

## Multi-Agent 不是越複雜越好

Multi-Agent Collaboration 這章我最喜歡的是那六種通信拓撲圖。很多人一上來就搞複雜的，但其實大部分場景三種就夠了：

單 Agent（獨立執行）：任務能拆成互不依賴的子問題，每個 Agent 自己搞定自己的。簡單，好維護。

對等網路（Peer-to-Peer）：Agent 之間直接通信，沒有中心控制節點。去中心化，容錯性好，一個 Agent 掛了不影響全域。但協調成本高，容易亂。

Supervisor（中心排程）：一個 Supervisor Agent 管一群 Worker Agent。分配任務、收集結果、解決衝突。層級清晰，好管理。但 Supervisor 是單點故障，也是效能瓶頸。

另外三種（Supervisor-as-Tool、層級式、自訂混合）是前三者的變體和組合。書裡說得很實在：你需要的拓撲結構取決於你的任務複雜度。任務越拆越碎，通信成本越高，到一定程度 Supervisor 模式反而比層級式更有效率。

我的體會是，很多人搭 Multi-Agent 的時候花了 80% 的時間在通信協定上，忘了問一個更基本的問題：這個任務真的需要多個 Agent 嗎？書裡寫得很清楚，Level 2 的單 Agent + Reflection 往往已經夠用了。Level 3 是給那些單 Agent 確實搞不定的場景準備的。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526393-iaHJFwZ9rawAAZjsZjpg.jpg)

## Memory 三層模型，我之前隱約感覺到了但沒命名

Memory 這章我最有共鳴，因為我寫 Obsidian + Claude 那兩篇文章的時候，一直在琢磨一個問題：Agent 的記憶該怎麼分層？

書裡給了答案。

Session（會話層）：當前對話的上下文視窗，這是最短的記憶，對話結束就沒了。長上下文模型只是把這個視窗放大了，但本質上還是臨時的，而且每次推理都要處理整個視窗，又貴又慢。

State（狀態層）：當前任務進行中的臨時資料。比如「正在做的任務是什麼」、「已經完成到哪一步」、「中間產生了哪些資料」。比 Session 長，但任務結束就清理，書裡用 Google ADK 的 State 機制做了完整範例。

Memory（持久層）：跨會話、跨任務的長期記憶。使用者偏好、學到的經驗、重要的歷史決策，存資料庫或向量庫裡，語意檢索。書裡強調了一個很重要的點：Memory 不只是存下來，還要設計「存什麼、什麼時候存、怎麼檢索」的一整套策略。存太多了雜訊大，存少了不夠用。

我之前寫 Clawdbot 那篇文章裡提到「狀態檔案」和「workspace 文件」，本質上就是在手搓 State 層和 Memory 層，書裡把這件事框架化了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526384-iaHJFx4NWbwAA4214jpg.jpg)

## 五種假設，第五個最離譜

書末提了五個關於 Agent 未來的假設，前四個還在合理推演範圍內：

通用型 Agent 從寫程式碼到管專案、深度個人化主動發現你的需求、具身智慧走出螢幕進物理世界、Agent 成為獨立經濟實體。

第五個把我震住了：變形 Multi-Agent。你只宣告目標，比如「做一個賣精品咖啡的電商生意」。系統自動決定：先建立「市場研究 Agent」和「品牌 Agent」。跑了一輪資料後，自己判斷品牌 Agent 不需要了，拆成三個新的：「Logo 設計 Agent」、「建站 Agent」、「供應鏈 Agent」。如果建站 Agent 成了瓶頸，系統會自動複製出三個並行 Agent 同時幹不同的頁面。整個過程中，系統持續自動調優每個 Agent 的 prompt，不斷重組團隊架構。

書裡管這叫「目標驅動的、自我變形的多 Agent 系統」。它不是在執行你寫的計畫，是在自己生成計畫、自己調整計畫、自己重組執行團隊。

這讓我想起 Karpathy 的 AutoResearch：寫一個 program.md，定義目標、指標、邊界，按「啟動」。人類在迴圈外面。但這本書推得更遠：連 Agent 團隊怎麼組建、怎麼重組，都交給系統自己決定。人類只宣告「要什麼」。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779671526515-iaHJFwzoYbcAAulEYjpg.jpg)

## 三件可以馬上做的事

讀完這本書，我有三個立刻可以落地的動作：

第一，給你現在的 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 做到 Level 2：有工具、有 Reflection、有 Memory。書裡反覆強調，Level 2 的單 Agent 加上 Producer-Critic 和 Context Engineering，能覆蓋絕大多數實際場景。Level 3 是給真正跨領域、多階段、需要並行分工的任務準備的。大多數人的問題不是 Agent 不夠多，是一個 Agent 都沒調好。

這本書 453 頁，Springer 2025 年出版。程式碼範例覆蓋 LangChain/LangGraph、Google ADK、CrewAI、OpenAI API。前言是 Google Cloud AI VP 寫的，還有個 Goldman Sachs CIO 的推薦序，意外地好看。

但我推薦它的理由不是「全面」。是你讀完會意識到一件事：你過去半年在 Agent 上踩的坑，都有人整理成模式了。你不需要再去發明 Reflection，不需要再去猜 Memory 該怎麼分層，不需要再去試 Multi-Agent 該用哪種通信拓撲。

有人替你畫了地圖，剩下的就是走。

你在用 AI Agent 做開發嗎？你現在的 Agent 到了 Level 幾？評論區聊聊。

## 標籤

Agent, 教學資源, 其他, Google, Harness Engineering, Clawdbot