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 都没到。

Context Engineering：书里最被低估的概念。我写过一篇 Harness Engineering，讲的是赛道的设计比引擎的马力更重要。看完这本书我发现，Context Engineering 就是 Harness Engineering 在 prompt 层面的映射。传统的 Prompt Engineering 只管“你怎么问”。书里的 Context Engineering 管的是“问之前，Agent 的眼前摆着什么”。它包括四层信息：第一层，system prompt。定义 Agent 是谁、什么语气、什么边界。大多数人只写了这一层。第二层，外部数据。RAG 检索到的文档、工具调用的返回值、实时 API 数据。这是大部分人卡住的地方：知道要喂数据，但不知道怎么喂才不会把模型淹没。第三层，隐式数据。用户身份、交互历史、环境状态。你没明说但 Agent 应该知道的东西。比如你跟 Agent 说“帮我给 John 发邮件确认明天的会议”，它应该知道你日历里明天的会议是什么、你和 John 是什么关系。第四层，反馈回路。Agent 每次输出之后，自动评估质量、调整下次的上下文策略。书里把这叫“自动化的 context 优化”，Google 的 Vertex AI Prompt Optimizer 就是这个思路的工程化实现。我读到这里的时候想起之前写那篇“AI 智能体不是魔法”，里面有一条经验是“你的智能体需要规则，而且是很多规则”。现在回头看，那些规则本质上就是 Context Engineering 的手工版，书里把它系统化了。

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 模型全都能套。书里列了七种应用场景，核心逻辑一样：先产出，后审查，再修正。

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 确实搞不定的场景准备的。

Memory 三层模型，我之前隐约感觉到了但没命名。Memory 这章我最有共鸣，因为我写 Obsidian + Claude 那两篇文章的时候，一直在琢磨一个问题：Agent 的记忆该怎么分层？书里给了答案：Session（会话层）：当前对话的上下文窗口，这是最短的记忆，对话结束就没了。长上下文模型只是把这个窗口放大了，但本质上还是临时的，而且每次推理都要处理整个窗口，又贵又慢。State（状态层）：当前任务进行中的临时数据。比如“正在做的任务是什么”，“已经完成到哪一步”“中间产生了哪些数据”。比 Session 长，但任务结束就清理，书里用 Google ADK 的 State 机制做了完整示例。Memory（持久层）：跨会话、跨任务的长期记忆。用户偏好、学到的经验、重要的历史决策，存数据库或向量库里，语义检索。书里强调了一个很重要的点：Memory 不只是存下来，还要设计“存什么、什么时候存、怎么检索”的一整套策略。存太多了噪声大，存少了不够用。我之前写 Clawdbot 那篇文章里提到“状态文件”和“工作区文档”，本质上就是在手搓 State 层和 Memory 层，书里把这件事框架化了。

五种假设，第五个最离谱。书末提了五个关于 Agent 未来的假设，前四个还在合理推演范围内：通用型 Agent 从写代码到管项目、深度个性化主动发现你的需求、具身智能走出屏幕进物理世界、Agent 成为独立经济实体。第五个把我震住了：变形 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 做到 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 几？

[Yanhua]