No. 31: 我看了 19 个数字员工，发现它们根本不是同一种产品

为了继续做 AI Employee OS，我整理了 19 个国内外数字员工和企业 Agent 产品。最初我想做一张常规竞品表，把产品定位、核心能力和目标客户横向排开。

真正开始整理后，这张表很快失效了。RPA 厂商说的数字员工，办公平台说的数字员工，CRM 里的 Agent，以及面向客服场景的垂直 Agent，解决的并不是同一层问题。

如果只按产品名称比较，很容易把完全不同的能力放到一个排行榜里。于是我先停下功能对照，重新追问一个更基础的问题：企业买到的到底是什么工作结果？

这篇文章是我基于截至 2026 年 8 月 13 日公开资料做出的阶段性判断。它不能替代真实 PoC、安全审查、合同条款和正式报价，但足以帮我把这个市场的产品边界重新分清。

「数字员工」下面，其实藏着五类产品

把 19 个产品放回各自的执行环境后，我大致看到了五条不同路线。

这五类产品可以互相进入对方的边界，却有不同的起点。RPA 从确定性操作出发，办公 Agent 从协作上下文出发，业务系统 Agent 先拥有数据对象和权限，通用平台更关心构建与治理，垂直 Agent 则从一组可量化结果倒推流程。

所以「谁的功能更多」不是一个有效问题。先判断产品属于哪条路线，再看它能否覆盖目标工作，比较才有意义。

竞争正在从会回答，转向可靠地完成任务

早期企业 AI 产品的演示常常围绕一个聊天框展开：提出问题，模型根据企业知识给出答案。但回答只是工作的中间状态。真实任务还要识别身份、读取上下文、规划步骤、调用工具、等待审批、交付结果，并留下可追溯证据。

例如一个销售 Agent 给出客户摘要，并不等于销售准备工作已经完成。它可能还需要更新 CRM、生成跟进建议、创建待办，并在涉及价格承诺时交给负责人确认。少了任何一段，用户仍然要手工补齐最后一公里。

我因此不再把聊天体验当作数字员工的主坐标。更关键的指标是任务完成率、人工介入位置、失败恢复能力、权限边界和最终交付物。模型表达是否自然仍然重要，但它已经无法单独定义产品价值。

RPA 没有过时，它正在退回更合适的位置

生成式 AI 出现以后，RPA 很容易被描述成上一代技术。但从企业执行环境看，RPA 仍然解决着一个现实问题：大量遗留系统没有合适的 API，或者无法在短期内完成系统改造。

Agent 擅长理解模糊目标、处理非结构化信息和动态规划，RPA 擅长在确定界面上稳定执行。把两者放在同一个能力层里争论替代关系，没有太大意义。更合理的结构是让 Agent 负责判断与编排，让 RPA 成为必要时的执行器。

这也解释了为什么 UiPath、Blue Prism 等厂商会沿着既有自动化基础继续进入 Agentic Automation。它们的优势不只是一套机器人能力，还包括已经部署在企业里的流程、连接方式和治理经验。

真正的壁垒，是上下文和行动权同时成立

企业 Agent 想完成工作，至少要同时获得两种能力：理解企业上下文，以及在授权范围内采取行动。

只有知识，没有行动权，它就停留在问答助手。只有工具，没有足够上下文，它又可能在错误的客户、工单或业务阶段执行正确动作。上下文决定它理解什么，权限决定它能做什么，两者共同决定结果是否可信。

这也是办公生态和业务系统原生 Agent 的天然优势。飞书、钉钉、Salesforce、ServiceNow、Glean 等产品所处的位置不同，但它们都在利用已有的数据对象、用户身份、组织关系、流程与连接器缩短最后一公里。通用模型能力会快速扩散，企业上下文与行动链路却很难靠一次模型升级复制。

治理不是上线后的补充，而是购买入口

个人工具可以先试用再补规则，企业 Agent 的顺序往往相反。只要它会读取内部数据、代表员工执行操作，权限、审批、日志、评估、恢复、成本和数据驻留就会提前进入采购讨论。

治理也不等于做一个审计日志页面。企业需要知道 Agent 以谁的身份行动，调用了什么工具，哪些步骤获得过批准，失败后能否撤销或重放，以及结果依据来自哪里。缺少这些信息，业务负责人无法授权，安全团队也无法放行。

OpenAI Frontier、Salesforce Agentforce、ServiceNow AI Agents 以及各类 Agent 平台都在强化控制、评估和可观测能力。这不是大客户专属的附加功能，而是数字员工从演示进入生产的基本门槛。

选型不该从平台清单开始，而该从 Golden Task 开始

面对这样一个边界混杂的市场，最容易做错的事情，是先选一个看起来覆盖最广的平台，再努力把业务装进去。

我现在更倾向于先定义一小组 Golden Tasks。每项任务都要有真实输入、预期输出、权限范围、人工确认点、失败样例和验收标准。然后只让同一类别的产品进入 PoC，用相同任务和相同证据比较。

成本也不能只看订阅单价或 Token。更接近业务价值的口径是：

单位有效结果成本 = 总软件与实施成本 ÷ 通过验收的任务数量

这个分母很重要。一个价格低但需要大量人工补救的 Agent，未必比价格高却能稳定交付的产品便宜。

这次研究也改变了我做 AI Employee OS 的顺序

我原本很容易从「需要哪些 Agent 能力」出发设计系统。看完这些产品后，我更愿意先定义工作对象：任务由谁发起，员工拥有什么身份和权限，执行过程中在哪里请求确认，最后交付什么，失败以后如何恢复。

这意味着 AI Employee OS 不能只做一个员工列表、聊天窗口和 Skill 市场。那些都是看得见的界面，真正的骨架是 Agent、Task、Run、Tool、Deliverable 之间可验证的契约。

数字员工市场还会继续变化，19 个样本也不是完整答案。但只要把比较单位从产品名称换成真实工作，就能避免被相似的宣传语言带进错误分类。

把竞争单位换成一项可授权、可执行、可验收、可追责的真实工作，数字员工才有可比较的产品边界。

参考：UiPath Agentic Automation、Salesforce Agentforce、ServiceNow AI Agents、OpenAI Frontier、Glean AI Agents

← Writing