别一上来就造 Agent。真正在生产的团队,几乎都是从最简单的模式开始,按需一步步增加自主性。 这篇科普把业界沉淀的 Agent 设计模式按「自主性光谱」一次讲清——每个模式是什么、什么时候用、真实场景长什么样。
「Agent」不是一道二选一的选择题。Andrew Ng 说得最清楚:「与其纠结某个系统到底算不算 Agent,不如把系统看成在『类 Agent 程度』上有所不同。」
Anthropic 在《Building Effective Agents》里给出了一对最实用的区分,几乎所有讨论都建立在它上面:
LLM 和工具被编排在预先写死的代码路径里。流程固定,LLM 只在每一步内部做生成,不能决定下一步。
例子 · 固定 RAG 链:用户提问 → 程序固定「先检索知识库 → 再拼提示词 → 最后生成」,三步顺序写死,模型说了不算。还有「营销文案 → 翻译成多语言」的提示词链,也是典型的 workflow。
特点:可预测、易审计、低延迟,适合任务边界清晰、步骤确定的场景。
LLM 动态地决定自己的执行过程——选什么工具、调几次、何时停下,都交给模型判断。
例子 · 客服 Agent:用户说「我想退货」——没有固定脚本,Agent 自己决定:先调工具查订单 → 再核对退货政策 → 判断是否在窗口内 → 才执行退款。每一步用什么工具、要不要继续,都是模型现场决策的。
特点:灵活、能处理开放式任务,但代价是更高的成本、延迟,以及错误可能叠加。
Anthropic 与几十个团队合作后发现:最成功的实现几乎不用复杂框架,而是用简单、可组合的模式。Agent 系统经常用更高的延迟和成本换来更好的任务表现——只在值得时才做这笔交易。
下面这张「自主性光谱」是全文的地图:横轴是从「纯代码控制」到「LLM 完全自主」,每一档都有对应的成熟模式。读完每个模式,你就知道自己的场景应该停在哪一档。
一句话:LLM 是模型,Agent 是系统。区别不在聪明程度,而在于有没有「行动闭环」——LLM 只会生成文本,Agent 会完成任务。
单次输入 → 输出文本。不调工具、不查数据、没有记忆、不能行动——它只是在「生成最像样的回答」。
例子:问 GPT「我的订单到哪了」,它只能基于训练数据猜一个答案;它既不知道你的真实订单,也查不了物流系统。把订单号和物流 API 塞进提示词,它也只能"读"——不能"查"。
LLM + 工具 + 记忆,在一个循环里自主行动:查库、调 API、做动作,拿到结果再决定下一步,直到任务完成。
例子:同一个问题,Agent 会调用 lookup_order() 工具查你的真实订单,调用 track_order() 拿实时物流状态,再基于真实数据回答你——它不是在猜,是在「做事」。
Agent 不是「更聪明的 LLM」,而是「给 LLM 接上规划、记忆、工具,再套一个循环」。Lilian Weng(OpenAI 研究科学家)在 2023 年的经典博客《LLM Powered Autonomous Agents》里给出了这个框架——LLM 是核心大脑,外加三件套:
驱动推理和决策的模型。不必每个任务都用最强模型——先全部用最强模型跑出基线,再逐个换成小模型验证是否达标。简单检索用小模型,审批退款用大模型。
把复杂任务拆成可执行的子目标并排好顺序(任务分解),走不通就反思调整。代表技术:ReAct(推理 + 行动交替)、HuggingGPT 的流水线式拆解。本文 §6 编排-工人的「动态拆解」就是它的一种实现。
短期记忆 = 上下文窗口内的对话历史;长期记忆 = 存到外部存储(向量库、数据库),跨会话保留用户偏好与历史决策,需要时检索注入。记忆的关键不是「存」,而是写什么、读什么、何时忘。
Agent 获取信息、采取行动的通道。三类:Data 工具(查库、读文档、搜网页)、Action 工具(发邮件、改记录)、Orchestration 工具(把别的 Agent 包装成工具)。
Lilian Weng 的框架是学术原版;上生产还要补两样。一是 Instructions 指令:好的指令来自真实运营文档,要求拆解步骤、明确每个动作、预写边缘分支——没有它 Agent 的行为不可控(OpenAI 官方 Agent 指南的第一条)。二是 Guardrails 护栏:相关性分类、安全分类、PII 过滤、内容审核、工具风险分级。没有护栏的 Agent,不能上生产。
Anthropic 的建议:人机交互界面(HCI)值得多少投入,Agent 与工具之间的接口(ACI)就值得多少投入。工具描述要含示例、边界、参数说明;能用绝对路径就不要相对路径(他们做 SWE-bench 时发现模型用相对路径总出错,改成强制绝对路径后零失误)。
把任务拆成一串固定步骤,每一步的 LLM 调用处理上一步的输出。你可以在中间步骤加程序化检查(图中的「闸门」),流程不对就立即停止。
把每个 LLM 调用变成一件更小的任务,用延迟换准确率。每一步的错误不会滚雪球,因为每一步都被检查。
一个「智能交换机」:LLM 给输入分类,然后把它送进最合适的下游通道——不同的提示词、不同规模的模型、甚至不同的微调模型或微服务。
分类是关键能力。输入覆盖的主题和难度越分散,越值得路由——但前提是分类本身能可靠地做好。
让多个 LLM 同时干活,再把结果汇总。两种形态,别搞混:
把任务拆成相互独立的子任务并行执行。每个 LLM 专注解决一个方面——专注度本身就是质量。
例子:让一个模型处理用户主流程,另一个模型同时做内容安全筛查,互不干扰。
同一个任务跑多次(不同提示词或不同模型),拿多样化的结果比较、聚合,提高置信度。
例子:多路审查同一段代码找漏洞;多个提示词评估内容是否违规,投票表决。
收益只有两个:降延迟(同时跑)和提质量(专注 + 多视角)。复杂任务交给单个 LLM 一次处理,效果通常不如拆开让多个 LLM 各管一摊。
一个生成器 + 一个评估器,循环直到评估通过。和「反思 Reflection」是同一族——LLM 自己当评委,按清晰的标准反复打磨产出。
适用前提很苛刻:评估标准必须清晰可写,并且迭代真的能带来可衡量的改进。评估标准含糊,这个循环就会原地打转甚至越改越糟。
一个中央 LLM 动态拆解任务、把子任务派给工人 LLM、再汇总结果。和并行化的区别:子任务不是预先定义好的,而是编排者针对具体输入现场决定的。这也是 Andrew Ng 四大模式里 Planning 规划 的一种实现——planner 就是「任务分解器」,把复杂目标拆成可执行的子目标。
适合无法预测子任务形态的场景——没人能提前写死要改哪些文件、要搜哪些来源,只能让编排者临场判断。
人们平时说「AI Agent」时,指的通常就是它:一个 LLM + 一堆工具,在一个循环里自主决定下一步做什么,直到任务完成。
本质极其简单——一个 while 循环:把 LLM 的输出喂回去,让它看到环境反馈(工具返回结果、代码执行输出),再决定下一步。退出条件通常是:调用了最终输出工具、模型直接返回了答案、或者达到最大轮数。
为没有固定工作流的任务而生:步骤数量无法预估、路径无法硬编码。每步必须拿到环境的「ground truth」(工具结果、代码执行输出)来校准自己的进展。
重复无效调用:模型反复调同一个工具拿同样的结果(查询订单号无效→再查→还无效)。Databricks 的建议:设置迭代上限和超时;工具返回错误时,先反思是参数错了还是该问用户。
工具臃肿:工具超过约 10~15 个且高度相似时,模型开始选错工具。OpenAI 的实战经验:先用清晰的命名、参数和描述优化工具本身,优化不动再考虑拆成多 Agent。
多个各有专长的 Agent 分工协作。按「谁说了算」,从中心化到去中心化主要有两种,加上第三种自定义:
一个中央「经理」LLM 通过工具调用协调一群专业 Agent。经理唯一直接面对用户,把任务分派给合适的专家,再合成结果。
别名:Supervisor / Orchestrator
Agent 互为同级,通过handoff(交接)把执行权直接转给另一个 Agent,连同对话状态一起转移。没有中央控制。
别名:Network / Handoff
除此之外:Custom 自定义拓扑由你定义谁和谁通信、控制流怎么走,最适合规则复杂的业务流,也最可控。图视角下,多 Agent 系统就是一张图(Agent 是节点,经理模式的边是工具调用、去中心化的边是交接)——声明式框架(如 LangGraph)要求显式画图,代码优先框架(如 Agents SDK)用编程结构动态表达。
把系统的自主性推向极限,用来探索结果难以预测的开放式任务。代价同样拉到极限:更高成本与延迟、更难调试、还有 Agent 互相踢皮球的死循环风险。
「这些子任务真的需要独立的 Agent 吗?」MongoDB 和 OpenAI 的建议一致:先最大化单个 Agent 的能力——工具加够、提示词写清楚。多 Agent 只在指令复杂到单 Agent 跟不住、或工具重复度搞不定时才引入。预测不了结果的任务才值得多 Agent,业务上预测不了结果的场景本来就少。
下面五件事不挑模式——不管你是提示词链还是多 Agent,它们都必须被考虑,区别只在投入程度。
模型的知识有截止日期,也记不住你的业务数据。两条路解决的是不同问题:RAG 解决「知识够不够新、够不够专」,长期记忆解决「记不记得你是谁、之前聊了什么」。
RAG(检索增强生成)把外部知识在推理时注入上下文,分两条流水线:离线入库(抓取 → 清洗 → 分块 → 向量化 → 索引)和在线检索(向量检索 + 关键词检索,再用 Reciprocal Rank Fusion 融合结果)。分块策略是经典坑:块太小丢上下文,块太大稀释语义。
长期记忆让 Agent 跨会话保留用户偏好与历史决策,又分两层:
当前会话内的对话历史、任务进行到哪一步。直接放进 prompt 窗口,超长时用滑动窗口或摘要压缩控制长度。
跨会话保留:用户偏好、历史决策、项目背景。存到外部存储(向量库、数据库),需要时检索注入,而不是把全部历史塞进上下文。
有选择地沉淀重要信息(用户明确的偏好、已完成的关键决策),定期压缩去重;过时或无关的记忆要及时清理。乱记十万条,和没有记忆一样糟糕——检索时噪声会把 Agent 带偏。
OpenAI 的指南把护栏分成两类:LLM 型(相关性分类器、安全分类器)和规则型(正则、黑名单、长度限制),再叠加内容审核 API。推荐启发式:先覆盖数据隐私与内容安全,再根据真实线上翻车案例不断加层。
纯自动化不可行或不可取时,让人插进来。两种经典触发时机(OpenAI):超过失败阈值(重试多次仍不懂用户意图 → 升级人工)和高风险动作。给工具按「只读 / 可写 / 可逆 / 财务影响」评级:低风险自动执行,极高风险(取消订单、大额退款、付款)升级人工——退款的 API 和查天气的 API,不该拥有同样的信任级别。另外,自然语言天生有歧义,让人参与澄清对话对任何工作流都有价值,即使不是必须。
| 动作 | 做什么 | 为什么 |
|---|---|---|
| 先建评估 | 自动化评估(含 LLM-as-a-judge)建基线,再用专家与用户的人工反馈校准指标 | 指标与人的判断对不上,自动化评估就是自嗨 |
| 可观测性 | 每个请求、Agent 计划、工具调用都留痕(如 MLflow Tracing) | 多 Agent 调试全靠日志——这也是生产偏好简单模式的现实理由 |
| 版本固定 | 固定模型版本 + 频繁回归测试;提示词纳入版本管理可回滚 | 供应商后台换模型,行为就漂了 |
| 失败预案 | 每个 LLM/工具调用都有重试与降级逻辑(如失败退到更简单链) | 超时、格式错乱、空结果都会让工作流断掉 |
模式不是单选题。Databricks 的观察:真实系统几乎都是组合——一条基本确定的链里,某个步骤让 LLM 动态调 API;单 Agent 里嵌入人在回路和评估-优化循环让输出更可靠。设计原则始终是:只加被证据证明需要的复杂度。
还有两个正在快速标准化的协议值得知道(在《Agentic Design Patterns》里各有专章):MCP(Model Context Protocol)统一了 Agent 与外部工具的接入方式——工具一次实现,处处可用;A2A(Agent-to-Agent)统一了 Agent 之间的通信格式。它们是让模式之间「插头」标准化,不是模式本身,也不该替代「选哪种模式」这个核心决策。
把四个主流参考源(Databricks、MongoDB、Anthropic、OpenAI)的结论压成一张决策表。记住它们的共同建议:从最简单能工作的架构开始,有证据再加复杂度。
| 模式 | 什么时候用 | 优势 | 代价 |
|---|---|---|---|
| 提示词链 / 确定性链 | 任务步骤固定可拆;流程要求可审计 | 最高可预测性 · 低延迟 · 易测试 | 死板 · 新需求要改代码 |
| 路由 | 输入类别分明,想按难度省钱 | 各取所长 · 成本优化 | 分类错了全错 |
| 并行化 | 子任务独立;要多视角投票 | 降延迟 · 提质量 | 聚合逻辑要写 · token 开销 |
| 评估-优化 | 评估标准清晰,迭代有收益 | 质量显著提升 | 标准含糊会原地打转 |
| 编排-工人 | 子任务形态取决于输入(编码、跨源检索) | 临场拆解 · 高度灵活 | 调试变难 · 延迟增加 |
| 单 Agent | 开放式任务 · 中等复杂度 · 单一领域 | 动态适应 · 企业级甜点位 | 成本高 · 可能死循环 · 错误叠加 |
| 多 Agent | 跨域专家 · 独立上下文 · 探索性任务 | 高度模块化 · 可扩展 | 难编排 · 难追踪 · 互相踢皮球 |
所有参考来源的建议一致:从简单开始(需要确定链就先用链,别为想象中的复杂度买单)→ 逐步加复杂度(需要动态决策升单 Agent,领域明显分离、工具装不下再升多 Agent)→ 能组合就组合(确定链 + 某一步动态调 API,常常比整体升级更划算)。Anthropic 在此基础上还有三条铁律:
最成功的系统没用复杂框架,而是用简单可组合的模式。直接调 LLM API 就能实现大多数模式——先用基础组件,别急着叠抽象层。
显式展示 Agent 的规划步骤。用户和开发者能看到「它为什么这么做」,信任才有基础。
Agent 与工具的接口值得投入和 HCI 同等的精力:示例、边界、防错设计(poka-yoke)。他们在 SWE-bench 上花在优化工具上的时间比整体提示词还多。
造 Agent 不是军备竞赛。新的模式每周都在冒出来,但追逐最新潮流不是好策略。聚焦你的需求:选最简架构 → 认真评估 → 有证据再加件。从提示词链走到多 Agent 之间隔着好几级台阶,每一级都有人正在那个位置把产品做得很好。