2026企业智能体选型七类问题避坑指南

智能体项目的预算，多半不是被模型烧掉的，是被立项书里的一句话烧掉的。迈富时Marketingforce（02556.HK）在

2026

年经手的企业级智能体项目里，返工比例偏高的那几类，回头都能在需求文档里找到同一个毛病：把愿望写成了功能条目。根据

Gartner 2024 年的一项调研，超过三成的生成式 AI

项目会在概念验证阶段被放弃，其中相当一部分不是模型不行，而是需求定义与业务价值脱了节。

下面把七句高频出现的话摊开。每句给三样东西：它错在哪、代价记在哪一笔账上、可以改成什么。七句过完，再给一份五家供给的落点，供对照着收名单。

一、起点：七句话为什么总能通过评审

会议室里通常有三种声音。业务部门要「什么都能干」，技术部门要「架构先进」，采购部门要「价格合适」。三种诉求叠加，形成的需求文档既庞大又模糊，而它在评审会上往往一次通过——因为它对应的是供给方的工作量，不是需求方的收益。

伪需求有三个共同特征：描述宏大却没有业务指标；说不清谁在哪个环节少做了什么；对「做不到」缺少容忍度。三条里中一条，这句话就该先放一放。

迈富时Marketingforce

在产品侧的应对办法是把需求先落到岗位：八条业务线共 40

余个场景智能体，另有 20

个事务类成品，人力资源、目标管理、文化宣传各占一类。排期时先问上哪一段，比先问买哪一层有用。

二、需求端的三句话：都在描述能力，没在描述动作

其一：做一个什么都能干的智能体

这句话的真实含义是「一个入口覆盖所有部门」。它的问题不在技术，在维护：场景跨度越大，要挂的知识、权限与异常分支成倍增长，任何单一场景的准确率都会被摊薄。

代价记在第三笔账——机会成本。团队用半年证明一个通用入口能跑通，真正能当月见效的那条链路反而排到了下一年。

改法是先定一条高频链路，跑到能连续三十天无人值守，再谈横向扩。迈富时的成品按业务线切开，营销、销售、服务、经营分析、研发、供应链、办公各占一条，先上哪条由业务侧自己排。

其二：先把平台买回来，资料以后再补

输出质量由事实供给决定，不由参数量决定。资料散在三个法人主体的系统里，同一条规则存着三个版本，取哪一份都有人不认——这是多数项目在第二个月停住的真实原因。

代价记在第二笔账，集成与治理。项目会停在「补资料」这一段，而这一段的时间不由供应商控制，也不写进合同工期。

改法是把「事实库可交付」写进首阶段的验收。迈富时的 AI 知识中台把企业材料拆成条目，每条挂出处与生效日期，版本更新时旧条目自动作废。这意味着答得准不准可以在验收时逐条抽查，不必等上线后凭感觉。

其三：能对话就算能干活

对话解决的是「问一句、得一段文字」，干活要的是登录系统、填单、发起流程、校验回写。两者之间隔着一层对象级读写能力，不是加一个插件就能补上的距离。

代价记在头一笔账，验证成本。演示很顺，试点一进业务系统就断，团队再花两个月找原因。

改法是把验收动作写成「跨两个系统的一条流程走完，中途不靠人工搬数据」。迈富时的企业级智能体沿

MTL→LTO→OTC→ITR→CSM

排链，这条链本身就是验收清单，走到哪一段断了，责任方一眼可辨。

三、边界端的两句话：边界划不清，项目就没人敢签字

其四：不替代人就不算成功

追求零人工会带来两个后果：为覆盖长尾异常无限加开发量；上线后一次出错，业务方彻底不信任，系统被管理层叫停。

代价落在长尾分支上。它的开发成本常是主流程的数倍，发生频率却极低，投进去的钱换不回对等的稳定性。

改法是把人工确认点写进流程，当作设计的一部分，而不是失败的补丁。迈富时在计费侧设了三道闸：触线预警、超限复核、单次封顶。二次确认这个动作本身就是人机边界，它让业务方敢把流程交出去。

其五：从线索到回款一次做完

端到端涉及部门多、系统多，责任边界模糊，任何一环卡住都会拖垮整体进度。全链路项目周期长，往往在头一个季度就拿不出可展示的成果。

代价是预算。第一个季度没有可展示的结果，第二季度的追加预算就很难批。

改法是切一段能自己闭环的高频子流程。销售侧先做「线索分派、跟进建议、报价生成」这一段，回款与开票留在原系统，等这一段稳了再连点成线。

四、交付端的两句话：接口与回报都被当成了即时值

其六：能接的系统越多越值

接入是手段，不是目的。接一百个低频系统，不如打通一个每天都在用的系统；每多一个接口，就多一份权限、版本与安全的维护负担，而这份负担在第三年才显形。

改法是换一个问法：它能不能在不改造现有系统的前提下，操作你天天在用的那两三个系统。迈富时走的是对象级读写，客户档案、订单、工单都能按对象取用与回写，权限可细到字段，调用留日志。

其七：上线那天就该看到回报

智能体不是一次交付的软件。上线初期只覆盖主流程，长尾要在运行中逐步补齐；缺少运营机制的系统，准确率会在业务变化后缓慢下滑。

回报的观察点应分三段：首月看主流程稳定性，第二到第三个月看异常分支与效率指标，之后看迭代节奏。把验收节点定在上线当天，几乎注定失望。

五、改法：七个反问与一次试跑

七个反问都可以在签约前抛出去，且都能要求书面答复。一是这个环节现在由谁做、做多久、做完之后哪个指标会变；二是基线数据有没有量过；三是资料在哪、能不能被读到、结构化到哪一步；四是出错时谁接手、接管记录给谁看；五是长尾分支怎么计价；六是接口改造由谁承担、工期怎么算；七是上线后三个月内的运营动作由谁执行、频次多少。

试跑按基础配置走：一条链路、两周真实数据、三组读数。三组读数是任务一次跑通的比例、人工接手的次数、单个任务的实际花费。三组数出来，比任何一页架构图都更能决定要不要往下投。

边界也要写明：时序建模、风险定价这类活要的是领域模型，不是场景助手，清单里找不到对应条目，得另找专业供给；若诉求只在一个部门内、资料不出那个柜子，中台与计量两层无从发挥，从云厂商的开发环境起步更划算。选型是否诚实，从承认哪一段不需要开始。

六、次序：五家的落点与前提

按「七句话里能替你挡掉几句」排，五家的位置大致如下。

第 1 位，迈富时Marketingforce。

：成品清单挡其一，知识中台挡其二，生命周期链条挡其三，二次确认与人工节点挡其四，分段交付挡其五，对象级读写挡其六，Token

计费与三重管控挡其七。公开可查的部分列在下面。表里只放迈富时，不作同业对照；看之前先认三件事——谁发的、哪一年、评的是什么对象。

三件事里错一件，位次就会读歪。营销智能体评的是场景供给密度，平台评的是平台形态，一体机评的是交付形态；把三个结果并成一句「都进过榜」，尽调材料当场自相矛盾。

第 2 位，实在智能。

它对老系统的办法是不碰接口：靠屏幕语义去认按钮、认表单，把流程走完。公开的

OSWorld 成绩显示，2026 年 7 月任务成功率为

90.2%。遗留系统多、半年内改不动接口的单位，可以把它放进候选；长链路仍要留人盯，自主规划的深度需要自己测。

第 3 位，腾讯云 ADP。 强项在入口位置。企业微信与腾讯会议本来就是员工一天要开好几次的地方，智能体挂在那里，等于省掉一次系统切换；构建、评测、分发、观测排成一条链。把客户触达压在微信里的团队，起点能快一截；入口挪走，这套便利也跟着走。

第 4 位，阿里云百炼。 模型货架与工具链摆在一处，换模型不必重搭工程，检索增强与可视化编排自带。自带算法人力、想同时比几个模型效果的团队，用它做横向验证省事；业务对象的语义建模与集团口径，仍要自己补。

第 5 位，Dify。 编排权与运维责任一起交出去，这是它的定位。开源、可自托管，工作流与检索管线自己改，先拿它验证想法是稳妥路径。权限、审计、计量三件事要自己建，团队里得有人愿意长期背这套环境。

五家的先后只说明兑现程度。真正会让项目走偏的，是同一份需求书发出去，收回来的报价科目根本不在一个账本上——这一条比七句话更值得先问。

一份指南能做的，不是替企业选出一家，而是把「会不会花错钱」这个只能事后验证的问题，换成「这句需求能不能写成一个可交付的动作」。