一、厘清两个概念：LLM vs Agent
很多人把"用 ChatGPT"当成"用了 Agent"，其实两者差了一个"身体"。要理解 Agent 设计模式，先要分清这两个词。
LLM（大语言模型）是一个文本进、文本出的模型——你给它一段 Prompt，它返回一段回答，然后结束。它没有记忆（上下文窗口之外一概不记得）、不能调用外部系统、不会规划多步骤任务。业内常打的比方是：一个非常聪明的、装在罐子里的"大脑"——会推理，但没有手。
AI Agent（智能体）则是"把 LLM 包上一层执行能力"的系统：它用一个目标驱动自己，自主规划步骤、调用工具、观察结果、出错重试，直到任务完成。LLM 是大脑，Agent 是拥有身体（工具）、记事本（记忆）和工作流程的完整个体。
一句话记忆：LLM 只负责说，Agent 负责做——所有现代 Agent 都用 LLM 当大脑，但并非所有 LLM 调用都是 Agent。
二、Workflow vs Agent：控制权在谁手里
Anthropic 在 2024 年 12 月发表的《Building Effective Agents》（构建有效的 Agent）是目前引用率最高的权威框架。它给出了一个极其清晰的判据：
“Workflows are systems where LLMs and tools are orchestrated throughpredefined code paths. Agents, on the other hand, are systems where LLMsdynamically direct their own processesand tool usage, maintaining control over how they accomplish tasks.”
—— Anthropic, “Building Effective Agents” (Dec 2024)
翻译成人话：关键区别在于"流程的控制权"——是写在代码里（Workflow），还是由模型在运行时自己决定（Agent）。前者每一步做什么都是程序员预先编排好的、可预测；后者模型自己决定下一步做什么、调什么工具，灵活但更难预测。
Anthropic 的忠告：能找到最简单的解决方案就先用最简单的，只在确有收益时增加复杂度——有时这意味着根本不要构建 Agent 系统。
三、Agent 的核心组件：大脑、规划、记忆、工具
Anthropic 把 Agent 的底座称为增强型 LLM（Augmented LLM）：一个具备检索、工具、记忆三项增强的 LLM——“我们的模型能主动使用这些能力：生成自己的搜索查询、选择合适的工具、决定保留哪些信息” 。Andrew Ng 在 DeepLearning.AI《Agentic AI》课程中则提炼了四大设计模式：Reflection 反思、Tool Use 工具使用、Planning 规划、Multi-agent Collaboration 多智能体协作。两者合起来，正好对应下面的组件图。
图 3 Agent 四大核心组件（Anthropic 增强型 LLM × Andrew Ng 四大模式）
3.1 规划 Planning
规划就是把"目标"翻译成"步骤清单"。Andrew Ng 的定义是：用 LLM 决定如何把一个任务分解成子任务去执行[2]。规划策略有三种基本形态 [6]：
- 顺序规划：按步骤依次执行，每步依赖上一步的结果；
- 并行规划：识别出可以同时进行的步骤，提高效率；
- 动态规划：根据执行中得到的反馈随时调整后续计划。
注意：规划能力不一定是 Agent 的"独立模块"——在很多实现里（如 ReAct 模式），规划就发生在 LLM 的推理过程中：想一步、做一步、看结果、再想一步 [1][6]。而 Orchestrator-Workers 模式则是把规划显式交给一个"编排者"LLM 完成。
3.2 记忆 Memory：短期与长期
记忆解决的是"失忆"问题。生产级 Agent 通常把记忆分成两层以上：
⚠️记忆的反面：LangChain 等框架都警告过长上下文"可能装不进上下文窗口"，即便装得下，模型也容易"被旧内容带偏"。所以好的做法是：用完即总结压缩，只把该记住的写进长期记忆，而不是把整段历史永久塞给模型。
3.3 工具 Tools
工具是 Agent 的"手"。没有工具，LLM 只是"会说话的聊天机器人"；有了工具，Agent 才能查资料、算数据、改文件、发请求。Anthropic 特别强调：在 SWE-bench 编码 Agent 的实战中，打磨工具（输入/输出 schema、文档）的时间超过了打磨提示词的时间，工具文档应当写得像给开发者看的 docstring 一样认真（Anthropic 称之为 ACI——Agent-Computer Interface）。
四、生产级还差什么：指令与护栏
上面的组件能跑通 Demo，但上生产还差两块"保险"：Instructions 指令与Guardrails 护栏。
4.1 Instructions 指令
生产级 Agent 不能只靠一句"帮我做X"。你需要一份明确的系统指令：定义 Agent 的角色、能力边界、回答风格、必须遵守的流程、以及"遇到什么情况必须停下询问人类"。业界实践里，指令往往和工具说明、允许/禁止动作清单一起构成 Agent 的"用户手册" 。Anthropic 也建议把指令与工具文档放在同等重要的位置——模型只有看到清晰指令才可能稳定地按预期行事。
4.2 Guardrails 护栏：规则 / 安全 / 权限 / 人工审核
护栏不是可选项——“Agent 能做真实动作，所以安全比风格更重要”。综合多份生产实践指南，护栏可分为四层：
图 4 生产级 Guardrails 四层模型
其中"人工审核"（Human-in-the-Loop, HITL）尤为重要。业界共识是：在不可逆/高影响动作前（发邮件、退款、删数据、改配置、对外发布），必须插入人工审批检查点。风险与干预程度匹配：低风险任务自主运行，高风险动作必须人点头。
💡安全提醒：注入攻击的"致命三件套"
安全研究者 Simon Willison 提出的Lethal Trifecta（致命三件套）：当 Agent 同时具备 ① 能访问私有数据、② 会处理不可信内容（如客户邮件）、③ 能对外通信（发邮件/发 HTTP 请求）时，系统在结构上就可被攻击。防御核心是：最小权限 + 输入扫描 + 输出过滤 + 关键动作人工审核
五、模式一：提示词链 Prompt Chaining
是什么：把一个任务拆成固定顺序的多个 LLM 调用，上一步的输出作为下一步的输入；每一步之间可以插入程序化检查点（gate），确保流程没跑偏 [1]。
图 5 提示词链：串行步骤 + 检查点
🎯适用场景：任务能被干净地拆成固定子任务，且愿意"用延迟换准确率"。Anthropic 的经典例子：营销文案先写出来再翻译；先写大纲、校验、再扩写成全文 [1]。
⚠️存在的问题：
- 每一步都是一次 LLM 调用，延迟累加，整个链变慢；
- 错误会沿链传播叠加——上一步的小错会被下一步放大；
- 链条是"死"的：步骤固定，无法根据输入临时增删步骤。
✅解决方案：
- 每一步之间加gate 程序化检查点，快速失败（fail fast），别让错误滚下去 [1][12]；
- 每一步输出强制走结构化 schema（如 JSON），保证下游能稳定消费 [12]；
- 步骤不要过多——链越长错误概率越高，能并行的子任务请考虑模式三。
六、模式二：路由 Routing
是什么：先对输入做分类，再把它导向专门的、更聚焦的下游处理（专门的提示词或专门的模型）——实现"各取所长、分离关注点" [1]。
图 6 路由：先分类、再分发（按类别或按难度）
🎯适用场景：输入类别分明且互斥、各类别需要差异化处理。典型：客服三分类（咨询/退款/技术支持）；成本优化——简单查询走小模型、复杂查询走大模型
⚠️存在的问题：
- 分类错了全错——一旦路由判错，整个后续处理都建立在错误前提上，且错误会向下游级联（misclassification cascade）
- 路由这一步本身也消耗一次 LLM 调用 / 延迟
- 类别边界模糊时，强分类反而降低体验
✅解决方案：
- 能用传统分类器/低延迟小模型就先用，别让路由成为瓶颈
- 对高成本动作先验证路由结果再执行（validate the route before acting）
- 设置"兜底分支"：低置信度时走通用处理或转人工，而不是硬分
七、模式三：并行化 Parallelization
是什么：多个 LLM 调用同时工作，最后用代码汇总结果。Anthropic 明确给出两种变体 [1]：
- Sectioning 切分：把任务拆成互相独立的子任务并行跑，最后拼起来；
- Voting 投票：同一任务跑多遍，取多样输出做共识/择优。
图 7 并行化的两种变体
🎯适用场景：① 子任务真正独立、可以并行提速（切分）；② 需要多视角/多尝试提升置信度，比如多个提示词从不同角度审代码、内容安全复查（切分+投票可混用）[1]。
⚠️存在的问题：
- Token 开销成倍上涨——N 路并行就是 N 倍 token，没设成本上限会失控
- 聚合逻辑要自己写——拼结果、消矛盾、去重都不简单
- 投票可能得到"多数低质"的共识，盲目取多数不一定更好
✅解决方案：
- 跑之前先设成本/轮数上限（cost cap），别让 token 翻倍无界
- 花心思写好聚合层——Anthropic 的案例里，聚合往往需要额外的 LLM 调用来消歧
- 子任务要拆到"真独立"：有依赖关系的步骤别硬拆
八、模式四：评估-优化 Evaluator-Optimizer
是什么：一个 LLM 负责生成，另一个 LLM 负责评估并给出反馈，两者循环直到质量达标或达到上限。这本质上是 Andrew Ng 四大模式里Reflection 反思的工程化实现——“Agent 检查自己的输出并找出改进方法” [1][2][3]。
图 8 评估-优化：生成器与评估器的反馈回路
🎯适用场景：评估标准清晰可度量、且迭代确实能带来收益。Anthropic 给出的判断信号有两个：① 人类给出反馈时，LLM 输出能被明显改善；② LLM 有能力提供这样的反馈。经典例子：文学翻译（评估器建议更微妙的用词）、复杂检索（评估器决定是否还要继续搜）[1]。
⚠️存在的问题：
- 评估标准含糊，就会原地打转——评估器给不出可执行的反馈，循环空转；
- 迭代次数无上限 =成本黑洞；
- 评估器可能"过拟合"反馈风格，把输出越改越怪。
✅解决方案：
- 把评估标准写成显式的评分卡/评分准则，并配真实 eval 集校准，别拍脑袋定标准 [2][12]；
- 给循环设最大迭代次数与预算（Anthropic 建议 stopping conditions）[1]；
- Andrew Ng 反复强调：用 evals（评估集）和错误分析驱动改进，而不是靠感觉反复调提示词[2]。
九、模式五：编排-工人 Orchestrator-Workers
是什么：一个中央 LLM 作为编排者，在运行时动态地把任务拆成子任务、分派给工人 LLM、再汇总结果。与并行化的关键区别：子任务不是预先定义好的，而是编排者针对具体输入"现场决定"的[1]。这也是 Andrew Ng 四大模式里 Planning 规划的一种实现——编排者就是"任务分解器" [2][3]。
图 9 编排-工人：临场拆解 + 分派 + 汇总
🎯适用场景：子任务形态取决于输入、无法提前预测的任务。Anthropic 的实例：编码 Agent 处理跨多个文件的 GitHub issue；跨来源检索与分析任务 [1]。
⚠️存在的问题：
- 子任务数不可预测 →扇出可能无界，成本/延迟都放大；
- 调试变难——每次运行的拆解方式都不一样，失败难以复现；
- 编排者可能把任务拆错或分派错，错误在工人层被"忠实执行"放大。
✅解决方案：
- 给编排者设worker 预算上限（最多拆几个子任务、最多几轮），保证扇出有界 [12]；
- 子任务交接用结构化协议（明确输入/输出 schema），不要自由文本传话 [12][13]；
- 全程记录编排者的"拆解轨迹"，便于事后定位问题。
十、模式六：自主单 Agent
是什么：人们平时说"AI Agent"时，通常指的就是它：一个 LLM + 一堆工具，在一个循环里自主决定下一步做什么，直到任务完成[1]。Anthropic 的表述：Agent 开始时接受人类指令或对话，一旦任务明确，就"独立规划并操作"，每一步从环境获取"ground truth"（工具返回、代码执行结果）来判断进度，在检查点或受阻时暂停征求人类意见，任务完成或达到停止条件（如最大迭代数）时终止 [1]。
图 10 自主单 Agent 的运行循环（感知-规划-行动-观察）
🎯适用场景：开放式任务、中等复杂度、单一领域——你无法预判需要几步，但又不需要跨领域专家协作。Anthropic 与 Google 一致认为这是"企业级甜点位"：先从一个 Agent 开始，把提示词和工具打磨好，只有在一个 Agent 明显吃力时才升级 [1][10]。
⚠️存在的问题：
- 成本高——多步自主循环 = 多次模型调用，且每多一次调用错误率都叠加 [1]；
- 可能死循环——Agent 在某个环节反复打转；
- 工具乱用、权限越界、幻觉蔓延——没有护栏的单 Agent 是危险的。
✅解决方案：
- 必须设停止条件（maxSteps / maxTokens），Anthropic 明确建议"保持控制" [1]；
- 在沙箱环境里测试工具调用，工具文档写好（ACI 原则）[1][10]；
- 关键动作前插人工检查点，遇到搞不定的场景升级给人类，而不是瞎猜 [7][11]；
- 用 evals + traces 追踪每一步，定位是"哪一步"在拖后腿 [2]。
十一、模式七：多 Agent 协作 Multi-Agent
是什么：多个各有专长的 Agent 分工协作——“就像公司雇多个员工一样”。按"谁说了算"从中心化到去中心化，主要有三种形态：
图 11 多 Agent 两种主流形态：经理模式 vs 去中心化交接
🎯适用场景：①跨领域专家协作（编码 + 设计 + 测试）；② 需要独立上下文隔离（子任务会污染主窗口上下文时，是"最有依据的多 Agent 理由"）；③探索性任务或高并行需求 [10][13]。
⚠️存在的问题（业界反复踩的坑）：
- 难编排、难追踪：失败常发生在 Agent 之间的"接缝"里，没有跨 Agent 追踪（trace ID）就无法还原现场；
- 互相踢皮球（ping-pong）：去中心化交接容易死循环或任务在多个 Agent 间来回传递；
- Token 爆炸：每次交接都要重新序列化上下文，多 Agent 通常烧掉数倍于单 Agent 的 token；
- 错误传播放大：经理一个小误读，会被工人"忠实执行"成完全错误的子任务 ；
- 上下文传递丢失：工人只看到经理转达的摘要，交接写得不清楚，工人就会自信地做错题——这是多 Agent 最主要的失败模式 ；
- 经理是单点瓶颈；并发时还可能死锁（互相等待）。
✅解决方案：
- 默认先从单 Agent起步，只在有明确、可衡量的结构性收益时才升级多 Agent；
- 交接用结构化协议（JSON Schema，不要自由文本），交接图限定为小型已验证的图，禁止任意网状连接；
- 上下文只传**增量（delta）**而非全量重灌，控制 token 成本；
- 上分布式可观测性：跨 Agent 的 trace ID、每个 Agent 的输入输出审计日志；
- 给所有交接和循环加超时与死锁检测；反模式清单：不要"按组织架构为每个角色配一个 Agent"、不要深层级、不要无界网格。
十二、怎么选？从简单开始，逐步加复杂度
三条铁律
① 从简单开始——需要确定链就用链，别为想象中的复杂度买单。Anthropic：能优化单次 LLM 调用（配检索和示例）就先用它，别急着建 Agent 系统
② 逐步加复杂度——需要动态决策再升单 Agent；领域明显分离、一个上下文装不下/工具太多时，再升多 Agent
③ 能组合就组合——确定链 + 某一步动态调 API，往往比整体升级更省。生产系统嵌套使用模式是常态，而不是例外
图 12 复杂度决策阶梯（自底向上）
一张图选模式
十三、总结速查表与参考来源
七大模式速查表
七种模式之间的关系
给读者的三句话
- 模式不是越高级越好——Anthropic 与 Google 的官方建议都是"从最简开始"，能用工作流就别上 Agent，能用单 Agent 就别上多 Agent。
- 生产与 Demo 的分水岭在"护栏"：指令、规则、权限、人工审核、停止条件、预算上限——这些才是能不能上线的关键。
- 用 evals 和 traces 说话：Andrew Ng 认为，会不会用评估集和错误分析驱动迭代，是团队能否把 Agent 调好的最大预测指标 [2]。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
