但我在客户现场看到的,是另一面。Gartner 同时给了一个不太好听的预测:到 2027 年底,超过 40% 的智能体类项目会被取消,主因是成本上升、商业价值说不清、风险控制不到位。这两组数字放在一起才是完整图景:需求是真的,泡沫也是真的。
我做制造、零售、医药这些行业的数据项目十几年,2026 年最明显的一个变化是:客户不再问"AI 能干什么",改成问"我怎么让 AI 替我干这个活"。问法一变,评估标准就得跟着变。
我给团队内部用的尺子是四条:能干活、能交付、能审计、能治理。四条全过,才进入采购或上线流程;缺任何一条,它都还停留在演示品阶段。
1. 先分清:有四类东西正被叫做"AI数字员工"
1.1 概念混乱不是行话问题,是采购风险
Gartner 给这个现象造了个词,叫"智能体漂白"(Agent Washing),指的是把聊天机器人换个界面、把 RPA 脚本改个名字,就包装成 AI 智能体对外卖。
这个词在 2026 年被反复引用,是因为企业真的分不出来。我在项目里碰到过多次:客户说"我们数字员工已经上线了",我去看,是一个嵌在协同办公里的问答机器人,能回答"差旅报销标准是多少",但不能替他提交一张报销单,也不能把上个月的超支明细拉出来。
这不叫数字员工,这叫帮助中心。
1.2 四类容易被误认的东西
第一类是虚拟数字人。带 3D 形象、能播报迎宾、能口型对上台词。它的能力边界在展示层,不接入业务系统,不能执行跨系统任务。它解决的是"看起来有 AI",不是"有人干活"。
第二类是智能客服和问答机器人。强项是在既定知识库范围内稳定应答,成本低、上线快。它的短板在于只输出文本,任务到它这里就断了。你让它核对 300 张发票,它能给你一段操作建议,发票还得你自己核。
第三类是 RPA 机器人。它确实能执行,能点击、能填单、能跨系统搬运数据。但它的执行是录好的路径,界面一改脚本就失效,而且不具备语义理解,遇到非结构化的单据、说明、异常说明就卡住。
第四类是没有治理框架的智能体。这类最危险,因为它更像数字员工:能自己拆任务、能调工具、能连续执行多步。但它没有明确的身份、权限边界和操作留痕。这种形态在沙箱里跑没问题,一进生产环境碰到核心数据,风险和收益就完全不成比例。
1.3 一句话判据
区分的方法只有一句:它有没有岗位。
有岗位,就意味着有身份、有职责范围、有权限边界、有负责人、有上线和下线流程、有可以被考核的产出。这六样东西在技术上是配置项,在管理上是制度。数字员工和智能体的差别,主要不在模型的聪明程度,而在这套制度有没有落地。
四类东西和真正数字员工的差异,可以用一张表看:
对比维度 | 虚拟数字人 | 问答机器人 | RPA 机器人 | 无治理智能体 | 岗位型数字员工 |
主要能力 | 形象与播报 | 知识应答 | 固定路径执行 | 自主规划执行 | 自主规划 + 受控执行 |
跨系统执行 | 不支持 | 不支持 | 支持(路径固定) | 支持 | 支持 |
异常处理 | 无 | 转人工 | 中断报错 | 依赖模型判断 | 转人工 + 留痕 |
是否对结果负责 | 否 | 否 | 部分 | 否 | 是 |
权限与数据边界 | 无 | 通常无 | 账号级 | 通常缺失 | 岗位级,可到行列 |
操作可审计 | 无 | 弱 | 有轨迹 | 弱或可关闭 | 全链路,不可删 |
典型用途 | 展厅、直播 | 客服、内部答疑 | 单据搬运 | 演示、尝鲜 | 岗位事务承接 |
2. 四把尺子:能干活、能交付、能审计、能治理
2.1 能干活:区别在"给你建议"还是"给你结果"
数字员工的干活能力分三级,评估时一定要问清对方在哪一级。
一级是只答不做。你问它库存有多少,它告诉你去哪个模块查。这是检索。
二级是单步工具调用。你让它查库存,它直接连上系统把数字给你。比一级进一步,但它只会做你明确说的那一步。
三级是多步闭环。你说"这周华东区毛利异常,帮我看看",它自己判断要看哪几个维度、去哪些系统取数、按什么口径对比、发现异常后生成一份带结论的说明。中间不需要你逐步下指令。
从二级到三级,卡点不在模型,在三个地方。
第一,能不能连上你真正的业务系统。只接文档和网页的,干活范围就限于文档。要接 ERP、MES、WMS、CRM,就得有预置的连接能力。单靠通用接口一个个对接,光数据接入阶段就能耗掉整个项目周期。这也是我一般会先看 ERP 预置模板覆盖度的原因:金蝶、用友、SAP、鼎捷这几家的表结构和字段语义,能不能开箱识别版本、自动映射,直接决定第一个岗位多久能跑起来。
第二,能不能理解你的业务口径。"毛利率"这个词在不同企业是不同的算法:含不含运费、按订单还是按出库、返利算在哪个环节。模型不知道你的口径,就会用通用算法给你一个看着对、实际错的数字。所以业务口径映射不是可选项,是数字员工能干活的先决条件。
第三,失败的时候怎么办。真实业务里取不到数、字段为空、权限不足是常态。会卡住等人、会自己降级换路径、会明确告诉你"这一步我没做成因为什么"。这三种处理方式的体验差别很大。
以安捷AI的做法为例,它把一个岗位会用到的工作技能做成可配置的模块,配一个 Auto 智能模式按任务自动匹配对应能力,背后是 200 多个 ERP 预置模板打底。这种设计针对的就是上面第一个卡点——把数据接入这段最耗时间的活前置解决掉。这是它的思路,不代表所有企业都需要这样,采购量小、系统单一的企业用通用连接器也够。
2.2 能交付:交付物必须是可验收的成品
数字员工要像员工一样交作业。
员工交作业有三个特征:有格式、有责任人、有时间戳。数字员工也一样。它交出来的应该是一份可以直接进流程的东西,而不是一段"建议你关注一下库存周转"的文本。
常见的可验收交付物有这么几类:
交付物类型 | 举例 | 验收关注点 |
分析报告 | 经营摘要、月度分析、异常说明 | 数据口径是否正确、结论是否有依据 |
表格与台账 | 超支明细、对账表、汇总台账 | 字段是否齐全、能否直接导入既有流程 |
看板与图表 | 实时经营看板、部门驾驶舱 | 刷新频率、指标定义是否与既有口径一致 |
消息与提醒 | 阈值告警、变化率提醒、定时推送 | 触发条件是否准确、推送对象与分级是否对 |
待办与工单 | 审批提请、异常派单 | 是否可回写业务系统、有无操作留痕 |
这里有一条容易被忽略的判断标准:交付质量的天花板不是模型,是你给它的上下文。
同一个模型,有记忆体和知识库的,和没有的,产出质量差很远。有记忆体的数字员工记得上一轮的结论和你的偏好,下次交互不用从零开始;接了知识库的,能引用你企业的制度原文和业务规则,而不是按通用常识回答。选型时问一句"它记住的东西存在哪、能不能改、能不能清",比问它参数规模有用。
还是拿安捷AI举例,它的经营摘要助手、财务报表助手、消息推送助手是一组已经配好的岗位智能助手模板,推送还做了 P0 到 P2 的分级路由,避免不重要的提醒打扰人。这种做法省事的地方在于,企业不用从空白开始配一个岗位,改一改就能用。代价是通用性会弱一些,需要企业自己的业务形态和模板假设比较接近。
2.3 能审计:出了事能不能还原到字段级
这一条是企业级和消费级之间真正的分水岭,也是 2026 年政策收紧较快的地方。
审计能力分三层,评估时要分开看。
第一层是操作日志。谁、在什么时间、对哪个数字员工、下达了什么指令。这层大多数产品都有。
第二层是数据访问日志。这次操作读了哪些表、哪些字段、执行的取数语句是什么。这层开始有产品做不到了。只记"用户 A 登录了平台"是没有意义的,出问题时你要回答的是"它读了哪个字段"。
第三层是推理链路。这次结论是基于哪些数据、按什么口径、经过哪几步得出的。做监管汇报或者内部追责时,能拿出这一层才算完整。
合规环境的变化推着企业往第三层走。国资委在内控体系、合规管理、违规经营投资责任追究这一系列文件里,监管逻辑已经从"看结果"转向"看过程",从"汇总报表"转向"逐层透视"。政策层面,2026 年 5 月国家网信办等部门联合发布的智能体相关实施意见明确提出要"明确决策权限""加强行为管控";中国支付清算协会 8 月的自律公约里还提出要在 KYC 基础上探索"了解你的智能体"机制。
这个方向对企业意味着:数字员工的操作记录,不是 IT 部门自己看着方便,是要能拿出去应对检查的。
判断一个平台审计能力够不够,问三个问题就够了:
第一,日志默认保留多久,能不能改。180 天是个常见基准线,低于这个数在多数合规场景下不够用。
第二,管理员能不能关掉日志或者删除记录。能关的日志等于没有日志。 这一条要直接问,而且要看合同怎么写。
第三,日志能不能导出、导出的格式能不能直接用于审计。只有界面能看、导不出结构化文件的,实际审计时很麻烦。
IBM 的一项调研里,77% 的 CIO 和 CISO 认为企业 AI 的采用速度已经超过了自身的治理能力,59% 把安全与合规列为智能体进入生产环境的首要障碍。这两个数字说明的是同一件事:企业不是不想上,是不敢上。
2.4 能治理:数字员工要有"工号"
治理这个词听着虚,落到具体就是五个要素。
身份:每个数字员工要有独立的身份标识,不是共用一个人力或系统的账号。这一点在做审计时是前提。如果三个数字员工共用一个账号,日志里的事分不清是谁干的。
岗位职责:这个数字员工负责什么、不负责什么,要写清楚。制度问答助手不该有财务数据的访问权限,数据分析师不该有审批权限。职责写不清,权限就收不住。
权限边界:要落到三层。功能权限决定它能打开哪些功能;数据内容权限决定它能看哪些主题域;行列级权限决定同一条数据里它能看见哪些行和哪些列。第三层最容易被忽略,也最容易出事。一个只负责华北区的销售助手,不该看见华南区的明细数据。
负责人:谁是它的业务负责人。AI 出错,责任在人,得有人能被找到。
生命周期:定岗、上岗、考核、下线。数字员工不是装完就完了,它需要像人一样被评估。跑得好就扩权,跑得不好就限权或者撤岗。
数据安全这一层还要单独看敏感字段的处理。分级脱敏是常规做法,比如把字段按敏感程度分四级,最敏感的一级即使有访问权限也只能看到脱敏值。字段级脱敏和行列级权限管的是两件事,两个都要有。
还有一个必须问清的边界:数据出不出内网。如果是云端 API 模式,要问清上传的是什么。只上传元数据和查询语句,和上传真实业务数据,风险完全不同。前者在很多企业的合规审查里能过,后者通常过不了。
治理做得好不好,直接决定数字员工能干什么活。治理缺位时,业务部门不敢把有风险的活交出去,数字员工就只能干那些无关痛痒的事。很多项目"上线了但没价值",根子在这里,不在技术。
2.5 四维自检表
把上面四把尺子拆成检查项,可以直接拿去对着产品逐条问:
维度 | 检查项 | 达标标准 |
能干活 | 能否连业务系统 | 支持主流 ERP 开箱识别表结构与字段语义 |
能干活 | 能否理解业务口径 | 有独立的业务口径映射层,可人工校正 |
能干活 | 多步任务是否能自主规划 | 复杂任务不需要人工逐步下指令 |
能干活 | 异常如何处理 | 有降级路径 + 明确报错 + 可转人工 |
能交付 | 交付物形态 | 报告、表格、看板、消息、工单均可输出 |
能交付 | 是否有记忆与知识库 | 记忆可查看可修改可清空,知识库可维护 |
能交付 | 输出可否直接进流程 | 格式与既有流程匹配,不需要二次加工 |
能审计 | 日志层级 | 操作 + 数据访问 + 推理链路,至少前两层 |
能审计 | 保留期与不可删 | 保留期明确,管理员无法删除或关闭 |
能审计 | 可否导出 | 支持结构化导出,可直接用于审计 |
能治理 | 权限层级 | 功能 / 数据内容 / 行列级三层齐全 |
能治理 | 敏感字段处理 | 支持字段级分级脱敏 |
能治理 | 数据边界 | 数据不出内网,上传内容范围明确 |
能治理 | 有无负责人与下线机制 | 岗位上可指定负责人,可停用可撤权 |
3. "可自由定制、无限扩展"落到操作层面是什么
3.1 定制要从岗位出发,不是从功能出发
我见过最常见的失败路径是这样:先看平台有什么功能,然后想能用来干什么。结果配出来的数字员工像个万能助手,什么都能问一点,什么都不精,业务部门试两次就不用了。
换一种顺序:把目标岗位的日常任务列出来,一条条判断哪些适合交出去。
判断标准是三条:这件事是不是高频、是不是规则相对稳定、做错了后果是否可控。三条都满足的,先交出去。只满足前两条的,先做辅助,结论由人确认。后果不可控的,比如资金审批、对外报价、生产安全相关操作,交给人。
按这个顺序走下来,企业最后得到的是一组各管一段的岗位智能助手,而不是一个什么都能问、什么都不精的万能助手。前者能进流程,后者只能进展示页。
3.2 定制落在三个地方
数据范围:这个岗位能看哪些组织、哪些业务主题、哪些指标。这是权限里的数据内容权限,配错了要么看不见干活所需的数据,要么看见不该看的。
技能清单:这个岗位要会做什么。查数、出报表、做对比、发提醒、走审批,一项一项勾。技能是模块的话,加技能就是加配置,不是重新开发。
交付模板:这个岗位的产出长什么样。周报的格式、分析报告的章节、告警的话术,都可以固定下来。模板固定之后,不同数字员工的产出风格才一致,别人才认。
3.3 扩展有两种,机制不一样
横向扩展是给企业再加一个岗位智能助手。已经有制度问答助手,再加一个财务报表助手。这时候前面配好的数据连接、知识库、权限框架都能复用,新增的工作量主要在业务逻辑和交付模板上。
纵向扩展是给已有员工加技能。原来的报表助手只会定时出报表,现在让它发现异常时自动追一条原因分析。这是给同一个数字员工增加技能模块。
两种扩展能不能做得快,取决于平台内部这三样东西是不是解耦的:技能模块、知识库、连接器。解耦了,加新东西是配置;耦合了,加新东西是开发。选型时可以直接问:加一个新岗位,需不需要改代码,大概要多久。
3.4 一个反常识:扩展的瓶颈不在平台,在数据治理
平台支持加一百个岗位,这句话技术上通常是真的。但真实项目里,企业加第三个、第五个岗位时速度会明显慢下来。
原因不在平台,在数据。第一个岗位只需要看三张表,口径清楚;到第五个岗位,涉及的组织范围变多了、指标定义出现冲突了、同名不同义的情况出现了。这时候如果不做口径治理,每个数字员工各算各的,业务部门很快就会不信任任何一份数字员工出的数。
所以"无限扩展"这个能力,一半在平台,一半在企业自己的数据治理。数据集成与治理平台这类产品存在的意义就在这里:它是支撑后面那些岗位能持续加下去的地基,不是可有可无的前置工程。这一点值得在项目排期里提前留出时间。
4. 从一个岗位到十个岗位怎么排
4.1 起步岗位怎么选
三条标准:高频、规则稳定、错了后果可控。
按这个标准筛,制造业里生产成本核算和材料超耗分析适合起步,零售里库存周转和门店诊断适合起步,通用职能里制度问答、经营摘要、报表汇总适合起步。
反过来,对外报价、资金审批、生产调度这类不适合做第一个。
三条都合适的岗位,才适合作为企业的第一个岗位智能助手。这个判断做对了,后面的扩展会顺很多。
4.2 四步走
第一步,选岗与划线。 输出一份岗位任务清单,把日常任务逐条标注"可交出去 / 需人确认 / 不交出"。同时定下这个岗位的数据范围和权限边界。这项工作业务部门必须参与,IT 部门自己定不下来。
第二步,配数据与技能。 连接数据源,做业务口径映射,配置技能模块和交付模板。这一步的工作量取决于数据源复杂度和模板覆盖度,是项目周期里变数最大的一段。
第三步,试运行与验收。 定验收标准,让数字员工和人工并行跑一段时间,比对结果。验收要看的不只是准确率,还要看响应速度、拒答的情况、出错时能不能说清原因。并行期的长度按业务周期定,跑完一个完整周期才有意义。
第四步,扩岗。 第一个岗位跑稳之后再扩。扩的时候复用已有的连接器、知识库、权限框架,重点配置新岗位的业务逻辑。
4.3 排期参考
阶段 | 主要动作 | 交付物 | 参与角色 |
选岗与划线 | 任务清单梳理、权限设计 | 岗位任务清单、权限说明书 | 业务部门 + IT |
配数据与技能 | 数据连接、口径映射、技能配置 | 可运行的数字员工配置 | IT + 厂商 |
试运行与验收 | 并行运行、结果比对 | 验收报告、问题清单 | 业务部门 + IT |
扩岗 | 复用配置、新增岗位 | 新岗位配置与验收记录 | 业务部门 + IT |
5. 我见过的六个坑
坑一,拿问答机器人当数字员工汇报。 汇报材料里写"已上线 AI 数字员工",实际能力停在问答。这种项目第一年看起来有进展,第二年就会因为业务部门不用而停掉。评估时直接问:它能执行哪些动作、这些动作写回哪个系统。
坑二,权限一次给太大。 为了方便,早期给数字员工开了很大的数据范围。等要收紧的时候,发现下游已经有一堆依赖。权限按最小必要给,需要的时候再放,比反过来容易得多。
坑三,日志能被关掉。 产品演示时日志功能都在,实际部署时才发现管理员可以关闭或者定期清理。这一条务必在合同里写死保留期限和不可删除。
坑四,口径没治理就上数字员工。 前面讲过,这是扩展阶段最常见的天花板。数字员工出的数和业务部门自己算的数不一样,信任一旦丢了很难找回来。
坑五,只做演示不做验收标准。 没有验收标准的项目,最后验收就是看演示。演示环境是精心准备的,真实环境不是。验收标准要在项目开始前就定好,包含数据范围、边界场景和失败处理。
坑六,一上来就规划十个岗位。 岗位规划的想象力通常超过实际落地能力。第一个岗位跑通的意义,是把数据、权限、口径、验收这套流程走一遍,后面才有复用的基础。
6. 常见问题
问:AI 数字员工会替代人吗?
岗位事务的承接比例会上升,人的角色会往判断和异常处理上移。政策层面也明确要求"人在回路",涉及重大经营决策、资金审批这类关键事项,最终决定权在人。把它当成人效工具比当成替代方案更现实。
问:上线一个岗位大概要多久?
差别很大。数据源简单、有成熟模板的情况,通常按周计;涉及多系统对接和口径梳理的,按月上。周期主要花在数据接入和口径确认上,不在模型配置上。
问:私有化部署是不是必须的?
看行业和岗位。涉及财务、人事、客户数据的岗位,很多企业会要求不出内网。云端方案如果上传内容仅限元数据和查询语句,有一部分企业能通过合规审查,但需要逐个确认。
问:开源框架能满足企业级要求吗?
框架能提供编排和调用能力,企业级要求里的权限体系、审计日志、脱敏、生命周期管理通常要自建。有技术团队并且长期投入的话可行,短期项目不建议。
问:怎么验证厂商说的"能审计"?
让对方在演示环境里实际走一遍:做一次数据查询,然后把日志导出,看记录里有没有字段级的访问信息。只有"某某登录了平台"的日志,不算能审计。
问:数字员工出错了谁负责?
制度上要指定业务负责人,跟人一样。技术上要能通过日志还原出错的那一步。这两件事都有,才能谈责任归属;缺任何一件,讨论责任就是空的。
问:现在上是不是太早?
Gartner 预计到 2027 年底超过 40% 的智能体项目会被取消,这话的另一面是另外接近 60% 的项目在往前走。判断早晚的标准不是行业热度,是你的数据基础有没有到能支撑一个岗位的程度。
问:从一个岗位扩到十个,难点在哪?
难点在口径和权限的复用,不在平台功能。第一个岗位的数据和权限是单独的,第五个岗位开始出现交叉和冲突,这时候需要治理框架来统一。

