企业官网建设流程全解析

1. Workflow 和 Agent 不是代际关系，而是分工关系

1.1 从"记住答案"到"现场答题"：两种范式的本质差异

先说一个我经常遇到的认知偏差：很多团队把 Workflow 当成"上一个时代的东西"，把 Agent 当成"更先进的东西"，于是不管什么需求，一律先上 Agent。这种想法的潜台词是——只要够智能，复杂系统就能自动解决一切问题。但实际工程里做出来的东西往往不是更智能，而是更不可控。

先把两个概念说透。

Workflow 的本质是预定义路径。你写清楚第一步做什么、第二步做什么、什么时候走哪个分支、最终输出什么，每一步都是确定的，数据在节点间以固定的方式流转。它像一条流水线，每个工位做什么是固定的，工人换没换人、今天有没有状态不好，产品出来的结果都大致相同。LLM 在 Workflow 里可以是一个"节点"，也可以只是其中一步偶尔被调用，但整体流程不依赖模型自由发挥。

Agent 的本质是目标驱动的自主决策。系统拿到一个大目标，自己拆解成若干子任务，自己决定调用哪个工具、按什么顺序执行、看到中间结果之后要不要调整计划。它像一个新入职但知识量极大的实习生——方向感不错，但你永远不知道它中间会绕多少弯路，也不知道某个决策失误会造成多大损失，你只知道在最终结果出来之前，过程是不可逐字预见的。

关键区别在这里：**Workflow 卖的是确定性，Agent 卖的是可能性。**你要处理的是确定性强、规则明确的流程，Workflow 又稳又省；你要处理的是开放性强、规则说不清楚的问题，Agent 才有价值。但很多项目用 Agent 不是因为场景需要可能性，而是因为它听起来"高级"。

我在某数据平台项目里见过一个典型案例：一套日报生成系统，本来用 Workflow 写得很好——定时触发、拉数、套模板、推送。后来团队想让输出更有"分析味"，就改成了 Agent 全权处理。结果日报质量忽高忽低，分析角度每次都不同，有时候甚至为了一个数据口径反复调查几轮才生成，运行成本涨了十几倍。最后改回 Workflow + 局部调用的混合方案，只让 Agent 在"洞察生成"这一步做发散，其余全部固定。这才是正确的用法。

1.2 Agent 工程化之后，确定性是稀缺品

我们做工程的人，核心诉求永远是可控、可测、可修。Agent 在这三个维度上都做得不如 Workflow 好，不是因为它不够聪明，而是因为它天然具备概率性。

一个 Agent 系统跑十次，可能十次路径都不一样。路径不一样意味着什么？意味着你没法用传统手段做自动化测试——你写不了"期望调用序列"这种断言。你只能在每次跑完之后观察结果合不合理，但这在工业场景里几乎等于没法验收。

我见过一个更实际的案例：某内部工单处理系统，第一版用 Agent 自动分类、自动派发。分类正确率确实不低，大概 92% 左右，但那个剩下 8% 的错误，恰好集中在最高优先级的几类工单上。某天一个 P0 级事故被 Agent 误判成普通咨询，整整延误了一个多小时。事故复盘时所有人都在反思同一个问题：**我们能不能接受 8% 的错误率？答案是不能，因为错误的代价不是平均代价，而是尾部代价。**后来他们把所有确定性规则全部抽出来做成 Workflow 分类器，把 Agent 限定在"老分类器判断不置信"时做补充，整个系统才真正敢在生产环境跑。

所以我一直跟身边的开发者强调一句话：**如果需求方告诉你"必须稳定、必须一致、必须每次结果都一样"，那大概率该用 Workflow，不是 Agent。**稳定本身就是一种产品体验。很多用户的信任感和满意度，恰恰来自"每次点出来都是同样的结果、同样的流程、同样的耗时"。

2. 太多团队栽在一个错误假设上："Agent 更高级所以更好"

2.1 用 LLM 做 Workflow 也能叫 Agent 吗

写代码的时候大家都烦"岗位名膨胀"，什么高级工程师、资深工程师、首席工程师，到头来干的活可能差不多。Agent 圈也有类似的命名膨胀：很多产品对外说自己用了 Agent，拆开看不过是一次 LLM 调用 + 一个 if-else 分支。这倒不是说不能这么做，而是如果你把 Workflow 误认为 Agent，就很容易在架构决策时被概念带偏。

我见过不止一个团队，PPT 上写着"多 Agent 协作系统"，架构图里三个方框之间画着双向箭头，实际实现是三个 prompt 模板按固定顺序调用，中间没有自主决策、没有工具选择、没有反思机制。这种东西本质上还是 Workflow，只不过恰好用大模型做了某几个节点。没有问题，但如果你以为自己在构建 Agent 系统，就会默认"它自主能力强所以可以少做防御"，结果一上线就露馅。

反过来才麻烦。有些架构真的是 Agent——规划、推理、调用工具、根据结果修正计划，但团队把它当 Workflow 来承诺交付周期和质量指标，比如"今天一定给你上线""这个问题重跑一次就好"。Agent 的不确定性会直接击穿这类承诺。本质上就是用错了管理预期的方式：Workflow 适合做确定性承诺，Agent 只适合做概率性承诺。

我的建议是：开始设计之前，先在产品层面定死一句话——这个模块允许系统出错的概率是多少？如果容忍度低于 1%，不要用 Agent。因为当前模型的可靠性还撑不起这个容忍度。

2.2 三个最常见的过度设计场景

从我的观察看，团队把 Workflow 改成 Agent、最后又默默改回来的场景，主要集中在三种：

**第一种：流程明明可穷举，却加了自由发挥层。**比如报销审批流程：完整流程就是"提交单据 → 校验发票 → 审核金额 → 审批人通过/退回"，每一个分支都清晰，变量极少，Agent 在这里根本没有发挥空间。强行让 Agent 去"理解"一张发票是否合规，只会引入两个新问题——多花 token、偶尔出错。规则引擎能解决的事，非让模型背锅，没有意义。

**第二种：结果要求完全一致，却把生成逻辑交给概率系统。**比如合同审查、报表生成、日志摘要。这些场景用户要的不是"角度新颖"，而是"每次对相同输入给出相同输出"。Agent 的创意在这里就是 bug 而不是 feature。

**第三种：中间过程必须完全留痕审计，但 Agent 的路径不可预知。**一旦出问题，你拿什么跟审计方解释？"模型觉得这一步需要调用外部 API"？在很多监管要求严格的行业，流程可解释、可追溯比流程智能重要得多。

这三类场景，我的诊断结论都一样：**你的自由度是伪需求，你的确定性和可控性是真需求。**一旦确认这一点，改回 Workflow 只是时间问题。

3. 这些信号出现，说明该从 Agent 改回 Workflow 了

很多人问我说怎么判断该不该回头？判断依据其实不是架构本身，而是产品反馈。我总结了五个信号，出现任意三个，我就建议你认真考虑回退方案。

3.1 信号一：用户根本不关心"灵活"，只关心"稳定"

如果用户的真实诉求是"你能不能每次都把这个活干成标准答案"，Agent 的优势就是多余的。做客服机器人的时候我们最清楚：用户问"退货怎么操作"，标准答案是三段流程，你说得再天花乱坠也不如三步固定回复让用户安心。

怎么发现这个信号？拉用户日志看重复问题占比。如果你发现 70% 以上的请求都集中在几个高频模式上，那说明你需要的不是 Agent 的"千人千面"，而是 Workflow 的"千篇一律"。把高频请求抽出来做成 Workflow，Agent 只处理长尾新问题，效果和成本都会大幅改善。

我印象很深的一个案例：某商家后台的帮助系统，第一版用 Agent 回答一切问题，平均回复质量可以但方差极大。一次大促期间，系统同时遇到上千个同类咨询，每个咨询 Agent 都像"第一次见到这个问题"一样从零推理，响应时长直接翻倍，客服总监半夜打电话过来说能不能把回答写死。那一刻我彻底明白了一个道理：在线翼类场景里，一个确定的、平庸的答案，永远好过一个不确定的、偶尔惊艳的答案。

3.2 信号二：错误成本高到无法兜底

Agent 会犯错，这本身不是问题。问题是犯错之后怎么办。

在推荐系统里，Agent 猜错一个偏好，用户刷走换个内容就行，成本极低，Agent 可以放开胆子试。但在订单、支付、质检、医疗、法务、定价这些场景里，一次错误就可能造成不可逆后果。错误成本一旦高到"不能接受概率性失败"，Agent 就不适合做那个最终决定者。

我之前做过的某跨境订单履约系统也踩过类似的坑。最初让 Agent 自动判断"订单异常原因"，模型大部分时候判断得挺准，但偶尔会把"地址不完整"和"恶意订单"混为一谈。这两种判断导致的处理方式完全不同，一个是联系用户补全地址，一个是直接冻结订单。某次误判差点把一个大客户的订单冻结了，客户投诉后我们才意识到：**这类判断的准确率需要做到 99.9% 以上才算合格，而 Agent 目前达不到这个量级。**后来我们把判断逻辑改成了规则优先——先做明确异常的规则判断，规则覆盖不了的才交给 Agent，而且 Agent 的结论只做"建议"不做"决定"，必须经过人工确认兜底。

改动之后系统照样智能，但"智能"被关进了笼子。

3.3 信号三：成本与延迟吃掉业务收益

有一个特别反直觉的事实：很多人以为 Agent 能省人力，但没算清楚 Agent 本身的运行成本。一个 Agent 任务常常要调用模型 5 到 8 次——规划一次、执行一步看结果一次、反思一次、重试一次，这和一次单点调用完全不是一个量级。

拿我们自己做的一个内容分类系统来说，第一版用 Agent 对每条内容做"多步思考再分类"，效果确实比关键词规则好，但成本高了 30 倍，而且因为多次调用模型，延时从 200 毫秒涨到 5 秒。业务方的反馈很直接："准确率提升的幅度，抵不上用户流失的损失。"最后我们的方案是分级处理：简单分类走 Workflow 关键词 + 小模型；只有小模型置信度低的长尾内容才交给 Agent 详细分析。总成本只涨了不到一倍，准确率依然保持在合理范围内。

所以请养成一个习惯：**每次规划 Agent 方案时，顺手算一笔账——整个流程总 token 消耗、平均响应时延、单次失败补偿成本。**如果这三个指标里有两个接近不可控，Agent 方案基本是不划算的。

3.4 信号四：不可复现，排查问题全靠猜

做工程最痛苦的事情就是线上出了问题没法复现。Workflow 系统里，问题大概率在某个固定环节，你按路径排查就行；Agent 系统里，问题可能出在规划、工具选择、参数生成、上下文理解中的任何一环。你甚至不知道它为什么这么选。

举一个我印象很深的例子。某团队做了一个内部数据分析 Agent，用户可以自然语言提问，Agent 自己写 SQL 查数。有一次某个用户反复提同一个问题，结果答案前后矛盾，用户怀疑数据有问题。工程师查日志时发现，两次查询 Agent 生成的 SQL 完全不同，虽然表面上在查同一个指标，但一个用了distinct count，一个用了count，结果自然不一样。

这个问题的根源是 Agent 的自由度——它面对的是同一个请求，但它选择的路径会随机漂移。而用户理解的系统应该具有"同因同果"的基本逻辑。当你的用户问出"为什么这次和上次不一样"的时候，你就要开始考虑收紧自由度了。

Workflow 恰恰在"可复现"上碾压 Agent：同样的输入走同样的路径，产生同样的输出。即使某一步用了模型，也可以通过固定 prompt、固定 temperature 为 0，让输出稳定在可接受范围内。

3.5 信号五：上下文塞满，Agent 其实没有自主决策空间

还有一种情况比较隐蔽：Agent 看起来很自由，但任务本身已经把操作空间挤没了。比如一些工具调用场景，输入只有几个参数，输出只有几个固定选项，Agent 规划的每一步实际上是伪选择——它并没有真正在做"决策"，只是在做"选择一种表达方式"。

如果 Agent 的思考几乎不会改变最终执行路径，那就意味着 Agent 的存在只是增加了 token 开销和出错概率，没有任何收益。这时候你需要的只是"带条件的 Workflow"。

我在做某表单自动填写系统时就有这种体会：最初让 Agent 根据用户输入自动填表，模型每次都长篇大论地解释"为什么这样填"，但说实话，字段映射逻辑已经完全可以写死在代码里。后来直接把映射逻辑做成配置表，Agent 彻底下线，系统从"偶尔聪明偶尔抽风"变成"永远准确、瞬时响应"，用户满意度反而上升了。不要把简单问题包装成复杂问题，这是工程里最贵的虚荣心。

4. 从 Agent 回退到 Workflow 的具体改造路径

如果真的下定决心改回 Workflow，也不是"删掉 Agent 代码"那么简单。直接替换大概率会让系统表现断崖式下降，因为你当初引入 Agent 很可能真的解决了一部分 Workflow 解决不了的长尾问题。正确做法是分层回退、逐步收敛自由度。我分四步走，你可以直接参照。

4.1 先缩小自由度：把"自由对话"收敛为"结构化输入"

Agent 系统最直观的自由度，是让用户随便输入任意文本，系统自己理解意图。回退的第一步，是把入口改为结构化输入——选项尽量提供下拉选择、单选、多选。这样后面所有流程都基于明确的枚举值运转，不会因为一个模糊 input 让模型猜错方向。

这里有一个细节很多人容易忽略：**结构化的入口有时候比模型理解更受用户欢迎。**普通用户面对空白输入框时往往不知道说什么好，反而面对明确的选择题知道怎么下手。某物流客服系统改成"你遇到的问题属于哪一类？A. 查物流 B. 改地址 C. 退货 D. 其他"之后，人均通话时长下降了近三分之一，因为模型之前猜意图还得来回纠偏，现在用户自己给了边界，系统只做后续流程就好。

4.2 固定步骤、明确流转条件

第二步是把你脑海中已经"默认如此"的执行路径画出来：总共分几步，每步输入输出是什么，哪一步有分支，分支条件是什么。这本质上是反向工程——从 Agent 的历史轨迹里提炼常见路径。

具体做法我一般是这样：翻 Agent 日志，把过去一个月跑的路径全部汇总，按出现频次排序。最高频的那几条路径往往就是 Workflow 的主流程。比如月度报告生成任务，Agent 跑了 100 次，有 80 次都在执行"拉数据 → 处理缺失值 → 计算关键指标 → 套用模板 → 生成文案 → 推送"这个顺序，那就把这条链路固化成 Workflow，中间再穿插校验节点。

固定步骤之后要配一套防御逻辑：每一步输出进下一个节点之前，先做格式校验、范围校验、重试机制。Workflow 要认真配异常处理，不然它成了死板链路，一遇到特殊情况就直接崩溃，还不如 Agent 的随机应变扛造。

4.3 保留 Agent 的"逃生通道"：嵌套 Hybrid

说实话，我很少建议团队把 Agent 完全清除。更合理的架构是 Workflow 为主干、Agent 做旁路，只有主干处理不了的情况才把控制权临时交给 Agent。

具体来说，每个 Workflow 节点可以设置一个"置信度阈值"。比如"订单异常判断"节点，规则引擎能直接判定的就直接走；判定不了、置信度低于某个阈值的，把信息打包成一个子任务丢给 Agent 来分析；等 Agent 返回结论后，再回到 Workflow 继续走后续流程。

这种 Hybrid 的好处是：日常任务的确定性有保障，长尾和异常有兜底。更重要的是，它保留了将来调优的空间——如果某类问题 Agent 反复处理得很好，说明它的解决路径已经收敛，你可以再把这段处理逻辑固化成 Workflow 的新节点。

4.4 分阶段灰度替换，别指望一夜完成

最后一步是上线节奏。我自己的经验是：先挑用户感知最弱、错误容忍度最高的模块做试点转换，比如内部的日志分析，而不是直接切用户核心链路。

之前某团队做订单消息通知系统时，把"什么类型订单触发什么文案"这件事从 Agent 改成 Workflow。他们先跑了两周内部灰度，对比历史 Agent 输出的文案质量。对比方式也很简单：让三五个业务同事盲评。结果发现 Workflow 的固定模板虽然缺少花活，但基础信息的覆盖率和准确率是 100%，而 Agent 偶尔会在文案里加入主观推断，导致用户误解。两周灰度确认了 Workflow 更可靠，他们才全量切换。整个过程没有收到一例用户投诉。

这个节奏很重要，它能斩断团队内部"万一改出问题怎么办"的顾虑，用数据说话。

5. 灰色地带：如何判断是"优化问题"还是"选型问题"

5.1 先分清是 Agent 太笨还是场景不适合

当一个 Agent 系统效果不好时，第一反应都是"模型的 prompt 是不是没写好""工具调用是不是没调好"。这类优化确实有效，但有效范围有限。我更建议先问一个更基础的问题：这个场景里，Agent 的自主性到底创造了价值，还是制造了风险？

判断方法很简单：把 Agent 从系统里拿掉，改用一套最朴素的 if-else 骨架来模拟同样的任务处理逻辑，看看效果差距有多大。如果差距很小，说明问题简化为"加规则"而不是"靠模型"，场景本身并不适合 Agent。如果骨架完全无法处理，那才值得继续投入 Agent 方向。

我做过的一个小实验也印证了这点。某内容审核辅助系统，最初用 Agent 判断"哪些评论需要人工复核"。一次实验中把 Agent 换成一个简单的规则集——命中敏感词或者长度超过阈值就标记复核，结果召回率只下降了三个百分点，但成本降了二十多倍。所以别急着优化模型，先分辨问题出在"智能性"还是"场景适配性"。

5.2 试探性降级：从局部模块开始动刀

如果你拿不准整个系统该不该改回 Workflow，我的建议是不要整个推翻，选一个薄弱模块做试探。比如 Agent 系统里最不稳定、投诉最多、错误最集中的那个环节，把它独立出来打成 Workflow 模块，跑一段时间看效果。

这种方式能帮你收集到一手数据：降级前后这个模块的成功率、响应时间、用户投诉量、人工介入率。有了这些数据，决策就有了依据，不再是"我觉得该改"或"我觉得不该改"的情绪投票。

某图片理解系统就是这么做过渡的：最初全链路 Agent，用户上传一张图，Agent 识别、归类、打标签、配文案。后来发现打标签环节总出幺蛾子，就把打标签独立成 Workflow——固定用某分类模型，加一套标签校正规则。效果立刻明确：标签准确率上升、耗时下降、用户满意度提升。这一步成功后，他们又陆续把文案生成等环节逐个实验，能固化的固化，不能固化的保留 Agent。

5.3 决策清单：一张可以直接抄的判断表

很多人问有没有"一张表就能做决策"的方法。我整理了一份清单，你可以按顺序自查。

这套判断表不是万能公式，但它能帮你把情绪化的争论拉回理性轨道。我看到太多团队在例会里争论"Agent 是不是更好"吵不出结果，核心原因就是大家没有在同一组维度上讨论问题。把所有争论换成具体指标——是否可枚举、是否要求一致、是否允许概率性失败、是否在意成本，结论自然就出来了。

最后再说一个我个人深有体会的观点：Agent 和 Workflow 并不是"先进"和"落后"的竞争，它们只是解决不同约束的两种工具。工程上最怕的不是技术不够新，而是把不合适的工具硬吹到合适的份上。每次回退到 Workflow，背后几乎都是同一个原因——团队的确定性需求最终压倒了探索需求。能尽早识别这种需求变化并及时调整架构，比坚持"用上新东西"重要得多。