上个月我连写两篇拆解 DeepSeek Harness（dsh）：一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 说它开源的不是工具，是运行时；一切皆插件：真正硬核的是三个细节 拆了注册即副作用、事件日志做脊柱、乱序完成按序写回这三个工程承诺。当时我的结论是「可以吹，但不必急着用」——预览版、破坏性变更写在官方文档里，日常编码不如用成熟的 Coding Agent。
几周后打脸了：我们把一支真实的钉钉数字员工团队装在了它上面。项目叫 DWH（DingTalk Workforce Harness），四个员工——通用助手 default、管理员 dev、HR 助手 hr、老板秘书 assistant——各自是一个独立的 dsh 进程，在钉钉里各管一摊、各有权限、互相平级。这篇讲为什么「不必急着用」的判断没错，但「怎么用」的答案错了：开源 Agent 运行时的正确用法，不是把它当产品直接用，而是把它当操作系统，在上面建一层「员工管理制度」。
xAI 的 Grok Bot 发布页上，留着一条来自运营岗用户 Emma 的感言（译）：
「刚开始的时候，我每 15 分钟就要去查看一次 Bot，事无巨细地盯着它——直到它反过来问我，为什么我总是问这么多问题。现在我放手让它自己干，它反而越用越好。」
这可能是「数字员工」这个产品形态目前拿到的最好背书：不是一个等你提问的工具，而是一个你可以把工作交出去、然后转身去干别的事的队友。
但同一页往下翻，还有一行写给企业用户的小字：加入 waitlist。
喊得最响的「可以把真实工作交给它」，到了企业门口，只换来一句排队等候。这个反差值得认真对待：Grok Bot 上线 24 天，验证了什么？它又到底卡在哪？
先说结论： Grok Bot 验证了「持续角色」这个产品形态，但企业要的是「岗位」。从角色到岗位，差的最后一段不是模型能力，而是组织基础设施。 而这一段，恰恰是企业现在就应该开始在钉钉里上岗数字员工的原因。
半年前，我给自己上了第一批数字员工。上岗之前，我的想象是这样的：任务交给 Agent，我只管派活和收结果，我在钉钉上的时间应该大幅下降。
半年后，我打开自己的屏幕时间统计：我在钉钉上的时间没有下降——翻了一倍。
起初我以为是个体差异。但和几位同样在带数字员工的同事交流后，发现大家的处境差不多：Agent 越多，人在 IM 里花的时间越多。
这让我必须把一个判断写下来：
AI 不会造出新入口，只会加深你对旧入口的依赖。
客户第一次见面说：「我们想做一个销售 Agent。」
多数团队会立刻追问：想用哪个模型？知识库有多少文档？要不要私有化？
「FDE 前线」最近发了一篇文章，给出了另一套问法——20 个问题，分五组：业务结果、真实流程、数据与系统、风险与权限、采用与责任。第一问就不是「用什么模型」，而是「这条流程最终要产生什么业务结果」。
这 20 问在网上被当成销售技巧清单转发。但我读完后的判断不一样：这不是一份访谈提纲，而是一份组织上下文的采集协议。它真正的价值，和它最大的问题，是同一件事——它太贵了。
8 月 27 日晚上，我做了一场《钉钉数字员工架构与落地实践》的分享。六十分钟的正题讲完，真正让我反复回味的，是 Q&A 环节的四个问题。
最后一个最尖锐。提问者先铺垫了他的观察：从演示看，数字员工做的是秘书、提醒、传话、会议纪要这类辅助性工作。然后他话锋一转：
如果我让数字员工承担一部分技术开发工作，它将面对非常复杂的场景和长周期的任务。长周期任务下，执行的成功率会一路衰减。请问你们的数字员工能不能解决复杂的长期问题？如果不能……
「如果不能」悬在半空。我当时的回答很直接： 钉钉做的是让 AI 能进入企业组织架构的基建——数字员工账号、连接多 Agent，权限管控、运行审计、知识管理，为任务提供上下文等基础能力，还提供入转调离全生命周期管理、执行前主管审批确认放行、岗位能力评估和考核、拟人化交互等功能，但还不能对企业自建或生态交付给企业客户的数字员工的产出效果来负责。
分享结束后，我把这四个问题记了下来。它们看似散，其实指向同一件事： 数字员工的落地卡点，从来不是模型能力，而是四个组织问题。 而四个问题说到底，又可以归到一个词上： 委托 ——把工作交给 AI 之后，这份委托如何在组织里被信任。
2026 年 8 月 8 日下午，我们的数字员工失联了 16 分钟。监控这边，它一切正常。
说「失联」其实不准确——从所有监控指标的视角看，它一直活得好好的：进程存活检查正常，HTTP /session 探测返回 200，健康检查每 5 分钟跑一次，次次报「健康」。唯一的异常是：群里任何人 @ 它，它都不回。最早的「告警」是一个人在钉钉里发现不对劲——这比我们任何一条监控都快。
16 分钟不长，但足够让人意识到一件事：我们精心搭建的监控体系，监控的根本不是「数字员工在工作」，而是「装着数字员工的那个容器还在」。
这篇文章讲的，就是从这类事故里长出来的几个生产级实践。它们已经沉淀进数字员工的 harness 模板——三步上线一个数字员工 里讲过这个脚手架是什么、怎么三步上线；模板本身也在持续迭代，从内部生产版本一路提炼成开源的 dingtalk-opencode-tag。这篇是它的续篇：上线只是开始，生产环境会用它自己的方式告诉你，「能跑」和「生产级」之间还隔着多少坑。
8 月中旬，DeepSeek 开源了一个叫 DeepSeek Harness（简称 DSH）的项目，Slogan 只有一句话：Everything is a Plugin。写这篇文章时，它在 GitHub 上的 star 数已经突破 17 万——一个 developer preview 阶段的项目，热度超过了绝大多数成熟框架。
很多人把它当成又一个 Agent 框架来看。我看了几天代码和文档，得出一个不一样的判断：它真正改变的不是「Agent 怎么跑」，而是「数字员工怎么造」。
我准备探索一种新的数字员工开发方式：
给 Agent 一个岗位 Spec 和一组 Evals，让 Coding Agent 自主完成数字员工的开发、测试、部署和运维。
数字员工不再通过传统的 Agent Builder 拖拽 Workflow、配置 Prompt、配置工具来构建，而是交给 Harness 里的 Coding Agent 自己把它做出来。这篇文章讲讲为什么，以及它的边界和风险。
上周，一位做软件外包的朋友跟我吐苦水。
他给公司三十多个工程师全部配了 AI 编程工具，钱花了不少，工程师也很买账。半年后他拉数据，想看看交付速度提升了多少——结果发现，项目平均交付周期几乎没变。工程师写的代码确实多了，但代码堆在评审环节；评审通过了，又堆在测试和发布环节。
他问我：「是不是工具不够好？要不要换一个更贵的？」
我说：工具没问题。问题是 AI 把每个人手里的活干快了，但活和活之间的缝隙，一点没变窄。代码从「写完」到「上线」，中间隔着评审、测试、审批、排期——这些环节里没有一个 AI，全是人在等人。
今年 2 月，我写过一篇工程文章 通过桌面录屏实现自动化 RPA 的最佳实践：用录屏捕获屏幕画面和鼠标键盘事件，让多模态大模型理解操作序列，再自动复现。为了验证可行性，我自己写了实现——光录制模块和关键帧提取就是几百行代码，文末我还特意提醒：这条路离可用产品有距离。
六个月后，8 月 11 日，SpaceXAI 把这个机制直接做成了正式产品 Grok Bot。每个 Bot 拥有一台独立的云端 Linux 虚拟机，学会一个流程不需要任何配置：你像平常一样操作一遍，Bot 在旁边看着、记下来，下次它自己干。想用，先买 $200/月的 SuperGrok Heavy 订阅，或者 $120/人/月的团队版。
媒体标题都在喊「马斯克终极大招」「数字同事上岗」「硅谷炸锅」。但我想聊一个被忽略的部分：Grok Bot 最狠的不是「能干活」——能干活这件事，Claude Cowork 能做，OpenAI 也能做。真正狠的是 跟班学习 这四个字。它第一个会干掉的市场，不是聊天框，不是 Office，而是 RPA 行业。
这周二，我开了一场 AI 钉钉的战略沟通会。
会开完了，按惯例，事情应该到此为止——大家听完、散场、各自回去干活。但这一次我盯着会后那张评估问卷的回收数据，突然意识到一件事：这场会从头到尾，没有一个环节是「用完就扔」的。
HR 在会前一周就用 AI 表格收集了同学们的问题，其中大家最关心的是千问办公和钉钉的关系；我基于这些真实问题，用千问办公读我的个人 wiki，生成了一份沟通会叙述稿，自己调整之后做成 PPT；会后，HR 又用千问办公加 AI 表格技能，基于沟通内容生成了一张调研问卷，回收数据，再用千问办公对整场会的效果做了评估。
一场内部沟通会的完整生命周期——从「同学们关心什么」到「这场会到底有没有效」——全部跑在 AI 工具上，而且每一环的输出都是下一环的输入。
我觉得这很 AI native。但真正让我停下来想的，不是用了多少工具，而是另一个问题： 一场会开完，它留下的东西，到底是资产还是损耗？
