8 种 AI 应用设计模式全景图：真正卡住你的，从来不是模型

开场：一个我见过太多次的场景

某个团队要做「智能报告生成」。

第一版，用当时最强的模型，Prompt 写了两千多字，demo 效果惊艳，全场鼓掌。 第二版要接企业知识库，加了检索，效果开始飘，有时候准，有时候一本正经地胡说。 第三版要接业务系统自动取数，Agent 开始乱调接口，偶尔还会把不该写回的字段写回去。 第四版加了个「审核 Agent」做质量把关，结果两个 Agent 互相踢皮球，一轮任务跑四十多分钟，Token 账单翻了六倍。

三个月后复盘，结论是：模型能力还不够，等下一代模型出来再说。

我的判断正好相反：这不是模型问题，是模式问题。

四版迭代里，团队从头到尾没有做过一次真正的“选型”：该不该让 Agent 自主规划？要不要拆子 Agent？反思环节值不值得加？每一步都是拍脑袋加上去的，每加一步就多一份不确定性、多一份成本。

模型是发动机，设计模式是传动系。发动机再强，齿轮咬错了，车还是跑不快。你没选对模式，换一百个模型都救不回来。 一、先说一句可能得罪人的话：官方文档才是最好的老师

进入正题前，我先把话说清楚，免得你带着错误的期待往下读。

这一篇 不贴大段代码，不逐个参数讲解，不手把手教你把某个框架跑起来。这不是偷懒，是三个很实在的理由： 细节会过期，模式不会。 框架的版本号三个月一变，API 半年一改，你今天背下来的调用姿势，明年就是负债。但「什么时候该让 Agent 自主规划、什么时候不该」这个问题的答案，五年后依然成立。 视频教程是别人嚼过的。 你学到的是他的理解、他的版本、他的场景。更麻烦的是，你真正会踩的坑，往往不会出现在他的视频里，因为他的 demo 是照着能跑通的那条路径录的。 官方文档会告诉你它自己承认的边界。 一手定义、接口契约，以及“这个能力在什么情况下不该用”。第三件事最值钱，而没有哪个视频会花十分钟讲“别用我”。 ### 一句话方法论 别盯着某一个视频教程一个一个刷，去仔细研读官方文档。这是最快让你真正掌握一门技术的方式，没有之一。因为它是唯一不会为了“讲得顺”而替你省略边界的资料。 二、先把地基讲清楚

谈设计模式之前，得先有地方放它们。在我之前的文章中：《AI 落地的四层架构：真正卡住你的，从来不是模型》中提到： 基于团队内部落地实践的思考，我们把内部 AI 分成四层：硬件基础层、AI Infra 层、Harness 服务层与应用层。决定成败的不是分层，而是层间三条契约——上层提需求、下层供能力，任一层可整体替换而上层代码不用改。实践中最深的教训是顺序：先把模型接入收敛到网关，再选 Harness 立起权限、沙箱与检查点，最后才谈 Skill 与专家沉淀。顺序错了，返工成本远高于从零搭。 2.1 它真正在讲什么

很多人读这类文章，眼睛只盯着那四个方块，然后回去照着画一张一样的图，贴进 PPT，完事。但这篇的价值不在分层，在后半句。

分层是名词，谁都会画。 你随手一搜能找出二十种分层法，四层、五层、七层的都有，画出来都挺像那么回事。真正决定这套架构能不能活下来的，是层与层之间那三条契约。它是动词，它决定了你将来能不能换。 2.2 三条契约，各自管什么

| 契约 | 管的是什么 | 破了会怎样 | | ---------------------------- | -------------------------------------------------------- | ------------------------------------------------ | | 上层提需求，不提实现 | 接口按「我要什么」定义，而不是按「谁提供、怎么提供」定义 | 上层代码里出现下层产品名的那一刻，契约就已经破了 | | 下层供能力，且能力可度量 | 说清延迟、成功率、成本上限、失败时如何降级 | 说不清的「能力」，本质上只是个 demo | | 替换不穿透 | 前两条的结果，也是唯一可验收的判据 | 换一层就要改一片，架构退化成依赖 |

判断契约好不好，标准只有一条，而且特别残酷： 可替换性测试：把某一层整个换掉（换模型、换框架、换向量库、换硬件），上层业务代码要不要动？ 要动 → 那条契约是假的。 你画的不是分层，是依赖。 2.3 最贵的一条教训：顺序比选择更贵

原文里我最认同的一句是「顺序错了，返工成本远高于从零搭」。为什么？

因为选择错了，你损失的只是那一层；顺序错了，你前面所有的工作都建立在错误的假设上。 先做了一堆 Skill，再回头补 Harness：你会发现每个 Skill 里都散落着各自的权限判断、各自的沙箱逻辑、各自的错误处理，全得重写； 先做了 Harness 再收敛网关：你会发现权限体系是按某个模型的调用姿势设计的，换模型就得重来。

正确的顺序是一条单向路，不能跳步：

越靠近业务的东西越晚做，因为它最容易被底层的变动掀翻。 三、重点关注的应用层：8 种 AI 应用设计模式

四层架构回答的是「房子怎么盖」，设计模式回答的是「房间里怎么摆」。到了 L4 这一层，你每天真正要做的决策就是：这个任务，该用哪种模式？

先回应一个直觉上的疑问：为什么叫「设计模式」？

因为它和 GoF 那 23 种设计模式是同一类东西：不是代码，是「问题 → 解法」的可复用配对，外加这个解法的代价。单例模式的价值不在那三行代码，在于它明确告诉了你「全局唯一访问点」这个意图，和「隐藏依赖、难测试」这个代价。AI 应用设计模式也一样，每一种模式的真正价值，在于它诚实地标出了自己要收你多少钱。

按功能维度，这 8 种模式分成三大类（这个是个人在思考实践中的常用的应用模式）： 3.1 八个模式的一句话

| # | 模式 | 解决什么问题 | 你付出的代价 | | --- | -------------------------------- | -------------------------------------------------- | -------------------------------- | | 1 | Tool-Augmented 工具增强 | 让模型能碰到现实系统：调 API、查库、写回数据 | 权限边界、参数校验、越权风险 | | 2 | ReAct 推理行动协同 | 单次答不上来的问题，靠「想—做—看」循环推进 | Token 消耗高、易死循环 | | 3 | RAG Agent 检索增强 | 引入私有知识、压住幻觉；自主决定检索时机与查询改写 | 检索质量差时，幻觉反而被放大 | | 4 | Memory-Augmented 记忆增强 | 跨会话记住偏好与历史，做个性化 | 用户隔离、过期清理、存储成本 | | 5 | Plan-and-Execute 规划执行 | 复杂长任务的拆解与分步落地 | 首步规划错则全盘崩，容错难做 | | 6 | Reflection 反思改进 | 生成后自我纠错，拉高一次通过率 | 慢、贵，且反思本身可能出错 | | 7 | Multi-Agent 多智能体协作 | 专业能力分工（写码 / 测试 / 评审） | 协调成本极高、传话变形、调试噩梦 | | 8 | Autonomous Loop 自主循环 | 给目标就一直干到完成，无需人干预 | 预算失控风险，必须限次数限额度 | 3.2 三类模式，三种思考方式 能力增强类（1 / 3 / 4）：解决的是模型看不见、记不住、够不着。共同代价是外挂本身要治理。权限怎么收、记忆怎么隔离、索引怎么更新，这些活儿一点都不比模型少。 推理与工作流类（2 / 5 / 6 / 8）：解决的是一次对话干不完。共同代价是时间和钱。它们都在用额外的推理轮次换更好的结果，而轮次是最贵的东西。 组织协作类（7）：解决的是一个人干不全。共同代价是协调成本。注意，Multi-Agent 不是多几个 Agent，而是多一整套协调成本：消息格式、责任边界、死循环检测、失败归因，全要你自己写。 四、不是所有模式都该上生产：落地三梯队

这是我最想强调的一节。

上面那张全景图是一份能力清单，不是一份采购清单。把八个模式全用上，恰恰是新手最容易犯的错。你以为你在搭系统，其实你在搭一个不可控的成本黑洞。

按企业真实工程里的使用频率 × 落地成熟度，这八种模式是分梯队的。有的是水电煤，有的是奢侈品，有的目前还是期货。 4.1 三梯队速览

| 梯队 | 包含模式 | 落地现状 | 一句话判断 | | ----------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | 第一梯队 · 水电煤 | ① Tool-Augmented ③ RAG Agent ④ Memory-Augmented | 不用选型，绕不开。不接外部系统的 Agent 只是聊天机器人；不接私有数据的 Agent 迟早胡说 | 把这三个做扎实、做稳定，就已经跑赢八成竞品 | | 第二梯队 · 进阶利器 | ② ReAct ⑤ Plan-and-Execute ⑥ Reflection | 复杂场景高频使用，但必须严格管控。ReAct 常被框架封装；规划执行多用于长任务；反思在代码生成里效果好，在客服里太慢 | 稳定性和成本，永远压倒灵活性 | | 第三梯队 · 高端局 | ⑦ Multi-Agent ⑧ Autonomous Loop | 概念火爆，落地是踩坑重灾区。多 Agent 沟通极耗 Token 且易死锁；自主循环不加预算限制，一晚能烧掉几万块 API 费 | 面试要能说透，落地先别急着上 | 4.2 企业工程实践里的三条潜规则 架构越简单越好。 一句 Prompt 能解决，绝不用 ReAct；单 Agent 能解决，绝不用 Multi-Agent。这也符合架构设计的kiss原则。 重 Workflow，轻完全自主。 把规划与工具调用用流程图固定死（Agentic Workflow），用确定性换稳定性和低延迟，这是现在企业里真正的流行做法。 延迟和成本是两把刀。 ReAct / Reflection / Loop 都会显著拉长响应时间，C 端让用户等 10 秒就是灾难。 4.3 一个反直觉但正确的结论

如果你是去做业务落地，把第一梯队做扎实、做稳定，就已经能打败八成竞品了。剩下五个模式，是你在第一梯队跑顺、且业务确实需要时，才该考虑的东西。

这也是我一直在讲的那句话的另一种说法：别为 AI 而 AI。 能用确定性的工程手段解决的，就不要交给概率性的推理；能用一个模式解决的，不要堆三个。传统软件工程里那些朴素的原则单一职责、最小惊讶、可观测性。在 AI 时代一条都没过期，反而更值钱了。 五、模式不是互斥的，组合才是常态（但别堆）

最后一个常被问到的问题：这些模式是不是只能选一个？

不是。它们可组合，而且真实系统几乎都是组合体。一个成熟的 Multi-Agent 系统里，子 Agent 用 ReAct 去调工具，用 RAG 查企业知识库，用 Memory 记住用户习惯，外层再套一层 Reflection 做质检，最后由 Supervisor 收口。

但组合有一条铁律：每加一个模式，都要能回答它替我省下了什么。答不上来，就是堆。 5.1 选型时问自己的四个问题

这张图的终点只有一个：保持简单。所有模式都是被问题逼出来的，不是被趋势推出来的。 5.2 四层架构与设计模式的咬合点

把两件事串起来看，关系很清楚： L1 / L2 决定你能不能便宜地跑。 成本结构不对，模式再优雅也跑不起量。 L3 Harness 决定你敢不敢跑。 模式组合能上生产的前提如果没有权限、沙箱、检查点，Reflection 和 Loop 就是风险放大器。 L4 决定你跑得值不值。 八个模式是这一层的武器库，选错了就是开篇那个团队的下场。 四层架构给的是「能不能替换」，设计模式给的是「该不该这么干」。前者管演进，后者管当下。 总结 开篇那个团队的失败，不是模型问题，是模式问题； 想真正掌握一门技术，别刷视频，去研读官方文档。它最慢，也最快； 四层架构里，契约比分层贵，顺序比选择贵，可替换性是唯一判据； 八个设计模式是能力清单不是采购清单，按三梯队上，先做实水电煤； 组合是常态，但每加一层都要说清它替我省了什么，答不上来就是堆。

回到开头。模型会越来越强，这是确定的；但强模型不会自动帮你回答「该不该让 Agent 自主规划」这个问题。别把模型当壁垒，架构才是护城河。