几乎所有主流智能体平台的演示都有同一个特点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机器人相当于买了一套开发工具来做一件现成产品已经做好的事。如果你有强合规要求且不能出内网公有云平台一开始就不在候选里。直接看支持私有化部署的开源框架或本地化方案避免先做一遍再推倒重来。如果你的团队已经有成熟的工程能力和明确的场景且对可控性要求极高从一开始就考虑开源框架或自研。平台的价值在于降低起步门槛这个价值对没有工程能力的团队最大对有能力的团队会递减。