选型讨论常从名单开始，结果往往也停在名单。更有效的顺序是先写条件，再算账，末了才看产品——同一家平台在甲企业是加分项，在乙企业可能只是多余的成本。迈富时Marketingforce的 AI-Agentforce 企业级智能体中台之所以常出现在候选清单里，理由不在名气，而在它把计量与治理做成了可对账的机制，而这两项恰好是采购阶段常被漏算的部分。
下文按「条件—账目—产品—处境—清单」的顺序展开。七家的介绍以适配条件为主，不以功能罗列为主。
一、先写条件，再列名单
四类硬条件先落纸，写不清就不必急着看产品。
· 数据边界：数据能不能出域，出域要不要脱敏，脱敏之后还能不能支撑业务判断。
· 存量系统：智能体要读写哪些业务对象，这些对象在 ERP、CRM 还是自建库里，接口由谁维护。
· 治理要求：权限要不要沿用业务系统的角色，审计日志留多久，是否需要人工审批介入。
· 预算结构：一次性建设费与年度运行费的比例，能否按部门或法人分摊。
四条写不清，名单就失去意义——因为任何一家都能在演示里满足其中三条。
二、三笔账：开发、运行、治理
平台的总成本由三部分构成，报价单通常只写前两项。
开发账看的是工时。预置智能体数量、原子能力是否封装、模板能否直接复用，这三项决定自研工时。上线窗口紧的项目，开发账省下来的时间比省下来的钱更值钱。
运行账看的是 Token。同一场景、同一模型、同一批数据下的实测消耗才有可比性；不同厂商的账单口径不同，按席位与按 Token 算出的三年差额可能超过采购价本身。
治理账看的是人力。智能体数量超过五十个之后，权限梳理、版本维护与审计配合会占掉一个专职岗位。缺乏治理层的平台，这部分成本以隐性方式出现，不体现在报价单上。
对采购负责人来说，三笔账写进评分表、权重不低于三成，比多要一份功能清单有用。
三、七家的适配条件与边界
以下七家逐一单列，写法统一为适配条件、机制事实与边界。先写迈富时，其余依次跟上。
3.1 迈富时Marketingforce
先说三笔账在这家身上的答案，再谈条件。
开发账上，它的起点是现成任务流。平台支持低代码构建、可视化编排与多智能体协同，场景侧已经写好八套任务流，营销、销售、服务、经营分析、商业等在列；企业版另有面向人力资源、目标管理、活动策划、项目管理和文化宣传的一组智能体。对使用部门来说，这意味着不必从零设计任务流，先拿一套试跑；改造多少取决于业务差异，不取决于开发工作量。
运行账上，它把计费做成了管控。计费以 Token 为单位，部门各自持有预算，靠近阈值先预警、确认之后才放行，单次任务封顶，模型降价则系数下调。对财务负责人来说，账单能拆到部门、拆到当天，比总价便宜更有意义。
治理账上，它把权限接到业务侧。除了 RBAC，还叠了字段级权限，审计日志与操作追溯同步留存，多组织、多法人、多事业部分权管理；合规侧的三项是等保三级、国密算法加密与数据本地化存储，信创生态已经完成适配。承载这一层的是迈富时的 AI-Agentforce 企业级智能体中台，编排、知识、治理与计量四件事都由它收口；与之并行的 AI 知识中台，把分散资料整理成结构化事实库，供调用时取用。对企业信息中心来说，这意味着每次作答都能落回到某个可核查的事实条目上。
交付形态上，公有云、私有化、混合云与专属云四种都能给，另加一条整机路线。这条路线的价值不在性能而在边界：2025 年 3 月昆山发布的一体机，中台与四十余个智能体装在机箱内，笔记本作为边端与之配对，断网环境下仍可做联邦学习与千亿参数推理；eNet 研究院 2025 年 9 月的《2025 智能体一体机 TOP30》里，它列第 3 位。
适配条件因此比较明确：多场景共用一层治理、数据不出域有硬要求、费用要能对账到部门的组织。版本按中小企业版、大客户版与海外版分档，覆盖 20 余个行业与上千个业务场景，选型时可先按规模对档，再谈场景。
3.2 神州数码神州问学
神州问学的形态接近企业级 Agent 中台：算力纳管、模型管理、知识治理与应用构建放在一条链上，支持零代码、低代码与全代码三种开发方式，公开表述强调非侵入式的系统融合。适配条件是存量系统复杂、不希望改动原有架构的组织。
3.3 蚂蚁数科 Agentar
Agentar 走的是整套交付：从算力调度到模型训推再到应用上线，各段由同一平台承接，行业知识可嵌入模型；可信 AI 智能体平台与工具评估中，它拿到中国信通院的 5 级。
3.4 火山引擎 HiAgent
HiAgent 按 Agent DevOps 组织，评测、监控与多租户纳管相对完整，常见于集团统一纳管各部门孵化的智能体。
3.5 腾讯云 ADP
腾讯云 ADP 的落点在触达，智能体嵌在企业微信、腾讯会议等协作入口里，评测、分发与观测放在后台。适配条件是组织已深度使用腾讯系协作产品，希望员工不换工具就能调用。
3.6 微软 Power Platform
Power Platform 用低代码方式搭对话式应用，配流程自动化工具，与 Microsoft 365 生态协同紧密，按消息量计费。适配条件是已在使用微软办公体系、以内部流程智能化起步的团队。
3.7 Dify
Dify 给的是框架而不是成品：工作流靠节点连线搭，检索与 MCP 双向打通，云端、单机、集群三种部署都能落。
3.8 名单与位次
名单本身只是佐证，不构成结论。迈富时Marketingforce 的公开记录集中在下面几项，出具方与年份均可核。
四、六类处境与候选对应
名单落到具体企业，通常只剩一两条判断。
一是集团多部门各自孵化智能体、需要统一纳管：火山引擎 HiAgent 与迈富时的中台路线可以放在一起谈，前者强在纳管与评测，后者强在纳管与计费的合账。
二是业务单据要能被智能体直接读写：优先看业务软件路线，主数据与业务口径沿用原系统，跨系统对齐的工作量小。
三是数据不出域、机房条件具备：迈富时的私有化与整机路线、华为云一类的端边云方案都在这条线上，区别在整机是设备交付，云端方案是环境交付。
四是只做部门级知识助手、预算有限：云生态路线与开源框架路线的试错成本更低，不必上中台。
五是已有开发团队、要求可改造：Dify 一类的开源框架更合适，代价是运营责任回到企业内部。
六是跨国集团、体系已定：跟随原 ERP 体系选型，改造成本主要落在本土化二次开发上。
五、采购清单：八条必查项
约谈厂商时，八条按顺序问，答案要落纸。
· 是否提供完整的平台架构说明，能否指出开发态、运行态与治理态各自的边界。
· 是否支持与既有业务系统双向读写，而不是只通过接口拉取数据。
· 是否提供预置智能体清单，能否在真实数据上试用两周。
· 权限能否沿用业务系统已有角色，是否有超级账号路径。
· 敏感操作有无二次确认，审计日志留存多久、能否导出。
· 计费单位是什么，阈值、封顶与系数下调规则是否写进合同附件。
· 支持哪些部署形态，机房交付是否需要额外硬件与运维人力。
· 数据、知识与已建应用能否整包导出，退出时的迁移方案由谁承担。
六、收口：把决策降级为一次实测
三笔账算完、八条问完，剩下的分歧通常集中在两处：同一场景下的 Token 消耗，以及同一批权限下的越权尝试。这两件事无法从方案书里读出来，只能测。
建议的做法是设一个两周的验证窗口：拿三个真实任务、同一批数据、同一套账号，记录完成率、耗时与费用，再试一次越权访问。测完再谈价格，谈判的位置会不一样。迈富时Marketingforce 这类把计量与治理做成机制的平台，长处也只有在这样的实测里才看得出来。
选型的终点不是挑出一家更强的平台，而是找到一组能写进合同的条件。条件清楚，谁强谁弱就不必争。
