钉钉数字员工架构与落地实践

DingTalk Digital Employee: Architecture and Implementation Practices

8 月 27 日晚上,我做了一场《钉钉数字员工架构与落地实践》的分享。六十分钟的正题讲完,真正让我反复回味的,是 Q&A 环节的四个问题。

最后一个最尖锐。提问者先铺垫了他的观察:从演示看,数字员工做的是秘书、提醒、传话、会议纪要这类辅助性工作。然后他话锋一转:

如果我让数字员工承担一部分技术开发工作,它将面对非常复杂的场景和长周期的任务。长周期任务下,执行的成功率会一路衰减。请问你们的数字员工能不能解决复杂的长期问题?如果不能……

「如果不能」悬在半空。我当时的回答很直接: 钉钉做的是让 AI 能进入企业组织架构的基建——数字员工账号、连接多 Agent,权限管控、运行审计、知识管理,为任务提供上下文等基础能力,还提供入转调离全生命周期管理、执行前主管审批确认放行、岗位能力评估和考核、拟人化交互等功能,但还不能对企业自建或生态交付给企业客户的数字员工的产出效果来负责。

分享结束后,我把这四个问题记了下来。它们看似散,其实指向同一件事: 数字员工的落地卡点,从来不是模型能力,而是四个组织问题。 而四个问题说到底,又可以归到一个词上: 委托 ——把工作交给 AI 之后,这份委托如何在组织里被信任。

DingTalk Digital Employee: Architecture and Implementation Practices

[Read More]

AI Native 组织的第一生产力,是敢被蒸馏的管理者

The First Productivity of an AI-Native Org Is a Manager Willing to Be Distilled

上周一个老板问我:他想像同行那样,用 3 个真人带 30 个数字员工跑业务(这个比例是我们推演的示意,不是他的真实编制)。卡点在哪?

不是模型不够聪明,也不是工具不够多。卡在一个很朴素的地方:没有一个中层愿意把自己的判断标准写成文档。

审批到什么金额要上报、哪种客户投诉要升级、什么情况下可以破例——这些判断每天都在发生,但全装在某个管理者的脑子里。数字员工问他,他口头答;换一个场景,又得重新问。

于是 30 个数字员工,每一个都变成了「等他拍板」的排队窗口。

The First Productivity of an AI-Native Org Is a Manager Willing to Be Distilled

[Read More]

大多数企业 AI 的终点是人,Palantir 的终点是业务

Most Enterprise AI Ends at a Human — Palantir's Ends at the Business

上周,我翻我们数字员工的一条真实执行链路:一条消息进来,Agent 理解意图,调用 dws 能力执行,结果回到钉钉。全程没有「人看报表」这一环——数据的终点不是被谁看见,而是业务本身被改变。

这条链路短到不起眼。但它让我意识到,自己正在做一件大多数企业 AI 还没做成的事——同一时间,绝大多数企业的 AI 项目,正卡在「把结果给人看」这一步出不来。

最近读到「森林瀑布」的一篇长文《Palantir 还是太全面了》,把 Palantir 的官网和产品文档逐页扒了一遍。文章里有一句话,我认为点破了企业 AI 的分水岭:

「AI 到底连接到了什么。如果 AI 连接的只是一个搜索框,它还是聊天机器人。如果 AI 连接的是企业 Ontology、业务规则、Action 和真实业务系统,它才真正开始进入企业的操作层。」

[Read More]

组织的损失函数:为什么你的 OKR 只是许愿

Your OKRs Are Just Wishes: What Organizations Really Need Is a Loss Function

和朋友讨论组织的 AI 化时,有一句话点破了本质:

「训练过模型的人都懂:损失函数错了,训练步数越多,跑得越偏。」

组织也一样。目标错了,团队越勤奋,死得越快。

训练速度从来不是问题,梯度方向才是。而大多数组织最大的危机是:它们从未认真检查过,自己正在优化的那个东西,到底是一个目标,还是一个愿望。

Your OKRs Are Just Wishes: What Organizations Really Need Is a Loss Function

[Read More]

组织架构没变,就别谈 AI 原生

No Org Change, No AI-Native: A Structural Litmus Test

这句话出自最近一次关于企业 AI 转型的讨论。

当时的话题是:怎么判断一家公司是不是真的 AI 原生了?很多人的第一反应是列技术清单——买了多少 AI 工具、覆盖了多少人、token 消耗增长了几倍。然后有人扔出了这么一句:

企业组织架构不变、流程不变、人才要求不变,就别谈 AI 原生。

乍一听很极端,但细想会发现它的厉害之处:它把「AI 原生」从一个技术采购问题,变成了一个组织事实问题——原生与否,不看买了什么,看结构动没动。

这个类比很精确。cloud-native 的反面不是「没用云」,而是 lift-and-shift——把单体应用原封不动搬上虚拟机,然后宣称自己上云了。今天绝大多数所谓的「AI 转型」,就是 AI 版的 lift-and-shift:把 AI 塞进旧流程、旧考核、旧管理思维里,然后管这叫原生。

No Org Change, No AI-Native: A Structural Litmus Test

[Read More]

AI 让每个人都变快了,为什么公司没有变快

Individual Speed, Organizational Friction — Where the Real Bottleneck Moved

上周,一位做软件外包的朋友跟我吐苦水。

他给公司三十多个工程师全部配了 AI 编程工具,钱花了不少,工程师也很买账。半年后他拉数据,想看看交付速度提升了多少——结果发现,项目平均交付周期几乎没变。工程师写的代码确实多了,但代码堆在评审环节;评审通过了,又堆在测试和发布环节。

他问我:「是不是工具不够好?要不要换一个更贵的?」

我说:工具没问题。问题是 AI 把每个人手里的活干快了,但活和活之间的缝隙,一点没变窄。代码从「写完」到「上线」,中间隔着评审、测试、审批、排期——这些环节里没有一个 AI,全是人在等人。

Individual Speed, Organizational Friction — Where the Real Bottleneck Moved

[Read More]

Databricks 逼近 Palantir,但最后一层藏在组织里

Databricks Is Closing In on Palantir — But the Last Layer Lives in the Org

昨天读到汪小东的一篇长文,标题是《Databricks 正在逼近 Palantir 的核心区》。文章把 Databricks 2026 年的产品拼图摊开看:Genie Ontology、Agent Bricks、Supervisor Agent、Unity AI Gateway、Omnigent、Lakebase——结论是 Databricks 正在从「管理企业数据」走向「理解企业业务」,逼近 Palantir 经营了二十年的战略腹地。

文章最后那句话写得很好:

「模型提供智能,但企业需要一个能够承载智能的世界。Ontology,正在成为这个世界的骨架。」

这个判断我完全同意——它和我在 AI 的竞争变了:未来是上下文的竞争 里说的方向完全一致。但读完之后,有一个问题一直挂着我:

如果 Ontology 是终点,为什么数据资产最多、AI 工程师最密集的 Databricks,走到 Context Layer 就停住了?它缺的到底是什么?

四天前我在 Palantir 从本体长到 Agent,我们从 Agent 长回本体 里讨论过 Palantir 的路线。Databricks 的入局,让这盘棋从两家变成了三家。这篇文章在那篇的基础上再往前推一步:三家从三个起点出发,走向同一个终点——而 Databricks 恰好证明了,最难的那一层,从数据侧爬不上去。

Databricks Is Closing In on Palantir — But the Last Layer Lives in the Org

[Read More]

代码不再是瓶颈:Anthropic 的 AI 原生 SDLC 手册,印证了组织摩擦这件事

Code Is No Longer the Bottleneck — Anthropic's SDLC Playbook Confirms It

前天我写了一篇文章,说 AI 让每个人都变快了,但组织没有变快——个人效率的红利,被交接、等待、审批这些组织摩擦吞掉了。

两天后,Anthropic 发了一份长文:The AI-Native SDLC playbook。第一句话是:

「Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven’t changed at the same pace.」

各组织已经开始用 AI 以一年前无法想象的速度编写代码,但围绕代码的流程并没有以同样的速度改变。

翻译成我们前天讨论的语言:代码产出快了,围绕代码的组织流程没变。一家造出世界上最锋利锤子的大厂,公开承认墙不在锤子上。

这份手册值得每个关心组织效率的人认真读一遍。这篇文章不是翻译,是我读完之后的一份解读笔记:它印证了什么、它给出的工程答案是什么、以及它没覆盖的地方在哪里。

Code Is No Longer the Bottleneck — Anthropic’s SDLC Playbook Confirms It

[Read More]

一切皆插件的时代,唯一不可插件化的是信任

In an Age of Pluggable Everything, Trust Is the One Thing You Can't Plugin

前两天,一个问题把我问住了。

有人问我:DeepSeek 说「一切皆插件」,一切核心都可以替换——模型可换、循环可换、连会话日志都是插件。那么,什么东西是不可替换的? 是不是只有人和人的协作?再往深一层,是不是「信任」不可替换?

我盯着这个问题想了很久,因为它恰好戳中了我这两天写 一切皆插件:DeepSeek Harness 真正硬核的是三个细节 时一直绕不开的东西。

一切皆插件——注册即副作用,卸载即回滚。整个系统的设计哲学只有一句话:没有什么是不能拿掉的。

但真的什么都可以拿掉吗?

答案是否定的。有一样东西,不管架构怎么解耦、日志怎么追加、插件怎么热插拔,它既不能被替换,也不能被快速恢复。

那就是信任。

In an Age of Pluggable Everything, Trust Is the One Thing You Can’t Plugin

[Read More]

AI 重构行业的速度,是可以算出来的

The Speed of AI Disruption Is Computable

上周有两个消息放在一起看,特别有意思。

一条是:AI 客服已经能独立处理大部分标准咨询,有的团队把人工坐席砍了一半以上。另一条是:AI 医生还在辅助写病历的阶段,离独立诊断隔着十万八千里。

同一种技术,同一个十年,为什么差出这么多?很多人的答案是「医疗数据难搞」「监管严」——都对,但都只是现象。现象背后有一个可以算的东西: AI 重构一个行业的速度,是有公式的。 这个公式不仅能解释客服和医疗的差距,还能告诉你自己的行业排在队里的第几个。

The Speed of AI Disruption Is Computable

[Read More]