大模型应用做到一定复杂度你会发现一个卡点到底该让 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 定义成状态机而不是简单的前后步骤列表。状态机的好处是每个节点都有明确的输入、输出、跳转条件和异常出口。例如“申投诉处理”流程节点包括接收诉求-分类登记-指定处理人-处理中-待确认-闭环。每个节点都对应一个处理器HandlerHandler 里可以做校验、幂等、持久化。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对模型来说暴露的都只是参数 schemaorderId、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 线上监控如何判断架构是否健康混合架构的排障不能只看大模型输出对不对而是要看链路各环节的健康度。我建议每个团队至少盯四个核心指标指标含义推荐阈值路由准确率路由选择的流程是否匹配用户诉求 92%Agent 工具调用成功率工具调用有无异常/超时 95%RAG 命中率检索结果是否被生成环节采纳 80%人工介入率需要转人工的比例 20%如果人工介入率突然上升优先查 RAG 的召回质量大概率是知识库更新不及时导致 Agent 找不到依据。如果 Agent 工具调用成功率下降查 Skill 的输入参数常见问题是 Agent 生成的参数格式与 Skill schema 不匹配这个可以通过在调用前增加参数校验节点来规避。我还给链路加了会话级追踪 ID每一个请求从路由到大模型到工具调用全程打日志。排查问题时按 ID 拉全链路事件流很快能定位是哪一环出了问题。这个能力建议在项目初期就做后面再补会非常痛苦。6. 实战踩坑与排查经验6.1 幻觉根治不了但能被约束先说个扎心结论混合架构里如果用强 LLM 做终端回复幻觉只能被约束无法被根治。约束手段我提三个。一是回答前提引用。所有涉及事实性输出的节点Prompt 里强制要求“只能依据检索文档回答禁止自行补充”再配合输出端规则校验——如果关键实体不在检索文档中出现直接拦截返回兜底话术。二是限制模型的“自由发挥”空间。给 Agent 预设回答模板模板里有结构化填充槽位模型只能做选择和填空不能自由写段落。这样的好处是既保留语言多样性又卡住了事实边界。三是关键动作二次确认。凡是涉及金额、时效、承诺系统不直接采用生成结果而是把候选答案重新输入校验模型打标标签为“可承诺”或“不可承诺”不可承诺统一转人工。6.2 上下文污染多意图请求的隐形杀手混合架构最常见的错误是把所有信息一股脑塞进上下文。多意图场景尤其严重。用户说“改地址退款”系统要处理两个独立上下文。如果混在一起Agent 分不清当前是在改地址还是在退款。我踩过这个坑后改变了策略按意图维度隔离上下文每个意图维护独立的 memory slotReward 模型输出时严格限定在对应 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 参与更多开放场景。架构是长出来的不是设计出来的先小步走让数据告诉你下一步该把智能性放到哪个节点。