Agent 设计模式教学文案

课程地图

Agent 不是一段更长的 prompt，而是一套会观察、会调用知识、会拆解任务、会使用工具、会复盘、会协作的认知系统。学习设计模式的目的，是把“模型的聪明”放进“系统的秩序”里。

第一层：能力视角 从感知、记忆、推理、行动、反思、协作六个方向理解 Agent 能做什么。

第二层：模式视角 把常见能力沉淀为可复用模式，例如 RAG、ReAct、规划-执行、辩论、路由。

第三层：系统视角 根据任务风险、工具权限、成本预算和验证方式，组合出可交付架构。

读法建议：不要急着背名称。每个模式都问四个问题：它解决什么失败场景？它需要什么输入？它如何验证？它会引入什么新风险？

为什么 Agent 需要设计模式

传统软件大多处理确定性逻辑：输入明确、分支可控、函数返回稳定。Agent 面对的是开放环境：用户意图含混、资料会过期、工具会失败、模型输出有概率性。Prompt 可以提供指令，但不能单独承担架构责任。

工程问题	没有模式时的典型失败	设计模式提供的结构
信息太多	上下文一股脑塞给模型，答案抓不住重点。	注意力聚焦、分层记忆、检索重排。
知识不可靠	模型凭印象回答，引用不存在或过时。	RAG、来源溯源、事实校验。
任务太长	一开始计划漂亮，执行中偏离目标。	规划-执行、状态跟踪、动态重规划。
行动有风险	Agent 误发邮件、误删数据、误操作系统。	工具分级、权限控制、人工确认。
结果难验证	输出看起来流畅，但事实、代码或计算不对。	自我修正、测试、审查 Agent、辩论。

Agent 认知循环

点击图中的节点，查看每个环节的职责、输入和常见设计问题。

感知

Agent 首先要看见问题：用户真正想要什么、上下文里哪些信息关键、哪些信息缺失、是否需要主动搜索或提问。

设计问题：要不要先问用户？要不要调用外部工具？哪些信息会改变下一步决策？

21 个设计模式

下面的卡片按六大能力层组织。点击任意卡片，可以打开详细讲解和组合建议。

组合方案

单个模式像零件，真正的 Agent 系统来自组合。下面是四种常见应用的推荐架构。

研究助理：从问题到可信报告

主动感知
澄清研究问题 RAG
检索资料思维树
展开角度自我修正
核对引用反思记忆
沉淀偏好

适合论文综述、竞品分析、行业报告。关键不是“搜得多”，而是让每个结论都能回到来源，并区分事实、推断和建议。

编程 Agent：从需求到验证

注意力聚焦
锁定行为分层记忆
读取约定规划-执行
拆分步骤 ReAct
读写运行自我修正
根据测试调整

适合修 bug、加功能、迁移框架。强约束是：先理解现有系统，再最小修改，最后用命令或截图验证。

客服 Agent：从用户问题到可控处理

路由
识别类型情节记忆
查历史工单 RAG
查政策工具编排
查订单/建单人工确认
处理高风险

适合售后、退款、投诉处理。核心是权限和升级机制：低风险自动化，高风险交给人。

运维 Agent：从告警到定位

主动感知
拉日志指标思维图
构建依赖 ReAct
查询系统辩论
排除误判反思记忆
记录故障模式

适合线上故障定位。重点是可观测性和行动边界：诊断可以自动，修复动作要按风险审批。

架构搭配器

选择你的目标场景，下面会生成一份简化 Agent 架构草案。它不是最终答案，而是启动设计讨论的脚手架。

企业知识库问答长期个人助理自动化办公流程多 Agent 专家团队

小测验

用几个短问题检查你是否抓住了模式背后的工程含义。

1. 用户问公司制度，模型不应该凭印象回答，最应该先采用哪个模式？

2. Agent 需要一边查日志、一边根据结果决定下一步，最贴近哪个模式？

3. 企业助手需要把 HR、财务、工程问题分给不同专家，核心模式是什么？

最后的心法

Agent 设计模式的价值，不在于给每个能力起一个漂亮名字，而在于让你形成架构直觉：不确定性不可消除，但可以被约束、被观察、被验证、被复盘。

真正可靠的 Agent，不是“更会说话的模型”，而是“会在结构中工作的模型”。

把不确定的智能，设计成可靠的工作流