王思腾工作室· 王思腾 · 大模型工程 · 15 分钟阅读
大模型应用架构进阶：从 Prompt、工作流、RAG 到 Agent 的选型与演进
“Prompt、RAG、Agent 三选一”是个过于粗糙的说法。真实系统是一条从“全确定”到“全自主”的连续光谱，RAG 本质是给模型接知识的能力，Agent 也分固定编排和自主循环。这篇往深里聊：工作流模式、RAG 的三个深浅层级、什么时候才该让模型自主决策，以及成本、延迟和失败模式这些入门文章很少算的账。
讲大模型应用架构，最常见的说法是三种模式：直接调 Prompt、上 RAG、做成 Agent。这个分类对入门有用，但真到落地会发现它太粗了——它把几个不同维度的东西摆在了一条线上，也漏掉了生产中最常用的那一档。
这篇往深里聊一层：真实的架构不是三选一，而是一条从“全确定”到“全自主”的连续光谱；RAG 不是和 Agent 并列的“第三档”，而是一种随时可以插拔的能力；而决定成败的，往往不是你选了哪个模式，而是你有没有算清楚成本、延迟和失败模式。
一、根本张力：能力要靠“放权”换
先理解这条光谱背后的取舍。大模型应用里有一对永恒的矛盾：
- 你给模型的自由度越高（自己决定步骤、自己选工具、自己循环），它能处理的任务越复杂、越开放；
- 但自由度越高，结果越不可控：可能跑偏、可能死循环、可能调错工具，延迟和成本也越难预估。
所以架构设计的本质，是在“任务需要多灵活”和“你能容忍多不确定”之间找位置。把常见形态按自主性从低到高排开，是这样一条光谱：
flowchart LR
P["① 直接调用<br/>Prompt"] --> W["② 工作流<br/>固定编排"] --> R["③ RAG 增强<br/>（可叠加在任意一档）"] --> A["④ 自主 Agent<br/>模型自己决定流程"]
FT["微调 Fine-tuning<br/>改变模型本身，与上面正交"] -.-> P
FT -.-> W注意两点：微调不在这条线上——它改的是模型本身的能力/风格，和“怎么编排应用”是两个正交的维度，任何一档都可以配微调；而 RAG 也不是一个独立档位，它是“给模型接外部知识”的手段，从①到④都能用。入门文章把 Prompt / RAG / Agent 并列，其实把维度搞混了。
二、被漏掉的关键一档：工作流（Workflow）
三种模式里，Prompt 和 Agent 之间隔着一大片最有生产价值的区域，就是工作流：流程的路径和步骤由你写死，LLM 只在每个节点上做它擅长的那一小块（抽取、分类、生成、判断）。
Anthropic 在《Building Effective Agents》里把常见工作流归纳成几种可组合的模式（本系列 Agent 篇细讲过），这里点一下：
- 链式（Prompt Chaining）：任务拆成固定几步，前一步输出喂给后一步，步与步之间可以加代码校验；
- 路由（Routing）：先让模型分类，再分发到不同的专门处理流程；
- 并行（Parallelization）：多个子任务同时跑，再聚合；
- 编排者-工人（Orchestrator-Workers）：一个中心 LLM 动态拆任务、分派给多个子 LLM，再综合；
- 评估者-优化者（Evaluator-Optimizer）：一个生成、一个打分，不达标带反馈重做。
工作流和“直接调用”的区别是多步且有结构，和“自主 Agent”的区别是流程不由模型现场决定。
flowchart TB
In["输入"] --> Cls["分类 / 抽取（LLM）"]
Cls --> Gate{"代码路由判断"}
Gate -- 类型A --> F1["专门流程 A（LLM + 工具）"]
Gate -- 类型B --> F2["专门流程 B"]
F1 --> Chk["校验 / 评估（LLM 或规则）"]
F2 --> Chk
Chk -- 不达标 --> F1
Chk -- 达标 --> Out["输出"]这一档为什么重要？因为它用“确定性的骨架”兜住了 LLM 的不确定性：该确定的地方用代码，该灵活的地方用模型。大量看起来很智能的生产应用（客服分诊、合同审查、内容生成流水线）本质都是工作流，而不是自主 Agent。跳过工作流直接上自主循环，是最常见的过度设计。
三、RAG 的三个深浅层级
RAG 也不是一个点，而是一个从简单到复杂的层级。很多团队“上了 RAG 效果不好”，其实是停在了最朴素的第一层，却期待第三层的效果。
flowchart TB
subgraph L1["Naive RAG"]
N1["切块 → 向量检索 Top-K → 塞进 Prompt"]
end
subgraph L2["Advanced RAG"]
A1["查询改写/多路召回"] --> A2["混合检索<br/>向量 + 关键词 + 元数据过滤"] --> A3["Rerank 重排"] --> A4["上下文压缩"]
end
subgraph L3["Agentic RAG"]
G1["模型自主决定：要不要检索<br/>检索什么 · 检索几次 · 用结果怎么查下一步"]
end
L1 --> L2 --> L3- Naive RAG：切块、 embedding、向量检索 Top-K、拼 Prompt。能跑，但召回质量完全看切块和 embedding 的运气，答非所问很常见；
- Advanced RAG：在检索前后下功夫——查询改写（把口语问题补全成检索友好的表述）、混合检索（向量召回语义 + BM25 关键词兜底专有名词）、元数据过滤、Rerank 精排、上下文压缩去冗余。效果提升主要来自这一层，而不是换个更大的模型；
- Agentic RAG：把“检索”变成 Agent 手里的一个工具，由模型自己判断要不要查、查什么、查一次不够要不要换个关键词再查、甚至跨多个数据源迭代检索。最灵活，但也进入了高不确定性区。
经验是：先把 Advanced RAG 做扎实，再谈 Agentic。多数企业知识库场景，第二层就能解决八成问题，根本不需要让模型自由发挥。
四、什么时候才需要“自主 Agent”
工作流已经这么强，那什么时候必须上自主 Agent？判断标准很朴素：任务的步骤在写代码时无法预知。
- 能用一张流程图把“先做什么、后做什么、分几种情况”画出来 → 用工作流；
- 画不出来，下一步做什么取决于上一步的真实结果（比如“帮我调研这个竞品并出一份报告”，要查哪些资料、查几次、怎么追线索，事先没法定）→ 才需要自主循环。
即便如此，也建议局部自主：把开放的部分包在一个有明确边界和出口的模块里，外围仍是确定性工作流，高危动作（付款、删除、对外发送）一律人工确认。自主性应该像权限一样按需授予，而不是默认全开。
五、真正的选型决策：两个轴 + 一张流程图
别问“用 RAG 还是 Agent”，先回答两个问题：
- 任务需不需要外部知识 / 私有数据？ 需要就接 RAG（或搜索、数据库工具），这是能力维度；
- 任务路径能不能事先写死？ 能写死用工作流，写不死才用自主 Agent，这是编排维度。
flowchart TB
Start["一个新需求"] --> Q1{"需要私有/实时知识？"}
Q1 -- "否" --> Q2
Q1 -- "是" --> RAG["接 RAG / 搜索 / 数据工具"] --> Q2
Q2{"单步 LLM 能搞定？"}
Q2 -- "能" --> P["直接调用 Prompt"]
Q2 -- "不能" --> Q3{"流程能事先画出来？"}
Q3 -- "能" --> WF["工作流（链/路由/并行/编排）"]
Q3 -- "不能" --> AG["自主 Agent（局部自主 + 护栏）"]
Q1 -. "风格/格式/领域术语要求高且数据够" .-> FT["考虑微调"]微调单独说：它解决的是“模型的行为风格、领域语言、输出格式学不像”的问题，不解决“模型不知道你公司的事”——后者是 RAG 的活。数据足够、且需求稳定复现时，微调能让你用更小更便宜的模型达到大模型的效果，长期反而省钱；但它有数据和迭代成本，别为了“听起来高级”就上。
六、入门文章很少算的三笔账
模式选型之外，生产里真正让人头疼的是这三样：
1. 成本与延迟随自主性指数上升。 一次直接调用是一次模型请求；一个工作流可能是 3~5 次；一个自主 Agent 跑十步、每步还带上大段检索上下文，可能是几十次请求、几万到十几万 token。响应时间也从一秒变到几十秒。选型时要先算清“单次任务的 token 预算和可接受延迟”，而不是等账单来了才惊讶。
2. 失败模式完全不同。
| 模式 | 主要失败方式 | 兜底手段 |
|---|---|---|
| 直接调用 | 幻觉、格式不稳 | 降低温度、结构化输出、校验重试 |
| 工作流 | 某个节点分类/抽取错误传导 | 节点间加规则校验、分支兜底 |
| RAG | 召回不到 / 召回噪声 | 混合检索、Rerank、说“不知道” |
| 自主 Agent | 跑偏、死循环、调错工具 | 步数上限、人审、trace 回放 |
注意 RAG 也会失败：检索没召回时，模型容易“硬答”，一定要允许它在证据不足时说“资料里没有”。
3. 可观测和评估是自主系统的生命线。 直接调用看一眼输出就知道好坏；Agent 出了错，你得能回放“它当时怎么想的、调了什么、拿到什么”。每一步的 trace、token、工具入参出参都要记，并且要有一组固定任务做回归评测——否则你改个 prompt 都不知道是变好还是变坏。
七、演进路径：让架构被需求“逼”出来
一个健康的落地过程几乎总是渐进的：
- 先用直接调用 + 好 Prompt 验证价值，很多需求到这就够了；
- 知识不够 → 加 RAG，并直接按 Advanced RAG 的标准做检索质量；
- 单步搞不定、流程清晰 → 套工作流，用代码骨架锁住确定性；
- 出现真正开放、无法预定义路径的任务 → 局部引入自主 Agent，配好步数、权限、人审和 trace；
- 风格/领域需求稳定且量大 → 再评估微调降本。
每一步都由“当前模式确实撑不住了”的具体痛点驱动，而不是因为下一模式听起来更先进。
八、小结
- 大模型应用架构是一条从确定到自主的连续光谱，核心矛盾是“能力靠放权换，放权带来不确定性”；
- 工作流是被入门文章漏掉、却最常用的一档：流程写死、LLM 填空，用确定性骨架兜住模型；
- RAG 是接知识的能力，不是和 Agent 并列的档位，且分 Naive / Advanced / Agentic 三层，先把 Advanced 做扎实；
- 只有任务路径无法预知时才上自主 Agent，且坚持局部自主、高危人审；
- 选型看两个轴：要不要外部知识（RAG）、流程能不能写死（工作流 vs Agent）；微调解决风格而非知识；
- 别忘了算成本/延迟、失败模式、可观测评估这三笔账——它们才是 demo 和生产的真正分界线。
从 Prompt 到 Agent 不是升级打怪，而是一笔用成本和不确定性换能力的交易。好的架构师不是把最自主的方案用上，而是在刚好够用的那一档，把可靠性做到极致。
本文由 AI 辅助创作，所有内容仅供交流与参考。
