简介《Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems》是一本面向 AI 研发工程师、LLM 应用开发者与技术负责人的技术书籍系统讲解智能体系统的核心设计模式与工程实践。内容覆盖并行化与顺序化代理编排、短期与长期记忆管理、Human-in-the-Loop 人机协同、RAG 知识检索增强、任务优先级排序、多代理协作、评估监控机制及推理引擎内部原理并结合 Google ADK、LangChain 等框架给出可运行的代码示例帮助读者从理论到落地构建高效、可靠、可扩展的智能代理系统。书中还特别强调高风险环境中确保安全性、透明性与责任性的设计原则并给出自我验证与合同式交互等高可信度代理的实现思路。资源包共 1 个文件为英文原版 PDF 电子书压缩包大小 17.56MB便于技术查阅与日常参考尤其适合放在手边随时比对学习。目前已有 551 人学习下载适合系统掌握智能体设计模式、推进 LLM 应用生产级落地的人群阅读。1. 为什么放下万能系统提示词改学 Agent 架构1.1 一个把我逼到墙角的需求之前接了一个内部知识库问答项目需求听起来很简单让员工用自然语言提问系统给出准确答案。前两周我还挺乐观写好了一版上千字的系统提示词把文档分批塞进向量库再做一个检索增强生成流程demo 跑得很顺。但一到真实场景就露馅了用户问帮我查一下报销流程里关于发票丢失的处理方式顺便看看最近有没有相关的制度更新这种复合指令直接让单轮检索加生成的方式乱套——要么检索到一堆无关片段要么回答顺序错乱。更麻烦的是系统只会做回答这一件事。用户问帮我把这个报销流程和去年的对比一下整理成表格发到邮箱它做不到。因为它没有分解任务→查询数据→调用工具→生成表格→调用邮件服务这种执行链路。那段时间我反复调提示词效果始终不稳定后来才明白问题不在提示词工程而在架构设计。我需要的不是一个更聪明的模型而是一套能把模型能力编排成智能体的设计方式也就是现在常说的 Agentic Design Patterns。1.2 Agent 化系统的本质从一次生成到循环执行传统 LLM 应用的思路是输入一段文本输出一段文本模型和外部世界是隔离的。而 Agent 化系统最大的区别是引入了感知、决策、行动、反思这个闭环。用大白话解释普通模型像一个学识渊博但坐在那里不动的顾问你问他什么他答什么Agent 则像一个被派出去办事的人他会先理解目标再拆解步骤发现需要资料就去找遇到问题会调整思路做完之后还能检查结果对不对。所以 Agentic Design Patterns 不是某个具体框架或者某段代码技巧而是构建智能系统时反复出现的几种方法论。理解了这些模式你在面对复杂任务时就知道该用哪种结构去编排模型、工具、外部数据和反馈机制。这篇文章我想用做真实项目的角度把这几年踩过的坑、验证过的做法以及几个最关键的设计模式完整过一遍给正在从提示词工程师往智能体架构师方向走的朋友一个参考。2. 四个 Agentic 设计模式先建立起骨架认知Agentic 系统听起来很高大上但拆到骨架层面常用的核心模式其实就那么几个。我按自己实践中的使用频率来排分别是 Reflection反思、Tool Use工具调用、Planning计划和 Multi-Agent Collaboration多智能体协作。2.1 Reflection 模式让 LLM 扮演自己的审查员Reflection 是四个模式里最容易被忽略、但性价比最高的一个。核心思想很简单模型生成结果之后不要直接返回给用户而是再让同一个或者另一个模型对结果进行审查、批判、修正。刚开始我觉得这不就是多问一次大模型吗多花一次 token 有什么意义后来在写代码生成场景里被教育了。让 GPT 直接生成一段 Python 脚本经常出现 API 拼写错误、逻辑边界漏处理的问题。但如果加上一个 Review 步骤把生成的代码和需求描述一起交给模型要求它请你以资深工程师的视角审查这段代码指出可能出现的运行时错误、边界遗漏并输出修订版最终代码质量能明显提升。这个模式背后的原理是LLM 在生成时是自回归式的它倾向于顺着已生成的 token 继续写下去很难在同一轮里发现自己的逻辑漏洞。但切换到审查者角色时模型会从新的视角重新审视内容反而更容易发现问题。实践中建议把生成角色和审查角色分开设定甚至使用不同的 temperature 参数生成时偏创造、审查时偏严谨。2.2 Tool Use 模式把 API 变成模型的手脚Tool Use 是实现模型能做事的关键。它让 LLM 在对话过程中决定是否调用外部工具如搜索引擎、数据库查询、文件读写、第三方 API并根据工具返回值继续生成结果。在 OpenAI 之前那批 function calling 功能普及之后这个模式的实现难度大幅降低。但真正的设计重点是如何定义工具。我在项目里接企业微信通知工具时最初只写了参数content, receiver结果模型经常调用得乱七八糟。后来我学会了把工具描述写得像一份完整的产品说明书包含这个工具能做什么、不能做什么、参数格式、返回值含义、失败时可能抛出的错误。一个经典的场景是用户问帮我查一下服务器日志里的错误信息然后给出修复建议。如果没有 Tool Use模型只能回答我无法访问你的服务器有了工具模型会主动调用 log_query 工具、解析返回结果、再结合知识生成建议。可以说 Tool Use 是 Agent 从聊天走向干活的第一步也是后面几个模式的基础。2.3 Planning 模式先拆解再执行Planning 模式解决的是复杂任务。当用户提出的目标无法一步完成时Agent 需要先将目标拆解成多个子任务制定执行计划然后按顺序或并行执行。早期我实现过一个文档整理 Agent用户丢进来一批会议纪要和产品需求文档要求自动生成一份项目周报并且把每个人的待办事项提取出来按优先级排序。如果让模型直接输出效果会非常随机。正确做法是把它拆成读取文档列表、逐篇提取关键信息、识别责任人、按优先级排序、生成周报模板。我常用的实现方式有两种。一种是给模型提供计划-执行两步提示让它先输出一个 TODO 列表再逐个执行另一种是采用 ReAct 的思维模式让模型在每一轮边思考边行动循环往复。后者更灵活但容易在复杂任务中迷失方向所以我倾向于混合使用遇到大型任务先显式做一次规划再进入 ReAct 循环。2.4 Multi-Agent 协作模式多个角色分担复杂工作多智能体协作模式是近半年最火的方向。它不是简单地把多个 Agent 丢在一起而是给不同 Agent 设定不同角色和职责组成一个虚拟团队协同工作。举个例子我曾经做一个市场分析系统拆了三个角色数据收集 Agent 负责抓取行业信息分析 Agent 负责提炼趋势和洞察写作 Agent 负责把分析结果写成结构化报告。每个 Agent 有自己的系统提示词、工具集合和输出格式由一个调度模块负责消息传递和结果汇总。这个模式的优势是模块化程度高每个角色可以被单独测试和替换缺点是消息流转成本高、容易产生信息失真和任务扯皮。我的经验是如果单个 Agent 加工具能解决的问题绝对不要为了炫技而上多 Agent。多智能体的价值只有在任务本身确实需要不同专业视角、并且流程边界清晰时才能真正发挥出来。3. 动手前的关键决策框架选型、状态设计和循环控制模式讲完了不少人应该已经在想那我自己写代码怎么搞。这里直接说结论不推荐从零写 while 循环来管理 Agent 状态除非你想把全公司的问题都排查一遍。下面说我的选型思路和设计重点。3.1 我为什么选 LangGraph 而不是从零写 while 循环早期干过一件蠢事自己用 Python 写了一个while 循环调模型、根据结果决定是否继续的 Agent 调度器。最开始确实能跑因为任务足够简单。但加了工具调用、多分支路由、状态回退之后代码迅速变成一团浆糊。每次调试都要在循环里打无数日志却还是搞不清状态到底流转到哪一步了。后来我换成 LangGraph核心变化是它把 Agent 流程显式表达成一张图节点是函数边是转移条件状态由一个集中管理的对象维护。你可以理解成普通代码是一条流水线而 LangGraph 是一张地铁线路图——列车状态到了哪一站节点、下一站去哪个方向边都一目了然。它不一定比自研代码更聪明但它让复杂流程可观测、可控制、可恢复。当然这不代表你必须用 LangGraph。如果你只是在做一个调用一次模型、可能调用一个工具的场景用 OpenAI 原生的 function calling 就够了。框架选型的原则始终是给问题匹配对应的复杂度而不是为了用框架而用框架。3.2 状态设计才是 Agent 的真正难点很多初学者以为 Agent 的核心是提示词写得有多好但真正决定 Agent 能不能稳定的是状态设计。状态就是 Agent 在运行过程中需要持续维护和更新的全部信息包括当前消息列表、工具调用记录、临时结果、任务进度等。我在状态设计上吃过一个大亏。做一个客服 Agent 时用户和 Agent 来回多轮交谈我一开始只把用户历史消息放进了上下文结果 Agent 经常忘记自己之前已经查询过哪些订单用户改口之后它还会查询重复数据。后来我把状态拆成几块messages完整对话记录tool_results每次工具调用的结果摘要task_status当前任务做到哪一步比如 pending / running / donefailures已经出现过的错误避免反复踩同一个坑状态设计的目标是让 Agent 在任意节点都能从状态对象中搞清楚自己是谁、做过什么、还要做什么。这听起来麻烦但长期运行的系统必须这么做。3.3 循环终止条件一定要先想好退路Agent 的本质是循环而循环系统最怕的就是永不停机。因为没有显式终止条件模型会陷入自我对话的怪圈不断生成新意图、不断调用工具直到把上下文占满或者预算烧穿。我常用三种方式来控制循环终止。第一是设置最大迭代次数比如允许 Agent 最多执行 15 步超了就停止并返回当前结果第二是设置目标完成判定让 Agent 在每一步结束前自问目标是否已经达成达成则主动输出 end 标记第三是设置时间或 token 预算上限配合回调函数强制中断。强烈建议这三种同时使用别把鸡蛋放在同一个篮子里。4. 从零搭建一个自动排障 Agent 的完整过程理论说得再多不如跑一个真实案例。下面我分享一个在实际项目中验证过的自动排障 Agent搭建过程场景是用户上报某个服务访问异常Agent 需要自动查询日志、分析可能原因、给出修复建议。4.1 场景定义与工具清单这个场景里Agent 要做的不是回答一个问题而是完成一次排障任务。我给 Agent 设计了三个工具search_logs(service_name, time_range)查询指定服务的日志数据check_service_status(service_name)查询服务健康状态request_access(permission)在需要更高权限时发起申请工具定义代码如下核心是给模型清晰的结构化 JSON Schematools [ { type: function, function: { name: search_logs, description: 查询指定服务在某个时间范围内的日志返回原始日志行列表, parameters: { type: object, properties: { service_name: {type: string, description: 服务名称如 api-gateway}, time_range: {type: string, description: 时间范围如 last 30 minutes} }, required: [service_name, time_range] } } }, # check_service_status、request_access 结构类似省略 ]这里有个细节工具描述里一定要写清楚成功返回什么、失败返回什么、什么情况下不适合调用这个工具。比如request_access的 description 里我加了只有在确认权限不足且排障必须继续时才能调用否则模型会把申请权限当成万能钥匙动不动就发申请。4.2 核心代码实现定义状态、节点和反射回路我使用 LangGraph 来实现核心节点有三个call_model调用大模型决策、execute_tool执行工具调用、reflect反思总结。状态对象用一个字典维护。from typing import TypedDict, Annotated, List import operator from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: Annotated[List[dict], operator.add] tool_results: dict step: int done: bool def call_model(state: AgentState): # 将 messages 和 tool_results 打包成上下文调用 LLM response llm_with_tools.invoke(state[messages]) return {messages: [response], step: state.get(step, 0) 1} def execute_tool(state: AgentState): last_msg state[messages][-1] if not last_msg.tool_calls: return {done: True} results [] for call in last_msg.tool_calls: result dispatch_tool(call[name], call[arguments]) results.append({role: tool, content: str(result)}) return {messages: results, tool_results: {last: results}} def reflect(state: AgentState): # 反思节点检查排障是否完成生成最终结论 conclusion llm.invoke( 请基于以下对话和工具结果给出完整的故障原因和修复建议 如果无法确认请说明需要哪些额外信息。\n json.dumps(state[tool_results]) ) return {messages: [conclusion]} graph StateGraph(AgentState) graph.add_node(call_model, call_model) graph.add_node(execute_tool, execute_tool) graph.add_node(reflect, reflect) graph.add_edge(call_model, execute_tool) graph.add_conditional_edges( execute_tool, lambda s: reflect if s.get(done) else call_model, {reflect: reflect, call_model: call_model} ) graph.add_edge(reflect, END)这段代码里最关键的是conditional_edges的用法工具执行完以后如果判断任务完成就进入反思节点输出结论否则继续循环回到call_model做下一轮决策。这个条件路由就是前面说的循环控制它能把 Agent 的行动收敛到一个终点。4.3 一次真实运行效果它真的会自我纠错我在测试时故意构造了一个故障用户问payment-service 最近 10 分钟访问报错很多帮我查一下原因。Agent 第一轮通过search_logs拿到日志发现大量 connection timeout给出的判断是数据库连接池耗尽。但我给它配置了一个外部信号check_service_status返回该服务的上游数据库 CPU 使用率异常高。这时候 Reflection 节点的作用就体现出来了模型重新审视了整段工具结果意识到连接池耗尽只是表象根因可能是数据库负载异常最终输出的结论从扩容连接池修正为检查数据库慢查询和连接数峰值。这个自我纠错的环节如果只有单轮生成是根本做不到的。5. 上线前必须解决的五个稳定性问题Agent 系统开发完只是第一步真正让系统稳健运行需要处理一堆工程问题。下面这五个坑我在生产环境里基本都踩过每个都值得提前设计好。5.1 Agent 陷入死循环比想象中更容易发生Agent 死循环的原因往往很蠢模型觉得任务没完成但它每次尝试的工具调用都失败或者它认为需要新的信息却不断复用同一个工具重新查询。我在一个竞品监控 Agent 里遇到过循环 20 次还在反复调同一个查询接口的情况。最后定位到问题源头工具返回的结果里明确写着无新增数据但模型对空结果的判断逻辑不清晰仍然认为再查一次可能会有数据。解决办法有两个一是把工具返回结果里加上本次查询已完成这是最终结果之类的明确标记二是在循环外设置硬性最大轮数超时后强制收敛到反思节点。老实说第二个办法才是保命的。5.2 上下文爆炸长期运行的隐形杀手每次工具调用结果、中间推理过程都会累积进messages长期运行的 Agent 上下文会越来越大最后超出模型窗口限制或者响应变慢、成本暴涨。我处理上下文爆炸用过三个阶段的做法。初级做法是截断只保留最近 N 轮消息简单但容易丢信息中级做法是摘要把较早的对话压缩成一段摘要文本再放进上下文高级做法是外置记忆把关键结论写成结构化 JSON 存到内存数据库需要时再动态取回。真正生产级的系统至少要做到摘要加外置记忆结合。5.3 工具调用失败后的恢复策略工具调用的失败其实是常态网络抖动、权限过期、参数错误都会遇到。但如果 Agent 一遇到工具失败就崩溃或者笨拙地重复同一个调用体验会相当糟糕。我的做法是在状态里加一个failures列表记录每次失败的错误类型。收到工具异常时先把错误信息返回给模型并提示你可以尝试修改参数重试或者换一个工具如果多次失败请直接说明障碍。另外部分工具要设计降级方案。比如日志查询超时可以降级成查询最近沉淀的指标数据保证 Agent 能完成半成品的判断而不是彻底卡死。5.4 可观测性黑盒 Agent 没法维护Agent 系统的决策链路长、工具调用多一旦输出错误结果排查到底是模型判断错还是工具数据错非常耗时。我强烈建议在开发阶段就埋好全量日志至少记录以下信息每一轮模型输入的完整消息列表触发了哪个工具、传入了什么参数工具返回的原始结果模型为什么继续循环或结束每一步的 token 消耗和时间开销在 LangGraph 里可以直接给节点加回调函数把上述信息结构化输出到日志中心。你甚至可以做一个简单的回放页面把整个 Agent 的运行轨迹可视化出来。没有可观测性的 Agent就像没有仪表盘的飞机能飞起来但没人敢长期乘。5.5 成本失控静态预案不如动态预算Agent 类应用的成本比普通问答高得多尤其是多轮循环加反思一个任务烧掉几万 token 很常见。我见过不少项目 demo 跑得很好一上真实流量就被账单吓醒。控制成本有两种思路静态方式是在系统提示词里要求优先用检索结果回答避免不必要的工具调用动态方式是给每个会话设定 token 预算当消耗超过阈值时自动切到更小的模型或缩短上下文。我习惯在做状态设计时就预留cost_so_far字段每一轮结束后累加 token 数达到阈值就强制进入总结节点。这是个很笨但很有效的办法至少账户不会被一夜之间烧空。6. 关于模式规模的一点个人取舍6.1 能用单个 Agent 解决的不要急着上多 Agent多 Agent 协作模式现在被讨论得很热闹但我的建议很保守先尝试用单个 Agent 加工具解决整个任务把流程跑通、果能实现就别拆多 Agent。因为每增加一个 Agent必然增加消息传递开销、角色冲突、上下文冗余排障难度也会指数级上升。我见过最夸张的设计做一个简单的周报生成系统硬拆了五个 Agent结果每次对话要来回传递十几轮消息成本和延迟都让人崩溃。多 Agent 更适合边界天然清晰、每个角色需要不同工具权限和数据范围的场景比如数据分析 Agent 不能用文档编辑权限文档编辑 Agent 不需要数据库权限这种隔离需求。6.2 反思深度与响应延迟的平衡Reflection 虽然能提高结果质量但它本质上是多跑一次模型延迟和成本都会增加。在实时对话场景里用户等待时间每多一秒体验下降都很明显。我的经验是给反思设计分级简单任务只做轻量自查让模型在最终输出前顺手检查格式问题重要任务才做深度反思引入独立的审查模型并要求输出修订对照。你可以通过判断任务复杂度来选择不同路径用路由规则控制质量与延迟的平衡。6.3 最后一个实操小技巧把工具描述当成产品文案来写这个建议我反复强调给团队工具描述的质量直接影响 Agent 调用工具的准确率。同一个工具写给模型看的描述如果含糊不清正确率会明显下降。你要站在模型的角度想象它手里拿着几十个工具怎么知道哪个是最适合当前任务的写工具描述时我通常按这个模板来这个工具负责什么、在什么时候特别适合调用、在什么情况下不要调用、参数格式和边界值是什么、返回结果成功和失败分别长什么样。别嫌写得长这些字花的不是 token而是给模型装上正确的方向感。把这个细节做好你会发现 Agent 的稳定性提升幅度比换一个更强的模型还大。Agentic Design Patterns 这个领域现在还在快速演进但无论后面冒出多少新框架背后的道理都不会变智能系统不是靠一条复杂提示词堆出来的而是靠清晰的模式、严谨的状态设计和扎实的工程控制组合出来的。按这个思路去搭骨架然后再用真实业务需求去打磨细节你也能做出值得上线的 Agent 系统。本文还有配套的精品资源点击获取