从 OpenClaw 爆火到现在，各种 worker、buddy、数字员工产品越来越多。
我一开始也容易被这些东西带着走：看它能不能连工具，能不能完成任务，能不能多轮协作，能不能接企业系统。看起来只要模型够强、工具够多、流程能跑，数字员工就差不多成立了。
这段时间和同事讨论企业数字员工，越讨论越发现不是这么回事。
数字员工真正难的地方，不是让它回答问题，也不是让它执行一次任务。难的是把它放进企业组织以后，它到底算什么，归谁管，在哪个团队工作，用什么权限，产出归谁，出了问题怎么追。
如果这些问题说不清，数字员工再聪明，也只是一个会调用工具的临时机器人。
我现在更愿意用一个粗糙但实用的标准来判断：
数字员工不是能对话的 Agent，而是能被组织管理、被团队派工、被系统追踪、被责任链路约束的工作主体。
下面这张图，是这段时间讨论过程中沉淀出来的一版简化模型。它不是数据库 ERD，而是为了把第一阶段最容易混在一起的几个概念拆开：真实员工、数字员工画像、稳定数字员工、临时克隆、团队、工作空间和治理记录。
问题不在数字员工能不能聊天
现在很多数字员工产品，演示时都挺顺。
你给它一个任务，它能拆步骤；你给它一组工具，它能调用；你把它放进群里，它能回复；你让它跑流程，它能触发系统。
这些能力当然重要，但还不够。
企业内部真正关心的是另一批问题：
- 它是长期员工，还是临时克隆？
- 它的能力从哪里来，谁批准，谁维护？
- 它能加入哪个团队，服务哪个项目？
- 它的权限怎么来，又怎么撤？
- 它做出的文件、消息、决策和副作用归谁？
- 它执行失败以后，谁负责处理？
- 它消耗了多少资源，是否值得继续保留？
这些问题不是模型能力问题，是组织治理问题。
所以评估数字员工，不能只看 Demo 里“会不会干活”。那只是第一层。真正要看的是，它能不能进入企业协作结构。
先把四个身份拆开
讨论数字员工时，最容易乱的是身份。
真实员工、数字员工、数字员工克隆、数字员工画像，经常被混成一个“Agent”。一旦混在一起，后面权限、生命周期、审计都会跟着乱。
我现在会先拆成四个对象。
第一个是 AE，Actual Employee，真实员工。
真实员工有企业身份，有工号，有组织归属，可以成为团队负责人，也能承担最终责任。
第二个是 DEP，Digital Employee Profile，数字员工画像。
DEP 不是一个正在工作的员工。它更像能力定义层，描述一类数字员工能做什么、怎么做、能用哪些工具、默认边界是什么、适合哪些岗位或场景，以及如何评测。
第三个是 DE，Digital Employee，稳定数字员工。
DE 是长期存在的数字员工身份。它可以归属岗位、部门或组织资源池，可以加入团队、参与任务，也应该有稳定工号、权限边界和生命周期治理。
第四个是 DEC，Digital Employee Clone，数字员工克隆。
DEC 是临时身份，通常服务某个团队、项目、任务或阶段性场景。它可以批量创建，但每个 DEC 都应该有独立身份、临时工号、明确负责人、作用域和生命周期。
这里有个关键点：DEC 不应该从某个 DE 实例复制出来，而应该从 DEP 或 DEP 的版本创建。
Soul / 能力资产
-> DEP / 数字员工画像
-> DE / 稳定数字员工
-> DEC / 数字员工克隆
为什么要这么绕？
因为稳定数字员工身上可能已经带了组织归属、历史上下文、权限痕迹和运行状态。如果直接从 DE 复制 DEC，很容易把不该复制的东西一起带出去。可复制的应该是能力定义，不是某个已经入编的工作主体。
评估数字员工，第一眼要看的不是它会不会调用工具，而是身份能不能治理。
如果一个系统只能创建“一个 Agent”，但说不清它是画像、稳定员工、临时克隆还是运行实例，后面大概率会出问题。
团队才是数字员工落地的主轴
数字员工不能只挂在某个人名下，也不能只散落在群聊里。
企业里的工作，最后大多落在团队上。可能是项目组，可能是专项小组，可能是一个长期职能团队，也可能是一个人的个人团队。
所以 Team 要成为一级业务对象，而不是简单等同于 Channel。
Channel 只是沟通面。Team 才承载成员、目标、权限上下文、任务、项目、产出和责任归属。
一个 Team 里面可以有人，也可以有数字员工：
Team = AE + DE + DEC
这件事看起来像概念洁癖，其实很实用。
如果任务归属 Channel，换个群就断了。如果产出归属某个消息线程，后面复盘、搜索、审计都会散。如果数字员工只存在于对话里，它做完事情以后，团队很难知道这些结果应该沉淀到哪里。
把 Team 作为主轴以后，很多关系会清楚：
- Team 有且只有一个负责人，负责人必须是 AE；
- Channel 属于 Team，是团队的沟通面；
- Task 归属 Team；
- Project 必须有 Team；
- Channel 里的产出最终归属 Team；
- 个人场景可以用 Personal Team 统一，而不是另起一套个人空间模型。
一个数字员工产品如果只能回答个人问题，不能进入团队、任务、项目和产出归属体系，它更像个人助理，不像企业数字员工。
所以第二个问题就出来了：它能不能进团队协作。
工作空间决定它能不能做长任务
很多数字员工演示都偏短任务。
查个数据、发个通知、转个审批、写段总结，这些可以是无状态的企业系统调用。调用完成，结果返回，事情结束。
但企业里还有另一类工作：代码修改、长时间分析、持续调试、项目交付、多数字员工协作执行。这些任务不是一次 API 调用能解决的。
它需要工作空间。
这里引入一个概念：Team Resource Cell，简称 RC。
Team 是业务协作单元，RC 是 Team 的有状态资源与运行时边界。每个 Team 逻辑上对应一个 RC，但 RC 不应该默认占资源，而是在有状态执行需要时按需激活。
RC 可以承载这些东西：
- Team 级 agent runtime；
- shared workspace；
- member workspace；
- DEC workspace；
- DE 参与 Team 时产生的 team-session workspace；
- task / project output space；
- runtime state、checkpoint 和 logs。
这里有一个很重要的边界：DE 的长期工作空间不在 Team RC 里。
DE 是组织资源，归属岗位或部门。它参与某个 Team 时，可以在 Team RC 内产生团队会话空间；DEC 则通常服务某个 Team 或 Personal Team，它的 workspace 就应该落在对应 Team RC 内。
这能避免两个问题。
一个是把组织级数字员工的长期记忆和某个项目的临时上下文混在一起。另一个是项目结束后，临时克隆和它的工作空间无法释放。
如果一个数字员工平台只能展示“运行中”，却说不清工作空间、checkpoint、中间状态、产出归属和资源释放，它很难支撑真正的长任务。
这时候要看的，不是它能不能跑起来，而是工作空间能不能隔离。
运行投递要能追踪
还有一个容易被低估的问题：数字员工什么时候应该被唤醒？
普通消息要不要触发？有人在历史引用里写了 @reviewer，要不要触发？有人点了 reaction，要不要触发？一个 App 事件进来，没有绑定团队或任务，要不要触发？
如果只靠文本扫描，系统会很快变得不可控。
更稳的做法，是把协作事件和运行投递拆开。
普通协作事件只是事实记录，不一定要求运行时处理。只有满足明确意图、合法目标、合法作用域，并通过触发策略的事件，才生成 Delivery。
Collaboration Event
-> Delivery
-> Attempt
-> Runtime Execution
Delivery 不是消息本身，也不是任务本身，而是一份标准化的运行时投递单。它要回答：
- 谁触发的；
- 在哪个 Team 或 Personal Team 作用域下触发；
- 要交给哪个数字员工或运行时处理；
- 为什么触发；
- 期望什么结果；
- 结果应该回写到哪里；
- 当前状态是什么；
- 有几次执行尝试；
- 产生了哪些 reply、effect 和 artifact。
这一步很关键。
数字员工不是看到消息就冲出去干活。它应该通过明确的投递链路进入运行时，并且每一次执行都能被追踪、重试、取消、失败诊断和复盘。
如果一个产品只能告诉你“Agent 已回复”，但不能区分 Delivery、Attempt、Runtime Execution、Reply、Effect、Artifact，那么它还停留在聊天体验层，没有进入企业运行治理层。
执行可追踪，才算从聊天体验走进运行治理。
控制和记录不能后补
数字员工一旦能接企业系统，就不能靠自觉。
它读取什么上下文，能用什么工具，能访问哪个目标系统，能不能执行有副作用的操作，失败后怎么记录，资源消耗怎么归因，这些都要有控制关口。
同时，还要有治理记录面。
审计、成本、可观测、合规，不是事后补几个日志字段。它们要覆盖身份、团队、运行时、工作空间、投递单、执行尝试和产出链路。
否则后面会遇到几个很现实的问题：
- 数字员工做了事，但不知道是谁让它做的；
- 产出存在，但不知道属于哪个团队；
- 工具被调用了，但不知道用了谁的权限；
- 资源消耗上去了，但不知道算哪个项目；
- 出了事故，只能翻聊天记录猜。
控制和记录能不能闭环，是最后一道门槛。企业数字员工不是越自由越好。越能干，越要有边界；越自动，越要能追责。
落到五个问题
到这里，企业数字员工的评估可以先压成五个问题。
身份能不能治理？
能不能区分 AE、DEP、DE、DEC、运行实例？能不能表达稳定身份和临时克隆？能不能控制谁可以创建、复制、停用和回收数字员工？
能力能不能版本化？
数字员工的能力是不是有画像？角色、工具、知识、约束、评测标准能不能沉淀成 DEP？能力升级后，历史员工和新克隆怎么处理？
团队能不能协作？
数字员工能不能进入 Team？任务、项目、频道、产出是否有归属？个人场景和团队场景是不是同一套模型？
执行能不能追踪？
系统能不能区分触发源、投递单、执行尝试和运行结果？失败、重试、取消、产物、副作用有没有稳定语义？
成本和风险能不能控制？
运行空间是否按需激活？权限是否取交集？上下文是否裁剪？资源消耗、审计、可观测和责任链路是否能落到团队和负责人？
这五个维度不一定就是最终评分表，但已经能帮我们过滤掉一批“看起来很热闹”的方案。
会聊天，只能证明它像一个助手。
能被组织接住，才有机会成为数字员工。
先问几个笨问题
现在再看数字员工，我已经不太愿意先问“它能不能完成某个任务”。
我会先问几个更笨的问题：它有没有身份？归哪个团队？能力从哪里来？工作空间在哪里？执行过程能不能追？权限怎么收？产出归谁？成本怎么算？出了问题谁接？
这些问题不漂亮，但企业最后就卡在这里。
如果一个数字员工系统回答不了这些问题，它可能仍然有价值，但价值更接近个人助理、自动化脚本或聊天机器人。
真要进入企业，它迟早要补上组织、团队、工作空间、运行投递和治理记录这几层。
这也是我现在对数字员工比较保守的判断：先别急着看它多聪明，先看它能不能被管理。