企业官网建设流程全解析

直接进入正文。

1. 先搞清楚三者的本质区别，才不会选错

去年帮某公司做客服系统智能化改造面试了一个刚从大厂出来的研发，他开口闭口都是“用Agent把所有流程重构一遍”。我问他客服退款场景怎么设计，他说“让Agent自己去调用退款接口就行”。我当场就让他回去了——退款接口如果被大模型理解错了参数，谁来赔这笔钱？

这不是个例。现在很多人把“Agent”当成万金油，什么需求都往上套，结果项目烂尾、成本失控、用户骂产品智障。问题的根源在于：大多数人对“普通对话、工作流、Agent”这三者的适用边界根本没有概念。它们不是同一技术路线的高低配，而是三种完全不同的架构范式，选错了解法，后面所有的工作都是白费。

先给一个最简单的框架，方便你快速对号入座：

• 普通对话：一次一问一答，无状态，不需要调用外部系统，答案好不好全看模型本身。
• 工作流：预先把步骤写死，每一步做什么、需要哪些输入、调用什么接口、产出什么结果，全部在代码里定义好，大模型只是流水线上的一颗螺丝钉。
• Agent：你自己不写死步骤，只给一个目标，让模型在运行的时候自己“思考”先做什么、后做什么、用什么工具，每一步做完看结果再决定下一步。

一句话总结：普通对话是“问答应答机”，工作流是“按图纸盖楼”， Agent是“给个目标让施工队自己想办法”。

记住这个区别之后，下面所有的选型判断才有讨论基础。

2. 需求稳定性决定了你是“写死”还是“让模型自由发挥”

判断该用工作流还是Agent，第一个硬指标是：这个任务的处理步骤是不是确定的？

2.1 给模型“写剧本”和“给目标”是两套玩法

我常拿订机票来举例。用户说“帮我订一张后天从北京到上海的机票，越早越好”。

• 如果用工作流：你事先定好步骤——第一步提取出发地、目的地、日期、舱位偏好；第二步调用航班查询接口；第三步把结果排好序展示；第四步如果用户确认，调下单接口；第五步返回订单信息。大模型在这里扮演的角色很有限：它只负责把用户的自然语言解析成结构化参数，剩下的逻辑全是代码在驱动。

• 如果用Agent：你把任务目标“订一张后天北京到上海的机票”丢给它，它在运行时可能要自己决定“我应该先用哪个工具查航班”“返回的结果里有延误信息，用户没提，我要不要提示”“用户说越早越好，我是不是该按起飞时间排序”“如果早班机都卖完了，我要不要替用户选下一班”。每一步决策都发生在运行过程中，没有任何一段代码预先把流程固定住。

说白了，工作流和Agent的本质区别在于：决策点在哪里。工作流的决策点在开发期就全部决定了，Agent的决策点留给了运行期的模型。你越希望系统行为可控、可预期、可审计，就越应该把决策点留在开发期；你越希望系统灵活、能处理意外情况，就越需要把决策点交给运行期的模型。

2.2 从成本和风险角度倒推选型

我见过太多人一上来就选Agent，理由是“工作流写死了，不够聪明”。这话对了一半：如果流程就是稳定的，写死恰恰是优点。因为写死意味着确定性和可控性，而可控性直接关系到成本。

算一笔账就清楚了。假设一套工作流里有6个节点，每个节点的大模型调用一次,平均每次消耗约2000个token，一次完整流程大约消耗12000个token。而同样任务交给Agent自主规划，它为了“确保自己没做错”，通常会多轮试探、反复推理,实际token消耗往往是工作流的3到5倍。按当前国内主流大模型API价格来说，一个Agent任务的成本大约在几毛钱到几块钱人民币之间浮动，但当你的业务是每天上万次调用时,一天的成本差距就是几千块，一个月就是几十万。

所以我的判断标准非常简单粗暴：

• 步骤确定、输入输出结构固定、不允许出错的场景，优先工作流。
• 步骤不确定、输入非常开放、需要处理大量异常分支的场景，才考虑Agent。
• 两者都说不准的时候，先上工作流，跑通之后再局部替换成Agent，而不是一上来就全上Agent。

2.3 普通对话在什么情况下才是主力方案

千万不要忘了最基础的普通对话。很多时候，用户根本不需要一个“任务执行引擎”，他只是想知道答案。

比如知识库问答、产品使用咨询、政策解读、方案推荐。这类场景不需要调用API，不需要操作业务系统，大模型靠自身知识+检索增强（如果你接入了知识库的话）就能给出不错的回答。你非要套一个工作流，把问题分类、拆解、路由、多轮追问都做成节点，反而增加了延迟和失败率。

举个例子。用户问“你们这个产品的续费政策是什么”，这个问题就是一个简单的单轮问答。你如果给它套一个多步骤工作流：先意图识别、再查订单系统、再查政策库、再生成回复——用户要多等两秒，多付几十倍成本，得到的结果和直接把政策库扔给模型检索问答差不多。何苦呢。

普通对话的适用边界其实很明确：目标是“获取信息或建议”，而不是“执行某个操作”，或者操作本身不涉及外部系统的副作用。

3. 实操选型：结合具体业务场景的判断决策树

光讲理论没用，我把它画成一张决策树。这是我给团队内部做的简化版，你直接拿去用：

3.1 一张图看懂选型逻辑

判断逻辑总共三步：

1. 用户需要的是“回答”还是“执行”？回答 → 普通对话；执行 → 进入下一步。
2. 执行路径是否明确固定？路径确定 → 工作流；路径不确定、需要现场规划 → 进入下一步。
3. 执行结果是否能容忍AI自行决策带来的不确定性？能容忍（比如推荐内容、生成文案、排序结果）→ Agent；不能容忍（涉及资金、法务、数据删除等）→ 回到工作流，同时缩小场景范围，尽量把问题拆到步骤可控为止。

这套逻辑里有一个关键点值得展开：很多“看起来必须用Agent”的需求，其实本质是“工作流没有拆够细”。

我有一个做HR SaaS的朋友，最初他们的需求是“有员工问年假余额、调休规则、请假流程”，第一个版本用Agent做，模型表现飘忽不定：有时候答非所问，有时候让员工跳到错误的下级流程。后来他们把这个问题拆成了三级路由：先判断问题类型（余额/规则/流程），再判断动作意图（查询/申请/变更），最后落到对应的工作流分支。整三个对话节点把大模型当分类器用，结果准确率从82%飙到97%，成本降了60%。这就是把Agent的工作用工作流分解的经典案例。

3.2 表单类场景适合哪种

表单是最容易被误解为“必须用Agent”的场景。

举个例子：员工报销系统，需要用户提交的字段包括——姓名、部门、报销类型、金额、发票号、事由说明。很多人一看到“用户可能用自然语言描述报销单”，就觉得需要Agent来自动提取字段、自动查发票、自动校验。

但实际上这个场景用工作流更合适。理由在于：字段节点是固定的，输出是结构化的，逻辑路径是清晰的。工作流完全可以做到——第一步用文本抽取模型（不一定是大模型，小模型也行）从用户的描述里抽取字段；第二步校验字段合法性；第三步调发票查验接口；第四步按规则审批；第五步通知结果。整条链路唯一用到大模型的地方，就是把用户的话转成结构化字典，这部分工作流也能胜任，事先定义好字段模板和输出JSON Schema就完事了。

Agent在这里的真正价值在另一个点：当字段没法预先定义的时候，比如“特殊报销”场景——员工说“我帮公司垫资买了办公用品，部分票据丢失，但领导让我先报”。这种场景的审批路径、要求字段、异常处理都是个性化的，没法写成固定节点，这时候你才需要Agent去理解非标准化流程，并动态生成处理方案。

3.3 对话式数据分析的取舍

数据分析也是选型高频区。老板想用自然语言直接查报表：“上个月华东区哪个产品线营收增长最快？”

这个场景我见过两种截然不同的做法，效果差距巨大：

• 低效做法：直接让大模型写查询代码。问题是模型不了解表结构，生成的代码经常有隐含错误，查出来的数字看起来是对的，实际上是错的，而且你很难排查。上线一个月，业务部门就会发现“这系统数字不准”，然后废弃不用。这是典型的大模型直接操作数据库翻车案例。
• 高效做法：工作流把流程固定——第一步，意图识别，判断是查询、对比、还是趋势分析；第二步，通过语义解析（或用预设的查询模板）把自然语言转成查询参数；第三步，从指标字典里找到用户说的指标和维度的映射关系；第四步，生成查询语句，但查询语句要经过白名单校验（只允许查指定的表和字段）；第五步，把查询结果送给模型做概括性解读。

第二种做法里，大模型从“代码生成器”降级成了“自然语言转参数”和“结果解读器”，看似浪费了模型能力，实际换来了准确率和安全性。你说哪种更聪明？当然如果数据结构极其复杂，且查询维度开放、无法穷举，可以引入Agent让模型动态判断查询路径、必要时多轮追问用户条件，但前提是必须加护栏——后面会专门讲护栏怎么做。

4. 混合架构才是真实世界的常态，别指望一套方案吃天下

讲完三种方案的区别，你可能已经发现：现实业务往往不是非此即彼的。

4.1 混合架构的典型形态

真实世界里的系统，绝大多数是三者混用的。我举一个我负责过的模拟项目X：企业端的工单系统智能助手，给售后客服用的，大概有这些能力需求：

1. 解释售后政策 →普通对话，接知识库直接答。
2. 查询订单物流信息 →工作流，步骤固定（取订单号→查物流接口→返回结果）。
3. 处理退换货申请 →工作流+普通对话：先用小模型/规则引擎判定是否符合退货条件，符合的走固定审批流，不符合的用普通对话解释原因并给出建议。
4. 处理“这个商品坏了，但我说不清楚问题”这类开放投诉 →Agent：让模型自己判断用户描述的问题类型，决定是否需要更详细地追问，再决定走向哪个处理流程，必要时开一张优先处理单。

这几个能力如果都用同一种方案实现，结果就是灾难。全用工作流，开放投诉场景无法覆盖；全用Agent，政策解释成本翻倍、答案还不稳定；全用普通对话，物流查询和退换货又无法真正执行。所以混合架构的核心原则是“让最擅长的模块干它最擅长的事”。

4.2 用大模型做“路由器”的分层调度

在混合架构里，有个很好的模式，叫“大模型做路由器”。

具体做法是这样的：用户输入先经过一个“意图分流层”，这个层由大模型实现，它的任务是判断这条输入应该走哪个子模块——是问答、工作流还是Agent。然后请求被路由到对应模块执行，执行完的结果汇总后，再回到统一的出口生成最终回复。

这个模式的巧思在于：它给了系统一个“总控大脑”，但大脑本身不做具体业务操作。大脑只负责意图判断、上下文管理、回复润色，而真正的高风险操作仍由经过验证的确定性代码执行。这样既保住了灵活性，又守住了确定性底线。

我做这个“路由器”时用了一些技巧，分享几个实测好用的：

• 意图分类不要用自由文本，而是要让模型输出一个限定范围内的字符串（比如ANSWER、WORKFLOW、AGENT），并且给出每个选项的详细说明。
• 模型分类结果要带置信度，低于阈值时默认走人工兜底或者普通对话，不要硬闯工作流。
• 对分类结果做个白名单映射，哪怕模型输出乱码，代码也不会因此崩溃。

4.3 给Agent装上护栏，别让它“裸奔”

如果你经过评估，确定某些场景必须上Agent，那下面是几条保命建议。

第一，限制Agent可用的工具集。不要让Agent看到全部API接口，它只需要能看到当前场景下允许调用的那些工具。你可以像白名单一样在代码里配好每个Agent角色能看到的工具列表。比如售后Agent只能查物流和开退款单，不能碰客户数据导出接口。

第二，强制在Agent的关键节点加“人类审批”。涉及资金支付、大额退款、删除数据、对外发送消息等高风险操作，不能允许Agent独自执行。正确的做法是Agent生成操作请求 → 挂起 → 推送给管理员确认 → 确认后由代码执行。这些节点可以在Agent的工具定义里都声明为“需要用户确认”的那种。

第三，限制最大迭代轮数。Agent自以为聪明的时候会陷入无限循环：查询→觉得结果不对→再查→再纠结。给每一步都设定一个max_iterations参数，比如最多5轮，超过就强制结束并转人工，否则你的API账单会很难看。

第四，日志和审计不能省。每个Agent决策、工具调用、参数、返回值都要记录到日志。这样出了问题你才知道是模型抽风还是参数传错，而不是面对一个无法解释的黑盒系统。

很多项目最终坏就坏在第四点上：Agent上线后效果时好时坏，但因为没日志，团队根本定位不了问题，只好回滚。这种事我见了不止三次了。

5. 三个真实案例：不同选型带来的成本与效果差距

光讲方法论有点悬，我用三个自己做过的模拟项目做对标，你可以更直观地感受到选型差异。

5.1 案例一：知识库问答（普通对话 vs 过度设计）

某公司内部系统想做员工手册问答，最初外包团队给了一个工作流方案：意图分类节点→问题改写节点→文档检索节点→答案生成节点，一共四个步骤。

实测效果：每次查询先花 1.2 秒做意图分类（其实只是区分“请假/报销/考勤/其他”四大类），再花 0.8 秒做问题改写，再检索再生成。整个过程2~3秒，成本一次约0.2元（当时用的模型较贵）。而且因为环节多了，任何一个环节出错都会导致整体失败，兜底逻辑也麻烦。

后来我介入之后，把系统简化成最基础的知识库问答——向量检索加普通对话生成，就两个环节，连贯的一次生成完成。响应时间降到 0.8 秒，成本降到每次约0.05元，准确率反而更高，因为少了不靠谱的“问题改写”节点。

教训：不要为了用工作流而用工作流。对话解决的问题，就不要引入流程编排。所谓技术选型，其实是选最省力、最容易维护的方案。

5.2 案例二：电商售后处理（工作流为主，局部Agent）

某电商平台的售后助手，最初设想是“全Agent”——让模型自己判断售后工单的类型、责任方、处理方式。想法很好，实际效果惨不忍睹：30%的工单会因模型幻觉开出不合理的处理方案，比如未发货订单竟然开出“退款补偿”，实际上这笔订单根本没有完成支付。客户投诉暴涨。

改造后的方案是“工作流为主+Agent处理边缘场景”：

• 订单状态、支付状态、物流状态全部从数据库/接口直接取，不经过模型理解。
• 规则引擎先判断是否符合退款条件，符合的走固定退款流程。
• 只有遇到“规则判断不了”的模糊场景（比如用户说“商品有问题但拒绝提供照片”），才让Agent介入做开放式询问和进一步的信息收集。

改造后工单处理时长从平均6.2分钟降到了2.1分钟，争议工单占比从25%降到了8%。核心逻辑只有一条：能用确定性判断的绝不用概率性判断。

5.3 案例三：竞品情报监控（Agent的合理用武之地）

也有反过来有必要用Agent的案例。某团队要做竞品价格与评论监控，场景特征是：数据源分散（官网、电商平台、社媒）、格式不统一（表格、长文本、图片）、监控对象经常新增，没法预先写死采集模板。

这种场景就是Agent的天然主场：Agent可以自己决策去访问哪些页面、提取哪些关键字段、变化时如何比对、夜间定时执行报告汇总。它的灵活性带来了传统爬虫+规则脚本完全做不到的覆盖率。实测下来，Agent方案比传统方案多发现约15%的异常价格变动事件。

但这个场景成功的前提是：任务结果可以被事后验证，而且结果错了不会造成直接经济损失。监控信息采集这种场景，错一条顶多明天修正，它的容错空间比前面两个场景大得多，这才是Agent能够发挥优势的土壤。

6. 常见选型误区与高频问题排查

讲完了选型逻辑和案例，收集几个我经常碰到的团队问题，你很可能也会踩。

6.1 选型误区清单

误区一：Agent比工作流高级，所以优先选Agent。这完全是错的方向。架构选型没有高下之分，只有适配与否。所谓“高级”，是在正确的场景用合适的工具。选Agent本身并不会让你的产品显得更强，它只会让你的项目变多变难。

误区二：普通对话就是“没技术含量”。恰恰相反，把普通对话做好很难，难在回答的准确性、一致性、人格化和安全护栏。没有护栏的普通对话会让用户感到“在跟傻子聊天”，这种伤害比没有AI功能还严重。

误区三：觉得工作流太死板，怕用户问题超出预设。应对之道不是干脆不用工作流，而是把工作流的“兜底”做好：识别不了的意图，回退到普通对话或转人工。设一个“未识别”出口，比让系统硬撑体面得多。

误区四：让Agent直接操作数据库。这是最危险的。大模型生成的查询代码可能带过滤条件错误、可能跨表关联出完全不符合预期的数据、可能把用户权限之外的敏感字段查出来。任何时候绝不允许大模型直连数据库执行动态生成的SQL或代码。要么走白名单模板，要么走内部API，就是不要给它一把万能钥匙。

6.2 高频问题排查实录

问题一：Agent经常“自作主张”去做用户没要求的事。

排查思路：检查工具描述里有没有误导性词汇；检查目标提示词里有没有隐含“你要尽量帮用户多做一步”之类的表述；检查是不是Top-P或温度设置过高。大多时候是提示词里某个细节惹的祸，先把温度降到0.1以下再试。

问题二：工作流执行经常出错，但不知道错在哪里。

排查思路：工作流每个节点都要有输入输出JSON的日志。最忌讳把所有节点包在一个大函数里、中间状态不落日志。把每个节点的入参和出参打印出来，错误定位基本是秒级的事。这件事开发期就要做，上线之后再加日志你会被自己调试到崩溃。

问题三：普通对话回答不够专业，总在泛泛而谈。

排查思路：多数情况是检索质量的问题，不是模型的问题。检查你的知识库切片大小是否合适——太长会把不相关的上下文塞给模型，太短会丢失关键信息；检查检索召回的文档数是不是太少或太多——建议5到8篇左右开始调；检查有没有对检索结果做rerank。做这些优化之前先别急着换更大参数的模型，先排除工程问题再说。

问题四：成本飙升，一天跑了上百万token。

排查思路：先看是不是把“全链路对话历史”都送给了模型。很多AI产品把用户跟系统的所有交互历史一股脑塞给模型，这是成本爆炸的首要原因。只保留最近的几轮关键信息，其他用摘要压缩。再看有没有多余的工具调用，Agent每次意图判断和工具选择都会消耗token，用确定性的意图路由替换它，成本能立刻降下来。

6.3 快速选型自检表

这是我给咨询过的团队做的一张自检清单，当你要启动一个新AI功能时，逐条过一遍：

表格里有一列值得单独强调：“失败容忍度”。绝大多数企业级场景，流程执行失败的代价远大于对话失败的代价，所以在选型时优先保稳定性，再谈智能性。

我用一句话总结自己的选型哲学：能用规则用规则，能用工作流用工作流，普通对话兜底，Agent只在规则解决不了的地方做补位。别让“Agent”这个词绑架你的架构判断。

最后分享一个我在多个项目里反复验证过的经验：一个AI功能的成功，架构选型的贡献度只有三成，剩下七成在于数据质量、评测闭环和细节打磨。很多团队把精力全花在“要不要Agent”这种宏大问题上，却忽略了评测集只有几十条、知识库文档混乱不堪、错误反馈没有回收机制。先把这些基本功做扎实了，再来讨论架构选型，你会发现很多纠结自然就消失了——因为你的业务数据会直接告诉你，哪个环节才是真正的瓶颈。