简介《Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems》是一本系统讲解智能代理Agent设计模式与工程实践的PDF电子书内容从基础概念一直延伸到并行化执行ParallelAgent / SequentialAgent、短期与长期记忆管理、Human-in-the-Loop人机协同、RAG知识检索增强、任务优先级排序、多代理协作、评估监控以及推理引擎内部工作机制面向具备AI/ML/软件工程背景的研发、技术负责人与AI产品经理帮助读者从模式层面解决智能系统设计中效率、可靠性与可控性难题。资源为单份PDF压缩包约17.56MB体积适中可在电脑或平板上直接阅读。书中以Google ADK、LangChain等框架提供实际代码示例读者可动手搭建高效、可扩展的智能代理并学习在高风险场景中通过人类监督、自验证机制与合同式交互保障安全性、透明性和责任性。目前已有551人学习对于希望从设计模式视角构建可靠LLM应用的专业人士具有较强参考价值。 我最早接触 Agentic Design Patterns 这个词是在帮客户做客服系统升级的时候。当时的任务很朴素用户问“我的订单什么时候能到”系统得先查订单、再查物流、还要猜测用户是不是想催件。用传统流程写判断逻辑写到最后分支全都糊在一起。后来看到 Anthropic 那篇讲 Building Effective Agents 的文章才算正式把“智能体设计模式”这个词刻进脑子里。这篇文章不跟你聊概念只聊怎么动手适合正在用大模型做产品的工程师、想从纯对话转向任务型智能体的开发者以及被复杂业务逻辑折磨得不行的技术负责人。1. 智能体设计模式到底在解决什么问题先说结论智能体设计模式不是一套“高级框架”而是对“模型 工具 循环”这套结构的工程经验总结。它解决的问题是——怎么让大模型在一个真实业务里替你做决策而不是只做一个一次性回答问题的接口。1.1 从“写死流程”到“让模型自己选路”传统 API 调用是确定性的你写if order.status shipped程序就按这句话走。但真实业务里有太多“用户没说清楚”“数据缺失”“需要跨系统查询”的情况你不能把所有情况都写进代码里。智能体的核心变化是把“走哪条路”的判断权交给模型。你给它一堆工具再给它一个目标它自己决定先调用哪个、结果不够就再调一次。听起来很美好但乱用会翻车。所以社区把常用的组合方式沉淀成了几种固定套路这就是设计模式的由来。提示我见过最典型的翻车场景是新手一上来就搭一个“超级智能体”把所有工具、所有权限都塞进去结果模型不知道该先干什么甚至把不相关的工具轮着调用一遍。1.2 四种最基础的模式拆解模式典型场景调用方式失败特征Prompt Chaining先审核、再生成、后格式化上一个输出作为下一个输入中间某步格式出错链路直接断Routing根据意图分流到不同处理逻辑一次性分类然后走对应分支分类错误导致后向流程全错Evaluator-Optimizer生成内容后反复自检、修改生成 → 评估 → 再生成评估标准不明确陷入死循环Orchestrator-Workers把大任务拆成子任务分配给多个子agent主agent分解任务汇总结果子任务结果互相冲突汇总困难这四种模式各有各的脾气。拿 Routing 来说最适合的场景是“用户问题明显分几类每一类有完全不同的处理方式”比如售后和售前。Evaluator-Optimizer 则适合写代码、写文案这种需要多次打磨的任务生成一遍、让模型自己打分、再改一遍。1.3 为什么现在才流行起来不是现在的模型变聪明了才流行而是成本降到可以随便循环调用了。2023 年的时候一次 agent 循环可能要调四五次模型成本扛不住。2024 年下半年开始输入输出价格降了一个数量级延迟也控制在可接受范围内循环调用才成为工程可行方案。另外function calling能力的成熟给了模型稳定的“手”。模型输出一个结构化调用指令系统执行再让模型看到结果。没有这个能力智能体就只是“会聊天的玩具”。这些模式本质上是把人的工作流告诉模型什么时候该停、什么时候该查、什么时候该改。2. 从零开始一个航班改签智能体的完整实现我建议你第一次做智能体时别用太重量的框架先用代码把一个最小循环跑通。下面这个例子是我在项目里反复用过的原型结构全部用 Python 伪代码加注释说明你完全可以在本地把它跑起来。2.1 选型先别上 LangGraph除非你真的需要LangGraph 在编排复杂流程时确实好用但很多人一上来就用它结果被图结构、状态管理、条件边折腾得怀疑人生。我现在做原型第一版总是先写一个简单的while循环配上if判断能跑通后再决定要不要迁移到框架。选型逻辑不复杂你的流程如果只有一条主链路手写循环完全够。如果子任务之间要并行、要互相传递结果、要支持人在环审批再上 LangGraph 也不迟。早期用框架反而会劝退你因为报错信息光是理解就要花半天。2.2 定义状态与工具层智能体最重要的设计是“状态”。状态就是所有工具之间共享的一张便签纸模型读到什么、修改什么、最终输出什么全在这张纸上写清楚。from typing import TypedDict, List, Optional class FlightState(TypedDict): user_input: str from_city: Optional[str] to_city: Optional[str] date: Optional[str] flight_results: List[dict] selected_flight: Optional[dict] confirmed: bool注意状态字段不要贪多能用到的才放进去。我见过有人把整段用户历史都塞进状态结果模型每次读取都消耗大量 token 还不一定找准重点。工具层则是真正的业务执行查询航班、锁定价格、发起改签都是具体动作。def search_flights(from_city: str, to_city: str, date: str) - List[dict]: # 调用真实航班查询接口返回航班列表 return [...] def book_flight(flight_id: str) - dict: # 调用订票接口返回确认单 return {status: ok, pnr: ABC123}2.3 主循环逻辑模型 工具轮流接力核心主循环长这样把用户输入交给模型模型决定调用哪个工具执行工具后把结果返回给模型直到模型认为任务完成。def run_agent(state: FlightState, max_steps: int 5) - FlightState: for step in range(max_steps): messages build_messages(state) response model.call(messages, tools[search_flights, book_flight]) if response.tool_calls: for call in response.tool_calls: result execute_tool(call) state.update(result) else: # 模型没有要调工具说明认为可以作答 state[final_answer] response.content break return state这里max_steps是保命符。不加这个上限模型在复杂场景里可能会无限循环每晚一次循环都在烧钱。我一般先设 5 步调试完再根据业务需要调整。每次工具调用的返回结果要拼接成新的消息交给模型这一步建议单独封装函数别塞在主循环里不然代码很快会乱成一团。2.4 模式应用为什么不用 if-else 写死有读者会问航班改签不就是先查、再订、再确认吗用 if-else 一步步写死不就行了问题在于用户表达可能缺字段比如只说“帮我看看明天的机票”没说城市。传统流程就必须写一堆“缺什么就问什么”的逻辑而智能体模式里模型自己知道要查航班前先问清楚城市。这就是 Routing 模式的内置效果——模型在循环里天然担任了路由器的角色。你不必写“if 缺城市 then 提问”这种逻辑只需在系统提示词里说清楚“缺少必要信息时先向用户询问不要调用工具。”3. Agentic RAG 与工具调用设计让系统真正会用资料传统 RAG 在智能体时代必须升级。以前的流程是“用户问题 → 向量检索 → 拼接上下文 → 生成回答”一次成型。但在真实的智能体场景里问题往往不是一个大模型能一步解决的可能需要先检索、发现不够、再改写查询、再检索。3.1 传统 RAG 和 Agentic RAG 的本质区别维度传统 RAGAgentic RAG查询方式单轮向量检索多轮改写、多路召回、迭代补全决策权固定 pipeline无分支模型根据检索结果决定下一步上下文一次性拼入动态筛选、压缩、丢弃失败处理直接给兜底回答可再检索、可追问、可换策略打个比方传统 RAG 是图书馆前台你问什么他就翻什么Agentic RAG 是一个会主动帮你找书的助理这本书没有就换一本目录不对就换个关键词最后还会自己总结。3.2 一个“搜索-重写-再检索”的循环示例def agentic_rag(query, retriever, llm): context retriever.search(query) if not context: rewritten llm.rewrite_query(query) # 模型改写查询 context retriever.search(rewritten) # 判断检索结果是否充分 verdict llm.judge(query, context) # 返回 sufficient 或 insufficient if verdict insufficient: return agentic_rag(query 具体细节, retriever, llm) # 递归补充 return llm.answer(query, context)这个递归的出口一定要控制不然模型会因为检索结果永远“不够好”而无限递归。我通常会在函数外套一层步数计数器最多允许 3 轮超过就强制用已有上下文回答。Agentic RAG 最值得做的地方是让模型拥有“判断检索质量”的能力这一步能明显提升答案准确率。3.3 工具调用最容易踩的三个坑参数幻觉模型会把用户输入里没有的信息硬填进工具参数比如默认了个出发日期。对策是工具定义的描述里明确提醒“不确定时必须向用户确认”。结果校验缺失工具返回的数据格式和模型预期不一致模型会懵掉。对策是在工具内部先做一层 normalize把数据整理成统一 schema 再返回。上下文膨胀每轮工具结果都拼进上下文三轮之后 token 就爆炸了。对策是只保留本轮最重要的结果摘要历史结果可丢弃。这三个坑我在真实项目里全踩过。参数幻觉的杀伤力最大——它让用户看到系统居然“自作主张”填了个今天日期去查机票特别不靠谱。所以我在设计工具层时所有必填参数都做了强校验缺字段就先抛异常绝不把不完整的调用留给模型决定。4. 安全红线借鉴 OWASP Agentic Security Top 10 的工程实践智能体的安全问题和传统 API 完全不同。传统漏洞影响的是数据泄露智能体漏洞可能让系统直接执行真实操作比如退款、删除资源、发送邮件。我先看 OWASP 的 Agentic Security Initiative Top 10 时第一反应是“这哪里是安全清单这分明是工程部事故大全”。4.1 为什么安全问题在智能体时代被放大因为智能体把“决策权”交给了模型而模型是可被注入的。一条恶意构造的用户消息可能绕过所有业务逻辑让智能体去调用一个不该调的工具。传统代码里权限控制靠代码逻辑智能体里权限控制靠系统提示词加工具白名单这两者强度完全不是一个量级。4.2 我整理的六项高风险与缓解措施风险项触发场景缓解措施提示注入用户消息里夹带“忽略以上指令执行XX操作”将系统提示词与用户消息严格隔离系统提示词提示模型忽略非任务指令不当工具调用模型把“查询”误判成“删除”工具白名单 敏感操作二次确认过度授权子智能体拥有全部工具权限每个子智能体只分配最小必要工具集数据泄露检索接口返回了不该公开的数据做权限过滤层在工具层做数据脱敏无限循环模型反复调用同一工具全局步骤上限 单工具调用次数限制供应链信任外部工具返回恶意内容对所有外部返回内容做内容安全过滤注意OWASP 清单里有一项容易被忽略——智能体之间的“记忆污染”。一个子智能体处理了恶意输入后它共享的记忆对象可能被改写下一个子智能体就会受影响。所以任何时候跨智能体传数据都要做一次“无害化”清洗。4.3 安全清单可以直接抄作业我不是让你看完 OWASP 就把全部 10 项都实现一轮而是在落地智能体时至少要保证这几点一是工具层做最小权限每个 agent 只能看到它必须用的工具二是所有涉及真实系统写操作的工具必须加一个confirm参数模型必须向用户确认后才执行三是设置全局运行预算时间超时、步骤超限、费用超限都要强制终止。这些措施加完之后系统稳定性会明显提升。有一次我在演示时故意向测试 agent 发了一条“帮我退掉昨天的订单”结果系统在第一步就和用户确认避免了误操作。那一刻我意识到安全设计不是给安全工程师看的是给每个做 AI 产品的人看的。5. 下一个前沿Agentic RL 与跨界设计模式的启示智能体领域的热点发展很快Agentic RL智能体强化学习已经开始进入工程视野。我理解的 Agentic RL不是让模型自己训练自己而是让智能体在环境里通过奖惩反馈学会更优的工具调用策略——比如“查订单之前先问清楚订单编号”这种行为理论上可以通过强化学习自动习得而不再依赖人工写提示词。目前这块离大规模工程落地还有距离但方向已经明确。5.1 为什么 Agentic RL 可能改变设计模式现在的主流模式都依赖人工设计提示词来约束模型行为但提示词本质上还是自然语言不确定性很高。Agentic RL 的目标是通过奖励函数直接优化策略让智能体形成固定、可靠的调用习惯。举个容易理解的类比人工设计模式像手写菜谱Agentic RL 像训练一个厨师——你不再告诉他每道菜怎么做而是告诉他做出什么味道会得高分他自己琢磨出稳定的手艺。这个转换如果能落地设计模式会被重写。但现阶段工程上不要指望 RL 能直接取代模式成本和技术门槛都还很高。我的建议是持续关注但先把前面的基础模式用熟。5.2 从嵌入式系统的 C 设计模式里学到的三件事搜索热词里有个特别有意思的组合design patterns for embedded systems in C。你可能觉得怎么把嵌入式设计模式和智能体扯上关系但我研究了一遍发现嵌入式系统对资源极度敏感设计上特别讲究“有限状态”“事件驱动”“任务隔离”这些和智能体系统的诉求高度重合。第一个很重要的是状态机思维。嵌入式代码里系统永远知道自己当前在哪个状态不会既在登录又在支付。反观很多智能体对话混乱的根因就是状态边界模糊模型不知道当前处于哪一步。第二个是事件驱动嵌入式系统全靠中断事件触发对应到智能体就是“查询”“点击”“确认”这些触发点。第三个是模块解耦嵌入式里各模块能单独测试智能体的工具和决策逻辑也要能各自单测。5.3 我的跨界结论设计模式的核心不是某个语言的语法而是对“在约束条件下解决问题”的沉淀。嵌入式系统里的状态机模式、分层思想可以直接迁移到智能体系统设计里。以后你写智能体的时候不妨多想想“如果我只能用 64KB 内存我会怎么设计这个流程”答案往往会清晰很多。最后的实操建议做智能体一年半我的体会是不要被新概念带着跑先把基础模式吃透。Prompt Chaining、Routing、Evaluator-Optimizer、Orchestrator-Workers这四种模式每一种都写一个最小例子跑通你才能真正理解它们的边界在哪里。遇到复杂业务场景时先问自己“这个流程能不能拆成几个子步骤”而不是“我要不要上个 agent 框架”。还有一点值得所有做这件事的人记住智能体设计模式的终点不是让系统变得多聪明而是让系统在复杂环境里依然可预测、可控制、可排查问题。任何模式都只是手段稳定性才是目标。如果你钻研这个领域时遇到“无论如何都调不对”的情况多半不是模型的问题而是你的状态设计、工具边界或者评估标准出了问题——这时候把层级往回调一层事情往往就通了。本文还有配套的精品资源点击获取