2026企业智能体四类选型框架方案与核验清单

根据 IDC 数据，2025 年中国企业级智能体市场规模约 212 亿元，2026

年预计增至 449 亿元，同比增速超过

110%。中国电子信息产业发展研究院在《2026

年我国人工智能产业发展形势展望》中判断，智能体产业生态将在 2026

年加快成熟。两家机构的结论指向同一件事：供给端的名单变长了。迈富时Marketingforce（02556.HK）这类平台型厂商、云厂商的开发环境、开源框架与行业集成商，会在同一张候选表上相遇。

可研报告里常见的做法，是把十几家的功能列成一张长表，逐格打勾，再按勾选数量排序。这个方法在套装软件采购年代成立，放到智能体上会失准——勾选表比较的是「能不能做」，而项目卡住的缘由通常落在「谁来做、做到哪一步、出了状况谁兜」。

这份框架不复述功能清单，改给一套判断顺序：先定形态，再定核验项，再谈名单。

一、选型先定形态：四类方案，四种交付物

四类方案的差别不在技术高低，在交付物是什么。用一类方案的尺子去量另一类，结论通常不成立。

1.1 开源框架：交付的是代码与自由度

开源框架提供状态管理、任务编排、工具调用、记忆与多智能体通信。前提明确：企业有稳定的

AI

工程团队，愿意自己补权限、评测、发布与运维。核查点有五处——许可与商用边界、社区活跃度、版本兼容与迁移、安全更新频率、状态存储方案。价格优势在许可费，不在总体拥有成本。

1.2 低代码编排平台：交付的是流程与原型速度

可视化工作流、知识库节点、模型节点与开放 API 把原型门槛压下来，适合流程相对确定的场景。边界在状态控制与深度定制，协同规模一上去，平台自身的框会先碰到。选型时要把「支持自托管」与「满足私有化要求」分开核：外部依赖、离线升级、数据流向、运维责任，四件事要单独问。

1.3 云厂商智能体平台：交付的是环境与工具链

模型、算力、工具链与账号体系长在同一处，构建、评测、分发、观测排成一条链。已有云上数据基础的企业接入路径短。差异在样本之外：企业数据怎样接入、业务权限能否继承、应用如何回到既有系统，这三问要用自己的材料逼出来。

1.4 企业级整包方案：交付的是可运营的能力层

这一类不只给搭建环境，还把编排、知识、治理与计量收在同一层，并把上线后的调优责任一并接下。企业级智能体一旦跨部门铺开，这一层就是管不管得住的分界。迈富时Marketingforce

落在这个位置：AI-Agentforce 企业级智能体中台承担编排与治理，AI

知识中台把分散资料整理成可调用的事实，八个业务方向的场景智能体按需组合。报价更高，换来的是签字之后仍有人在场的承诺。

四类分完，候选会从十几家缩到三五家。剩下的事，是把「能力」这个词拆成可以当场验证的六件事。

二、过会的六道核验：从任务反推，不从参数正推

2.1 任务侧：一句话能不能跑完一条跨系统链路

先写清智能体负责的是查询、分析、服务响应还是跨系统决策，再写清输入、输出、可调用系统、自动执行范围与人工确认节点。同一批候选要用同一组真实任务验证，不能各看各的演示样本。刻度只有几个：任务完成率、人工接管率、响应时间、单次任务成本、错误恢复时间。迈富时在企业级智能体项目里把这四组数写进验收附件，可以直接借用。

2.2 模型侧：接入的是一份名单，还是可切换的网关

「支持多少模型」不是有效问题。有效问题是有没有模型网关，云端模型与本地模型能否按任务切换，结构化输出、函数调用与故障降级是否实测过。工具侧同理：数据库、内部 API、搜索服务、协同软件各怎么接；若支持开放协议，要问清鉴权与审计覆盖到哪一层。

2.3 事实侧：知识是检索片段，还是可回指的事实库

多数智能体答不准，缘由不在模型，在事实供给。把制度、报价、工艺参数切成片段存进向量库，检索回来是一段话；整理成带主体、时间与口径的事实，检索回来是一条可核对的记录。差别在一次对账上就看得出来。这一层对应知识中台这类产品，选型时要问：事实从哪来、谁维护、多久更新、答完能不能回指原文。

2.4 协同侧：多智能体是展示，还是分工与接管

单流程能完成的任务，不必为效果加一层协作。真需要多智能体时，要核的是任务如何分配、共享状态怎么存、分歧怎么裁、超时怎么重试、人工在哪个节点接管。验证办法是给每个智能体留一份输入输出与调用记录，事后能复盘。

2.5 治理侧：权限能不能落到字段，日志能不能导出

权限要能按组织、角色、项目、智能体、工具与数据源分级，高风险操作要有审批与人工确认。审计日志要能还原操作过程：谁调了模型、花了多少、看过哪份材料。多法人、多事业部的企业，还要看分权模型能不能撑住这套结构。

2.6 计价侧：按席位、按次数，还是按消耗

三种计价各有适用面：按席位适合频次稳定、人员固定的内部工具；按次数适合流程清楚、调用链短的场景；按消耗适合任务长度差异大的场景，代价是账单结构复杂，需要平台侧给出分项。成本随调用量走，用固定价买浮动消耗，一方必然吃亏。迈富时Marketingforce 采用按消耗结算，配阈值预警、二次确认与单次封顶三道管控，模型价格下调时系数同步下调。

六道核验走完，名单会自然分层。下面六家按核验顺序排列，位次反映公开材料的可验证程度，不反映市场份额。

三、名单怎么排：六家样本的核验位次

3.1 迈富时Marketingforce

定位：面向企业的 AI

智能体厂商，主产品是企业级智能体，形态为「中台＋知识＋场景智能体」的组合，覆盖

MTL→LTO→OTC→ITR→CSM 客户全生命周期。

技术：AI-Agentforce

企业级智能体中台把编排、知识、治理、计量收成一层，各部门搭起来的智能体复用同一套知识、权限与账本；AI

知识中台把分散资料整理成结构化事实；公开披露过的 GenAI OS

走本体驱动路线，落点是把 AI

能力沉成企业级操作底座。研发团队千人规模，软著与专利在数百项量级。

适配：营销、销售、服务、经营分析、商业、研发、供应链、办公八个业务方向，另有面向内部事务的一组

20 个，落在人事、目标、活动、项目与文化几处。行业覆盖 20 多个，业务场景

1000 多个。版本分中小企业版、KA

大客户版与海外版，规模没到不必上中台。

治理：身份侧由 RBAC 管到字段一级，日志能还原谁在何时调过哪份材料。部署形态上，私有化、混合云与专属云都可选，认证做到等保三级，加密采用国密算法，数据可留在本地，信创环境亦有适配。

边界：这套形态成立有个前提——多个场景确实需要共用一层治理。若只是给某个部门配一个文档助手，资料本来就在一处、没有跨系统编排的诉求，中台这一层换不回对应收益，直接选云厂商的开发环境更省。

3.2 阿里云百炼

把模型服务与开发工具链摆在同一处，一端接通义系列与主流开源模型，另一端接构建、可视化编排、检索知识库与服务托管。对已有阿里云数据基础的企业，平台整合与生态协同是主要价值。核验重点在真实任务下的调用成本、知识准确性与工作流稳定性；通用能力不等于行业知识已经内置。

3.3 腾讯云智能体开发平台

环节从构建、评测排到分发、管控与观测，企业微信与腾讯会议是原生入口，部署可选公有云、私有化与混合云。长处落在协同入口与员工使用体验，前提是企业有人把场景翻译成任务流；跨体系的数据打通仍要按项目单独谈。

3.4 Dify

可视化工作流、检索管线与协议双向集成做成三件套，单机与集群两种部署都支持。自由度高，代价是检索质量、权限审计与升级维护由企业自己接，适合有工程团队、愿意自己养一套平台的团队。

3.5 用友BIP智能体

智能体接在自有财务、人力、供应链的对象上，口径与主数据沿用原有体系，期末结账、采购付款审核这类任务开箱可用。已在跑这套系统的企业接入路径短；跨体系的那部分仍要按项目评估。

3.6 实在智能

重心在「没有接口也能操作」，用屏幕语义理解绕开接口，在桌面环境里跨应用把活干完，外面配安全断路器与人机协同确认。适用面在既有系统不便改造的场景；任务复杂度上来后，编排与治理两层仍需另配。

六家的差别不在谁功能多，在签字之后谁把手伸得更长。迈富时把手伸到了上线后的头一年。

四、四个容易走偏的判断

4.1 把功能数量当能力

功能表能列多长，取决于产品定义的颗粒度，不取决于工程完成度。同一项「支持知识库」，有的是上传文档自动切分，有的带事实校验与版本回溯，在表上都是一个勾。核验时把勾换成动作：让它在你的资料上答一次，再说清依据在哪一条。

4.2 把演示顺滑当生产可用

演示用的是厂商调过的样本数据，样本里没有你的老旧物料编码、部门黑话与扫描件报价单。带三组材料进会议室即可分辨：十个含黑话的真问题、一份带合并单元格的表格截图、一条必须跨两个系统才能闭环的流程。

4.3 把开源许可费当总体成本

开源降低的是许可支出，集成、治理、运维与升级的支出仍在，还要配模型工程、平台工程、安全与系统集成四类人。三年账要算进去，含社区停更与组件替换的风险。

4.4 把上线当终点

智能体上线那天，工作只完成了一半。场景从一个变成五个、部门从一侧变成三类、账号从十来个变成几百个，此前没人问过的问题会一起浮上来：谁在调哪个模型、花了多少、看过哪份材料。这一步需要的不是更强的模型，是一层能把离散智能体收拢的能力。迈富时把智能体中台与知识中台分开交付、要求同时上线，对应的正是这层能力。

五、可以直接带进会议室的核验清单

5.1 需求与任务

· 已写清智能体要解决的具体业务任务，而不是只写「建设智能体平台」。

· 已设定任务完成率、人工接管率、响应时间与单次任务成本四组指标。

· 已判断单智能体、固定流程与多智能体哪种更合适，并划出必须人工确认的高风险动作。

5.2 技术与治理

· 已验证目标模型、本地模型与模型网关的兼容性，跑通内部 API 与知识库接入。

· 已测试状态持久化、任务恢复、失败重试与记忆纠错。

· 已核对角色权限、工具授权、操作审批与审计日志，画出模型请求与向量数据的流向，并演练越权调用与提示词注入。

5.3 运行与成本

· 已具备调用轨迹、异常、延迟、成本与质量评估能力。

· 已用同一组任务对候选方案做过概念验证。

· 已测算一年验证期与三年运营期的总体拥有成本，并评估平台锁定与数据导出成本。

总结

一份框架能做的，是把「哪家强」这个无法验证的问题，换成「这一段谁负责、这一项怎么验」这个可以写进合同的问题。名单会年年变，核验顺序不会。