企业官网建设流程全解析

做AI应用这段时间，被问得最多的不是“哪个模型最强”，而是“这功能到底该用普通对话、工作流，还是Agent”。问的人里有刚入行的开发者，有带团队的技术负责人，也有根本不懂代码但想用AI改造业务流程的运营同学。能问出这个问题，说明大家已经意识到这三者是有边界区分的，不是拿一个AI接口往后端一怼就完事。

我在这上面栽过不少跟头。最早做一个客服问答Demo，觉得Agent很酷，把知识库检索、订单查询、退换货判断全塞给模型自主决策，结果线上跑了一个星期就崩了——模型在用户没问订单的时候自己查了订单，在用户只想要个人工客服的时候写了一长篇退款建议，最离谱的一次它替用户申请了优惠券。后来换回工作流，把每一步操作固化成节点，问题反而全消失了。也是从那次开始，我认真梳理了这三者的本质、边界和选型逻辑。

这篇东西不聊算法原理，就讲怎么选、为什么这么选，以及生产环境里真正跑得通的组合方式。内容基本来自我自己和身边团队的反复试错，案例全部脱敏，你可以直接对着判断自己手里的项目。

1. 先厘清概念：普通对话、工作流、Agent的本质差异

选型之前，必须先把术语对齐。我发现很多争议其实来源于大家对同一个词的理解不一样，有人管循环调用模型都叫Agent，有人把复杂的提示词工程也叫Agent，这会导致沟通成本急剧上升。

1.1 普通对话：只回答，不做事的“AI翻译官”

普通对话就是模型和用户之间一问一答，用上下文窗口维持多轮记忆，模型根据问题直接生成回复。它的核心特点是：模型不主动调用外部工具，不修改任何系统状态，不具备多步骤的执行规划。

你可以把它理解为一名“AI翻译官”——把用户的自然语言翻译成答案文本送回来。用户说“我最近睡不好”，它说“建议规律作息”；用户说“写一份活动文案”，它写一份文案。但它不会帮用户预约医生，不会把文案提交到某个系统里，也不会在下一次对话之前记住这次聊了什么。对话结束，状态清零。

这个形态适合什么场景？知识问答、内容生成、头脑风暴、情感陪伴、学习辅导。特点就是灵活、边际成本低、开发量小，接上模型API就能用。缺点也很明显：不可控，不稳定，不产生业务动作。同一问题换一种问法，答案可能就完全不同。如果业务的核心诉求是“准确执行”，普通对话单独撑不起来。

1.2 工作流：预制好的“流水线作业”

工作流是把一个任务的执行过程拆成固定的步骤，每个步骤完成某个确定的功能，步骤之间按顺序或条件流转。比如“意图识别 → 查订单库 → 生成答复 → 推送工单系统”，每一步做什么、参数怎么传、下一步走哪条分支，都是预先定义好的。

你可以把工作流理解成“流水线作业”：机器人手臂负责拧螺丝，传送带负责移动零件，管理看板做质量检查，所有环节的先后顺序不会因为今天拧螺丝的人心情好就改变。工作流里的“智能”主要体现在个别节点用模型替代规则，比如用大模型做内容分类，但流程骨架是确定的。

这种形态最大优势是可控、可观测、易恢复。每一步的运行都有日志，坏在哪个环节能立刻定位，参数可以复现，测试可以自动化。企业里的客服工单、审批流、数据处理管道，本质都是工作流的形态。代价就是灵活性差——任务一旦出现预期外的分支，流程就卡住。

1.3 Agent：有决策权的“临时实习生”

Agent的核心是用大模型做“规划器”，由模型自己决定执行哪些步骤、调哪些工具、按什么顺序执行，直到任务完成。标准的做法是给模型一组工具，模型先理解用户目标，再拆解成子任务，动态调用工具获取结果，观察结果后决定下一步动作，循环往复。

你可以把Agent理解成一名“有决策权的临时实习生”：你告诉他“今天把这份客户名单按行业分级”，他不会机械地挨个问你怎么分，而是自己制定一个分类方案，调用表格工具读取数据，发现规则不清晰就再细化，最后给你一份分级表，并附上他做决定的依据。他能处理那些你没手把手教过的情况，但你也得承担他跑偏的风险——他可能分错类，可能花太长时间反复尝试，甚至可能用了你没授权他使用的数据。

Agent适合处理的是：目标明确但路径不唯一的开放型任务、需要多轮决策的动态任务、需要跨多个工具协同的复杂工作。代价是成本高（一次任务可能相当于十几次模型调用）、延迟大（要循环思考）、结果不可100%预测，必须有护栏。

2. 选型前先问自己：五个决定性的判断维度

概念清楚之后，真正的问题变成：我的场景应该用哪种。这里没有万能公式，但我提炼了五个判断维度，每次选型前过一遍，基本能定调。

2.1 确定性：这件事有没有可枚举的正确答案

最高优先级的维度是任务的确定性。如果这个任务在开发阶段就能枚举出所有可能的分支和对应的处理策略，那它就是确定性任务，应该优先考虑普通对话（作为交互壳）加工作流（作为执行骨架）。比如“查询订单物流信息”，分支无非是“有订单号”“没有订单号”“订单不存在”，每一步都写得清楚。

如果任务很难提前枚举，比如“根据公司历史销售数据给出下季度策略建议”，你需要让模型自己决定看哪些数据、对比哪些维度、用什么视角分析，这时候才轮到Agent上场。我习惯用一个简单测试：让团队里最熟悉业务的人写出这个任务的完整流程图。如果他能在半小时内画出来，那就不需要Agent；如果他画到一半说“这里得看情况”，那可能真的有Agent的发挥空间。

2.2 错误代价：做错一次要付出多大成本

这个维度常常被低估。同样是模型回答错误，闲聊场景里说了一句冒犯的话，最多被举报；但如果是风控决策、医疗建议、资金操作，一次错误的代价就是重大事故。

错误代价高，哪怕是高技术力能覆盖的场景，也优先用工作流兜底。我的原则是：核心权限操作绝不让模型自主决策，最多让模型生成“建议动作”交给人工确认执行。反过来，如果错误代价很低，比如推荐几部电影、生成几版文案初稿，那就可以放心用Agent折腾，失败了反正是低成本的。

2.3 用户控制权：做决定的人应该是用户还是系统

有些场景用户需要掌控感，每一步做了什么都要能解释，用户随时可以插手干预。这类场景适合工作流，因为流程透明、分支可见，用户能知道“我现在在哪一步”。比如自动化的报销流程，用户希望每一步都能看到审批进度，而不是系统自己默默就处理完了。

另一些场景用户只关心结果、不在乎过程，把决策权放给系统收益更高。比如用户说“帮我找一份上周做的市场分析，总结重点，发到部门群”，你没必要让用户自己选模型和工具，Agent直接完成就是了。控制权问题其实是在问：把决策权交给模型，你的用户接受吗？如果用户必须在特定节点确认，那工作流至少能在那些节点暂停等待。

2.4 成本与响应延迟：一次行动到底花了多少钱、多少时间

模型调用不是免费的，Agent的最大成本来自循环调用。一个简单Agent任务，最少要经历“理解任务→选工具→调工具→格式化输出”四轮，如果中途要纠错重来，轻松上十轮。我见过一个文档整理Agent，一次完整任务消耗了将近15万token，换算下来成本接近一次工作流失败的50倍。而普通对话，一轮就能完成大部分问答需求。

延迟同理。Agent动辄要等几十秒甚至几分钟，而工作流中只有个别环节需要模型推理的话，整体可以控制在2-3秒内。用户对延迟的容忍度是有明确上限的——短时间内得不到结果，用户就会流失。如果必须让用户在截图中等待Agent跑一分钟，请一定配上进度提示和预期等待时间。

2.5 可观测性：出问题的时候你能查到哪一步

生产系统出问题不可怕，可怕的是出了问题无从排查。工作流的每个节点天然有输入和输出，可以打日志、设监控、回放流程，问题定位基本在半小时内。Agent决策过程是模型自己生成的，虽然可以强行抓取思考过程和工具调用记录，但这些信息本身就不够结构化，想精确复现一个出错的Agent任务非常痛苦。

我的判断标准是：如果这个功能出了问题，需要多久才能定位到具体是“哪个模型调用、哪个步骤、哪个参数”导致，如果目标超过半小时，谨慎用Agent。必须用的话，至少把Agent的每一步决策记录落库，方便回放。

3. 三个真实场景逐一拆解：同一需求，三种做法完全不一样

理论讲完，来点实际的。我拿三个典型场景分别拆一遍，看看三类形态各自怎么实现，以及最终选了哪条路、为什么。

3.1 场景一：客服工单自动分类与应答

某电商团队想做智能客服，需求是：用户发消息进来，系统识别意图，查询相关订单或售后记录，生成回复，并同步创建工单。

用普通对话做就是最简单的一版：用户消息直接丢给模型，让它输出一段客服回复。问题马上出现：模型回答风格不稳定，同一个“物流到哪了”的问题，有时候回答得干脆专业，有时候啰啰嗦嗦像写小作文；更严重的是，模型不会去查真实订单数据，所有回答都基于想象，错的订单号它也煞有其事地回复。

用Agent做是当年的翻车版本。给模型接了订单查询、工单创建、优惠券查询等一堆工具，它倒是真能查数据了，但自主决策太多。多次出现用户没要求优惠券时它主动发了券，用户问一句“你们售后怎么样”，它就调了三轮工具，最后答非所问。而且一次请求动辄20秒起步，用户根本等不起。

最终用了工作流方案：第一节点用意图分类模型，把用户消息分成“查物流”“查订单”“退换货”“转人工”“闲聊”五类；第二节点根据意图走对应分支，每个分支调用固定的查询接口，然后把数据填充进预设回复模板；遇到分类置信度低于0.6或不属于任何已知意图，直接转给人工客服。整个流程所有节点都有日志，每次可以精确回放。

从这个案例能看出来：客服业务的容错率太低，模型自主决策带来的不确定性远大于收益。工作流牺牲的只是“处理预期外问题”的灵活性，换来了稳定和可控，这对客服场景来讲是压倒性的优势。

3.2 场景二：探索式数据分析

另一个团队需要做月度经营分析，领导每次问的问题都不一样：“这个月哪个品类增长最快？”“华东区为什么退货率上升？”“如果砍掉低毛利品，对利润影响多少？”

用工作流做过一版，预设了“读取数据→固定维度统计→生成报告”的流程。但真实问题千变万化，每次都得手动调整SQL和报表参数，团队成员要把大部分时间花在配置上，根本不值。

这里用Agent反而效果很好。给模型接上数据库查询工具、报表生成工具、数据字典查询工具，用户直接问自然语言，Agent自己把问题拆解成SQL查询，循环查询多次，最后生成一份带结论的分析报告。做错了一步也问题不大，无非是报告内容不准，重新问一遍就行。

这个场景成立的前提是：数据分析本身是个开放任务，错误代价极低（报告不准最多浪费几分钟），且Agent大幅降低了使用门槛，让非技术背景的人也能做基础探索。缺点则是成本偏高、响应慢。但对于低频的价值密度高的任务，这都属于可接受范畴。

3.3 场景三：营销内容批量生产

这个更典型。某内容团队要每周产出30篇产品介绍文章，过去是编辑一篇篇写，想用AI提效。

先让编辑试试普通对话：在对话框里输入需求，让模型直接写。大部分编辑反馈“能写，但风格不对，改起来比自己写还累”。原因很简单，模型不知道产品特点、目标受众、品牌语调，每次都从零发挥。

后来做了工作流：先配置一个选题库，每篇文章走“基本信息提取→大纲生成→初稿生成→人工审核→发布”流程，后台预先配置了产品资料、风格指南、历史文章样式。这样产出的文章风格统一，质量稳定，编辑只需要在每个环节做一些操作，不再需要绞尽脑汁从零开始。但这个方案有一个问题：如果人工审核环节发现初稿方向不对，整个流程要回退重跑，很僵化。

现在这个团队跑的是混合模式：用Agent先根据模糊的方向探索素材、生成三版差异较大的初稿，再由编辑挑一版，进入工作流节点做风格统一和格式调整。Agent负责发散，工作流负责收敛，效果明显提升。

4. 别我全都要了，混合架构才是生产环境的常态

读到这里你可能发现，很多场景里我并没有选“某一个”，而是让它们协作。这其实是真正的结论：生产环境中，这三者不是互斥选项，而是一层层嵌套的组合。

4.1 对话负责引流和兜底：先听懂用户再说下一步

最外层通常还是要有一个对话界面，不然后面所有能力都没有入口。用户说一句话，系统先判断这到底是一个随口闲聊、一个控制指令、还是一个需要复杂的多步操作。这个识别过程本身，可以用意图识别模型来实现，但承接用户的界面，永远是对话形态。

当用户说“你们这个平台怎么收费”，对话层可以直接给出标准答案；当用户说“我要报一个5月份的发票”，对话层识别出这是一个流程触发点，调起工作流；当用户说“帮我做一份竞争对手分析报告”，对话层判断这是一个复杂的开放任务，转发给Agent。对话在这里像一个总控台，不好用的总控台会直接毁了后端的体验。

4.2 工作流嵌Agent节点：固定骨架里保留灵活手脚

不要以为工作流里就不能有“智能”成分。我的习惯是：工作流负责框架，Agent负责框架中不好硬编码的环节。比如内容审核工作流，前面步骤都固定，但“判断这篇文案是否涉及违规”本身就带有主观性，适合嵌入一个Agent节点：给它看审核标准，让它自主判断并给出理由。这样既保留了主要流程的可控性，又让每个节点拥有适度的灵活性。

4.3 Agent调工作流工具：让大脑指挥熟手工

反过来，Agent的输出端往往可以复用工作流的能力。给Agent配置工具时，不一定要接一个普通的API，而是把完整的工作流封装成一个“技能包”。比如Agent需要处理用户退款，它可以调用“退款工作流工具”，而不是每次都自己从头规划退款步骤。这样Agent负责思考，工作流负责固化执行，两边都省力。

以我目前的经验，一个健壮的Agent系统应该具备三层结构：第一层是入口对话层，负责意图路由；第二层是调度层，决定当前任务走工作流还是Agent；第三层是执行层，工作流的步骤和Agent的工具都挂在这一层。大量生产问题其实都可以收敛在这一套架构里。

4.4 一套可落地的混合编排参考

我常用的伪代码结构长这样（语言无关，任何框架都可以翻译）：

# 伪代码示例：混合编排主流程 def handle_user_message(message, session): # 第一层：对话层意图识别 intent = classify_intent(message) # return: chat | workflow | agent if intent == "chat": return direct_chat(message, session) if intent == "workflow": # 第二层：定位到具体工作流节点 flow_name = intent_to_flow(message) return execute_workflow(flow_name, message) if intent == "agent": # 第三层：Agent执行，内部会调用各类工具/工作流技能包 agent = Agent(tools=[query_order, refund_flow, knowledge_base]) return agent.run(task=message, max_iterations=10)

生产环境里还有两个补充细节。一是要给Workflow和Agent分别设超时，比如工作流20秒、Agent120秒，超时自动转人工兜底。二是要强制记录日志，每个环节的输入、输出、模型调用token数、耗时全量落库。这些细节决定系统是“可以上生产”还是“只是演示Demo”。

5. 我踩过的坑和现在的快速判断清单

最后聊一点坦白局，分享我踩过的坑和现在习惯用的判断清单。

5.1 最容易翻车的几个判断错误

第一个坑是“Agent万能论”，一遇到复杂需求就忍不住上Agent，把服务搞成了高成本的推理机器。一定要记住，Agent不是银弹，是“最后的武器”，能不用就不用。判断标准：如果规则能完成，或者用一点点“if-else”加查询接口能做完，不要用Agent。

第二个坑是没有设终止条件，Agent任务无限循环。曾经跑过一个资料调研Agent，因为工具返回了异常数据，它不停重试，半小时烧掉了几十万token。后来学乖了，所有Agent任务必设最大迭代轮数（一般5-10轮），并且有人在环的关键操作要停下来让用户确认。

第三个坑是工具描述写不清楚。给Agent挂了七八个工具，但工具定义写得像排队栏干一样，结果它在选择工具这件事上反复出错。后来规范了工具描述：写明触发条件、输入参数含义、输出结构，保留一个中文示例，调用准确率一下就上来了。

第四个坑是过度追求全自动，把用户彻底排除在过程之外。很多场景里用户需要知道“系统正在做什么”，并提供中途干预的机会。一个Agent跑了几十步，用户完全看不见过程，最后给个结果，用户根本不敢信，特别是涉及钱和重要文件的。我在Agent的每步决策里都输出关键动作摘要，用户随时可以确认或中止，信任度好很多。

第五个坑是忽视上下文管理。普通对话可以无脑把历史记录全塞进上下文，但工作流和Agent里每多一轮循环，token消耗都翻倍。我的习惯是：过程性对话用摘要压缩，只有关键业务数据保留原始细节，别让上下文变成垃圾桶。

5.2 现在的快速自检表（可直接抄）

每次做一个AI功能，我先拿这个表格过一遍。任何一步命中右边区域，就优先考虑对应的形态。

坦白说，我过去犯的最大错误不是选了错误的技术，而是花了过多时间纠结“这是不是Agent”这个概念。其实你只需要想清楚三件事：任务确定性高不高、错了代价大不大、用户要不要过程掌控。把这三件事想明白，选什么形态自然就出来了。

这套方法帮我处理了不少需求，