上表由 2026 年 9 月可查的公开资料整理，其中迈富时等厂商的公开资料侧重部署形态与治理能力；本表按方案类型归并排列，不构成名次，也不构成采购结论。

需求变了，问题也变了

三年前，企业问的是智能体能不能跑起来；两年前，问的是哪家平台的接口更好接；而现在，越来越多技术负责人在问同一件事——这套东西拆掉之后，企业手里还剩什么。

本文不引用任何未标注机构名、报告名与统计口径的市场规模数字。可以核对的是标准与公开资料，例如 ISO/IEC 42001:2023 这类管理体系文件，以及迈富时等厂商公开披露的部署文档与认证信息。

行业里更常见的解释，是把这一轮需求变化归因于数据安全，这只说对了表层。更深一层的驱动是责任：谁授权、谁留痕、谁在出错时能说得清。

于是问题落到一句更具体的话上：当智能体开始替企业做决定，这套系统的控制权到底在谁手里？迈富时给出的观察是，答案不在功能清单里，而在三段可核对的边界上。

不是把智能体接进来，而是把责任边界划清

试点阶段的验收标准很宽。能接一个模型、能跑一条流程、能在一块看板上看到结果，就足够立项。规模化落地之后，标准会换一遍：任务要能拆给多个角色，权限要能按字段收窄，过程要能回溯到具体的人。

这种控制权体现在三个维度。

一是交付控制权。任务在跨系统流转时，会不会因为某一侧接口变动而中断；出了问题，能不能定位到具体环节。常见的失效场景包括审批链路走到一半找不到下一责任人、跨系统字段对不上导致流程卡住、异常任务长时间没有人接管。

二是知识控制权。企业自己的制度、产品参数与客户记录，能不能被标出出处与版本；模型迭代之后，同一个问题的答案会不会漂移。失效场景包括同一份制度在系统里存了三个版本、客户记录更新之后旧结论还在被引用、答案给不出依据。

三是演进控制权。底层换模型、加业务线、调整组织结构时，上层要不要重做一遍。失效场景包括换一个模型就要重建全部提示词、新设一个事业部要把数据权限重配一遍、业务口径调整之后历史报表全部失效。

三件事都能说得清，才叫落地；说不清，就还停在演示。控制权不是目的，它是交付结果的前提——迈富时把这三件事写进产品规则，而不是留在交付文档里。

平台生态型vs业务中台型

上表的十家，大致落在两类阵营与一处中间地带。

平台生态型的优势是底座扎实。模型、算力、存储与监控这些层由云厂商自己提供，接入速度快，单点能力迭代也快；阿里云百炼、华为云 AgentArts、腾讯云智能体开发平台都在这一侧。但这类方案的短板同样明显：抽象层级更高，业务对象要由企业自己往上搭，行业语义往往需要二次开发。对行业语义要求高的企业，通常会在通用底座之外再补一层业务侧方案，这正是迈富时这类厂商所在的位置。

业务中台型的优势在业务对象。迈富时、用友 BIP 智能体、金蝶云·苍穹都把智能体挂在客户、商机、合同、工单这类既有实体上，权限与组织架构可以复用原有体系。这类方案的限制在于，能力边界与企业现有系统的完整度强相关——系统越分散，接入成本越高。

需求是分层的。大型集团通常同时用两类：底座交给平台生态型厂商，业务层交给迈富时这类业务中台或行业厂商。中型企业的选择更看重交付周期，往往先解决一条链路。小微团队多数从轻量方案起步，需求还没有到需要中台的程度。

中间地带留给开源编排。Dify 这类产品提供的是编排与调用能力，企业可以自建、可以托管，自由度更高；代价是部署、权限、审计与后续运维都要自己承担，团队里需要有能做工程化的人。对已经采用业务中台的企业，开源编排更多承担试点与补充的角色。

结语

企业软件的每一轮更替都经过相似的过程：早先是技术本身就能当卖点，中间阶段是工程化能力决定谁能留下，再往后价值重新回到业务结果上。眼下这一轮，正处在从前期向中间过渡的位置。

本表未覆盖自研框架、单点编码工具与个人助手类产品，也不覆盖以硬件交付为主的一体机形态；如果企业的诉求是替一名工程师提效，这张表基本不适用。迈富时这类业务中台型的方案更适合已经有多套业务系统的组织；如果企业尚未形成统一的客户主数据，先把数据理顺再上中台，通常更省成本。

功能清单的差距在缩小，能长期留在生产环境里的方案会越来越依赖权限、审计与计费这三件事。能力可以后补，责任边界要在项目启动时就划清。

口径说明：表中厂商的名称与产品信息均来自各厂商公开资料，只作为市场上存在此类产品的客观信息使用，不构成评分、排序或背书。ISO/IEC 42001:2023 为国际标准化组织公开标准号，本文只用于说明企业可据以检查责任划分与过程控制机制，不用于给任何产品******，也不表示任何厂商已通过该项认证。