一句话总结：Antonio Gulli 的《Agentic Design Patterns》把 agent 系统拆成 21 个可复用设计模式，从 Prompt Chaining、Routing、Tool Use、Planning 到 Memory、RAG、Guardrails、Evaluation，核心价值不是提出单个新算法，而是给工程团队一套构建可靠 agent 的模式语言。

TL;DR 速览

• 问题：LLM agent 很容易被包装成“会调用工具的聊天机器人”，但真实系统需要可组合、可调试、可监控、可回退的工程结构。
• 方法：
• 用 Prompt Chaining / Routing / Parallelization / Reflection 组织 agent 的基本控制流。
• 用 Tool Use / MCP / A2A / RAG 连接外部世界、知识库和其他 agent。
• 用 Memory / Learning / Goal Monitoring / Prioritization 维护状态、目标和长期改进。
• 用 Exception Handling / HITL / Guardrails / Evaluation 把不确定的 LLM 行为纳入工程约束。
• 关键数字：全书覆盖 21 个 agentic design patterns，正文约 424 页，重点在每个模式的“何时用、如何实现、如何和其他模式组合”。
• 一句话评价：适合作为 agent 工程架构 checklist；不足是偏手册和实践范式，缺少统一实验评估和严格理论边界。

tags: [agentic-ai, design-patterns, llm-agent, tool-use, rag, guardrails, multi-agent] related: [[AgentX_Towards Agent-Driven Self-Iteration of Industrial Recommender Systems 精读笔记]], [[AgentSociety2 精读笔记]], [[Exploring Recommender System Evaluation_A Multi-Modal User 精读笔记]]

摘要

[!PDF|] Agentic-Design-Patterns.pdf, p.14

In simple terms, an AI agent is a system designed to perceive its environment and take actions to achieve a specific goal.

这句话是全书的起点：agent = 感知环境 + 为目标采取行动。它和普通 LLM 的区别不在“会说话”，而在能否形成闭环：接收目标、读取环境、制定计划、执行动作、从结果中修正。

这张图把 agent 描述成五步循环： 1. Get the Mission：目标输入，不只是 prompt，而是任务边界。 2. Scan the Scene：读取邮件、日历、数据库、工具状态等环境信息。 3. Think It Through：把目标转成计划或候选动作。 4. Take Action：调用工具或执行外部动作。 5. Learn and Get Better：根据成功/失败反馈调整后续行为。

1 模式总览：把 21 个 pattern 放进一张工程地图

这张表的读法：前 4 个模式是 agent 的“控制流骨架”；Tool/RAG/MCP/A2A 是“外部世界接口”；Memory/Learning/Goal 是“状态和目标”；Exception/HITL/Guardrails/Evaluation 是“可靠性护栏”。

2 基础控制流模式

2.1 Prompt Chaining：把大任务拆成可验证的小任务

[!PDF|] Agentic-Design-Patterns.pdf, p.23

Rather than expecting an LLM to solve a complex problem in a single, monolithic step, prompt chaining advocates for a divide-and-conquer strategy.

Prompt Chaining 的重点不是“多写几个 prompt”，而是把任务拆成具有清晰输入/输出契约的步骤。例如论文阅读可以拆成：抽取结构 -> 找贡献 -> 找实验 -> 生成摘要 -> 生成批判性思考。每一步都能单独调试，失败时也能定位到具体环节。

[!tip] 什么时候应该用 Prompt Chaining？ 当任务天然有阶段依赖，且每阶段的输出可以被检查时，chain 比单次长 prompt 更稳。典型场景包括报告生成、代码迁移、文档问答、数据分析流水线。它的风险是错误会沿链传播，所以每个中间产物都应该有 schema 或验证逻辑。

2.2 Routing：让 agent 在多条路径里做选择

Routing 把固定流程变成条件流程。用户问订单状态走订单库；问产品信息走商品检索；问投诉走人工升级。这里的关键是 路由器必须输出可执行、可审计的分支标识，而不是模糊自然语言。

[!tip] LLM Routing vs 规则 Routing 规则路由稳定、成本低，但覆盖不了长尾表达；LLM 路由灵活，但需要置信度、fallback 和日志。工程上常用混合方案：高置信规则先拦截，模糊 case 再交给 LLM 分类，最后保留 clarification 分支。

2.3 Parallelization：让独立子任务并发

Parallelization 的收益来自减少等待，而不是提高单步智能。检索多篇资料、调用多个慢 API、让多个 critic 独立审查，都适合并发。它的核心约束是子任务之间不能有强依赖，最后需要一个 synthesis 步骤合并结果。

2.4 Reflection：把“生成”变成“生成-评价-修正”

Reflection 是 agent 可靠性的早期补丁：先产出，再自评，再修正。它适合文本质量、代码 review、计划检查、事实一致性检查，但不能替代真实执行验证。最重要的工程经验是：critic 的评价标准要外部化，否则只是让同一个模型换一种语气重复错误。

3 外部世界接口：Tool Use、Planning、MCP、A2A

3.1 Tool Use：突破 LLM 静态知识边界

[!PDF|] Agentic-Design-Patterns.pdf, p.79

The Tool Use pattern, often implemented through a mechanism called Function Calling, enables an agent to interact with external APIs, databases, services, or even execute code.

Tool Use 的完整链路是：定义工具 schema -> LLM 判断是否调用 -> 生成结构化参数 -> 框架执行函数 -> 返回 observation -> LLM 继续推理。这里最常见的问题不是模型不会调用，而是工具定义不适合 agent：参数过多、语义模糊、没有查询/过滤/分页、错误信息不可恢复。

[!tip] 什么是“agent-friendly API”？ agent-friendly API 不只是把旧接口包成 function call，而是让接口天然适合模型决策：名称清晰、参数少而明确、支持筛选/排序/限制返回量、错误信息可解释、返回结构稳定。AgentX 和 AgentSociety2 都说明了同一点：越是非确定性的 agent，越需要强确定性的工具和协议托底。

3.2 Planning：当 “how” 不知道时才需要计划

[!PDF|] Agentic-Design-Patterns.pdf, p.100

the decision to use a planning agent versus a simple task-execution agent hinges on a single question: does the "how" need to be discovered, or is it already known?

Planning 的适用边界很关键：如果流程已知，用固定 workflow 更可靠；如果路径需要探索、约束会变化、工具结果会影响后续步骤，才值得让 agent 动态规划。换句话说，Planning 解决的是未知路径，不是所有复杂任务。

3.3 MCP：标准接口不能代替好接口

MCP 的重要性在于把 resources、prompts、tools 统一暴露给 LLM host。但书里提醒了一个容易忽略的点：MCP 是接口标准，不会自动让糟糕 API 变好。旧系统如果只提供“逐条取详情”而没有过滤、聚合、排序，agent 会又慢又容易出错。

3.4 A2A：跨框架多 agent 协作的协议层

A2A 解决的是 agent 之间的互操作：不同框架、不同供应商、不同角色如何发现彼此、声明能力、传递任务、追踪状态、处理安全。它和 Multi-Agent Collaboration 的关系是：后者是架构模式，A2A 是协议实现候选。

4 状态、知识和长期改进

4.1 Memory Management：短期上下文和长期记忆不是一回事

短期 memory 是上下文窗口里的最近消息、工具结果、当前计划；长期 memory 是外部数据库、向量库、知识图谱或文件系统里的持久信息。长上下文模型只扩大了短期 memory，不等于解决长期记忆、召回、遗忘和一致性问题。

4.2 RAG：让回答有外部依据

RAG 的关键不只是“向量检索 + 拼 prompt”，而是把知识库构造成可被 agent 可靠使用的工作流：文档切分、metadata、召回、重排、引用、答案生成、事实核查。对企业 agent 来说，RAG 也是权限控制和可审计性的基础。

[!tip] RAG 和 Memory 的区别 RAG 通常面向外部知识，用来回答“世界中有什么”；Memory 面向 agent 自身经历和用户上下文，用来回答“我之前经历了什么”。很多系统会把两者都放进向量库，但使用策略不同：RAG 更重来源可靠性，Memory 更重时间、用户和任务状态。

4.3 Learning and Adaptation：从经验里改进，但要防止错误归因

Learning and Adaptation 可以来自强化学习、监督学习、在线学习、few-shot 适配或 memory-based learning。工程上最危险的是把一次成功/失败直接写成规则。AgentX 的 negative-result assetization 和 SGPO 是更严谨的版本：必须记录上下文、失败原因、可重放验证，而不是只存“某策略有效”。

5 可靠性：HITL、异常恢复、Guardrails、Evaluation

5.1 Human-in-the-Loop：不是兜底，而是系统边界

[!PDF|] Agentic-Design-Patterns.pdf, p.204

The Human-in-the-Loop (HITL) pattern represents a pivotal strategy in the development and deployment of Agents.

HITL 的价值在于把人类判断放在正确节点：高风险动作前、不可逆动作前、低置信推断后、伦理/法律/品牌判断时。它不是“模型错了就找人”，而是把人作为控制面的一部分。

5.2 Exception Handling and Recovery：让失败可恢复

一个可靠 agent 至少需要： 1. 错误分类：工具错误、权限错误、参数错误、环境不可用、模型输出不合规。 2. 重试策略：指数退避、换模型、换工具、降级路径。 3. 状态回滚：外部动作要么幂等，要么有 undo/compensation。 4. 失败记录：把失败写成可检索案例，而不是丢进日志黑洞。

5.3 Guardrails：覆盖输入、输出、工具和行为

Guardrails 分四层： 1. 输入层：prompt injection、恶意内容、越权请求。 2. 工具层：哪些工具可用，参数范围是什么，是否需要审批。 3. 输出层：事实性、合规性、毒性、隐私泄漏。 4. 行为层：预算、任务边界、禁止动作、人工确认。

5.4 Evaluation and Monitoring：agent 上线后才是真正开始

Evaluation 不能只看一次离线 benchmark。生产系统需要监控任务成功率、工具错误率、延迟、token 成本、用户满意度、人工接管率、安全拒绝率、回滚率。对 agent 来说，轨迹日志本身也是训练和改进资产。

6 和另外三篇论文的关系

最有启发的连接：这本书给的是 pattern vocabulary，AgentX 和 AgentSociety2 给的是这些 pattern 在真实复杂系统中的组合样例。

个人思考

与其他论文的关联

• 与 [[AgentX_Towards Agent-Driven Self-Iteration of Industrial Recommender Systems 精读笔记]]：AgentX 可以看作本书多个 pattern 的工业化组合：Routing 决定 proposal 状态，Tool Use 落代码和 A/B，Evaluation 把线上结果变 reward，Learning/Adaptation 用 SGPO 更新 harness。
• 与 [[AgentSociety2 精读笔记]]：AgentSociety2 把 Skill、Workspace、Tool、Human-in-the-loop 做成社会科学研究平台，正好对应本书的 Memory、Tool Use、Planning、HITL。
• 与 [[Exploring Recommender System Evaluation_A Multi-Modal User 精读笔记]]：A/B Agent 是一个更窄但很清楚的应用：把用户行为模拟 agent 化，并通过多模态 UI、memory 和 fatigue system 提高仿真一致性。

在我的工作中能怎么用

1. 做 agent 系统设计评审时，可以把 21 个 pattern 当 checklist：是否有路由？是否有工具 schema？是否有 memory 策略？是否有异常恢复？是否有评估和人工 gate？
2. 做推荐/实验自动化时，优先实现“可验证链条”：proposal schema、工具调用日志、A/B 判断规则、失败资产化，而不是先追求全自动。
3. 对每个工具接口做 agent-friendly 改造：过滤、排序、分页、 dry-run、错误码、权限、幂等和审计。

开放问题/疑问

1. 21 个模式之间缺少严格依赖图：哪些是最小可用 agent 必须有的，哪些只在复杂场景需要？
2. 多模式组合后，错误传播如何评估？例如 RAG 召回错 + Tool Use 执行错 + Reflection 自信修正，会造成复合风险。
3. “Learning and Adaptation” 在生产中需要怎样的回放验证，才能避免把噪声写入长期记忆？

局限性

1. 更像工程手册，不是实验论文；缺少统一 benchmark 证明每个 pattern 的收益。
2. 某些章节偏概念介绍，真实落地还需要结合具体框架、权限、监控、数据治理。
3. 对高风险行业的合规、安全、审计深度不够，需要和组织内治理体系一起设计。