企业官网建设流程全解析

这半年我密集跑了好几场AI智能体大会。台上每个演示都很好看，有做客服的、有做报表的、有做内部流程自动化的，现场跑起来行云流水。可只要走到互动环节就露馅了，一问到“从客服会话切到后台工单，刚才的上下文还能不能接着用？”“用户从一个场景跳到另一个场景，你到底是保留记忆还是清空记忆？”能讲清楚的少之又少。

场景切换、AI智能体选型、落地评估，这三个词绑在一起才是真正要解决的问题。这篇文章就围绕这句话展开，先给判断框架，再给落地步骤和避坑经验，算是一份给准备选型的人现场参考笔记。无论你是被安排去参加智能体大会选产品的，还是自己团队要做技术选型的，看完应该能少走不少弯路。

1. 为什么我把“场景切换”当成选型的第一指标

很多团队选智能体，习惯先看模型能力，再看工具生态，最后看价格。这没有错，但漏掉了一个真正决定成败的点：当用户从一个场景切换到另一个场景时，智能体能不能保持稳定。我见过太多在单场景测试集上跑出高分、一到真实业务就崩的系统，问题几乎都出在场景切换环节。

1.1 场景切换会引发四类典型失控

第一类是状态污染。智能体在客服场景里已经知道了订单号，切换到底单处理场景后，它可能还带着这个订单号去查另一套系统的数据，甚至把上一轮对话里的字段当成下一轮任务的关键参数。这个现象在真实落地中非常普遍，模型有时候不是能力不够，而是被多余的旧状态带偏了。

第二类是提示词串扰。每个场景通常会配一套系统提示词，客服场景说“你是客服助手”，数据分析场景说“你是数据分析师”。当两个场景在同一个会话里切换时，模型很容易混淆角色，要么继续把自己当客服回答数据问题，要么把两个提示词的部分内容缝合在一起，输出四不像。

第三类是工具权限边界模糊。场景一里，智能体有权限创建订单，场景二只是个查询场景，按道理不该有写权限。但如果平台的权限模型只能给整个Agent配置工具集，没法按场景细分，那么切换到场景二后，它依然保留着创建订单的能力。轻则产生脏数据，重则引发越权操作。

第四类是任务漂移。模型虽然在单个场景上看懂了“做什么”，但跨场景切换后，它可能会延续上一个场景的推理惯性，把新任务的执行方式想象成旧任务的延续。比如用户在知识库问答之后紧接着让它填一个表单，模型可能直接在答案里开始编造表单字段，而不是调用表单API。

如果你现在要选型，我建议把“场景切换是否干净”放到比“单场景准确率”更高的权重来考虑。因为单场景指标只证明它在一个封闭环境里能干活，而真实用户永远是在多个场景之间来回跳的。一个能在切换时保持边界感的智能体，哪怕单场景指标略低一点，实际体验也会好很多。

1.2 先区分六类典型场景再谈选型

场景这个东西不能抽象地谈，必须具体到业务类型才有意义。我总结下来，企业里的智能体场景大致可以分成六类，每一类对选型的要求完全不一样。

表格我把特点、切换频率和容错度列清楚了：

区分这六类的意义在于：你不能用同一个评判标准去选所有场景的智能体。固定流程自动化场景，本质上是把原本规则脚本里需要人来判断的部分交给模型，更适合“工作流为主、Agent为节点”的实现方式；实时协同场景，对延迟和可回滚的要求极高，那选型时就该关注流式响应、操作审计、断点恢复这些能力，而不是追求参数规模。

数据探索与分析场景，则要看模型能不能把业务词汇准确映射到数据结构上，以及工具的权限控制是否足够细。复杂研究综合场景恰恰相反，它需要的是长上下文和记忆管理能力，哪怕慢一点也能接受，重点是别出现信息幻觉。

先把场景类型区分开，你后面做选型才不会被“通用智能体”这个词带偏。市场上确实有很多号称通用的平台，但真实业务不存在通用的场景切换，只存在被伪装成通用规范的局部经验。

2. 选型前先梳理四张清单

去智能体大会看产品之前，我强烈建议你先把自己的需求整理成清单。否则很容易被现场演示带节奏，看什么都觉得好，回来一落地就发现对不上。四张清单分别是场景清单、工具与数据清单、状态与记忆清单、成本与合规清单。

2.1 场景清单：把“会切换”落到可测试的具体用例

多数团队对场景的描述停留在“我们想做智能客服”。但这个描述太粗了，智能客服至少包含意图识别、知识检索、工单创建、订单查询、售后处理、满意度回访等好几个子场景，每个子场景的输入输出、成功标准和切换关系都不一样。

我建议按“场景卡片”的方式来整理。每张卡片至少包含这些字段：场景名称、触发入口、输入信息、期望输出、成功标准、异常处理、依赖工具、可访问数据范围。例如：

场景卡片的好处是：它把一个抽象能力变成了可验收的具体用例。你要求智能体实现“工单草稿自动填写”，就必须先定义清楚“从哪个场景拿订单号”“以什么方式传给工单场景”“传过去之后原场景的数据还在不在”。这些问题不提前想明白，评测时根本不知道看什么。

场景清单至少要准备两条以上。不是越多越好，而是至少要覆盖两个会产生切换关系的场景。一条场景只能验证单点能力，两条场景才能验证切换能力，而切换能力恰恰是智能体落地中最容易出问题的部分。

2.2 工具与数据清单：边界意识越早越好

第二个清单是工具与数据清单。把智能体可能调用的每个工具都列出来，包括工具名称、功能说明、输入输出字段、执行时间、是否幂等、调用成本、使用频次、所属系统、权限等级。这里有个容易被忽略的原则：同一个动作在不同场景下，不一定应该对应同一个工具。

举个例子，订单查询在“客服查询场景”里要查出完整信息，包括内部成本价；但在“客户自助查询场景”里就不能返回成本价。如果工具层面不区分这两个查询，光靠提示词约束模型“不要返回成本价”，早晚会翻车。聪明的做法是拆成两个工具，一个只用只读副本，一个带权限字段控制。

工具清单还要关注幂等性。创建类操作往往不是幂等的，智能体一旦因为超时而重试，就可能创建出重复工单。选型的时候要考察平台能不能支持工具级别的幂等控制，或者在出问题时能不能做到回滚。很多平台在Demo里只展示了工具调用效果，压根不展示重试策略，这个细节对业务系统的伤害是巨大的。

数据Boundaries也一样，不是所有数据都该让模型直接看到。比如把全量数据库表结构直接暴露给自然语言转SQL模型，它可能知道得太多了，反而容易产生越权查询。正确的做法是给每个场景限定“数据视图”，让模型只能看到该场景需要的数据字段，其余的一律隔离。

2.3 状态与记忆清单：决定哪些状态能跨场景保留

状态管理是场景切换的核心，也是最容易被低估的一块。很多人以为状态就是对话历史，直接把聊天记录全部塞给下一轮模型，结果是上下文越滚越长，模型最后分不清哪条信息属于哪个场景。

我建议把状态分成四类来看：

所谓“允许跨场景”不是说可以原样把整个上下文丢过去，而是要有一个清晰的状态交接协议。比如用户在客服场景里确认了订单号，切换到开票场景时，智能体应该收到的是结构化参数“订单号=某值”，而不是“之前用户说他的订单号是多少”这段历史描述。这种结构化传递方式能大幅降低状态污染概率。

选型时你可以直接问平台三个问题：场景切换时你们传什么？不传什么？传丢了怎么处理？能回答清楚这几个问题的，说明状态管理是设计过的；回答“我们都保留”的，千万要小心，它大概率是把复杂度转嫁给了模型。

2.4 成本与合规清单：别最后补课

成本清单要算两种账，一种是模型调用成本，一种是人工兜底成本。模型调用成本建议用“单会话成本”这个指标来估算：平均每轮输入Token加输出Token，乘以平均轮数，再乘以单Token价格和一个月的会话量。

举个例子，一个业务Agent平均每轮输入2000Token、输出400Token，平均每单12轮，那么每单消耗约为28800Token。如果按百万Token几十块的价格来算，每单成本就在一块钱上下。单看不多，但一天一千单，一个月就是三万单，成本马上就上去了。这还没算工具调用失败、模型重试、人工复核带来的额外开销。

合规清单更不要省。智能体涉及的数据包括用户隐私、订单信息、内部资料，每一步调用都要能追溯。选型时要确认平台是否支持场景级审计日志、问答数据留存、删除策略、人工审批点。我只提醒一句：很多智能体平台对开发很开放，对审计很敷衍，等到合规部门介入时才会发现日志缺失。宁可在选型时多问一句“日志能否按场景字段导出”，也别等上线后再补。

3. 架构选型：单体、编排器-子代理、多智能体

现在智能体大会聊架构的人越来越多，但说法有点混乱。有人推崇单体Agent，有人说要上多智能体系统，还有人拿工作流和Agent对打。我的观点是：架构选择必须由场景切换的特征决定，而不是由技术热度决定。

3.1 单体Agent，只在低切换频率下成立

单体智能体把所有能力塞在一个模型上下文里，共享一套工具和提示词。好处是链路简单、调试直观、延迟较低，特别适合单一封闭场景。比如一个只做发票识别的Agent，输入是图片，输出是结构化字段，从头到尾没有第二个场景，单体结构就很合适。

但单体结构一旦遇到场景切换就很麻烦。你为了让智能体既能做客服又能做数据分析，就得在系统提示词里堆一堆场景设定，看起来像是一个模型拥有了多个人设。切换的时候，模型往往分不清现在该启用哪套人设。这就像把所有衣服都塞进一个行李箱，找的时候容易翻乱，压的时候还容易串味道。

如果确定要用单体架构，请务必将业务范围压缩到非常有限的单场景里。一旦你开始规划“在不同场景之间切换”，单体架构就该被排除出候选列表。

3.2 编排器-子代理，最通用的场景切换结构

目前我看到落地效果最稳的，是编排器加子代理的结构。每个子场景对应一个子代理，子代理拥有独立的提示词、独立的工具白名单、独立的记忆空间。总控制器负责判断当前用户意图属于哪个场景，然后把经过筛选的上下文转交给对应子代理，而不是把全部历史倒进去。

这种结构的核心在于切换时传递内容的“最小化”。用户先问订单状态，然后说“帮我开发票”，总控制器识别出目标是开票场景，只传订单号和发票抬头这两个结构化字段给开票子代理，而不是把整个客服对话记录一起传过去。子代理拿到参数后，在它自己的记忆空间里执行任务，完成后再把结构化结果返回给总控制器。

这个模式很自然地解决了上下文污染和提示词串扰问题，因为每个场景的状态被关在了独立空间里。缺点是总控制器的路由准确率会直接影响整体体验，而且多一跳调度会带来一定延迟。但和解决状态污染带来的收益相比，这些代价是可以接受的。

实施时还要设计好异常回退路径。子代理一旦执行失败，应该把异常传回总控制器，由它决定是换一个子代理还是转人工。绝不能出现子代理失败后，总控制器直接拿原始对话历史再试一次的方案，那相当于把污染又引了回来。

3.3 多智能体协同，不是越复杂越好

多智能体系统像是把多个Agent放到一个团队里，通过消息机制协作完成一个复杂的任务。它适合的场景是多个独立子系统之间需要并行配合，比如一个Agent负责采集数据，一个Agent负责分析，一个Agent负责生成报告，它们之间可以通过任务队列解耦。

但多智能体带来的复杂度是指数上升的。每个Agent之间怎么通信、谁先执行谁后执行、某个Agent挂了之后整体要不要回滚、共享状态放在哪里，全部需要体系化的设计。如果你只是两个场景互相切换，上个编排器加子代理就够了，根本没有必要上多智能体架构。

这里我要给一个反共识的建议：不要为了演示效果去追求多智能体。智能体大会经常展示多Agent协作的炫酷Demo，好像一个系统里Agent越多越先进。真实业务恰恰相反，Agent数量多一条，故障点就多一层。能用编排器解决的就不要用消息队列，能用子代理隔离的就不要再造一个跨国通讯的中心化路由器。

3.4 工作流还是Agent，先把确定性边界画出来

判断一个流程该用工作流还是Agent，看的是“分支是否有限且规则明确”。报销审批流程里，发票信息抽取这一步不确定因素多，文本模糊、格式多样，适合用Agent来做智能抽取；但抽取完之后审批路由是固定的：金额小于多少走自动审批，大于多少走部门主管，这些规则是确定的，应该用工作流实现。

我见过不少团队把所有逻辑都交给Agent自由发挥，结果流程不可控、不可测、不可回溯。也见过一些团队完全抗拒模型，把所有模糊判断都交给规则脚本去硬匹配，结果识别率惨不忍睹。最合理的做法是混合架构：确定性部分用工作流，不确定性部分用Agent作为工作流里的节点。这样整个流程的可观测性可以保持住，Agent的核心能力也被用在了该用的地方。

我也把这个判断作为一个选型问题去问平台方：你们的场景支持混合编排吗？同一个流程里能不能既有工作流节点又有Agent节点？如果答案是“只能整体是Agent”，那遇到确定性流程时你会很痛苦。

4. 重点能力评测的方法

去大会看产品，听讲解容易上头，但真正要判断一个智能体能不能用，不能靠感觉，得有一套可复现的评测方法。评测不是只在选型时做一次，而是要在后续每次升级模型、改提示词时都回归。

4.1 三个关键指标：切换成功率、上下文污染率、工具越权率

我在实际评测中总用三个指标来看场景切换能力。

切换成功率定义：连续两个场景任务中，第二个场景的首次动作正确的次数占总切换次数的比例。这里的“首次动作正确”指的是模型应该调用工具时调了正确的工具，应该直接回答时给出了正确回答。比如A场景结束，B场景需要调用“查询库存”，模型如果调用成“查询订单”，就算切换失败。

上下文污染率定义：在B场景的输出内容里，出现A场景专有信息或专有术语的比例。这个指标针对的就是状态残留问题。计算时可以人工标注小样本测试集，也可以让评分模型判断B场景输出里是否混入了不该出现的旧上下文内容。

工具越权率定义：所有工具调用中，模型调用了当前场景权限范围之外的工具的次数占比。这个指标不需要多高才算好，正确的数值就是0。出现任何一次越权都应该被视为高危，因为它一旦出现在真实环境里就可能造成安全事故。

这三个指标建议配合一个小样本测试集来跑。比如准备一百个切换用例，跑完看成功率是否超过90%，污染率是否低于5%，越权率是否为零。达不到这三个阈值的话，无论演示效果多惊艳，落地都要打问号。

4.2 五类现场测试用例设计

评测智能体不能只用一个固定测试集，尤其要设计出针对场景切换的压力测试。我整理了自己的五个用例类型，仅供参考：

构造场景切换测试时有个技巧：要让B场景的部分输入依赖A场景中产生的中间结果。比如A场景里用户说了“订单号9527”，B场景要求按这个订单号生成退货单。这个测试能逼出很多隐藏问题。模型如果不能正确提取订单号并传给B场景，后续就会出现重复询问、错误引用、甚至幻觉出另一个订单号的情况。

长会话压测其实也是场景切换压力的一种。因为很多Agent的状态管理在轮数变多之后会退化。有些是上下文直接爆掉，有些是模型开始遗忘早期用户提到过的关键信息。这个测试能检验平台对记忆分层和压缩的实现程度。

4.3 选型还是自研，什么时候不该自己搭

关于选型还是自研，我的态度很明确：能买不要自己造。智能体不是一个模型调用那么简单，它涉及提示词管理、状态隔离、工具权限、可观测性、成本控制、安全审计，每一样都是长期工程。如果选型阶段被一个Demo打动就决定自研，后面只有两种结果，要么被细节拖垮，要么在合规上补课补到怀疑人生。

选择一个现成平台或框架时，我建议考察四个问题：第一，能否把每个子代理的状态和工具权限隔离开；第二，场景切换时的上下文传递能否自定义；第三，是否提供完整的链路Trace，能不能回放某个会话的每一步工具调用；第四，成本和会话量是否有可视化的管理能力。如果这四点的答案都明确，平台就算值得考虑。

什么情况下才自研？一种是当前平台的工具权限模型满足不了你的审计要求，比如金融、大型企业内部系统对数据访问边界要求苛刻；另一种是你已经踩完了现成平台的坑，清楚知道自己要什么，而不是因为“感觉自研更高级”。自研的最低门槛是有一个全职的人负责评测集、上下文设计、工具权限安全和变更回归，而不是只写调用代码。连人都没有，就不要谈自研。

5. 落地路径：从试点到全量

选型只是开始，落地才是真正的战场。很多团队选完平台，第三周就想全量上线，结果出了问题之后信心崩盘。我更建议你把落地走成一个温水煮青蛙的过程，每一步都要有明确的通过线。

5.1 第一步：选定两条相关场景做试点

试点一定不要只选一条场景，也不要去选一条业务中最复杂的场景。最好的试点是两条切换频率高、业务链路短、出错影响可控的场景。比如客服咨询转工单创建、客户资料查询转订单信息录入，这类组合能在短时间内暴露状态管理问题，又因为链路短，就算出了错也不会造成巨大的业务事故。

试点周期建议拉足两到四周，前两周主要是跑通链路和积累真实数据，后两周开始用积累的数据做回归测试和指标校准。成功标准也不是“智能体能跑起来”，而应该是切换成功率不低于90%、人工接手率不高于原有流程的1.5倍、工单字段准确率不低于98%。达不到就继续调整，不要硬上。

5.2 第二步：建立场景回放与回归测试

这一步几乎决定了项目后续能不能持续升级。很多团队上线的第一天效果好，三天后改了提示词发现效果变差，又不知道哪里变差了。原因就是缺少回放机制。

回放机制很好理解：把线上会话日志脱敏后变成可回放的测试集，每次对模型、提示词、工具配置做变更之前，先跑一遍回放测试集，看关键指标有没有下降。日志至少要包含会话ID、场景标签、用户输入、模型输出、工具调用记录、人工干预标记。有了这些字段，你才能回答“这个变化是变好了还是变坏了”。

回归集建议分成三层：第一层是单场景Case，保证基础能力没有回退；第二层是场景切换Case，保证切换成功率没有下降；第三层是故障注入Case，保证异常处理没有被破坏。测试集不用一开始很大，几百条就可以，但要有代表性。每个Case要明确标注它属于哪一类，这样跑挂之后才能快速定位是哪个环节的问题。

5.3 第三步：上线观察与灰度发布

灰度不是一个可选项，而是必须项。我习惯按照流量比例5%到20%再到50%最后到100%来放量，或者先按内部团队试用再面向真实用户。灰度期间的观察指标比Demo指标实在得多，包括整体完成率、人工接手率、平均轮次、单会话成本、用户投诉率。

参考阈值如下：

人工接手率是最值得盯住的指标。智能体如果把问题处理得稀烂，用户就会反复找人工，你的客服压力不降反升。有人说看用户投诉率，但投诉率太滞后了，人工接手率才是实时信号。人工接手率一旦明显高于老流程，大概率不是用户难搞，而是智能体产生了更多混乱。

5.4 人机协同的兜底设计

上线过程中还需要提前想好兜底机制。任何智能体系统都应该有“我不行”的出口。我见过太多失败的案例，都是因为系统设计时假设智能体一定能正确处理所有请求，结果一旦遇到未知场景，它就卡在死循环或者编造答案。正确做法是明确设置置信度阈值，智能体拿不准时直接转人工，不要硬答。

对人机切换的设计要细节化：转人工时要把当前场景的关键上下文一起转过去，让客服看到用户已经操作到哪一步；转人工后智能体不得继续在同一会话里产生干扰输出，避免人工和机器抢话。这个机制看起来简单，但真正做过的才知道，它的价值比很多模型技巧都大。它守住了用户体验的底线，也给智能体系统留了一条安全的后路。

6. 常见问题排查与避坑速查

最后把我在实际项目中遇到的高频问题和应对方式整理成速查表，你可以直接拿来当诊断手册用。

6.1 常见现象与原因对应

这里重点说一个容易被误判的情况。切换后答非所问，很多人第一反应是模型能力不行，于是换更大的模型。但多数时候问题出在上下文隔离和状态传递上，换了更大的模型只会把旧的脏上下文记得更牢，反而问题更严重。排查的时候先看上下文拼接逻辑，再考虑模型要不要换。

6.2 三个我印象深刻的坑

第一个坑是当初为了做“无缝切换体验”，直接把上一轮对话历史完整拼到下一个场景的提示词里。结果用户在客服场景里报过一个订单号，切换到退货登记场景时，模型死活觉得用户想退的是那个历史订单，虽然用户实际说的是另外一单。那之后我把所有跨场景传递都改成了结构化字段，再也不传原始对话记录。

第二个坑是工具权限全局放开。一开始图方便，把所有工具都配给了一个智能体，结果在只读查询场景里，它自作主张调用创建工单工具写了一条测试信息。虽然没造成大事故，但暴露了一个原则性问题：工具权限必须按最小场景集配置，宁可少配多等，也不能多配乱调。

第三个坑是上线前只用单场景测试集做评测。单场景指标漂亮得像个明星，一旦把两个场景连起来测，切换成功率连60%都不到。后来老老实实加入了真实日志回放机制，每一次提示词变更都要先跑一遍场景切换回归，才算把质量控制住了。

6.3 快速选型打分的参考表

如果在智能体大会或者供应商交流现场，你没法现场做完整评测，可以用下面这个打分表快速做一次筛选。打分建议采用五分制，按维度权重加权后得到总分。

打分时要注意，不要被对方PPT里的某个惊艳Demo拉满分数。每项评分都要结合你的场景清单去问，尤其是“切换时上下文传什么、不传什么”这个问题，对方如果能给出具体策略，说明产品在状态管理上是用了心的；如果支支吾吾只说“我们有记忆能力”，基本可以扣掉一半分。

我个人的经验是，选型讨论不应该从模型评分表开始，而应该从场景切换的那一个瞬间开始。开大会看演示时，我不会立刻问对方模型排名多少，而是会先画两个相邻场景，然后问：用户从A场景跳到B场景，你们到底传什么、不传什么。能把这句话说清楚的产品，通常落地都不会太差。

踩过几次坑之后不得不承认，选型选到最后比的是谁对状态边界更敏感，而不是谁的参数规模更大。这篇参考算是我这段时间见展商、做评测和复盘踩坑的一个汇总，也是给自己下一次选型留的检查清单。希望它也能让正在做智能体选型的你，少走一段我走过的弯路。