★ FEATURED ARTICLE 先说明一下这篇内容源自我们团队过去一年里拿到三个真实企业项目里反复试错后的复盘。标题确实有点“营销味”但拆开来看RAG、Workflow、Agent 这三个词恰好对应企业把大模型用起来时躲不开的三个问题知识怎么喂进去、流程怎么跑起来、系统怎么自己判断下一步。如果你正在负责企业内部的 AI 落地或者被“用大模型改造业务”这个任务砸中下面这些内容应该能帮你少走不少弯路。1. 为什么是 RAG Workflow Agent 这个组合1.1 单点大模型能力在企业场景里远远不够先说个常见现象。很多团队一开始都会做一个“AI 问答机器人”把大模型接口接上上传几份文档然后让员工来问问题。Demo 阶段效果不错领导看了挺满意一旦放开给真实用户用问题就全冒出来了。第一个是幻觉问题。大模型对训练数据之外的内容并不了解你问它内部制度里某个具体条款它可能一本正经地编一个差不多的答案看着好像对细究全是错的。第二个是“知道但不行动”的问题。就算它答对了用户还是要自己去 OA 系统里填单子、走审批、等流程问答只是多了一块牌子业务链路没变。第三个是“每次动作不一样”的问题。同一个问题上午问和下午问或者换个人问走的过程可能完全不同这在企业场景里没法接受——操作都是要审计、要留痕的。所以单点大模型能力就像一把好用的螺丝刀但企业要的是一整套工具墙还得有个师傅知道什么时候用哪把。RAG、Workflow、Agent 这三个东西正好对应这套工具墙的不同层RAG 解决知识供给Workflow 解决流程的确定性Agent 解决路径的动态决策。1.2 三者各自的定位与分工我用一个相对好理解的类比来说明这三者的关系Agent 是项目经理Workflow 是公司里的标准作业流程RAG 是档案室。Agent 的职责是听懂任务、拆解目标、决定下一步调用谁。它面对的是开放性问题路径不确定比如“帮我查一下上个月华东区的报销异常情况并生成报告”这种任务没办法写死流程只能靠 Agent 临时规划。Workflow 的职责是保证“这件事必须按规则走”。比如费用报销必须经过部门主管审批、财务复核、出纳打款这个顺序不能乱任何一步都不能靠大模型即兴发挥。它不是用来智能化的而是用来固化的。RAG 的职责是让系统有据可依。模型原本的训练知识是“通识”企业内部的知识它不知道也更新不了而 RAG 可以把最新制度、产品文档、历史案例切成片段存进向量库回答问题时先检索再生成每个答案都能带回引用来源。三者分工清楚之后组合起来才不打架。如果只用 Agent 不用 Workflow核心流程会频繁失控只用 Workflow 不用 Agent业务人员还是得把问题翻译成固定表单两个都用了但没有 RAGAI 就是个没有内部知识的空壳做着做着就开始胡编。1.3 组合之后产生的增量价值能有多大举个例子。我们做过一个面向企业内部 IT 支持场景的系统员工报障时不再需要选故障类型、填工单、等人工分派。员工直接说一句“我邮箱登录不了密码应该没输错”Agent 先判断这是一个账号类问题先去 RAG 检索账号解锁的标准解法发现自助重置就能解决就给用户返回操作指引如果用户说“试过了还是不行”Agent 再判断需要人工介入自动触发一个 Workflow创建工单、分派给对应二线工程师、同步状态给用户整个过程用户只说了两句话后台全跑完了。从效果上看RAG 解决了回答准确性和可解释性Workflow 解决了“AI 说了不算数”的尴尬Agent 则把这两者缝合成一个能自主办事的数字员工。这三样组合起来实际上是在企业内部搭建了一个“可以理解业务、可以执行流程、还可以自我校验”的智能体系统。这个增量是单一技术堆叠无法提供的。2. 整体架构怎么搭先搭骨架再填肉2.1 一套经过验证的四层架构我们反复调整之后最终沉淀下来的架构分四层每一层只干一件事边界非常清晰。最底层是模型层各家大模型接口、私有化部署的小模型、行业专属模型都在这层通过统一的模型网关对外提供服务。模型层不关心上层业务只提供“文字进、文字出”或者“文字进、结构化信息出”的能力。第二层是知识层也就是 RAG 的底座。企业内部文档经过解析、清洗、切分、向量化之后进入向量库上层无论是 Agent 还是 Workflow都可以按需检索。这一层做得好不好直接决定了后续回答的质量上限。第三层是流程层Workflow 在这层落地。我们把企业里那些成熟的、规则明确的操作固化成可编排的流程每个节点都有明确的输入、输出、负责人和超时机制。流程层是整套系统里“确定性”的保证。第四层是智能编排层Agent 就在这里。它负责理解用户的目标结合上下文判断这个问题应该查知识库还是走某个固定流程还是直接调用某个 API。它像一个交通枢纽把请求分流到正确的轨道上。这四层从上到下是调用关系Agent 在顶层它指挥下面各层干活。反过来从下到上又是被依赖关系模型层和知识层越扎实上层的 Agent 就越不容易失控。2.2 技术选型不要只看热度要看匹配度技术选型这一块我们踩的坑最多先说结论优先选择你自己团队能够驾驭的体系而不是网上讨论热度最高的那套。编排框架方面市面上主流的方案大致分两类。一类偏确定性执行适合流程高度固定的场景设计上像画流程图节点之间线性或分支连接排错很容易另一类偏智能体自主决策适合路径开放的场景但这也意味着结果的可控性更低。我们的选择是两者都保留通过统一的抽象接口切换。向量库选型要结合数据量来看。百万级以内的文档片段主流开源向量库完全够用部署运维成本也不高如果到了千万级以上才需要考虑分布式方案。另外不要忽略一个细节企业文档往往需要跟结构化数据混合查询比如“找出上季度销售额超过 X 的产品同时匹配相关说明文档”所以向量库对过滤条件、标量字段的支持能力往往比检索速度更重要。模型选型还要考虑“大模型小模型”的组合。复杂推理、任务规划用能力强的通用大模型文本分类、实体抽取、意图识别这种重复性高的活用一个小的开源模型或者调用低成本的专用模型接口效果不差成本却能低一个数量级。这个组合省下来的钱够覆盖整个 RAG 基础设施的运维成本。2.3 有一条核心原则确定性优先智能只在必要处分岔这是整套架构里我认为最重要的判断原则能用规则解决的不要用模型能用 Workflow 固化的不要交给 Agent 自由发挥只有那些确实需要理解上下文、动态决策的环节才值得引入 Agent。为什么这么强调因为企业环境里一次错误的自动化操作带来的损失可能远超十次人工操作的失误。模型天然带有不确定性我们再怎么调优它仍然是一个概率系统。而 Workflow 是确定性的逻辑写死了就是写死了跑一千次都一个样。所以正确的做法是把业务拆开能用代码写清楚的部分用代码能用流程编排固化的部分用流程把 Agent 的智能用在那些“必须看懂才能决策”的窄缝里。这样设计还有个额外好处排查问题快。一旦某个环节出错你可以先检查流程是否正常再检查 Agent 的决策是否合理最后检查模型输出是否偏差。如果所有地方都是黑盒出了问题根本无从下手。3. 核心环节实现细节这三块肉必须分别做熟3.1 RAG 建设决定回答质量上限的基础工程很多人以为 RAG 就是“文档丢进向量库检索完拼给大模型”实际落地远没那么简单。第一道坎是文档解析。企业内部大量文档是 PDF、扫描件、Excel、PPT还有那种排版复杂的制度文件解析出来经常是多栏错乱、表格丢失、页眉页脚混入正文。我们的经验是先做版面分析把标题、段落、表格、图表区域分割出来再逐块提取文本表格转成 Markdown 结构保留行列信息。第二道坎是文档切分。切得太粗检索时相关性稀释严重答案不够精准切得太细语义被切断关键上下文丢失。我们一般按“语义段落 递归字符切分”结合的方式做先识别文档里的标题层级把文档切成若干二级章节每个章节内部再按 300~500 字左右的粒度递归切分chunk 之间保留少量重叠。这个参数不会一上来就调好需要拿真实测试集反复验证。第三道坎是召回和重排。向量检索是第一步它负责把候选片段捞回来但召回结果并不总是适合直接作为答案。我们会在向量检索之后加一层重排模型对候选片段按语义相关性重新排序取 Top3 送入大模型。这样一个简单的重排步骤回答命中率能提升 10 到 20 个百分点是我推荐优先投入的一环。还有一件事必须做引用溯源。RAG 的回答必须带上出处文档和原文位置方便用户点击核对。不是所有场景都硬性需要但企业内使用几乎必不可少——这既是让用户信任 AI 的有效手段也是异常排查时定位问题的关键链路。检索不到、检索乱、检索到但答案拼接错误这些问题靠引用都能更快定位。3.2 Workflow 落地把“确定性”变成系统能力Workflow 的核心价值是固化所以设计上重点考虑三件事节点的粒度、人工审批的位置、异常时的回退策略。节点粒度方面一个流程节点不宜做得过大。比如“生成报销单”这个动作如果做成一个节点逻辑里同时包含查历史报销、填金额、校验发票、生成 PDF出错了你很难判断到底是哪一步出了问题。正确的做法是拆成“查历史”“填单”“校验”“生成文件”四个节点每步独立记录日志和状态。人工审批节点在 Workflow 里必须保留。很多团队为了“智能化”把所有环节全自动结果出现错误后成本极高。我们的原则是影响资金流出、对外承诺、数据删除这三类高风险操作必须插入人工确认节点。AI 可以做一切准备工作和草拟工作但最终确认按钮一定是要有人按的。状态存储和幂等性容易被低估。流程一旦跑起来涉及的节点可能有十几个期间系统重启、接口超时、消息丢失都可能导致流程中断。建议每个流程实例都有独立的持久化状态记录每个被调用的外部接口都要支持幂等重试。简单来说就是“同一个请求重复提交不会产生两个后果”。我们曾因为没做好幂等一次网络抖动导致用户收到了两条内容相同的审批通知审批人点了两次系统里出现两笔重复工单处理起来非常狼狈。3.3 Agent 编排给智能套上缰绳Agent 部分的实现重点不在于模型多聪明而在于边界和控制。我们从三个层面控制 Agent 行为。工具定义要非常“窄”。每个工具就是 Agent 能调用的一个 API描述里写清楚它的功能、输入参数格式、适用场景和限制条件。工具的描述越精确Agent 越不会乱来。比如一个工具叫“查询员工余额”描述里要写“仅适用于查询在职员工的话费账户余额不要用于查询报销余额”否则模型很可能把相关但不同的业务混在一起调用。规划循环要设上限。Agent 在执行任务时通常会经历“思考-调用工具-观察结果-再思考”这个循环。我们建议把单次任务的循环次数上限设为 5~8 次超过上限自动终止并转入人工处理防止模型陷入死循环或者在没有结果的路径上白白消耗。这个数字要根据任务复杂度调整但一定不能设成无限次。护栏方面我们加入了敏感动作拦截和定期审计两个机制。Agent 的每一次工具调用都会记录在案形成日志流高风险动作比如发送对外邮件、修改财务数据在调用前会触发规则引擎二次校验不符合预设规则直接拒绝执行。简单说Agent 就像新入职的员工能力强可以有但权限边界先给画清楚所有动作都要有日志可查。3.4 三者如何打通调用链决定体验三块能力分别建设完之后真正的挑战是怎么把它们拧成一条完整的调用链。我们的实践模式是“Agent 做网关Workflow 做主干RAG 做支路”。举一个售前咨询场景的例子。客户在官网提问“某型号设备支持的最高工作温度是多少”请求先进到 AgentAgent 识别出这是一个产品参数问题不需要走流程直接到 RAG 检索产品手册检索到相关片段后生成回答附带手册页码。客户接着问“我想订购 50 台需要什么审批流程”Agent 判断这是一个商机流程调用 Workflow 创建一个售前商机单预填客户信息和需求类型然后通知销售跟进。整个过程中Agent 像路由器一样把不同意图的请求分发到不同通路而 Workflow 和 RAG 各自只关注自己的执行。这样的分层设计还带来一个好处每一段能力都可以独立测试和升级。RAG 换了切分策略不影响流程执行Workflow 加了审批节点也不用重写 Agent 逻辑维护成本和故障半径都大大缩小。4. 实战踩坑记录这些坑我们替你们先踩了4.1 知识库“脏数据”让 RAG 效果全线崩溃我们在一个项目里出现过很典型的情况向量库里塞进了大量重复版本的历史文件比如同一份制度文件修订了五次老版、新版、修订说明版都在库里。检索时系统经常召回旧版内容回答出来的政策和企业现行标准完全相反用户信任度断崖式下跌。排查过程很痛苦最后定位到根源是知识库准入机制缺失。我们立刻做了三件事第一建立文档版本管理以最新生效版本为准入库旧版本彻底下线并加入禁用名单第二增加入库前的内容审核节点包括格式校验、敏感词过滤、重复率检测第三建立定期巡检机制每两周抽查一次知识库对比原始文档确认一致性。修复之后回答准确率明显回升。这个教训让我明白RAG 系统的天花板不是模型是知识库的治理水平。4.2 Workflow 过度编排导致“简单事情跑半天”另一个项目里我们把一个内部请假流程做了非常精细的编排自动校验假期余额、自动计算薪资影响、自动通知三方、自动生成日报、自动更新日历前前后后 12 个节点看起来很大而全。实测效果却很糟糕一次请假审批从发起到结束平均耗时 3 分钟远超之前人工操作几十秒。问题在于编排粒度过度精细化每个节点都要经过完整的事件总线、消息队列、外部接口调用网络开销和排队耗时被无意义放大。后来我们做了性能剖析发现大量时间消耗在“不需要异步同步处理”的环节上于是合并了其中 6 个节点把纯计算类节点改为进程内同步调用外部通知改为异步批量发送整体耗时降到了 15 秒以内。4.3 Agent 的“聪明反被聪明误”自由度越高越容易翻车Agent 在自由规划时的失控主要体现在三个表现上一是跳过必要的确认环节直接执行了高风险操作二是在某条错误路径上反复重试浪费资源三是把不同场景的工具混用产生严重逻辑错误。我们的修复方案不是“把 Agent 变笨”而是给它加约束。给工具调用增加了白名单校验不在白名单内的动作一律拒绝给规划过程增加了“前置条件检查”的强制步骤每次调用高风险工具前先自查是否符合权限和规则最后还加了一个兜底机制允许用户随时打断输入对 Agent 说“不对你走错方向了”系统会立即停止当前执行退回上一步让人工介入。4.4 Token 成本失控AI 用得越爽账单越吓人没有预算管控之前我们的一个测试环境每个月 Token 费用高得出乎意料。排查发现两个主要来源一是 Agent 规划循环中反复调用大模型每次失败重试都会重新计入 Token二是 RAG 系统把许多不必要的内容拼进了上下文导致输入 Token 激增。对策分三个方向第一在规划循环里增加智能收敛如果上一步工具已经返回了足够信息就不再调用下一次大模型推理第二优先调用小模型完成意图识别、实体抽取等简单任务只有最终生成和复杂规划才调用大模型第三对所有模型调用做预算看看板按业务线设置月度 Token 限额超限自动降级到人工处理。这套成本治理之后整体模型成本下降了约 40%同时业务效果没有明显退化。下表是我们整理的常见问题速查表可以直接保存问题表现可能原因优先排查方向回答内容旧、与现行制度不符知识库中存在多版本文档检查知识库版本管理机制检索结果相关但答案还是错重排环节缺失或模型选择不当检查重排模型和 TopK 参数流程执行缓慢编排节点过多、虚假异步做性能剖析合并无关节点流程中断无法恢复缺少持久化状态和幂等机制补状态记录和幂等重试Agent 调用错误工具工具描述不清晰、缺少白名单重新编写工具描述加校验费用异常上涨规划循环无上限、小任务用大模型设循环上限分层使用模型5. 给准备上马的团队落地路线与启动建议5.1 第一步先跑通一个最小闭环不要一开始就铺大平台我见过很多团队一上来就规划“企业统一 AI 中台”各种组件齐上阵做了半年连一个业务场景都没跑通。这种做法的风险在于你还没有一个真实场景来验证架构合理性却已经背负了巨大的建设成本。更务实的路线是选一个足够典型、影响面可控、数据条件好的场景快速做出端到端闭环。哪怕场景很小比如“IT 工单智能分派”或者“销售合同问答”也能把 RAG 建设、Workflow 编排、Agent 调度这三块核心能力全部跑一遍。跑通之后团队对整套体系有了真实的体感再复制到其他场景就有了可复用的底座。5.2 第二步从高频低危场景切入逐步建立信任场景优先级很难拍脑袋定我们的推荐排序原则是“高频、低危、数据全”。高频保证团队持续用、持续发现问题低危保证初期出错了代价不大数据全保证 RAG 有足够的原料避免一开始就去啃“数据清洗”的硬骨头。适合做切入的场景包括内部制度问答、报销流程答疑、常见故障排查辅助、销售物料生成等。暂时不建议一上来就碰直接操作资金的场景、面向外部客户承诺的场景、涉及法律或医疗结论的场景。这些场景需要在系统稳定运行、护栏机制完善之后再审慎引入。5.3 第三步把评估体系建起来再谈优化没有评估体系的 AI 项目优化无从谈起。我们内部建立的是一套“三层评估”第一层评测回答准确性用一批标注好的测试问题检查回答是否命中标准答案、引用是否完整第二层评测流程有效率看端到端完成时间、人工介入次数、异常中断率第三层评测业务收益看单次处理成本、用户满意度、处理量上限。这套评估体系每两周跑一次结果全部记录成表格任何一次模型替换、切分策略调整、流程节点变更都必须拿评估结果说话。我个人的体会是企业 AI 落地最大的风险其实不是技术做不出来而是做完了一团黑既说不清好不好也说不清为什么好最后只能靠玄学维护。评估体系就是打破玄学的那把尺子。最后再分享一点个人体会。RAG、Workflow、Agent 这个组合本质上不是什么高深的算法创新而是把“知识、流程、智能”三件事在企业环境里重新组织了一遍让大模型从一个只会聊天的工具变成一个能干活、可审计、能负责的协作对象。不同行业的落地路径会不同但骨架和原则是相通的。只要记住一条不要追求算法最强要追求流程最稳不要把一切都交给智能要让确定性先兜底。这套东西才能真正从演示走向生产。
阅读完成 · 觉得有帮助？
