Agentic Design Patterns 前 5 章学习与思考

Sun, 14 Jun 2026 00:00:00 +0000

背景

最近在系统学习《Agentic Design Patterns》（作者 Antonio Gulli，中文翻译仓库由 xindoo 维护在 adp.xindoo.xyz）。这本书讲的是 AI Agent 系统的各种设计模式——和写代码时常用的"设计模式"是同一类概念，只是把对象从代码结构换成了 Agent 编排。

这周连着读了前 5 章。整体感觉是：每一章都解决一个具体的"痛点"，五章拼起来刚好是一个最小可用的 Agent 系统骨架。把这 5 章的笔记和思考整成一篇，方便以后回看。

我对前 5 章的整体理解

提示词链可以是从 LLM 到 Agent 的一个过渡，从单次交互到多次任务。在多维度的任务下，单一提示词可能：指令忽略、上下文偏离、错误传播、上下文窗口不足、幻觉。通过提示词链可以做到：顺序分解增强可靠性。不断聚焦到更精细的地方。

总的来说，提示词链是一种执行策略和流程控制方法。它将一个复杂的任务，拆解为一系列带有明确前后依赖关系的子任务。上一个节点的输出被解析并组装成下一个节点的输入。主要目的是降低单次生成的认知负荷，提高输出的确定性、准确性、可控性。

hermes注：你把"提示词链"提到了"执行策略和流程控制方法"的高度，这比把它当成"一个技巧"要准。它本质上是给 LLM 调用加了一层 DAG——和传统编程里的管道、流水线、 MapReduce 是同构的。

hermes注：另一个值得记的视角是"从 LLM 到 Agent"。提示词链本质上是"让 LLM 不止回答一次"，而 Agent 是"让 LLM 自己决定什么时候不再回答"。前者是固定拓扑，后者是动态拓扑。

沿着这条主线往下看，后面四章就是在这个"提示词链 = DAG"基础上做扩展：

章节	解决的痛点	在 DAG 上的位置
Ch1 链	任务太长，单步 LLM 撑不住	把节点排成线
Ch2 路由	任务不一样，固定流程处理不了	加分支节点
Ch3 并行	任务独立，但顺序执行太慢	多个节点并发
Ch4 反思	输出质量不稳定，需要质检	节点加自循环
Ch5 工具	LLM 不能直接动外部世界	节点挂上对外接口

从 Prompt Engineering 到 Context Engineering

上下文工程和提示词工程。Prompt engineering → context engineering。传统 prompt engineering 专注于优化用户的当前会话的内容，例如 system message、基于角色的提示词等等，是对话层面的内容。Context engineering 则进一步丰富了信息，包括 prompt、rag、memory、state、history、structured output、tool results 等等，将任务从"回答问题"转变为"智能体执行任务"的层面。

hermes注：你提到的这个转变其实是看 agent 系统的关键视角：前 4 章和第 5 章是两层——前 4 章是"在 LLM 内部编排"，第 5 章是"把 LLM 接到外部世界"。所以 prompt engineering 关心"一句话怎么写好"，context engineering 关心"围绕这一次调用要准备哪些东西"。

这五章里凡是要"让 LLM 做好一件事"的，本质上都是 context engineering：链是上下文分段、路由是上下文分类、并行是上下文分发、反思是上下文比对、工具是上下文替换（把工具结果塞进下一轮上下文）。

提示词链（Ch1）

原文用了一个三层链的例子：市场研究报告 → 总结 → 趋势识别 → 邮件撰写。重点不是例子本身，而是它说清楚的三件事：

拆完之后每一步的认知负荷小，模型更稳
步骤之间用结构化输出（JSON / XML）传递，比纯自然语言少出错
这种"分而治之"是后续所有模式的地基

hermes注：原文还提到"分而治之"——和传统编程里把大函数拆成小函数是同一回事，只是这里的"函数"变成了 LLM 调用。

我的疑问是：拆多少步算合适？拆得太细，调用次数爆炸；拆得太粗，又回到单提示词的老问题。原文没给出明确答案（实际也不会有，这是个工程权衡），但有一个隐含信号——每一步的输入输出应该能用一个简单 schema 描述。如果描述不了，说明这步本身还该再拆。

路由（Ch2）

第二章，路由。这里我就不详细研究了。简单来说就是，根据不同的方式路由到不同的节点。路由方式可以有：基于 LLM、基于 embedding（语义相似度）、基于规则（关键词、正则、if-else 等等）、基于机器学习（分类器、判别模型等等）。

hermes注：你对路由的 4 种实现方式分类（LLM / 嵌入 / 规则 / ML）和原文完全对上号了。原文还提了一个细节值得记：基于 ML 的路由"决策组件不是在推理时执行提示词的生成模型……路由逻辑被编码在微调模型的学习权重中"——这意味着它和基于 LLM 的路由不是同一个抽象层，LLM 那条路是"prompt 触发决策"，ML 这条路是"权重编码决策"，前者灵活后者确定。原文给的代码示例也走了两条路：LangGraph 显式构图、ADK 自动流——前者让你看清路由逻辑，后者把路由藏进框架。

我对这章的收获是：路由的本质是"决策路由"。选哪种实现方式，取决于决策的复杂度 + 决策的频率 + 决策的可解释性要求。

规则路由：快、确定、可解释，但维护成本随规则数线性增长
LLM 路由：灵活、能处理模糊输入，但要付推理成本、结果有随机性
嵌入路由：语义级匹配，介于规则和 LLM 之间
ML 路由：把决策烧进权重里，速度极快，但要训练数据 + 重新训练

实际工程里我猜用得最多的是 LLM 路由（最简单）和规则路由（最确定），嵌入和 ML 在大规模场景才划算。

并行化（Ch3）

https://adp.xindoo.xyz/chapters/Chapter%203_Parallelization/ 不细看了，就是任务可以并行化，设计层面想好

hermes注：你的总结"设计层面想好"很准。并行化的核心是"识别独立子任务"——是设计决策，不是实现细节。文章举的例子（搜 A → 总结 A → 搜 B → 总结 B）能并行，本质是因为 A 和 B 互不依赖；但综合那步还是顺序，因为它依赖所有并行任务的结果。所以并行化的边界 = 数据依赖图。

hermes注：原文也提了一个反面的提醒：“采用并发或并行架构会引入显著复杂性和成本，影响设计、调试和系统日志等关键开发环节”——不是所有任务都该并行，简单顺序就别强行并发。

这一章的"反面提醒"我觉得是这 5 章里最有价值的一段——容易被忽略。作者的潜台词是：并行化是优化手段，不是架构起点。先画好数据流图，看哪些节点之间没边、没依赖，再考虑并行。能用顺序就别用并行。

反思（Ch4）

反思部分，稍稍类似 ReAct 框架。通过不断的反思来完善，也有一种，两个 agent 对抗来完善产出的感觉。

hermes注：你提的"类似 ReAct"和"两个 agent 对抗"是这一章的两个核心视角。ReAct（Reasoning + Acting）侧重于"思考—行动—观察"循环，反思侧重于"生成—评审—优化"循环——两者都引入了"迭代反馈"，但 ReAct 的反馈来自外部环境（工具结果），反思的反馈来自内部评估（评审者）。生产者-评审者（Producer-Critic）这种"对抗"在生成式 AI 里被泛化成了"对抗式"模式：用一个独立的视角打破生成者的"认知偏差"。这就是为什么"评审者用不同 system prompt"这么重要——它强制构造一个新的视角。

hermes注：反思模式的一个隐性成本：原文点出了"超出模型上下文窗口或被 API 服务限制"——多轮反思会把对话历史撑爆。所以反思一般搭配记忆管理（第 8 章）和上下文工程来用，不是孤立模式。

我对这一章最深刻的印象是：反思是给 LLM 加"自我意识"的尝试。但它的代价是：每多一轮反思，多一次 LLM 调用、多一份延迟、多一份上下文。所以反思要省着用——能用规则校验的（编译错误、断言失败）就别上 LLM 评审。LLM 评审留给那种"对错没有客观标准"的输出（写作、规划、对话）。

工具调用（Ch5）

https://adp.xindoo.xyz/chapters/Chapter%205_Tool%20Use/ 工具调用是关键，将 LLM 转变为能够感知、推理、行动的智能体。

hermes注：你的"将 LLM 转变为能够感知、推理、行动的智能体"点中了工具调用的本质。感知 = 通过工具读（搜索、查询、API），推理 = LLM 自己的思考，行动 = 通过工具写（发邮件、改数据库、控制设备）。原文里有一句特别值得记：“工具调用是连接 LLM 推理能力与大量可用外部功能之间差距的技术机制”——这句话定义了工具调用在 agent 体系中的位置。

hermes注：原文还做了一个重要区分：“函数调用"和"工具调用”。前者是字面意义（调一个 Python 函数），后者是更宽泛的概念——API、数据库、agent-to-agent 委托都可以是"工具"。从设计角度，“工具"是个抽象层，agent 不用关心底层是函数、HTTP 还是另一个 agent。

工具调用这一章补完了整个闭环。前 4 章都是"在 LLM 内部编排”，工具调用是"把 LLM 接到外部世界"。可以理解为 agent 系统的"动作"层。感知（读）+ 行动（写）+ 内部思考 = 完整的 agent 闭环。

5 章小结

把这 5 章放一起看，是一个递进结构：

Ch1 链：内部顺序（一个长任务怎么拆）
Ch2 路由：内部分支（不同输入怎么处理）
Ch3 并行：内部并发（独立任务怎么加速）
Ch4 反思：内部质检（输出怎么变好）
Ch5 工具：连接外部世界（感知 + 行动）

这五个组合起来，是"智能体系统"这个概念的最小完整集合。后续要学的规划（Ch6）、多 Agent（Ch7）、记忆（Ch8）都是在这个基础上加更复杂的协调层。

关于这个系列的学习策略

由于这个系列课程里的内容，大多是使用第三方库来做的，我觉得没有太大必要按照章节顺序来学习，所以后面会跳着看。

hermes注：这是个很清醒的判断。书里的"代码示例"是手段，“设计模式"是目的——模式一旦内化，下次遇到具体场景自己挑库实现就行。所以跳着看反而更省时间：先把"模式"啃透，“代码"按需再补。

待续

系列进度：5 / 21 + 7 附录。下次可能先跳到 Ch6 Planning，也可能先看 Ch7 Multi-Agent，看当时的兴趣。

Prompt Chaining on Zewang's Blog