企业官网建设流程全解析

做Agent工程化落地这几年，我一直保留一个习惯：每过一个季度，就把线上维护的Agent清单拉出来，逐个问一遍——这个模块，真的非用Agent不可吗？听起来有点反直觉，毕竟现在整个行业都在说Agent要取代Workflow，好像不用Agent就显得不够“智能”。但上季度我做的一次改造，彻底改变了我对这两者关系的认知：把一个智能问答Agent改回了以显式流程为骨架、让大模型只在局部做判断的Workflow，整体调用成本下降了近七成，平均响应时间从7秒多一路降到600毫秒以内，线上错误率反而更低。这个结果让我想清楚了一件事——Agent和Workflow从来就不是替代关系，它们是两把用途完全不同的工具，选错了工具，再聪明的模型也扛不住工程成本和稳定性压力。

这篇文章想把这套判断思路完整梳理一遍：什么信号出现时，你应该考虑从Agent回退到Workflow；如果决定回退，怎么做得平滑、不损失太多智能性；以及我从一次真实改造里得到的数据和避坑经验。如果你正在做Agent类项目，或者正被大模型调用的成本和不稳定表现折磨，这篇文章大概率能给你一个更清晰的决策框架。

1. 为什么要把“越聪明的模块”换回“越笨的流程”

很多团队在立项时会有一个潜意识：Agent听起来比Workflow高级，用Agent来做核心链路，技术含量高、演示效果好。但工程化不是做演示，你得把可靠性、成本、延迟、可维护性都摆到桌面上一起算账。

1.1 三个容易失控的工程信号

我在多个Agent项目中观察到，当一个Agent系统开始失控，通常会提前释放三个信号。

第一个信号是同一类问题反复出现不同的处理路径。比如用户问“订单怎么退款”，Agent有时候直接走退款接口，有时候反问用户原因，有时候建议人工客服。从产品角度讲，这不算错，但从工程角度看，你根本没法预测下一个用户会遇到哪条路径，测试用例写不全，线上故障无法复现。

第二个信号是每次Agent自主调用的外部接口数量和顺序都不固定。用户在对话里说了三句话，Agent可能判断需要查库存、查物流、查优惠券，然后连续调用三个接口；下一次同样的话，它可能只调了一个接口就输出答案。这种不确定性在演示环境没问题，但在生产环境会带来灾难性的对账问题和接口限流问题。

第三个信号是模型稍微一升级，行为就明显漂移。大模型版本升级后，Prompt没动，但Agent对某个意图的判定从“直接处理”变成“反复确认”，链条整体变慢，用户投诉上升。这类问题排查起来极其痛苦，因为你完全不知道模型哪一次内部推理会改变路径。

1.2 成本和延迟的微观账本

很多人低估了Agent的单次成本。Agent类任务往往是多轮推理，每完成一个子任务就要调用一次大模型，有些框架还会为了“反思”额外调用两三次。假设一个任务平均调用大模型4次，每次消耗约8000个token，按某个主流大模型的定价折算，一次完整Agent任务的成本大概是纯Workflow方案的3到5倍。

延迟更是肉眼可见的差距。Agent在系统1完成推断后，要决定下一步调用什么工具，这个决定本身又是一次大模型调用。一次链式循环，延迟是成倍叠加的。我实测过一组数据：同样的“查订单状态”任务，走Agent方案平均耗时7.8秒，走规则路由加工厂模式的Workflow只需要0.5秒左右。对C端用户来说，7.8秒已经足够让人流失了。

1.3 一切问题的共同根源

把上面这些信号和成本问题归因到底，共同根源只有一句话：Agent把决策权外包给了大模型。大模型擅长的是开放域语义理解，但它并不擅长严格遵守业务规则、边界约束和成本预算。你越是把过程自由度交给它，它就越容易钻出你预设的笼子。

而Workflow的本质是用确定性对抗不确定性。业务流程的骨架是明确写死的，每一步做什么、调用什么接口、失败后走哪个分支，都由开发者在代码里定义。大模型只在特定节点上做填空式的判断，比如判断用户意图属于哪个分类、提取哪些关键词，而不是自由规划整个链路。这样一来，不管你换什么模型，业务主干的稳定性都有保障。

这也是为什么我现在的主导观点变了：不是“能用Agent就用Agent”，而是“凡是能用规则表达清楚的，就绝对不用Agent来承担决策；凡是需要开放语义理解和内容生成的，再用Agent去补位”。

2. 什么时候应该改回 Workflow：五个核心判断指标

每个团队的具体业务不一样，不能拍脑袋决定“这个该用Agent”或“这个该用Workflow”。我把自己做决策时参考的指标整理成了五个维度，你可以把每个维度看作一票否决项。

2.1 指标一：意图空间是否收敛

这一条最重要。你要问自己：这个业务场景里，用户可能的意图到底是有穷的，还是无穷的？

如果一个客服机器人处理的业务只有查询订单、申请退款、修改地址、开发票、人工投诉这几类，那意图空间就是收敛的。收敛的意图空间，天然适合做意图识别模型或者规则引擎，直接把每个意图映射到固定流程即可。反过来，如果用户可能提出任何问题，产品不预设边界，比如“企业知识库问答”，意图空间是近乎无限的，这个时候Agent才有发挥空间。

判断意图空间收敛与否有个很简单的实操方法：把线上历史对话拉出来，统计前10个意图占全部对话的比例。如果前10个意图占了95%以上，那几乎可以确定这个业务适合用Workflow；如果占比在70%以下，且长尾模糊问题很多，那么保留Agent才有必要。

2.2 指标二：对确定性的底线要求

有些业务可以接受“一次答错再追问”，有些业务完全不能接受。

举个例子，如果你的Agent在做营销文案生成，输出有点跑偏，用户重新生成一次就是了，代价很低。但如果你的Agent在控制一个自动化运维动作，比如根据监控日志自主重启服务、动态扩容，那一次幻觉就可能导致事故。这类对结果有强约束的业务，必须把决策流程从模型手里拿回来，放到规则和人工审批链路上。

我之前遇过一个团队做的运维助手，用Agent自主判断是否执行某个变更操作，结果模型在理由不充分的情况下连续触发两次变更，差点出问题。后来改成“监控指标触发规则 → 候选操作生成（用LLM辅助建议） → 人审批 → 执行”，本质上是一个带LLM辅助的Workflow，模型只能建议，不能决定。

这里我有一个明确的经验总结：如果业务结果不可逆、会造成实际损失，不要允许模型在主干上做决策，最多让它在辅助节点输出建议。

2.3 指标三：外部依赖的契约化程度

Agent的一大常见能力是调外部工具或API。如果外部接口是稳定的、契约明确的，比如查询天气API、查航班状态、调用公司内部订单接口，那这些接口的正确使用方法其实是可以写成代码的。

Workflow的优势在于接口调用顺序和重试策略都能被精确控制。而Agent调用接口时，返回结果一复杂，它往往会在下一步推理中“脑补”一些接口里根本没有的字段，这是大模型的常见幻觉场景之一。外部依赖越关键、接口契约越严格，越应该用Workflow把调用过程固定下来。

反过来说，如果你的外部知识源本身是非结构化的，比如一堆PDF、PPT、在线文档，没法用固定接口获取，必须靠模型抽取和理解，那么这部分做成Agent或者RAG链路会更合理。

2.4 指标四：响应时间与成本的资源预算

这个指标特别现实。你首先要定义一个约束：一次完整交互的响应时间预算和单次成本预算。

我先给一个参考测算思路。假设产品容忍的响应时间是3秒，一次Agent任务如果要做三步推理加一次外部调用，每个推理步骤按1.5秒估算，很可能就超了。这时候就不能让Agent自由探索，必须把主干改成Workflow，把一些环节合并或改成规则化处理。

成本预算就更直接了。如果你的商业模式是订阅制，每个用户每月付费几十元，那一个高频使用的Agent一天可能跑几十次，光模型调用费就能吃掉大量利润。我当时算过一笔账：某个Agent日均调用10万次，单次成本0.2元，一天就是2万元，一个月60万元；改成Workflow后，单次成本降到0.03元，一个月只要9万元。省下来的钱完全可以覆盖更好的模型或者更多人力投入。

2.5 指标五：团队的调试与可观测能力

如果出现问题，你能不能在短时间内定位原因？对于Agent系统，这个问题的答案往往是否定的，因为模型内部的推理路径是不可枚举的。你可能知道它调用了哪些工具，但很难知道它为什么选择调用这些工具，更难复现。

而Workflow的调试是确定的：它走了哪个分支、哪一步返回值异常、哪个字段缺失，全都记录在日志里。如果团队没有专门的算法工程师或者足够的模型调优经验，我强烈建议在关键业务链路上选Workflow，把技术风险压到最低。

3. 如何平滑地从 Agent 切换到 Workflow：分级降级的落地步骤

一旦你决定回退，不要直接一刀切把所有Agent模块都删掉。正确姿势是分级降级，把确定性链路沉淀下来，把模型的自由度收缩到最小必要范围。下面是我验证过比较顺畅的三个步骤。

3.1 第一步：把 Agent 的决策日志沉淀成流程样本

Agent在线上跑了一段时间，它的日志里其实积累了大量的决策样本。这是最好的流程设计素材。你需要从日志里提取的信息包括：每个任务实际走了哪几步、每一步调用了哪些工具、哪些步骤在90%以上的任务中都会出现、哪些步骤是偶发的。

我当时做客服Agent改造时，先把3000多条线上日志结构化，然后用统计方法归纳出高频链路。结果发现，80%以上的会话集中在五条主要路径里：订单查询、物流查询、退款申请、发票申请、转人工。这五条路径中的共同步骤也高度相似：识别意图、提取订单号、查询订单状态、生成答案。

这些高度相似沿着主干流程的步骤，就是你可以转换成Workflow的候选节点。逻辑很简单——如果连模型自己都总是走同一条路，那说明这条路根本不需要模型来选，你直接把它画成流程图就行了。

3.2 第二步：用确定性模块替换高频链路

第二步是把识别出来的高复用链路替换成确定的规则代码。这里并不需要引入多么复杂的工作流引擎，最简单的就是状态机，或者一个带步骤标记的代码逻辑。

以客服场景为例，我改造后的核心流程长这样：用户发消息后，先进意图分类模型（可以用小模型，也可以让大模型做一次极短的分类调用），分出意图后进入对应的处理流程。每个流程有严格的先后顺序：先校验有没有登录，再提取订单号，再调用订单查询接口，最后把接口返回的JSON组装成话术。整个过程没有任何一个环节需要模型去决定“下一步做什么”。

值得说明的是，这个阶段不要完全移除大模型。大模型在Workflow里依然有位置，但它的角色从“驾驶员”变成了“零部件”。比如意图分类这一步，完全可以用大模型来做；订单号提取也可以用大模型做；话术组织和润色也可以让大模型做。真正的变化是：模型不再拥有流程控制权。

3.3 第三步：保留“兜底 Agent”作为逃生舱

总有一些长尾问题是你没覆盖到的。就算前10个意图占了95%的流量，剩下5%的问题依然需要处理。我的做法是给Workflow一个默认出口：当规则路由无法匹配任何已知意图时，把会话降级到Agent模式，让模型自由处理，同时给出“该问题可能需要人工介入”的提示。

这个兜底Agent的开支其实是可控的。因为5%的流量占比很低，它对整体成本和延迟的影响很小，但它能保证系统不会因为误判而把用户晾在原地。这个机制类似于保险丝：正常电流走主线路，异常电流触发熔断保护，但整个系统不会因为异常而瘫痪。

在推进降级改造时，我建议先灰度跑两到四周。把新Workflow和旧Agent放在同一流量下对比，观察成功率、转人工率、用户满意度等指标。如果Workflow的表现不低于Agent，再逐步切流量；如果某些分支波动明显，就把这些分支重新放回Agent兜底，做局部分层。

3.4 混合架构的经典模式

现在我已经很少写纯Agent或者纯Workflow了，大多数项目的最终形态是混合架构：上层用规则和路由做主干，中层用大模型做语义理解，底层用Agent兜底处理开放域问题。

一个比较典型的混合分层长这样：最外层是意图路由器，把请求分配到不同业务子链；子链内部是明确的Workflow，步骤固定，调用稳定接口；如果某一步的参数提取失败，或者流程无法继续，就尝试让大模型做一次补充理解；如果最终还是失败，就进入人工或者兜底Agent。这套模式兼顾了稳定性、成本和智能性，也是我现在在新项目里的默认架构。

4. 一个真实的改造案例：客服 Agent 改回 Workflow 的完整复盘

光讲理论太虚了，分享一个我实际参与过的改造项目，匿掉敏感信息后，整个过程很有参考价值。

4.1 改造前的问题表现

某公司的对外客服系统，业务是帮用户处理订单、物流、退换货、发票等电商售后问题。第一版把整个客服机器人做成了Agent方案，底层是大模型，可以调用订单查询、物流查询、售后单创建等业内系统接口。

上线第一周效果还行，用户自由表达，Agent理解得不错。但两周后问题开始集中暴露。一是订单类重复问题的回答路径经常变，用户问“东西到哪了”，Agent有时只给物流信息，有时同时查订单状态和物流信息，答案内容不统一；二是高峰期成本飙升，客服量一大，模型调用量线性上涨，账单非常难看；三是偶尔会出现幻觉，比如把已签收的订单回复成“配送中”，用户投诉压力很大。

从数据上看，那时的成功率虽然也有将近90%，但剩下10%的问题里，有将近一半是可以通过固定流程避免的低级错误。为了那10%的“自由探索能力”，团队承担了高成本、高延迟、不可复现的多重代价。

4.2 改造后的流程设计

我们做了一套四级流水线，替换掉原来“Agent自由规划”的模式：

第一步，用分类模型判断用户意图，类别设定为10个高频意图加1个兜底意图。这一步的准确率做到95%以上并不难，关键是样本要覆盖足够多的话术变体。

第二步，根据意图映射到对应的业务子流程。每个子流程是固定的多步操作。以物流查询为例，固定路径是：提取订单号 → 校验用户身份 → 调用物流接口 → 解析返回结果 → 组装话术。所有分支都有显式定义，不会跑偏。

第三步，每子流程内只设少量模型调用点，用于提取参数和润色回复。提取订单号时，把历史订单列表作为候选，让模型做选择，而不是让模型认任一串数字。这种“候选排序”式的用法比“开放生成”式的用法稳定得多。

第四步，如果10个意图都没有命中，或参数提取连续失败，才进入Agent兜底链路，交给大模型自由处理，同时附带一个“可能需转人工”的提示。

4.3 改造关键数据对比

这是这次改造里最让我觉得震撼的部分。改造前后同一周维度的数据对比：

首轮解决率提升其实在意料之外。后来分析，原因是固定流程保证了每个关键步骤都不会遗漏。Agent可能因为推理步骤太随意，有时候跳过校验直接给答案；Workflow则强制先把身份校验、订单校验跑完，再进入结果输出，出错率自然下降。

这个案例对团队最大的启发是：Agent化并没有让业务变“智能”，它只是给业务增加了更多不可控的自由度。消费者想要的只是准确、快速地解决自己的问题，而不是看模型展示推理过程。

4.4 复盘中的三个意外收获

第一个意外收获是，改造完之后，Prompt管理变得简单多了。过去在一个Agent里塞一堆工具描述和约束规则，现在每个子流程的Prompt很精简，调整某个环节不会动摇其他环节。

第二个意外收获是，排障效率明显提升。以前用户投诉答错了，根本提供不出路径日志。现在每一条回复都有明确的流程标记：走的是哪个意图分支、提取到什么参数、调用了哪个接口。出问题可以精准定位到具体节点。

第三个意外收获是，团队里非算法背景的同事也能参与优化了。Workflow的分支逻辑和异常处理是工程问题，前端、后端同学都能改。此前Agent的决策逻辑几乎只有算法同学能调，整个人力瓶颈一下子被打通了。

5. 我总结的决策清单与避坑心得

如果把整个思路压缩成一张可以随时拿出来对表的判断清单，那么大概是下面这个版本。

5.1 一张可执行的判断表

这一条我在多个项目里反复验证：不要因为“用了Agent”而自豪，要因为“系统稳定又便宜”而自豪。架构的合理性永远以业务结果为准。好用的Agent有时候正是那些看起来一点都不“Agent”的Workflow。

5.2 复盘过程中最真实的几个经验教训

第一个教训是，改的时候不要一次性把所有流量切过去。我们第一次灰度只切了5%流量，跑了两天发现一些边缘意图还是有问题，又花了几天调整分支，才逐步放到30%、50%、100%。如果当时直接全量切换，很可能引发一大波客服事故。

第二个教训是，兜底Agent的Prompt不要跟原版一模一样。原版Agent Prompt是面向自由规划的，讲究给足上下文、给足工具列表。兜底Agent面对的已经是“规则链路无法处理”的残局，Prompt应该强调“先澄清用户需求，再尝试解答”，而不是急着调工具。

第三个教训是，流程日志要从改造第一天就规范化。改造时我们同步把日志打印格式统一了，每个节点输出结构化JSON，包含意图标签、参数置信度、接口返回码。这对后期数据分析、效果迭代帮助巨大。日志不规范，复盘就全靠记忆，等于瞎搞。

5.3 最后分享一条小技巧

如果你正拿不准一个模块到底要不要从Agent改回Workflow，有一个快速低成本预判法：找20条典型线上问题，手写一个伪代码级别的流程图，看能不能在不借助大模型的情况下把这20条问题全部“翻译”成确定的分支逻辑。如果能，就说明这个问题域的规则强度足够高，Workflow大概率是更合适的方案；如果写到一半发现分支太多、条件太细，根本没法画完，再考虑用Agent来吃掉这部分复杂性。

这个方法我用了很多次，准确率相当高，而且整体花费不到一个小时，比争论哪种架构更先进有意义得多。架构演化是没有终点的，Agent和Workflow的边界也会随着模型能力变化而移动。你唯一要锚定的，是业务目标本身：稳定、便宜、可控、让用户满意。剩下的选型，全都是为这几件事服务的。