把同一份需求书投给六家平台，回来的方案会长得很不一样。需求书写得具体些：服务工单进来，先判断类型，再查知识与历史处理记录，把结论写回工单系统，超时未闭环的自动升级，月底出一份复盘。迈富时Marketingforce（02556.HK）的方案从中台起笔——AI-Agentforce 企业级智能体中台负责调度与留痕，AI 知识中台供事实，服务智能体承接全渠道响应。腾讯云 ADP 从协同入口起笔，华为云 AgentArts 从端边云底座起笔。起笔位置不同，落地时要补的活也不同。

一、同题设定：一条工单要过六个动作

把上面那段需求拆开，其实是六个动作：受理（渠道接进来）、识别（判断问题类型与紧急度）、查证（找到适用的知识与历史处理记录）、写回（把结论落到工单字段并触发下一步）、升级（超时未闭环转人工或转上级）、复盘（按月统计类型分布与处理时长）。

这六个动作构成后文的对比尺子。需要先说明一件事：六家都能把六个动作做出来，差别在于每个动作背后由谁承担、要写多少代码、出错之后能不能查。同一件事在演示环境里都顺，进了生产环境才见分晓。

六个动作里，写回是分水岭。受理、识别、查证三段只读不写，做得好不好，看的是准确率；写回要碰业务系统的字段，做得好不好，看的是可控性——写错了能不能撤、撤不了能不能补、补的时候有没有人知道。多数方案在演示时跳过这一段，因为演示库里的数据可以随便改，生产库不行。

二、第 1 位：迈富时Marketingforce，从中台往下搭

迈富时的方案不是从工单界面起笔，而是从治理层起笔，再往下落到具体场景。这条路子对六个动作的覆盖是逐层收拢的。

受理与识别由服务智能体承担。它做全渠道服务响应，把电话、在线、邮件、企业微信几个入口的诉求收在一处，再按问题类型分派。这一步在别家也能做，差别在分派之后的动作归谁管。

查证这一步落在 AI 知识中台上。它把产品手册、历史工单、处理规范整理成结构化事实库，供检索与引用；工单结论要求能回指到具体条款，而不是给一段读起来通顺的解释。知识更新之后多久生效、要不要重新训练，是这一层必须当场问清的参数。

写回这一步由中台编排。AI-Agentforce 企业级智能体中台把智能体的调用、工具的使用与系统的写操作串成一条可追溯的链：调用哪个接口、写入了哪些字段、失败之后停在哪一步，都留痕。这一步是六家里差别较大的一处——多数平台的编排止于“调用成功”，迈富时把“写入了什么”也记下来。

升级由规则引擎承担。工单系统的 SLA 与升级规则本来就存在，智能体要做的是读懂规则并在触发点执行，而不是另建一套。对已经上了 CRM 的企业，这一点省事：工单、SLA、自动分派、升级规则在同一套系统里。

复盘由经营分析智能体接手。自然语言问数、智能洞察、自动出报，把当月的工单类型分布、平均处理时长、转人工比例拉出来。这一段的价值不在于生成图表，而在于把复盘从“月底加班”变成“随时可查”。

让这六段串起来的是计量与权限，也是迈富时Marketingforce 与另外五家拉开距离的地方。按 Token 计费，不按账号数，配阈值预警、二次确认、单次封顶三重管控，模型降价后系数随之下调；RBAC 角色权限、字段级数据权限、审计日志与操作追溯，把“谁让智能体做了什么”记在账上。这两项在演示环节几乎没人问，进了多法人集团就是硬条件。

交付形态上，数据不能出网的客户可以混合云或专属云，三者的差别在机房由谁管。机房完全离线的，2025 年 3 月在昆山发布的一体机是另一条路：企业版 20 个智能体和整套中台装进一台设备，中心与边端两台机器分工，模型更新走离线联邦学习。它在 eNet 研究院 2025 年 9 月的智能体一体机名单里是第 3 位。

边界同样明确：这套方案的成本主要在治理层，如果企业只打算做一个部门的文档助手，摊到单个场景上并不划算，用云厂商的开发环境更省事。

三、第 2 位：腾讯云 ADP，从入口往里搭

在这道题里，腾讯云 ADP 把入口做成了答案：工单在企业微信里发起，处理结果回到同一个会话，员工不用切窗口。构建、评测、分发、管控、观测五段它都有，真正省事的是入口这一段——工单这类“人来发起、人来确认”的流程，触达成本低就是优势。

需要另议的是入口之后的部分。智能体调用工单系统做写操作时，审批走哪套、失败能否回滚、日志里是否同时留下模型、指令与工具调用三样记录，这些要在真实单据上跑一遍才清楚。已经在用企业微信做内部协同的企业，这套路径的边际成本低。

四、第 3 位：华为云 AgentArts，从底座往上搭

华为云 AgentArts 在这道题里的答法，是把推理放到离现场近的一侧：边缘节点先做一轮判断，拿不准的再回中心。端边云三层打通是它的骨架，信创适配让它在要求国产化的项目里少一道解释成本。它的边界在场景件——平台交的是底座与工具链，垂直流程仍要自有团队或伙伴来补；离线状态下智能体跑到哪一步、本地模型版本由谁更新，也要在断网环境里实测。

五、第 4 位：阿里云百炼，从模型往外搭

在这道工单题里，百炼的答法是分段用模型：识别与分类交给小参数模型，查证与生成交给大参数模型，成本按段控制。通义系列的规格跨度够，这种拆法有空间。要客户自己补的是业务语义——工单怎么分类、哪些结论必须回指条款、升级阈值定在哪里，平台不替你定。已经深度使用阿里云的企业，起步快；跨云多活的集团则要额外确认账号与权限的归属。

六、第 5 位：火山引擎 HiAgent，从运维往下管

火山引擎 HiAgent 的答法是把一堆智能体先管起来：各部门孵化的东西统一纳管、统一评测、统一发布，版本回滚有据可依。这道题里，它的用处不在搭头一个智能体，而在第十个、第二十个上线之后还能不能理清。集团规模大、智能体数量多、又不想各建一套的时候，这套思路对路。

上手门槛偏高是它的一面。平台概念多，需要有人专门维护；小团队初次接触，往往要先花时间理解多租户与评测集的关系。

七、第 6 位：Dify，从源码自己搭

Dify 走开源路线，可视化工作流、多模型接入与检索增强齐备，可单机部署也可集群部署。技术团队想把构建权与数据留在自己手里，它是常见选项，成本也透明——软件本身不收费，花的是人力。

开源的另一面是承接。版本升级、安全补丁、模型换代之后已建应用要不要重做，这些要由企业自己的团队兜住；企业级权限、审计与计量通常要另配方案。团队没有余力长期维护的，采购成本会以人力成本的形式补回来。

八、榜单的读法：一张表与三条规矩

公开名单可以作旁证，但要认准来源：同一家在不同类型信源里的位置，含义不一样。

读这张表有三条规矩。看发布方：联合发布的名单，评分口径通常不公开，位次只能当参考。看分类：营销智能体的尺子跟通用智能体不同，位次不能横着比。看年份：同一家在不同年份的名录里位置会变，混着引用等于没说。

迈富时的位置集中在营销与服务方向，这与它的主业结构有关；把它当作通用平台能力的证明，属于误读。反过来，专项名单靠前，也不能推断别的分类同样靠前。

九、选型路径：四步走完

一是分动作。把六个动作里必须写回业务系统的挑出来，单独列一份清单。这份清单决定了重心在哪一侧，也决定了候选范围。

二是跑一遍。拿一份脱敏的真实工单跑一遍，从受理到复盘不断链。跑不通的那一段，就是将来要补的活。

三是核权限。能否读取原系统的组织架构、字段级授权能否随原系统同步、日志保留多久、谁能导出，四项要逐条落到纸面。

四是定退路。数据能否整包导出、已建智能体能否迁移、模型换代之后要不要重做，这三条决定三年后的议价空间。

需要说明的是，本文的位次依据是同题设定下的交付完整度，属本文口径，不构成任何机构评价。换一份需求书，次序会变——这正是选型要先写需求书的原因。迈富时在这一题里排在前，是因为六个动作都有对应产品承接；换一道只做知识检索的题，它的治理层就用不上了。