AGENT 理论 · 04

智能体设计模式

先看 9 种模式速查表，再用《Agentic Design Patterns》（453 页，21 种模式）的书评逐个加深：L0–L3 先判定"这是不是 Agent"。

原作者 @AdarshChetan / @yanhua1010 来源 X 发布 2026-09-05 / 2026-05-24

📏

开篇：你写的可能根本不是 Agent

以下来自 @yanhua1010 读 Antonio Gullí（Google 工程总监）453 页著作《Agentic Design Patterns》（21 种设计模式，Springer 2025）的书评。书里最狠的判断藏在 prologue：

等级	是什么	关键
L0	裸 LLM：没工具、没记忆、不会行动	不是 Agent——问它 2025 奥斯卡最佳影片，它靠猜
L1 工具使用者	会调搜索、API、数据库	门槛是"自己意识到"要调工具：没人告诉它"你去搜一下"，它自己判断训练数据里没有、主动去搜
L2 战略思考者	多了规划＋Context Engineering＋自我反思	不做信息堆砌，做筛选裁剪打包上下文
L3 多智能体协作	像搭团队：项目经理＋研究员＋设计师＋文案	别造全能 super agent，关键是 Agent 之间的通信

记住：一句话结论：很多人说"我的 Agent 不好用"，模型没问题，问题是把它当聊天机器人用——可能连 L1 都没到。先判定等级，再谈模式。

高中生类比
L0–L3 像驾照等级：L0 是坐在驾驶位但不会开车的人（看着像司机，其实不是）；L1 是会自己看导航找路的新手；L2 是会规划路线、自己检查车况的老司机；L3 是一支车队，有调度、有分工。别给 L0 发"营运证"。

书评作者读这本书的动机：他写过 Harness Engineering、Clawdbot 踩坑、"AI 智能体不是魔法"，每次写完都有个没想透的问题——这些东西背后有没有一套可复用的底层逻辑？这本书给了答案。

🗂

9 种智能体设计模式速查表

以下来自 @AdarshChetan。核心观点：构建智能体的真正力量来自"为问题选对模式"，而非只选强模型。

#	模式	是什么	最适合
1	反思 Reflection	对自己的输出批判，迭代改进	准确性、复杂推理
2	工具使用	调外部工具/API 获取信息或干活	现实世界操作、数据查询
3	ReAct	逐步推理→用工具行动→观察结果→继续	复杂多步骤问题
4	规划 Planning	执行前先定计划，再逐步跟进	复杂工作流、长期任务
5	多智能体	研究员＋程序员＋分析师＋作家协作	复杂问题、专业化
6	路由 Routing	按输入把请求发给最合适的 agent/模型	多功能、模型选择
7	记忆 Memory	存取信息，随时间维持上下文	个性化、长对话
8	自我修正	评估输出、发现错误、修正重生成	可靠性、降幻觉
9	人在回路	与人协作要指导、反馈或批准	高风险决策、安全

典型工作流：理解 → 计划/推理 → 行动 → 观察 → 反思/改进 → 交付，循环直到目标达成。

评论区共识很实在：Mikhail Rogov 说路由是清单上常被跳过的一项，"说实话这里最便宜的解决办法就是它"；Atlas Frontier 补刀：路由、记忆、工具、人在回路决定生产环境的可靠性——模型选择只是其中一层。

避坑
别只收藏速查表。@AdarshChetan 的关键句：别只是构建一个 AI 智能体，要为任务选择正确的模式。下一节用书评给每个模式加"实战纵深"。

🔍

单智能体模式深化：书里的实战细节

以下来自 @yanhua1010 的书评。速查表告诉你"有什么"，书告诉你"怎么做好"。

核心：Producer 和 Critic 必须是两个不同 system prompt 的 Agent。同一个 persona 审自己的东西一定有盲区——让同一个 LLM 先写代码再审自己的代码，它大概率说"挺好的"。

书中完整示例：Producer 的 prompt 是"你是 Python 开发者，写阶乘函数，处理边界和异常"；Critic 是"你是吹毛求疵的高级工程师，逐行审查，完美就输出 CODE_IS_PERFECT，否则列出所有问题"。for 循环：写→审→按意见改→再审，直到 CODE_IS_PERFECT 或到最大迭代次数。

成本警告：每次反射都是一次 LLM 调用，且历史膨胀挤占推理空间。最佳实践：最大迭代次数设 3，Critic 满意就停，别追完美。

用途不止代码：写文章、做计划、总结文档、解逻辑题，七种场景同一套逻辑：先产出，后审查，再修正。

传统 Prompt Engineering 只管"你怎么问"，书里的 Context Engineering 管"问之前，Agent 眼前摆着什么"。四层：

第一层 system prompt：Agent 是谁、什么语气、什么边界——大多数人只写了这一层；第二层外部数据：RAG 文档、工具返回值、实时 API，难点是不把模型淹没；第三层隐式数据：用户身份、交互历史、环境状态（比如"给 John 发邮件确认明天的会"，它该知道你日历里明天的会是什么）；第四层反馈回路：自动评估输出质量、调整下次上下文策略（Vertex AI Prompt Optimizer 就是工程化实现）。

妙例：找两地中间的咖啡店，Agent 调地图拿到一堆数据后，自己判断"下一步只需要街道名"，裁成短列表再喂给本地搜索——每一步都在做信息降噪。金句："要让 AI 达到最高准确率，必须给它短小、聚焦、有力的上下文。"

书评作者的洞察：Context Engineering 是 Harness Engineering 在 prompt 层面的映射。

原文配图：Context Engineering 四层（@yanhua1010 书评）

Session（会话层）：当前对话的上下文窗口，最短的记忆，对话结束就没了；长上下文只是把窗口放大，又贵又慢。State（状态层）：任务进行中的临时数据——做到哪步、中间产了什么；任务结束清理（Google ADK 的 State 机制有完整示例）。Memory（持久层）：跨会话长期记忆——用户偏好、学到的经验、重要历史决策，存库里语义检索。

关键：Memory 不只是存下来，还要设计"存什么、何时存、怎么检索"的一整套策略——存多噪声大，存少不够用。

工具使用：L1 的门槛就是"自己判断何时调工具"（见开篇）。ReAct：推理→行动→观察的循环，每轮加深理解。规划：L2 的标志之一，先定计划再执行。路由：评论区公认"最便宜的解决办法"，常被跳过却关键。自我修正：有外部真实反馈才有效，模型自己审自己会失效（与课 01 的 checker 结论一致）。

🤝

协作与边界：多智能体拓扑＋灵魂拷问

以下来自 @yanhua1010 的书评。Multi-Agent 章他最喜欢的是六种通信拓扑图，但先泼冷水：大部分场景三种就够了。

拓扑	怎么连	trade-off
单 Agent	任务拆成互不依赖的子问题，各干各的	简单好维护
对等网络	Agent 间直接通信，无中心节点	去中心化、容错好；但协调成本高、容易乱
Supervisor	一个调度者管一群 Worker：分任务、收结果、解冲突	层级清晰；但 Supervisor 是单点故障＋性能瓶颈

另外三种（Supervisor-as-Tool、层级式、自定义混合）是变体和组合。书里的实在话：任务越拆越碎，通信成本越高，到一定程度 Supervisor 反而比层级式更有效率。

高中生类比
三种拓扑像三种公司：单 Agent 是个体户（一人全包）；对等网络是合伙制（人人直接商量，没老板，但容易吵）；Supervisor 是科层公司（经理分活，效率高，但经理一病倒全公司停摆）。选哪种，看你的"业务"复杂到哪。

避坑
灵魂拷问（书评作者原话）："这个任务真的需要多个 Agent 吗？"很多人花 80% 时间在通信协议上，忘了 Level 2 的单 Agent＋Reflection 往往已经够用。Level 3 是给单 Agent 确实搞不定的场景准备的。

人在回路：模式 9 的位置

速查表里"人在回路"最适合高风险决策、安全、一致性。书评的视角是：先把单 Agent 做到 L2（工具＋Reflection＋Memory），再问要不要上多智能体、要不要人在回路——大多数人的问题不是 Agent 不够多，是一个都没调好。

🔮

未来假设与三个可马上做的事

以下来自 @yanhua1010 的书评。书末五个未来假设，前四个还在合理推演内：通用型 Agent 从写代码到管项目、深度个性化主动发现需求、具身智能进物理世界、Agent 成为独立经济实体。

第五个最激进：变形 Multi-Agent

你只声明目标，比如"做一个卖精品咖啡的电商生意"。系统自动：创建"市场研究 Agent"＋"品牌 Agent"→跑一轮数据后自己判断品牌 Agent 不需要了，拆成"Logo 设计""建站""供应链"三个→建站成了瓶颈，自动复制出三个并行做不同页面→全程持续自动调优每个 Agent 的 prompt、重组团队架构。

它不是在执行你写的计划，是在自己生成计划、自己调整计划、自己重组执行团队。书评作者联想到 Karpathy 的 AutoResearch（写 program.md 定义目标指标边界，人类在循环外面），但书推得更远：连团队怎么组建、怎么重组都交给系统，人类只声明"要什么"。

三个可马上做的事（书评作者原话）

给你现在的 Agent 加一个 Critic——不管 Claude Code、CrewAI 还是自搭框架，在 workflow 末尾加一步：让另一个 Agent（不同 system prompt）审查上一步输出。代码配代码审查，文章配事实核查，计划配可行性评审。多一次 LLM 调用，质量提升往往翻倍，Producer-Critic 即插即用；
开始做 Context Engineering，不只是 Prompt Engineering——回头看你的指令文件：如果全是"你要怎么做"的规则，缺"你现在面对什么环境"的上下文，补上。它和你的 AGENTS.md 是同一件事的两个表述；
先别急着上 Multi-Agent——把单 Agent 做到 Level 2：有工具、有 Reflection、有 Memory。书里反复强调，L2 单 Agent＋Producer-Critic＋Context Engineering 能覆盖绝大多数实际场景。

书目信息：Antonio Gullí 著，453 页，21 种设计模式，Springer 2025 出版；代码示例覆盖 LangChain/LangGraph、Google ADK、CrewAI、OpenAI API；前言 Google Cloud AI VP，Goldman Sachs CIO 作推荐序。

记住：书评作者的推荐理由：你过去半年在 Agent 上踩的坑，都有人整理成模式了。不需要再发明 Reflection，不需要再猜 Memory 怎么分层——有人替你画了地图，剩下的就是走。

词

术语翻卡：点卡片看解释

设计模式

Design pattern

前人踩坑后沉淀的可复用解法：遇到同类问题，直接套模式，不用重新发明。

L0–L3

Agent levels

判定是不是 Agent 的标尺：L0 裸 LLM 不是 Agent；L1 会自己判断调工具；L2 会规划反思；L3 多智能体协作。

Producer-Critic

反思模式的实战形态：一个 Agent 生产（Producer），另一个不同 persona 的 Agent 审查（Critic），循环到通过为止。

上下文工程

Context engineering

管"Agent 眼前摆着什么"：system prompt、外部数据、隐式数据、反馈回路四层，不做信息堆砌。

反思

Reflection

干完活自己审一遍、发现问题自己改；关键是审查者必须和生产者是不同的 Agent。

记忆三层

Memory layers

Session（会话窗口，临时）/ State（任务中临时数据）/ Memory（跨会话持久记忆，要设计存取策略）。

通信拓扑

Communication topology

多智能体之间怎么连：单 Agent、对等网络、Supervisor 三种主流＋三种变体。

人在回路

Human-in-the-loop

高风险决策让智能体暂停、交人审批；是护栏的最后一道，不是第一道。

测

自测一下：点问题展开参考答案

L0 是裸 LLM：没工具、没记忆、不会行动，问它 2025 奥斯卡最佳影片靠猜，所以不是 Agent。L1 的门槛是"自己意识到"何时该调工具——比如主动判断训练数据里没有新剧信息、自己去调搜索，而不是等人告诉它。

同一个 persona 审自己的东西一定有盲区：让同一个 LLM 先写代码再审查，大概率说"挺好的"。书中示例里 Critic 的 prompt 是"吹毛求疵的高级工程师"，完美才输出 CODE_IS_PERFECT，否则列出所有问题；最大迭代次数用 3。

四层：system prompt（Agent 是谁）、外部数据（RAG/工具返回，别淹没模型）、隐式数据（用户身份/历史/环境）、反馈回路（自动优化上下文策略）。区别：Prompt Engineering 只管"你怎么问"，Context Engineering 管"问之前 Agent 眼前摆着什么"。

Session（当前对话窗口，临时）、State（任务进行中的临时数据，任务结束清理）、Memory（跨会话长期记忆）。持久层关键不是存下来，而是设计"存什么、何时存、怎么检索"的一整套策略。

① 给现有 Agent 加一个 Critic（不同 system prompt 的审查 Agent）；② 开始做 Context Engineering，不只是 Prompt Engineering；③ 先别急着上 Multi-Agent，把单 Agent 做到 L2（工具＋Reflection＋Memory）。