xAI 的 Grok Bot 发布页上，留着一条来自运营岗用户 Emma 的感言（译）：
「刚开始的时候，我每 15 分钟就要去查看一次 Bot，事无巨细地盯着它——直到它反过来问我，为什么我总是问这么多问题。现在我放手让它自己干，它反而越用越好。」
这可能是「数字员工」这个产品形态目前拿到的最好背书：不是一个等你提问的工具，而是一个你可以把工作交出去、然后转身去干别的事的队友。
但同一页往下翻，还有一行写给企业用户的小字：加入 waitlist。
喊得最响的「可以把真实工作交给它」，到了企业门口，只换来一句排队等候。这个反差值得认真对待：Grok Bot 上线 24 天，验证了什么？它又到底卡在哪？
先说结论： Grok Bot 验证了「持续角色」这个产品形态，但企业要的是「岗位」。从角色到岗位，差的最后一段不是模型能力，而是组织基础设施。 而这一段，恰恰是企业现在就应该开始在钉钉里上岗数字员工的原因。
一、Grok Bot 的前 24 天：一条被加速播放的产品路径
8 月 11 日，xAI 发布 Grok Bot Beta，Slogan 只有一句：AI teammates you can give real work to（可以把真实工作交给它的 AI 队友）。
它的起点是 xAI 自己的内部原型：销售 Bot 更新 CRM、起草跟进邮件，运营 Bot 给新员工开通账号、处理发票，工程 Bot 复现 Bug、提工单、再把修复移交给另一个调试 Bot。这些场景被写进了官方发布页——注意，不是演示视频里的设想，而是已经在内部跑起来的工作。
把发布时的机制拆开看，Grok Bot 的产品单位已经不是一次会话或一个任务：
- 持续身份：每个 Bot 有名字、有记忆，你可以像给同事发消息一样给它派活，随时回到同一条线程；
- 自己的电脑：Bot 共享一台云端电脑，登录你授权的工具，在你下线时继续推进工作；
- Skills 与 Routines：你带它做一遍工作，它把流程存成 Routine，下次自己跑；成功的方法沉淀为可复用的 Skill；
- 多 Bot 协作：几个 Bot 拉进群聊，自己传递工作、分配归属，只在需要判断时把人拉进来。
更值得注意的是它后续的迭代顺序。8 月 28 日，官方账号宣布开放 Templates：一条链接，就能把 Bot 分享给别人——距离 Beta 上线不到三周。
Templates 的设计值得盯着看一会儿：链接里带走的，是 Bot 的身份、描述、Skills 和 Routines；不 复制的，是云端电脑、登录会话、凭证，以及运行中的 Case。有技术博客打了个准确的比方：你分享的是菜谱，不是那盘已经做好的菜。
翻译成企业语言： 可分发的是角色定义与能力配置，不可迁移的是组织特定状态——权限、依赖关系，和尚未履行的承诺。 xAI 用一个产品机制，无意间画出了数字员工的资产边界：哪些部分是可以在市场上流通的「能力资产」，哪些部分是长在企业里的「组织资产」。
再看一眼赛道。The Verge 的报道把 Grok Bot 的同类列了出来：OpenAI 的 ChatGPT Work、Anthropic 的 Claude Cowork、微软的 Copilot Tasks。2026 年下半年，最头部的几家公司不约而同地把产品单位从「一次任务」换成「一个持续干活的家伙」。
这不是某家的产品偏好，而是一次集体转向：行业正在从 Task 走向 Role。
二、持续角色不等于企业岗位
Grok Bot 解决了「谁能持续干活」，但没解决「谁能对结果负责」。
把「持续角色」和「企业岗位」摆在一起，缺口一目了然：
| 维度 | Grok Bot 的持续角色 | 企业岗位还差什么 |
|---|---|---|
| 身份 | Bot 名字 + 持续对话 | 工号、汇报线、离职交接、可审计的责任主体 |
| 权限 | 用户授权登录的工具 | 按动作分级的权限矩阵与审批链 |
| 完成 | 「需要审批时回来找你」 | 完成标准、验收证据、结果归因 |
| 状态 | 云端电脑 + 对话上下文 | 可查询、可恢复的 Case：依赖、检查点、接管记录 |
| 进化 | 个体层面的越用越顺手 | 经过评估、灰度、可回滚的能力版本治理 |
左边这一列，Grok Bot 做得相当漂亮。右边这一列，它一行都没碰——这也解释了为什么企业用户只能排 waitlist。
最近一篇公众号文章《从 Grok Bot 浅谈数字员工的产品思路》把右边这列拆成了四个部署接口：完成定义、状态与恢复、权限治理、能力更新。它给出的角色契约公式值得抄下来：
角色契约 = 职责范围 + 完成标准 + 状态范围 + 行动权限 + 验证证据 + 升级与接管条件。
这四个接口里，最容易被低估的是「完成定义」。发布页上另一位用户、产品岗的 Roman 说了句大实话（译）：
「90% 完成和 100% 完成之间隔着一条鸿沟。大多数 AI 能带你到附近，而 Grok Bot 能把最后一下做完，因为工作落在真实工具里、落在人会放的地方。」
「落在真实工具里」解决的是交付的最后一公里，但企业要的还不止这个——还要有人定义什么叫「做完了」：邮件发出去了，算不算完成？如果这封邮件带着一个超出授权的承诺呢？没有完成标准，就无法验收；无法验收，就无法按结果计价，更无法训练和追责。
那篇公众号文章还往训练侧延伸了一步：推测 xAI 未来可能让数字员工的运行环境反向参与「职业级」能力的训练与评估。这个推测我没有找到公开证据支撑——今年 1 月，前 xAI 工程师 Sulaiman Ghori 在访谈中确实提过代号 MacroHard 的「人类模拟器」项目（他称之为「数字版 Optimus」，目标是规模化部署），但 Ghori 在访谈后数日便离开了 xAI，运行环境反哺训练这件事至今只是推断。我不打算在这里展开它——重要的是产品侧已经成立的事实：角色，已经成为数字员工的产品单位。
两周前我写别配置 Agent 了，给它一个岗位，说的是数字员工的开发方式该变了。Grok Bot 从另一个方向提供了佐证：连最激进的模型公司都不再卖「一次任务」，开始卖「一个角色」。
但岗位不会悬空成立。角色要变成岗位，必须落进一张组织网络里。
三、上岗：把角色契约写进组织图谱
Grok Bot 创建一个角色，只需要点一下「Create a Bot」。企业上岗一个数字员工，更像给新员工办入职——而且这份入职清单，恰好就是角色契约的落地形式：
数字员工上岗四步清单
────────────────────────────────────────
① 给身份 工号、通讯录、汇报线——先让它在组织图谱里成为「一个人」
② 划边界 按动作可逆性配权限：检索、起草可自主；支付、删除、对外承诺必须审批
③ 定完成 每个工作单元写清楚：什么算交付、谁来验收、证据是什么
④ 立 Case 目标、进度、依赖、检查点、接管记录——可查询、可恢复、可审计
① 给身份。 我在 Claude Tag 的 Agent Identity 里讲过一个真实场景：同事在群里 @了一个 Agent 跑数据，事后审计时安全团队问「这个操作，日志里记的是谁」——答案是那个 @它的人。读数据、写报告的是 Agent，背锅的是人。身份不是锦上添花，是审计的前提。钉钉的数字员工有工号、进通讯录、有汇报线——它先在组织图谱里成为「一个人」，然后才谈得上干活。
② 划边界。 那篇公众号文章里有一句话我完全同意：决定自主范围的，不应是任务难度或模型评分，而是 动作的可逆性、影响半径和恢复成本。检索、整理、起草、沙箱测试，留痕后可以放手；支付、删除数据、修改生产配置、对外作出商业承诺，哪怕操作再简单，也要走审批。企业的审批链、权限体系不是为 AI 发明的，但它们恰好是数字员工授权治理现成的载体——Grok Bot 要从 waitlist 里走出来，迟早也得补上这一层。
③ 定完成。 完成标准就是一份岗位级的评测集。我在评测集是一份没人签字的文件里说过，评测飞轮停摆的根因往往是「什么叫好」没有主人。上岗时的完成标准同理：它必须被某个具体的人签字确认，否则数字员工干得越多，扯皮越多。
④ 立 Case。 Grok Bot 的状态住在云端电脑和对话线程里，对个人用户足够，对企业不够。岗位履约要回答的是：这项工作推进到哪一步了？卡在谁身上？上次人工接管是因为什么？这些必须维护成结构化的、可查询可恢复的 Case，而不是散落在聊天记录里——聊天记录没法审计，也没法交接。
这四步走完，还有一件事要长期盯住：自主权漂移。随着使用时间变长，团队会自然而然把更多动作放进「自动执行」，权限在无人察觉中越滚越大。所以角色生命周期必须是完整的：影子运行 → 逐项审批 → 限定自主 → 按表现扩权或降权 → 转岗或退出。每一次扩权都要绑定历史合格率和异常记录，而不是因为底层模型升级了就整体放开。数字员工的长期可信度，取决于治理界面，而不是能力界面。
四、为什么是现在
写到这里，先回答一条必须面对的反方意见：你是钉钉的 CTO，说「企业该在钉钉里上岗数字员工」，是不是自卖自夸？
我的回应是把这句话拆开。它的前半句——「企业该现在上岗数字员工」——是一个可以被证伪的判断：如果组织特定数据不构成复利，这个判断就是错的，跟钉钉无关。它的后半句——「在钉钉里」——是一个有条件的建议：条件是，你的审批链、通讯录、权限体系已经长在那个组织底座上。如果一家企业的全部组织资产在别的平台上，同样的逻辑指向那个平台。我卖的不是结论，是这个论证结构；结论里带钉钉，是因为我的论证恰好长在我的语境里。读者该检验的是论证，不是推销。
然后是另一条更实质的反方：模型进化这么快，现在上岗是不是太早？等再成熟一点、等 Grok Bot 们把企业版做出来，直接摘果子不好吗？
我的回答是：你等得起模型，等不起数据。
数字员工上岗后积累的，不是通用语料，而是三类买不到的组织特定资产：角色契约（这个岗位在你公司到底负责什么、什么算完成）、Case 历史（真实业务的依赖、异常和接管记录）、权限与验收数据（哪些动作被批准、哪些被打回、为什么）。这三样东西无法从公开语料获得，也无法从供应商那里打包购买——它们只能从你自己的组织里长出来。
这正是我在数字员工的自我进化里说的：生产数据是递归式自我改进最稀缺的原料。谁先把数字员工放进真实岗位，谁的生产环境就先变成训练环境；等别人上岗时，你的数字员工已经在你的业务里迭代了几百个 Case。
也是AI 钉钉的护城河里那位汽车零部件客户问题的答案：他那七个有工号、有审批链、有审计日志的数字员工，换一个平台就全部归零——不是代码搬不走，是长在组织图谱里的东西搬不走。今天你上岗的每一个数字员工，都在加深这条护城河。
所以，上岗的姿势比上岗的时机更重要。别从「替代一个岗位」开始，从一个 完成标准清楚、动作可以约束、失败可以接管、结果能够归因 的工作单元开始。拿「完成指定区域的线索研究与首轮触达」这个单元，填一份完整的角色契约长这样：
角色契约示例：线索研究专员（数字员工）
────────────────────────────────────────
职责范围 指定区域线索研究与首轮触达；报价、谈判、成交不在职责内
完成标准 每条线索：研究证据 ≥3 个独立来源 + 触达记录回写 CRM，
由销售主管按周抽检签字
状态范围 每条线索一个 Case：证据、发送状态、回写记录、阻塞原因
行动权限 自主：检索、整理、起草；审批：对外发送（首月逐条，
合格率 ≥95% 后按批次抽检）；禁止：一切商业承诺
验证证据 研究来源清单、邮件副本、CRM 回写记录
升级条件 证据不足、客户要求报价、触达被退回两次 → 转人工
# generated by hugo AI
这份契约里没有一个字需要模型参与——它全是产品和组织问题。填得出这份契约的工作单元，才值得上岗；填不出来的，先别谈替代岗位。这样的单元同时给出产品边界、训练边界和商业边界。
衡量标准也要跟着换。别看调用量和 Token 消耗，看 合格交付率、每百个 Case 的人工接管次数、每次接管消耗的专家时间——只要交付增长仍然要求专家兜底同比增长，那你用的就还是人机服务，不是有软件规模效应的岗位系统。
写在最后
Grok Bot 上线不到一个月走完的路，恰好替整个行业验证了两件事：数字员工的产品单位是角色，不是任务；角色可以被分发，但岗位不能——岗位长在组织的身份、权限、审批和审计里。
队友可以从市场上请，员工只能在组织里养。Grok Bot 证明了数字员工值得雇；至于在哪雇、怎么上岗、怎么养大——这道题回到了每家企业自己的组织图谱里。
你的组织里，第一个值得上岗的数字员工岗位是什么？欢迎留言聊聊。