截至 2026 年 6 月，LLM 生产的四种核心应用模式——Chat（对话）、RAG（检索增强）、Agent（自主执行）、Workflow（工作流编排）——的架构对比、组合策略和产品化决策框架。

一句话解释

LLM 应用的本质是在模型能力、系统复杂度、可控性和成本之间做权衡，四种模式代表从"完全交给模型"到"完全由代码控制"的渐变光谱——选对模式比选对模型更重要。

核心问题：为什么需要理解应用模式？

• Chat 模式能力有限：纯对话没有外部信息源，幻觉高、不能执行操作
• RAG 模式解决了知识问题：但无法处理多步操作
• Agent 模式最灵活：但不可控、成本高、延迟大
• Workflow 模式最可控：但灵活性差，需要预定义每条路径
• 没有最优模式，只有最适合当前任务的模式

四种模式全景

各模式深度解析

1. Chat 模式 — 纯对话

用户输入 → [LLM] → 文本输出
           ↑
      [System Prompt]

维度	说明
复杂度	⭐ 最低，仅需 API 调用 + System Prompt
可靠性	⭐⭐ 完全依赖模型知识，幻觉概率最高
延迟	⭐⭐⭐⭐⭐ 最低，单一 LLM 调用
成本	⭐⭐⭐⭐⭐ 最低，无额外基础设施
可控性	⭐ 最低，输出无法预测
适合场景	闲聊、创意写作、头脑风暴、翻译
不适合	需要事实准确性的任务、需要操作外部系统的任务

典型产品：ChatGPT 免费版、Claude.ai 对话、AI Chat 玩具

技术要点：

• System Prompt 是唯一的设计杠杆
• 所有知识依赖模型训练数据（截止日期）
• 改进方式：Few-shot / 思维链 / Structured Output
• 最容易被低估的模式——很多场景 Chat 模式已经足够

2. RAG 模式 — 检索增强

用户输入 → [Query 改写] → [向量检索] → [检索结果]
                                    ↓
          [System Prompt + 检索结果] → [LLM] → 基于来源的回答

维度	说明
复杂度	⭐⭐⭐ 需要检索管道 + 文档向量化 + 数据库
可靠性	⭐⭐⭐⭐ 有外部知识作为事实基础
延迟	⭐⭐⭐ 增加检索步骤（100ms-500ms）
成本	⭐⭐⭐ 额外：向量 DB + Embedding API + 存储
可控性	⭐⭐⭐ 可追溯来源，但模型可能忽略检索结果
适合场景	客服知识库、企业内部知识问答、文档分析
不适合	需要多步推理、需要操作外部系统

典型产品：Perplexity、Notion AI Q&A、企业客服机器人

核心技术栈：

• Embedding 模型（text-embedding-3-large / Cohere）
• 向量数据库（Pinecone / Milvus / pgvector）
• Chunking 策略（句级/段落级/递归）
• Reranking（Cohere Rerank / BGE Reranker）

常见陷阱：

• Chunk 大小不对：太小丢失上下文，太大引入噪音
• 检索结果没用：需要 Query 改写 + Hybrid Search
• 模型不听话：模型可能忽略检索结果坚持自己"知道"
• 评估困难：需要同时评估检索质量和生成质量

详见 RAG基础 和 向量数据库对比

3. Agent 模式 — 自主执行

用户输入 → [LLM 推理] → [工具选择] → [工具执行] → [结果分析]
              ↕                        ↑
         [记忆/上下文]          [MCP Server / API]
              ↕
         [多步规划/反思]

维度	说明
复杂度	⭐⭐⭐⭐⭐ 最高，需要工具/记忆/编排/容错
可靠性	⭐⭐ 最低，多步操作中错误累积
延迟	⭐ 最高，可能数分钟完成一个任务
成本	⭐⭐ 最高，多次 LLM 调用 + 工具执行
可控性	⭐⭐ 低，Agent 可能走意想不到的路径
适合场景	复杂编码、多步研究、数据分析、自动化运维
不适合	需要稳定可预测输出的场景

典型产品：Claude Code、OpenAI Codex CLI、AutoGen

核心技术栈：

• ReAct 循环（Reason + Act）
• Tool Use / Function Calling
• MCP 协议（Agent 与外部服务的标准接口）
• 记忆系统（上下文管理 + 状态持久化）
• 容错策略（重试 / Human-in-the-loop / Fallback）

关键挑战：

• 错误传播：第一步错 → 后续全错，需要 Checkpoint + 回滚
• 工具幻觉：Agent 可能调用不存在的工具或传错参数
• 成本不可控：一个任务可能产生 10-100 次 LLM 调用
• 安全风险：Agent 可能执行非预期的危险操作

详见 Agent基础、Agent框架对比、MCP协议（待创建）

4. Workflow 模式 — 工作流编排

[用户输入] → [意图分类] → [NLU 处理] → [业务逻辑] → [LLM 生成] → [输出格式化]
              ↓              ↓            ↓
         [路由节点]    [API 调用]    [条件分支]

维度	说明
复杂度	⭐⭐⭐⭐ 需要预定义流程 + 状态管理
可靠性	⭐⭐⭐⭐⭐ 最高，每一步被代码控制
延迟	⭐⭐⭐ 取决于流程深度
成本	⭐⭐⭐⭐ 较低，只在需要时调用 LLM
可控性	⭐⭐⭐⭐⭐ 最高，每步可检查/测试/回滚
适合场景	客服流程、审批系统、数据管道、内容审核
不适合	需要模型灵活探索的场景

典型产品：Dify Workflow、LangGraph、n8n + AI 节点

设计模式：

• Chain：顺序执行，前一步输出是后一步输入
• Router：根据意图/分类分发到不同子流程
• Parallel：Fan-out 并行处理，合并结果
• Orchestrator：中心调度器协调子任务
• Evaluator-Optimizer：生成 → 评估 → 迭代优化

与 Agent 模式的关键区别：

Agent 模式：模型决定下一步做什么（动态）
Workflow 模式：代码决定下一步做什么（静态）

两者可以嵌套：Workflow 中的某个节点可以运行一个 Agent

核心对比矩阵

维度	Chat	RAG	Agent	Workflow
实现复杂度	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
事实准确性	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
响应速度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐
成本效率	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
可预见性	⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
可扩展性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
灵活适应	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐
安全可控	⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
调试难度	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
用户信任度	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐

成本与延迟对比（典型值）

模式	每次请求 LLM 调用次数	端到端延迟	典型成本倍数
Chat	1	1-3s	1x (基准)
RAG	1-2	2-5s	1.5-2x
Agent	5-50+	10s-10min	5-50x
Workflow	1-5	3-30s	1-5x

模式组合策略

四种模式不是互斥的，实际产品通常组合使用多种模式。

常见组合模式

Chat + RAG        = Perplexity / 智能问答
                        ↓
RAG + Workflow    = 客服系统（检索 → 分类 → 生成回复）
                        ↓
Agent + Workflow  = 自动化运维（工作流编排 Agent 执行步骤）
                        ↓
Chat → RAG → Agent = 渐进式架构（从简单开始，逐步放权）

组合决策矩阵

需求	推荐组合	理由
知识问答	Chat + RAG	RAG 提供事实基础，Chat 提供对话体验
客服系统	RAG + Workflow	工作流控制对话流程，RAG 提供知识
编码助手	Chat + Agent	简单问答用 Chat，复杂任务用 Agent
数据处理	Workflow + RAG	工作流编排 ETL 流程，RAG 查询知识库
自动化研究	Agent + RAG	Agent 执行多步调研，RAG 检索资料
金融合规	Workflow + Chat	工作流确保合规路径，Chat 优化体验
教育辅导	Chat + Workflow	自由对话 + 教学流程控制

嵌套模式案例

电商客服系统：
                         [用户消息]
                             ↓
                      [Workflow: 意图分类]
                      /        |        \
                 [退货]    [查询订单]   [投诉]
                    ↓          ↓          ↓
              [RAG: 退货政策]  [API: 查DB]  [Agent: 升级处理]
                    ↓          ↓          ↓
              [Chat: 生成回复] [Chat: 生成] [Chat: 安抚+转人工]

产品化决策树

渐进式放权框架

从 Chat 到 Agent 的递进路线（Anthropic 推荐架构）：

Level 1: Chat — 纯对话，人做所有决策
    ↓
Level 2: RAG — LLM + 检索，人校验来源
    ↓
Level 3: Tool — LLM 调用 API，每次需要人确认
    ↓
Level 4: Workflow — 代码控制流程，LLM 做子任务
    ↓
Level 5: Agent — LLM 自主规划执行，人监督例外
    ↓
Level 6: Multi-Agent — 多个 Agent 协作，人只定义目标

关键原则：从 Level 1 起步，仅当当前级别不满足需求时才升一级。 70% 的 AI 产品卡在过早升级到 Agent（不必要的复杂度、不可控的成本）。

选型铁律

1. Chat 模式永远是最佳起点 — 一个 API 调用就能跑，先验证价值再增加复杂度
2. RAG 先于 Agent — 知识问题先解决检索，再考虑自主性
3. Workflow 优先于 Agent — 能预定义的路径就不要让模型探索
4. Agent = 最后手段 — Agent 的复杂度是 Chat 的 10-50 倍，成本是 Chat 的 5-50 倍
5. 组合优于单一 — 没有产品只用一种模式，RAG+Workflow 比纯 Agent 更稳定
6. 可控性 > 灵活性 — 生产环境中可预测的输出比灵活的 Agent 更有价值
7. Human-in-the-loop 不是失败 — 最成功的 AI 产品（GitHub Copilot、Claude Code）都会在关键节点让人确认

常见误区

1. "所有场景都需要 Agent" — 2026 年最大的过度工程趋势。聊天机器人就先用 Chat 模式
2. "RAG 解决幻觉" — RAG 能降低但无法消除幻觉，模型仍可能忽略检索结果
3. "Agent 是未来，Workflow 已过时" — 生产环境中最稳定的 AI 产品恰恰是 Workflow 模式
4. "模式是二选一" — 实际上所有成功产品使用 2-3 种模式的组合
5. "先上 Agent，发现问题后再降级" — 反向操作成本极高，Agent 的系统设计不适合被简化成 Workflow

与其他概念的关系

• RAG基础 — RAG 模式的深入技术原理
• Agent基础 — Agent 模式的核心概念和架构
• Agent框架对比 — LangGraph/CrewAI/AutoGen 等 Agent 框架对比
• AI Coding工具对比 — 编码场景中 Chat/Agent 模式的实际应用
• LLM模型对比 — 底层模型的编码/推理能力决定了每种模式的上限
• Function Calling与Tool Use — Tool Use 是 Agent 和 Workflow 模式的基础能力
• 模型幻觉与不确定性 — 影响每种模式准确性评估的关键因素
• Prompt Engineering方法论 — Chat 模式的核心设计工具

可继续补充的方向

• 各模式评估框架：如何量化评估 Chat vs RAG vs Agent 在具体任务上的优劣
• 实际案例库：知名产品（Perplexity/GitHub Copilot/Claude Code/Dify）的模式组合分析
• 安全性对比：四种模式的 Prompt 注入、越狱、数据泄漏风险差异
• Human-in-the-loop 设计：每种模式的人机协作机制设计模式
• 模式迁移案例：产品从 Chat → RAG → Agent 演进过程中的架构变更和踩坑
• 成本模型：四种模式在 100 万次调用下的总成本测算（含基础设施）
• 延迟预算：每种模式在 200ms/2s/10s 延迟目标下的架构取舍

---

参考资料：Anthropic "Building effective agents" 指南 (2024.12)、LangChain 官方文档、实际产品架构分析。模式分类和分级框架参考 Anthropic 的 Level 1-6 Agent 分级体系。