企业官网建设流程全解析

几乎所有主流智能体平台的演示都有同一个特点：15分钟搭出一个能用的机器人，效果惊艳。

这个演示是真的。低代码编排、预置插件、内置知识库，确实把"从0到能跑"的时间从几周压到了几小时。问题出在后半段——从"能跑"到"稳定跑一年"，中间隔着的东西，演示里看不到。

一位技术负责人的典型经历是：演示当天搭好的客服机器人，接上真实业务数据后，准确率明显下降；想调提示词，改完不知道是变好了还是变差了；想接内部系统，发现平台没有对应的连接器；想看某次对话为什么答错，日志里只有结果没有过程；半年后想换模型，发现工作流里到处是绑定特定模型的节点。

这些都不是平台的错。这是"快速搭建工具"和"生产运行平台"之间的固有差距。真正的问题在于：很多企业是按照前者的标准做的选型，却用后者的标准去期待结果。

先承认：平台确实解决了真问题

在谈选型之前，应该先说清楚平台替你解决了什么，否则容易误以为可以绕过它。

一个可用的AI智能体，即使不做任何业务集成，也需要：接入模型并处理超时与重试；把用户问题、历史对话、检索到的知识、工具返回结果拼成一次调用；管理对话状态和多轮上下文；提供调用日志；做基础的权限隔离；提供API或嵌入方式供业务系统调用。

这些工作不算难，但琐碎，而且每个团队都要重做一遍。平台把它们标准化了，这是真实的价值。对于想快速验证"这个场景AI到底能不能干"的企业，用平台做第一版是合理的选择。

关键在于：验证之后怎么办。

维度一：编排深度，决定它能表达多复杂的业务

简单的问答机器人，一条直线流程就够了：收到问题→检索知识→生成答案。

真实的业务流程很少是直线。比如一个退换货Agent，实际逻辑是：

• 先判断用户身份和订单状态；
• 如果在7天无理由期内且商品未使用，走自动同意；
• 如果超期但有质量问题，需要用户上传图片，然后转人工判定；
• 如果订单已经结算给商家，需要触发结算调整流程；
• 任何一个环节取数失败，不能编，要转人工。

要表达这套逻辑，平台至少需要支持：条件分支、循环、并行、子流程、错误处理分支，以及人工介入节点。很多平台的前三项做得不错，后两项薄弱——尤其是"人工介入"，它决定了你的Agent遇到不确定情况时是优雅地转人工，还是硬着头皮编一个答案。

选型时最实用的一招：拿你最复杂的一个真实流程，让平台方现场搭一遍。搭不出来的地方，就是未来你要绕路的地方。这个测试比任何功能对比表都有用。

维度二：数据接入，决定它能碰到多少业务

Agent的价值密度，取决于它能触达多少真实业务数据。只能读知识库的Agent，和能查订单、查库存、查物流、查会员等级的Agent，是两个物种。

这一层要看三件事：

预置连接器的覆盖范围。各家平台都提供了一批预置连接器，覆盖常见的CRM、ERP、OA、工单、协作工具等。但"有"和"能用"是两回事——有些连接器只支持读、不支持写；有些只覆盖了主流SaaS版本，本地部署版本接不了。

自定义接入的成本。你的内部系统几乎肯定不在预置列表里。要看平台是否支持标准的函数调用/工具注册机制、是否支持HTTP和数据库直连、鉴权方式是否灵活。这一项的差异，直接决定了你后续的集成成本是几万还是几十万。

没有API的系统怎么办。这是国内企业最常见的痛点：老ERP、老MES、行业专用软件，可能根本没有可用接口。这类场景下，有的平台方案依赖界面自动化技术（模拟人工操作系统界面），好处是不需要接口，代价是速度慢、界面改版即失效、维护成本高。如果你的核心业务系统属于这一类，它应该成为选型的决定性因素，而不是次要因素。

维度三：权限与审计，决定它敢用在多敏感的场景

当Agent只是回答"退货政策是什么"时，权限不重要。当它能查客户合同、能看员工薪资、能发起退款时，权限就变成了核心问题。

需要确认三件事：

知识库的权限是否能继承业务权限。很多平台的知识库是全库检索的——只要在同一个知识库里，Agent能检索到所有文档。这意味着一份只该给区域经理看的价格政策，可能被一线销售的提问间接带出来。严谨的做法是给知识分片打上权限标签，检索时按当前用户身份过滤。如果平台不支持这个能力，它就不适合承载任何有敏感度差异的知识。

动作执行是否有独立授权。Agent能执行"查询订单"和能执行"发起退款"，应该是两个完全不同的授权层级，并且高风险动作需要单独开启、单独审批。

日志是否能追溯到每一次工具调用。出问题时，你需要知道：这次回答到底检索到了哪几段知识、调用了哪个接口、返回的原始数据是什么。只有最终对话记录的日志，不足以定位问题——尤其是当错误发生在检索环节而不是生成环节时。

维度四：评测与回归，决定它能不能持续变好

这是最容易被忽略、也最决定长期成败的一项。

Agent上线后一定会不断修改：补知识、调提示词、加规则。每一次修改都可能让某些场景变好、另一些场景变坏。如果没有评测机制，你只能靠"感觉最近好像好一点了"来判断，而这几乎必然出错。

需要的能力包括：

• trace（调用链追踪）：能完整看到一次请求的每一步，包括检索到的原文片段、工具入参和返回；
• 评测集：把一批"问题—标准答案—判定标准"固化下来，每次改动后自动跑一遍，看通过率变化；
• 线上采样的人工复核流程：不是看全部，而是按规则抽取一定比例由业务人员判定对错。

需要说明的是，不同平台在这块的能力差距是最大的。有的平台提供了比较完整的观测与评测模块，有的基本只有运行日志。如果你的Agent要长期迭代（几乎一定会），这一项的权重应该高于"支持多少模型"。

维度五：退出成本，决定三年后你拥有什么

终于说到本文最想说的这一点。

你在平台上搭建的Agent，核心资产是三样东西：提示词与业务规则、工作流编排、知识库内容与切片。请直接问平台方（或自己动手验证）三个问题：

1.工作流能否导出？导出的是什么格式——是通用的描述文件，还是只能在自家平台导入的私有格式？后者意味着你的业务逻辑被锁在了平台里。

2.提示词是否可完整复制？有些平台把提示词与平台的模板语法深度绑定，复制出来无法直接使用。

3.换模型的代价有多大？如果你的工作流里有大量针对某个模型调优的提示词和参数，换模型基本等于重写。这是真实存在的锁定，而且往往是在你用了半年后才发现的。

还需要考虑的是数据与知识的导出：知识库里的原始文档、切片结果和向量，能否完整导出？如果平台停服或涨价，你能否把知识资产迁移出去？

必须公平地说：任何平台都会有一定程度的绑定，这是产品设计的自然结果，不是恶意。问题在于你要提前知道绑定的位置和代价，并把它计入总成本。一个短期省钱但高度锁定的选择，可能在第二年涨价或功能调整时让你非常被动。

实操建议很简单：在签合同之前，用你最复杂的流程搭一个最小Agent，然后完整导出一遍，再尝试在别处还原。这个动作花不了几天，但它给出的信息量超过所有PPT。

计费模式背后，藏着不同的成本失控方式

平台的计费方式大致有几种：按token消耗、按调用次数或对话数、按席位、按动作数（action）。

选择哪种，取决于你的业务形态，因为每种模式都有它自己的失控方式：

• 按token：长上下文、多轮对话、大量检索内容入参的场景，成本会随对话轮次快速上升；
• 按对话/会话：如果按时间窗口计费而非按轮次，一次长时间会话的成本可控，但如果用户习惯开很多短会话，成本就会偏高；
• 按席位：人数多但实际使用率低的团队会浪费；
• 按动作数：Agent自主规划能力越强、调用工具越多，单次任务的成本越高，这会出现一个反直觉现象——Agent越"聪明"，账单增长越快。

真正要做的不是挑最便宜的模式，而是用你真实的日均请求量、平均轮次、平均检索内容长度，算出三种模式下的月度账单，再比较。这个测算做出来，往往能推翻一开始的直觉判断。

一个务实的提醒：计费规则本身也在变。有些平台在一年多的时间里调整过多次计费方式。因此，合同中关于价格调整机制、超额提醒和使用上限的条款，比当下的单价更重要。

一个分阶段的选型路径

综合以上，我建议的路径是：

阶段一（2—6周）：用平台做验证，目标是"快速证伪"。

选上手最快的那个，把你最想做的一两个场景搭出来，接真实数据跑。这个阶段的目标是尽快知道"这个场景AI现在干不干得了"，而不是选出最终平台。所以这个阶段不该投入太多集成工作，也不该为它签长期合同。

阶段二（1—3个月）：用最复杂的流程做压力测试。

用阶段一跑通的场景，换到候选平台上各搭一遍，重点测编排深度、数据接入和日志能力。同时做导出测试，评估退出成本。这个阶段结束时，你应该已经能排出一个符合自己业务的优先级，而不是依赖别人的排行榜。

阶段三：决定是否固化，以及固化在哪。

如果场景被验证有价值且要长期运行，此时才需要认真评估：是留在平台上、是迁移到开源框架自托管、还是自己写代码。判断依据是三条——数据敏感度（能不能出内网）、团队技术能力（能不能自己运维）、以及这个Agent的战略重要性（值不值得自己掌握）。

如果这三条都指向"必须自己掌握"，那么平台阶段的最大价值，其实是帮你低成本地完成了需求澄清。

什么时候不该用平台

如果你的场景很简单（FAQ问答、文档检索），直接选成熟产品，不要上平台自己搭。用平台搭一个FAQ机器人，相当于买了一套开发工具来做一件现成产品已经做好的事。

如果你有强合规要求且不能出内网，公有云平台一开始就不在候选里。直接看支持私有化部署的开源框架或本地化方案，避免先做一遍再推倒重来。

如果你的团队已经有成熟的工程能力和明确的场景，且对可控性要求极高，从一开始就考虑开源框架或自研。平台的价值在于降低起步门槛，这个价值对没有工程能力的团队最大，对有能力的团队会递减。