Google工程总监新书：创建AI Agent的21种设计模式深度解析（附3个落地策略）

作者：Yanhua

Antonio Gullí 是 Google 的工程总监。他在一本 453 页的新书中，将 AI Agent 的开发拆解为 21 种设计模式。

但这不是一篇书评。我读这本书的动机非常明确：我曾写过关于 Harness Engineering 的文章，分享过使用 Clawdbot 踩过的坑，也探讨过“AI agents are not magic”中从烧钱到真正实用的七个转折点。每次写完之后，总有一个问题我没想透：这些实践背后，是否存在一套可复用的底层逻辑？

这本书给了我答案，而且比我想象的更深。

你写的“Agent”，可能根本不是 Agent

全书最严厉的评判，藏在序言里。

大多数使用“AI”的人，其实只停留在 Level 0：裸 LLM，没有工具、没有记忆、没有行动。如果你问它 2025 年奥斯卡最佳影片是什么，它只能猜。书中直言：Level 0 的东西，不是 Agent。

再往上，才是真正的 Agent：

Level 1：工具使用者（Tool User）。Agent 开始使用工具：搜索、API、数据库。但这不仅仅是“能调用接口”，还要能判断何时调用、调用什么、如何使用结果。书中举了一个很具体的例子：当用户问“最近有什么新剧”时，Agent 意识到训练数据里没有这个信息，主动调用搜索工具查找，然后综合结果。关键一步是“自主意识到”。不是人告诉它“去搜”，而是它自己判断需要搜索。这种判断能力，就是 Level 1 的门槛。

Level 2：战略思考者（Strategic Thinker）。这一级增加了两个要素：规划能力（Planning）和上下文工程（Context Engineering）。书中对上下文工程的定义，不是简单堆砌信息，而是精心筛选、修剪和打包上下文。书中举了一个很妙的例子：用户想在两个地点之间找一家咖啡店，Agent 先调用地图工具收集大量数据，然后判断“下一步只需要街道名称”，将地图输出修剪成一张短清单，再喂给本地搜索工具。每一步都在减少信息噪音。

书中有一句话我反复读了几遍：“要让 AI 达到最高准确率，你必须为其提供简短、聚焦且有力的上下文。”上下文工程做的就是这件事。

在这一级，Agent 还能进行自我反思（Self-Reflection）。完成任务后，它会复盘自己的工作，发现问题并修正。这一点我稍后详细展开。

Level 3：多智能体协作（Multi-Agent Collaboration）。书中的立场很明确：别再想着造一个无所不能的超级 Agent。真正可靠的做法是组建团队，比如项目经理 Agent + 研究员 Agent + 设计师 Agent + 文案 Agent。书中举了一个新品发布的例子：一个“项目经理 Agent”统筹全局，把任务分配给“市场调研 Agent”、“产品设计 Agent”和“营销推广 Agent”。关键在于沟通：Agent 之间如何传输数据、同步状态、处理冲突。这一章用六种通信拓扑结构来说明，从最简单的单 Agent 到最灵活的自定义组合，并解释了每种适合什么场景。

看完这四个层级，我突然明白了为什么很多人说“我的 Agent 不好用”。问题不在模型，而在于你把它当聊天机器人用，它可能连 Level 1 都没达到。

上下文工程：全书最被低估的概念

我之前写过 Harness Engineering，讨论赛道设计比引擎马力更重要。读完这本书后我意识到，上下文工程就是 Harness Engineering 在提示词（Prompt）层面的映射。

传统的提示词工程只关心“你怎么问”。而书中的上下文工程处理的是“问之前，Agent 面前有什么上下文”。它包含四层信息：

第一层，系统提示（System Prompt）。定义 Agent 是谁、用什么语气、有什么边界。大多数人只写了这一层。

第二层，外部数据（External Data）。RAG 检索到的文档、工具调用的返回值、实时 API 数据。这是大多数人卡住的地方：知道要喂数据，但不知道怎么喂才不会压垮模型。

第三层，隐式数据（Implicit Data）。用户身份、交互历史、环境状态。那些你没明说，但 Agent 应该知道的信息。比如，你让 Agent“帮我发邮件给 John，确认明天的会议”，它应该能从你的日历里知道明天的会议是什么，以及你和 John 是什么关系。

第四层，反馈循环（Feedback Loop）。每次输出后，Agent 自动评估质量，并调整下一次的上下文策略。书中称之为“自动化上下文优化”，而 Google Vertex AI Prompt Optimizer 就是这一思路的工程实现。

读到这里时，我回想起之前在《AI agents are not magic》中分享的一段经历，当时我说“你的 Agent 需要规则，而且需要很多规则”。现在回头看，那些规则本质上就是上下文工程的手动版本，而本书将其系统化。

反思机制：两个 Agent 确实比一个强

这是全书对我来说最具实践价值的模式。

反思（Reflection）的核心很简单：Agent 完成任务后，复盘自己的工作，发现问题就修正。但实现方式至关重要。书中明确指出：生产者（Producer）和评审者（Critic）必须是两个不同的 Agent，各自使用不同的系统提示。同一个人格审查自己的作品，永远会有盲点。如果你让同一个 LLM 写代码再审查自己的代码，它很可能会说“写得挺好的”。

书中提供了一套完整的代码示例。

生产者的提示词是：“你是一名 Python 开发者，编写一个计算阶乘的函数，处理边界情况和异常。”

评审者的提示词是：“你是一名挑剔的资深工程师，逐行审查代码，检查 Bug、代码风格、遗漏的边界 case 以及可优化之处。如果完美无缺，输出 CODE_IS_PERFECT；否则列出所有问题。”

然后是一个 for 循环：生产者写代码 → 评审者审查 → 生产者根据反馈修改 → 评审者再次审查 → 直到评审者输出 CODE_IS_PERFECT 或达到最大迭代次数。

就是这么简单。但书中提醒我们一个容易被忽略的成本问题：每次反思循环都是一次新的 LLM 调用，迭代次数越多，成本越高。而且随着对话历史膨胀，上下文窗口会被早期版本和评审意见填满，实际推理空间反而减少。因此，反思机制的最佳实践是：设置合理的最大迭代次数（书中用了 3 次），评审者满意就停止，不要追求完美。

其应用远不止写代码。写文章、做计划、总结文档、解逻辑题——都可以使用生产者-评审者模型。书中列出了七种应用场景，核心逻辑都一样：先产出，再评审，最后修正。

多智能体不是越复杂越好

多智能体协作这一章我最喜欢的是六张通信拓扑图。很多人一上来就搞复杂，但其实大多数场景三种就够：

单智能体（独立执行）：任务可拆分为独立的子问题，每个 Agent 各管一摊。简单、易维护。

点对点网络（Peer-to-Peer）：Agent 之间直接通信，没有中央控制节点。去中心化、容错性强；一个 Agent 挂了不影响全局。但协调成本高，容易混乱。

监督者模式（Supervisor，中央协调）：一个监督者 Agent 管理一组工作者 Agent。它分配任务、收集结果、解决冲突。层级清晰、易于管理。但监督者是单点故障和性能瓶颈。

另外三种（Supervisor-as-Tool、层级式、自定义混合）都是前三种的变体与组合。书中很务实地说：你需要哪种拓扑，取决于任务的复杂程度。任务越碎片化，通信成本越高；到了某个临界点，监督者模式可能比层级式更高效。

我的经验是，很多人搭建多智能体时，把 80% 的时间花在通信协议上，却忘了问一个更根本的问题：这个任务真的需要多个 Agent 吗？书中讲得很清楚：一个带有反思机制的 Level 2 单 Agent，往往已经够用。Level 3 留给那些确实无法由单个 Agent 处理的场景。

记忆的三层模型：我曾隐约感觉到，但没能命名

记忆（Memory）这一章最让我共鸣，因为我在写 Obsidian + Claude 那篇文章时，一直在思考一个问题：Agent 的记忆应该怎么分层？

书中给出了答案：

会话层（Session）：当前对话的上下文窗口，是最短的记忆，对话结束就消失。长上下文模型只是把窗口做大，但本质上仍是临时的，每次推理都要处理整个窗口，成本高、速度慢。

状态层（State）：当前任务中的临时数据。比如“当前任务是什么”、“进展到哪一步了”、“中间生成了什么数据”。比会话层持久，但任务结束就清空；书中用 Google ADK 的 State 机制给出了完整示例。

记忆层（Memory）：跨越会话和任务的长期记忆。用户偏好、学到的经验、重要的历史决策，存在数据库或向量数据库中，用于语义检索。书中强调了一个重要观点：记忆不只是存，还要设计完整的策略——“存什么、何时存、怎么取”。存太多是噪音，存太少又不够用。

我在之前关于 Clawdbot 的文章里提到的“状态文件”和“工作区文档”，本质上就是手动搭建的状态层和记忆层；而本书把这套任务框架化了。

五大假设，第五个最离谱

书末提到了关于 Agent 未来的五个假设，前四个还在合理推演范围内：通用 Agent 从编程进化到项目管理、深度个性化并主动发现你的需求、具身智能走出屏幕进入物理世界、Agent 成为独立的经济实体。

第五个让我震惊：Transforming Multi-Agent（可变形多智能体）。

你只需要声明一个目标，比如“创建一家销售精品咖啡的电商企业”。系统自动决定：先创建“市场调研 Agent”和“品牌策划 Agent”。跑完一轮数据后，它判断品牌策划 Agent 不再需要，将其拆分为三个新 Agent：“Logo 设计 Agent”、“网站搭建 Agent”和“供应链 Agent”。如果网站搭建 Agent 成为瓶颈，系统会自动复制三个并行 Agent 同时处理不同页面。整个过程中，系统持续优化每个 Agent 的提示词，并重组团队结构。

书中称之为“目标驱动的自变形多智能体系统”。它不是在执行你写好的计划，而是自己生成计划、调整计划、并自主重组执行团队。

这让我想起 Karpathy 的 AutoResearch：写一份 program.md，定义目标、指标、边界，然后点“开始”。人类在闭环之外。但这本书推得更远：连 Agent 团队如何组建和重组，都交给系统自己决定。人类只负责声明“想要什么”。

三个你可以立即落地的行动

读完这本书，我有三个可以立即实施的行动：

第一，给你现在的 Agent 加一个评审者（Critic）。无论你用的是 Claude Code、CrewAI 还是自研框架，在现有工作流末尾加一步：让另一个 Agent（使用不同的系统提示词）审查上一步的输出。代码生成加代码审查，文章写作加事实核查，方案制定加可行性评估。这会增加一次 LLM 调用，但质量提升往往是翻倍的。书中的生产者-评审者模型是即插即用的。

第二，开始做上下文工程，而不是只做提示词工程。回头看看你给 Agent 写的指令文件，如果全是“你应该怎么做”的规则，缺少“你当前面对什么环境”的上下文，那就补上。告诉 Agent 它现在在什么项目里、之前做过什么决策、用户偏好是什么。书中的上下文工程章节，和你写的 AGENTS.md，其实是同一回事的两种表达。

第三，别急着上多智能体。先把你的单 Agent 做到 Level 2：有工具、有反思、有记忆。书中反复强调，一个配备生产者-评审者机制和上下文工程的 Level 2 单 Agent，足以覆盖绝大多数实际场景。Level 3 留给真正跨领域、多阶段、需要并行分工的任务。大多数人的问题不是 Agent 不够多，而是一个 Agent 都没优化好。

这本书共 453 页，将于 2025 年由 Springer 出版。代码示例涵盖 LangChain/LangGraph、Google ADK、CrewAI 和 OpenAI API。前言由 Google Cloud AI 副总裁撰写，还有高盛 CIO 的推荐，意外写得很好。

但我推荐它的理由不是“全面”。而是读完你会意识到一件事：过去半年你在 Agent 上踩过的坑，别人已经整理成了模式。你不需要再重新发明反思机制，猜测记忆如何分层，或试验多智能体该用哪种通信拓扑。

有人已经为你画好了地图，剩下的只是走上去。

你正在用 AI Agent 做开发吗？你现在的 Agent 到哪个 Level 了？