大模型应用混合架构：Agent-Workflow-RAG-Skill四要素协同实战

大模型应用做到一定复杂度，你会发现一个卡点：到底该让 Agent 自由发挥，还是把流程写死用 Workflow 硬编？纯走 Agent，回答发散、工具调用失控、出错不可追溯；纯走 Workflow，稍微有点开放性的任务就死板到没法看。我自己在落过几个实际项目之后，逐渐形成了一套 Agent-Workflow-RAG-Skill 四要素混合的架构方案。这套东西不是什么教科书理论，就是把“确定性”和“智能性”按比例调配，让每条请求找到最优处理路径。

这篇文章会把混合架构的设计思路、路由策略、状态管理、容错回退、RAG 和 Skill 的边界划分讲清楚，配合真实项目里踩过的坑和调参经验，适合正在做 Agent 应用落地、或者被“Agent 幻觉”和“流程僵化”两头夹击的技术负责人参考。

1. 先问为什么：大模型应用绕不开的路由难题

1.1 纯 Agent 与纯 Workflow 的矛盾

先说一个真实的尴尬场景。某客服系统，上线初期团队选了一条“最正确”的路：全部交给 Agent 处理。结果是，用户问“退款几天到账”这种固定问题，Agent 大脑一热编出“1-3 个工作日”，实际上系统规则是“原路退回 15 个工作日”；让它查个订单状态，它能连续调用五次查询工具，把上下文窗口塞满。问题不在模型能力，在于没有约束——Agent 天生是概率推理，它自己都不知道自己在说谎。

反过来，也试过纯 Workflow。每个流程节点写死，正常路径能跑，但用户一旦换个说法、岔开话题或者问点边界情况，流程直接断裂。比如“我要退货，但是发票先开了”，这种混合诉求在固定流程里根本没有对应分支。做系统的朋友应该都懂，CPU 好堆，状态机难画。

1.2 混合架构的解题思路：把“确定性”和“智能性”解耦

后来我意识到，问题的本质不是二选一，而是给请求分级。系统里要有两条腿：一条是确定性优先的 Workflow 骨架，一条是智能补位的 Agent 灵活决策。骨架负责流程不散，Agent 负责边界不僵。RAG 负责给整个系统提供实时知识，Skill 负责屏蔽底层工具差异。四者不是简单的串联，而是像人的大脑一样，有“决策中枢”和“条件反射”。

我后来在多个项目里把这种架构固化下来，核心就一句话：能用规则解决的，不交给模型；模型必须做决定的，用 RAG 和 Skill 约束它做决定的依据和动作范围。后面详细拆解每个角色和它们之间的协同链路。

2. 四个要素，各管一摊：先明确分工边界

2.1 Workflow：确定性流程编排，系统的“骨架”

Workflow 在混合架构里承担两个任务。第一，承载高频、标准化流程。比如“订单查询-展示状态-引导下一步”这种三段式结构，完全不需要模型思考，直接编排接口调用。第二，为 Agent 提供“安全网”，也就是当 Agent 决策完毕，执行的落地动作依然要走强约束的流程。

我在实际项目里通常把 Workflow 定义成状态机，而不是简单的前后步骤列表。状态机的好处是每个节点都有明确的输入、输出、跳转条件和异常出口。例如“申投诉处理”流程，节点包括：接收诉求-分类登记-指定处理人-处理中-待确认-闭环。每个节点都对应一个处理器（Handler），Handler 里可以做校验、幂等、持久化。Workflow 这层不写任何 Prompt，只写逻辑。

提示：如果你的业务是强合规场景（金融、政务），Workflow 要作为主控，Agent 只能在严格限定的节点内做子任务。

2.2 Agent：动态决策节点，处理“规则没写死”的部分

Agent 在这套架构里不是“万能大脑”，它更像一个“机动队”。它的存在是为了处理 Workflow 分支表覆盖不到的开放域。例如用户发起一个模糊请求：“我想投诉，但我说不清楚问题出在哪。”这种情况下，静态流程没有办法确定下一步该走投诉还是咨询，Agent 就要介入，通过多轮追问澄清意图，再映射到具体的 Workflow 入口。

Agent 设计的关键是给它设置动作边界。我会给 Agent 定义一组“技能白名单”——它只能调用预先注册好的 Skill，不允许自由发挥。例如 Agent 可以做意图判定、信息抽取、内容生成，但不能直接改数据库、不能发外部请求。所有这些能力都通过 Skill 暴露成独立函数，Agent 通过函数调用（Function Calling）触发，而不是让它直接写代码执行。

2.3 RAG：知识供给层，减少幻觉的关键

RAG（检索增强生成）在混合架构里的核心任务只有一个：给模型提供可靠的背景知识。客服场景里，政策变更是高频问题，模型训练数据永远跟不上业务变化，RAG 就是系统里的“实时信息员”，把知识库、历史工单、帮助文档切成向量片段，在模型生成前先检索并注入上下文。

但我要提醒一个容易犯的错误：RAG 不是越多越好。有段时间我为了追求 Recall 高，把每轮查询都注入 10 段文本，结果上下文被无关内容淹没，模型反而被错误信息带偏。后来我会对召回的文档做一次 rerank，只保留与当前问题相关性最高的 3~5 段，并且标注检索来源。这样既能提升回答准确率，也方便追踪知识的溯源。

2.4 Skill：标准化工具封装，隔离底层依赖

Skill 是最容易被忽略、但影响最深的一层。它把第三方 API、内部服务、数据库操作统一封装成“可被大模型理解和调用”的标准化接口。比如“查询订单”这个 Skill，不管底层对接的是自研订单中心还是外部 ERP，对模型来说暴露的都只是参数 schema：orderId、customerId、返回字段列表。

这样做有三个好处。其一，屏蔽了底层差异，模型不需要关心接口地址和鉴权细节；其二，集中管控权限和审计，每个 Skill 都可以加细粒度鉴权；其三，方便做沙箱，关键操作强制人工复核。Skill 的粒度控制很讲究：太粗模型没法精确调用，太细上下文会被 tool 描述撑爆。我的经验是一个 Skill 对应一个完整业务动作，参数控制在 5~8 个以内。

3. 路由与协同的关键：编排策略

3.1 前置意图分类：先用轻量模型定方向

混合架构的入口不是 Agent，而是一个意图路由器。我通常用两类方案：有标注样本的情况下训练一个轻量分类器（例如基于 Bert 的意图识别模型或小尺寸 LLM），样本少就直接用 LLM 做 JSON 结构化输出。路由的目标是把请求分成三类——固定流程类、Agent 动态处理类、人工介入类。

固定流程类，典型特征是高频、规则明确、场景垂直，比如“查余额”“改密码”“查物流”，直接走 Workflow，不经过大模型生成。Agent 动态处理类，一般涉及多轮对话、意图交叉、开放式提问，才进入 Agent 环节。人工介入类是风险业务，系统识别到情绪词、敏感词或者低置信度，直接升级给人工，不要让模型硬撑。

我常用的路由判定标准是置信度阈值。分类器输出每个意图的概率分数，例如分数大于 0.8 直接走对应 Workflow；分数在 0.5~0.8 之间，则把候选意图列表交给 Agent 做二次确认；低于 0.5 判为异常意图，转入人工。这个阈值不能拍脑袋定，要根据线上日志的准确率分布画曲线，找召回和精度的平衡点。

3.2 RAG 辅助决策：边查边做，不盲目发挥

RAG 在混合架构里不能只在最终回答前用一次。很多时候路由本身就需要 RAG 参与。举个例子，“今年三季度的佣金新规对我这笔订单适用吗”，如果直接把问题丢给路由分类器，它不知道“新规”是什么。正确做法是，路由阶段先判断是否涉及政策类知识，如果涉及，先检索知识库，把相关条款摘要一起传给下一级处理单元。

这个策略叫“先检索、后规划”。尤其在 Agent 决定工具调用顺序时，RAG 检索结果会影响它的决策路径。比如用户问“我的订单违约了怎么办”，RAG 提取出“违约处理流程”文档，Agent 根据文档步骤去编排调用相关 Skill，而不是靠模型记忆生成处理方案。我在设计 Review 节点的判定逻辑时，会校验 Agent 的输出是否与检索文档的要点冲突，冲突则驳回重写。

3.3 Agent 控制 Workflow 子流程：分层编排

很多人以为 Agent 和 Workflow 是互斥的，实际上它们应该是嵌套关系。我在系统里设计了两种编排模式。

第一种是Workflow 内置 Agent 节点。即主流程固定，但某个节点需要动态能力时，嵌入一个“子 Agent”。例如主流程是“工单受理-处理-回访”，在“处理”环节，如果是技术咨询，则启动 Agent 进行针对性解答，解答结果校验通过后回填工单，继续走回访流程。这种方式适合流程边界清晰、但节点内部需要智能化的场景。

第二种是Agent 编排 Workflow。即 Agent 作为主导，根据用户意图把多个 Workflow 拼接执行。比如用户诉求“改地址+补开发票+催发货”，Agent 识别出这是三个独立子流程，按顺序依次触发，并且处理彼此依赖关系。这种模式下，Agent 不能直接调用底层接口，只能触发 Workflow 引擎，所有流程状态由引擎管理。

第一种模式我更推荐大多数团队优先落地，原因很简单：风险可控。Workflow 是主干，Agent 只负责局部，出问题也容易定位。第二种模式自由度大，但需要更完善的流程链路追踪，否则 Agent 一旦编排错误，后续补救成本会很高。

4. 核心实现：调度器、状态机与回退机制

4.1 调度器设计：一切绕着状态转

整个混合架构的执行中枢是一个调度器（Orchestrator）。它不负责业务逻辑，只负责三件事：读状态、判条件、派任务。业务流程运行中，每个环节都被定义成独立的任务单元，调度器根据当前状态决定下一步动作。

设计上我强烈建议引入显式状态机，而不是用“if-else 链”写流程。状态机的好处在于状态可持久化、可回溯、可恢复。我用的状态定义大致包括：pending（待处理）、running（执行中）、tool_calling（工具调用中）、waiting_human（等待人工）、completed（已完成）、failed（失败）、aborted（中止）、escalated（升级）。

每个状态迁移都有前置条件和后置动作。比如从 pending 迁移到 running，前置条件是“意图分类完成且置信度达标”；迁移动作是“记录开始时间、初始化执行上下文”。这种方式让整套系统的可观测性大幅提升，线上排查问题不再靠猜。

调度器还需要处理并发与超时。Agent 工具调用容易卡住，我规定单个 Skill 的默认超时 10 秒，整体任务超时 60 秒。超过则强制降级，把任务转入人工队列，避免用户无限等待。

4.2 上下文与记忆管理：别让模型“失忆”

混合架构里的上下文和纯对话场景不一样，不是所有内容都要喂给大模型。做法是设计一个“工作记忆”模块，专门维护本次执行的关键信息。例如用户 ID、订单号、诉求类型、已经调用过的 Skill 及返回值。这层记忆是结构化的，不是对话历史拼接。

只在需要生成自然语言输出时，才把工作记忆中的关键字段转成 Prompt 片段。这样既能保证生成内容贴合上下文，又不会让模型被大量无关历史干扰。另外，对话历史要设置滚动窗口，我一般保留最近 5 轮的核心语义摘要，而不是全量 transcript。这个优化能让响应延迟降低 20% 以上，同时明显减少模型幻觉。

4.3 回退与容错：混乱场景兜底的最后一层

混合架构必须有兜底回退链路。哪怕路由再准，Agent 总会有判断失误的时候。我的经验是在三个层级设定回退策略。

第一层是模型层。如果 Agent 的生成结果通过不了规则校验——比如情绪负面、信息缺失、置信度低——重新生成一次，重试次数最多两次。第二层是流程层。如果 Workflow 执行失败，根据失败类型选择跳过、重试、终止或降级。第三层是整体降级。当整个智能链路走到死胡同，直接转入人工会话，把系统收集到的信息一键转交，人工可以在工作台看到完整执行轨迹。

这里最容易踩的坑是：没有给“回复用户”和“内部动作”之间做隔离。用户可能已经收到“退款处理中”的回复，内部流程却因为接口异常而失败。后来我加了动作校验机制：凡是涉及资金、订单状态变更的关键动作，必须等内部执行成功返回后再回复用户，绝不能先回复后执行。这属于架构层面的“治未病”。

5. 落地案例：一个客服系统的状态流转全演示

5.1 一个真实请求的处理链路

拿一个实际跑过的项目举例，某电商平台的智能客服系统。用户进来发了一句：“我上周买的耳机有问题，想退，但是发票好像也没给我。”这个请求如果放给传统的意图分类，大概率判定为“退货”，但其实涉及“退换货”和“发票”两个意图。

系统实际流转过程如下： 第一，路由层判断该请求是多意图混合，置信度矩阵不支持直接映射到单一 Workflow，于是转发给 Agent 节点。同时，RAG 根据“退货退款规则”和“发票补开规则”异步检索出两篇知识文档。 第二，Agent 节点通过多轮澄清确认（这个环节一般会回一句“您是想退货还是换货？发票需要补开吗？”），在得到用户确认后，输出结构化的处理计划：调起退货 Workflow + 补开发票 Skill。每个动作都标注了引用的知识来源。 第三，调度器按计划依次执行。退货 Workflow 创建售后单，生成退货地址；发票 Skill 校验订单信息后提交补开申请。两个动作完成后，状态机走到 completed，统一生成回复给用户。 整个过程耗时约 3.8 秒，远好于之前纯 Agent 方案的 9 秒平均耗时，且用户满意度提升了 12%。

5.2 线上监控：如何判断架构是否健康

混合架构的排障不能只看大模型输出对不对，而是要看链路各环节的健康度。我建议每个团队至少盯四个核心指标：

如果人工介入率突然上升，优先查 RAG 的召回质量，大概率是知识库更新不及时导致 Agent 找不到依据。如果 Agent 工具调用成功率下降，查 Skill 的输入参数，常见问题是 Agent 生成的参数格式与 Skill schema 不匹配，这个可以通过在调用前增加参数校验节点来规避。

我还给链路加了会话级追踪 ID，每一个请求从路由到大模型到工具调用，全程打日志。排查问题时按 ID 拉全链路事件流，很快能定位是哪一环出了问题。这个能力建议在项目初期就做，后面再补会非常痛苦。

6. 实战踩坑与排查经验

6.1 幻觉根治不了，但能被约束

先说个扎心结论：混合架构里如果用强 LLM 做终端回复，幻觉只能被约束，无法被根治。约束手段我提三个。

一是回答前提引用。所有涉及事实性输出的节点，Prompt 里强制要求“只能依据检索文档回答，禁止自行补充”，再配合输出端规则校验——如果关键实体不在检索文档中出现，直接拦截返回兜底话术。

二是限制模型的“自由发挥”空间。给 Agent 预设回答模板，模板里有结构化填充槽位，模型只能做选择和填空，不能自由写段落。这样的好处是既保留语言多样性，又卡住了事实边界。

三是关键动作二次确认。凡是涉及金额、时效、承诺，系统不直接采用生成结果，而是把候选答案重新输入校验模型打标，标签为“可承诺”或“不可承诺”，不可承诺统一转人工。

6.2 上下文污染：多意图请求的隐形杀手

混合架构最常见的错误是把所有信息一股脑塞进上下文。多意图场景尤其严重。用户说“改地址+退款”，系统要处理两个独立上下文。如果混在一起，Agent 分不清当前是在改地址还是在退款。我踩过这个坑后改变了策略：按意图维度隔离上下文，每个意图维护独立的 memory slot，Reward 模型输出时严格限定在对应 slot 内。

6.3 死循环：Agent 反复调用同一个工具

实际运行中，Agent 偶尔会钻牛角尖，反复调用同一个 Skill 却不推进任务。比如查库存的 Skill，调用三次返回都一样，Agent 仍在继续查，浪费算力和时间。解决方式很简单：给工具调用加频控，同一个 Skill 在单轮任务里最多调用两次，超限则判定该子任务“无法通过工具解决”，强制跳转到人工。

还要设计好最大步数限制。我给 Agent 节点设置单轮最大 12 步，超过自动终止，输出已执行的部分结果并引导用户转人工。这个参数要结合流程复杂度调，不要设得太小导致复杂问题处理不完，也不要设太大让系统空转。

6.4 关于 LLM 参数设置的一点体会

最后说两个参数偏好，纯属个人项目经验。一是路由和分类场景，temperature 直接设 0，用足够的 top_p 保证输出稳定；二是生成场景，temperature 设在 0.3~0.5 之间，超过 0.7 之后，Agent 的行为不再稳定，拒绝服务的概率会显著上升。很多人热衷于调 prompt 解决可控性问题，但往往改一行参数比写五段 prompt 更有效。

混合架构不是什么新概念，它就是把“机器擅长的事”和“模型擅长的事”分开，再通过编排把它捏合成一个整体。我用这套思路落过客服、文档助手、内部工单处理等多个场景，整体稳定性显著优于纯 Agent 方案。如果你们团队还在纠结全上 Agent 还是全做 Workflow，我建议先想想哪条请求路径最值得被固定下来，哪部分真的需要智能决策，把这两类流量分开路由，架构自然就清晰了。

最后再分享一个小技巧：混合架构的演进不要一上来就铺全。先挑一个高频、价值明确的业务场景跑通，比如订单售后问答，把 Workflow 的状态机和 RAG 知识库建起来，再逐步让 Agent 参与更多开放场景。架构是长出来的，不是设计出来的，先小步走，让数据告诉你下一步该把智能性放到哪个节点。