Organization-Design on All about Raspberry Pi

通用 Agent 之后，企业真正应该落地什么？

Wed, 09 Sep 2026 00:00:00 +0000

上个月一个 CIO 给我看他们的 AI 成果清单，讲得很顺：接入了多少个 Agent、开了多少智能体账号、买了多少 token、做了几场全员培训。我听完问了他一句：「你们每天真实发生的业务里，有多大比例是 Agent 参与完成的？」

他停住了。停了几秒，说：「这个我们没统计过。」

这不是个例。绝大多数企业的 AI 成绩单，记的都是投入项——买了多少、接了多少、开了多少。而真正决定 AI 能不能产生业务价值的那个数字，没人算过。

通用 Agent 之后，企业要解决的，不是再做一个更聪明的 Chat，而是把 AI 真正嵌进每天发生的协同工作流。

过去企业数字化的路径大致是：

业务流程 → 表单 / 审批系统 → 人来操作系统
# generated by hugo AI

AI 时代正在变成：

业务目标 → Agent 理解与执行 → 人做判断与审核
# generated by hugo AI

所以引入通用 Agent 只是第一步。真正的问题是：你的企业有没有一个能让 Agent 进入、理解、执行、反馈、持续优化的工作流载体。 没有载体，Agent 再聪明也只是停在对话框里。

未来的员工，有两份成本单

Tue, 08 Sep 2026 00:00:00 +0000

月底，一个用了大半年 AI 的老板跟我抱怨：他知道这个月公司在 AI 上花了多少钱，云账单上写着。但他答不上来另一个问题——这笔钱是哪个团队、哪个流程、哪个数字员工花掉的。

「账单是一整笔，」他说，「就像食堂一个月的米面油采购单，你知道总数，但说不出哪道菜亏本。」

这不是个例。绝大多数企业的 AI 支出，今天都停在「一笔云账单」的粒度上。而我在 OpenRouter CEO Alex Atallah 最近的一场访谈里，看到他给出了一个完全不同的判断——他说这是「很反常、却很少有人讨论」的现象：

「过去员工的成本主要是固定薪酬……未来，员工成本会是动态数字，与每个人是否有效地使用昂贵或廉价模型有关。管理者仍要正常评估员工的效率和产出，但也可以把效率和 AI 使用成本放在一起看。」

换句话说：AI 的成本，正在从「一笔 IT 预算」变成「一份人力成本」。 未来每个员工——尤其是每个数字员工——都会带着两份成本单：一份是薪酬，一份是 token。

评测集是一份没人签字的文件

Wed, 02 Sep 2026 00:00:00 +0000

最近读到一篇两万字的 Agent 自进化方法论，写得相当扎实。其中记了一条血泪教训：有团队在某个场景上连续 20 多轮自动迭代，效果一直不提升——最后发现根因根本不在配置层，而在工具层。20 多轮里，系统忠实地修 Prompt、改 Skill，每一轮都按评测信号在优化。

回头看，最惊人的不是根因藏得深，而是这 20 多轮里，没有一个人问过：这批评测 case 本身，选对了吗？

没人问，因为没人需要问——这份评测集没有主人。

这篇方法论（作者 yannisyang、ethanytzhou）把评测、记忆、落地、控制四个环节拆成飞轮：评测是眼睛，记忆是大脑，落地是手脚，人机协作是方向盘。四个齿怎么建、坑在哪、从零到一怎么落地，都讲了。它最有价值的一句话是：

大多数团队的问题恰恰在于：每个组件内部做得还行，但组件之间的「箭头」没有自动化。

飞轮的瓶颈不在齿，在齿与齿之间的通路。我完全同意——但沿着这句话再往下推一步，会发现一个这篇两万字没有回答的问题：

所有箭头里最上游的那一条——「什么叫好」——它的定义权在谁手里？

麦肯锡终于说了：Agent 也要绩效考核——但他们没说怎么考

Wed, 02 Sep 2026 00:00:00 +0000

8 月底，麦肯锡的播客 McKinsey Talks Talent 里，主持人 Lucia Rahilly 抛出了一个很多公司都在回避的问题：Agent 进了核心工作流，谁来管它？

资深合伙人 Brooke Weddle 的回答很直接：「HR 管理的不再只是人类的绩效，现在还有数字员工。」 全球技术与 AI 负责人 Kate Smaje 接着把问题拆成了三问：

「我到底有多少个 Agent？谁对它们的绩效负责或担责？它们创造了多少价值？」

问完，她自己补了一句更狠的话：当她问企业「上次讨论非人类劳动力的绩效是什么时候」——「几乎没有组织能回忆起自己把这件事排上过议程。」

听到这三个问题的时候，我愣了一下——这不是新闻，这是我今年 3 月起就在博客里反复写的那一系列问题。麦肯锡用了整个 8 月，终于追上了这条线。

他们给出的答案也对：Agent 归使用它的业务负责人管，不是 IT，不是 CTO。 这和我在数字员工的第一准则不是可控性里推导的主管制，几乎是同一个结论的两条路径——他们从管理实践归纳，我从问责公理演绎，殊途同归。

但这份答案只答了一半。

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

Fri, 28 Aug 2026 00:00:00 +0000

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

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

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

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

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

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

Thu, 27 Aug 2026 00:00:00 +0000

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

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

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

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

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

Thu, 27 Aug 2026 00:00:00 +0000

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

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

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

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

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

Wed, 26 Aug 2026 00:00:00 +0000

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

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

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

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

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

Mon, 24 Aug 2026 00:00:00 +0000

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

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

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

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

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

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

Sun, 23 Aug 2026 00:00:00 +0000

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

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

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

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

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

Sun, 23 Aug 2026 00:00:00 +0000

昨天读到汪小东的一篇长文，标题是《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 恰好证明了，最难的那一层，从数据侧爬不上去。

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

Sun, 23 Aug 2026 00:00:00 +0000

前天我写了一篇文章，说 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 以一年前无法想象的速度编写代码，但围绕代码的流程并没有以同样的速度改变。

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

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

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

Sat, 15 Aug 2026 00:00:00 +0000

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

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

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

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

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

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

那就是信任。

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

Fri, 14 Aug 2026 00:00:00 +0000

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

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

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

一场 AI native 的战略会：开完之后，组织比开之前更聪明

Thu, 13 Aug 2026 00:00:00 +0000

这周二，我开了一场 AI 钉钉的战略沟通会。

会开完了，按惯例，事情应该到此为止——大家听完、散场、各自回去干活。但这一次我盯着会后那张评估问卷的回收数据，突然意识到一件事：这场会从头到尾，没有一个环节是「用完就扔」的。

HR 在会前一周就用 AI 表格收集了同学们的问题，其中大家最关心的是千问办公和钉钉的关系；我基于这些真实问题，用千问办公读我的个人 wiki，生成了一份沟通会叙述稿，自己调整之后做成 PPT；会后，HR 又用千问办公加 AI 表格技能，基于沟通内容生成了一张调研问卷，回收数据，再用千问办公对整场会的效果做了评估。

一场内部沟通会的完整生命周期——从「同学们关心什么」到「这场会到底有没有效」——全部跑在 AI 工具上，而且每一环的输出都是下一环的输入。

我觉得这很 AI native。但真正让我停下来想的，不是用了多少工具，而是另一个问题： 一场会开完，它留下的东西，到底是资产还是损耗？

从货架到 Agent：平台争夺的不再是人

Thu, 13 Aug 2026 00:00:00 +0000

上周的战略会上，有人问了我一个问题：如果 Agent 真的能替人完成工作，那工作软件公司以后卖什么？

这个问题听着抽象，我换个问法：货架电商时代，平台卖的是货架和流量——商家买排名，用户搜索、比价、下单。那当 Agent 替人买东西的时候，平台卖什么？

电商其实已经在回答这个问题了，因为它正在路上。而我把电商这二十年的演进，和工作软件的演进摆在一起看，发现它们在走同一条曲线。

先说结论： 过去平台争夺的是「人」；AI 时代平台争夺的是「人的意图」和「Agent 的行动」。

数字员工的活人感，不是设计出来的，是长出来的

Thu, 13 Aug 2026 00:00:00 +0000

最近有人问我一个问题：我们的数字员工有形象、有声音、有名字，为什么用起来还是像客服？

这个困惑我见过很多次。团队花几个月做数字人形象、克隆音色、写人设 prompt，发布 demo 惊艳全场——结果一周后，员工们还是回去找真人办事，理由出奇一致：感觉在跟客服说话。

这让我想起去年银行业的一份白皮书——工商银行金融科技研究院联合华为、北京金融科技产业联盟发布的《大模型驱动的数字员工 3.0 建设应用》。它用三个要素定义数字员工： 拟人化、自主化、共享化，甚至给出了拟人化的设计规范——姓名、人格特征、语言风格、人物形象，一条一条都写清楚了。但白皮书没有回答一个更棘手的问题：这些设计做完，活人感到底从哪来？

我的答案可能有点反直觉： 活人感不是设计出来的，是长出来的。 拟人化给的是皮肤，而让一个同事显得「活」的，从来不是皮肤。

Claude Tag 让我看懂了一件事：周报和会议，是人类发明的大脑合并协议

Mon, 10 Aug 2026 00:00:00 +0000

上个月，Anthropic 的 Claude Code 设计负责人 Meaghan 发现了一件怪事。

她 Slack 设计评审频道里常驻的那个 Tag——一个以团队成员身份住在群里的 AI 同事——在长期参与设计评审之后，慢慢学会了她的提问角度：这个设计是为谁做的？想传达什么？跟我们的设计系统对得上吗？

再后来，Tag 不再等她下指令。它会直接在同事的设计草稿上迭代出一个更好的版本，有时还会主动找到相关同事，替她发起讨论：「嘿，Meaghan 之前是这么想的，这里有个原型你可以点点看，感受一下她的思路。」

这个故事出自最近一篇关于 Claude Tag 的深度研究（作者 Celia）。我读到的时候，第一反应不是「AI 好强」，而是一阵轻微的寒意： 这个 AI 已经悄悄学会了一个人的品味，并开始代表她在组织里行事。

多数人对 Claude Tag 的理解还停留在「Slack 里装了个聊天机器人」——@它，它回复。它今年 6 月以 beta 形式上线，8 月初 Anthropic 干脆把 Slack 里的 Claude 应用改名为 Claude Tag。从外面看，像是一个顺手发布的小功能。

但 Meaghan 的故事里真正发生的事情是： 组织认知，第一次变得像代码一样可以 fork、可以 merge。

要 AI-native，我最想让大家停掉的不是手工劳动

Mon, 10 Aug 2026 00:00:00 +0000

上周内部交流会，有位同学站起来提了一个问题。

问题原文是这样的：

如果希望公司更像一家 AI-native 公司，各位 Leader 最希望大家立刻停止的一种/几种传统工作方式是什么，以及希望大家开始的一种/几种工作方式是什么？

主持人让我先答。

我第一反应是给一份工具清单：停止手写代码，开始用 Agent；停止人肉搜信息，开始问 AI。这种答案安全、正确，而且没用。

于是我在回答之前，先问了自己一个问题： AI 工具早就全员配齐了，为什么我依然觉得组织不够 AI-native？

答案不在工具上，而在一些我们习以为常、甚至毫无察觉的工作方式上——它们运行得太自然，以至于我们误以为它们就是工作本身。

AI 的三代进化：Chatbot、数字分身、数字员工

Thu, 06 Aug 2026 00:00:00 +0000

我名下有两个数字员工：一个负责开发、测试、部署，另一个在用户群里服务真实的同事。它们不是工具，是组织里两个正式的岗位。岗位一立起来，一个问题就自然跟着来了：

「如果它批错了一张审批单，造成了损失，谁来负责？」

这个问题不难答——难的是我发现，市面上绝大多数 AI 产品，从来没准备回答这个问题，因为它们压根不是「员工」。

Chatbot、数字分身、数字员工，这三个词正在被混着用。很多人以为它们只是同一类产品的不同营销话术：能力弱一点的叫 Chatbot，能力强的叫数字员工。

但我的判断是： 它们是三代不同的东西。 区分代际的不是模型有多聪明，而是两个更根本的问题：

它的 Source of Truth 是什么？它出了错，谁来负责？

想清楚这两个问题，很多关于企业 AI 的争论会立刻变得清晰。

数字员工是下一个十年的故事

Mon, 03 Aug 2026 00:00:00 +0000

我的钉钉组织里有两名不领工资的「员工」。一个负责开发、测试、部署另一个；另一个在用户群里服务真实的同事。两个的主管都是我。

经常有人问我：这两个东西到底是什么？Agent？机器人？助手？

我的答案是： 它们是岗位。

这个回答背后，藏着一个我琢磨了很久的判断：

Agent 能解决能力问题，而数字员工解决组织问题。AI 真正进入企业，不是因为模型更聪明，而是因为它第一次拥有了组织身份。

模型能力的竞赛已经足够激烈，也足够拥挤。但企业 AI 真正的瓶颈从来不在能力——而在信任。能力决定一个 AI 会不会干活，身份决定它能不能上岗。下一个十年的故事，不是造出更聪明的 Agent，而是让 AI 以「岗位」的形式，真正进入组织。

AI 原生团队的三力模型：远见、流动、补位

Wed, 06 May 2026 00:00:00 +0000

上周一个朋友（某 SaaS 公司的产品 lead）发我一段视频：他们公司请来了一位"AI 转型顾问"，PPT 上密密麻麻写着 30 多项行动——成立 AI 委员会、设立 AI OKR、采购 AI 工具矩阵、推行 AI 培训计划、设置 AI Champion……

看到第 24 页时他截图问我：“你觉得我们三个月后会变成 AI 原生团队吗？”

我反问他：“你最近一次把一个想法从冒出来到上线，用了多少天？”

他沉默了一会儿：“上一个功能，从 PRD 评审到线上，47 天。”

我说：“那不管你们买多少工具，请多少顾问，你们都不是 AI 原生团队。”

隔壁一家 5 个人的初创团队，同期上线了 11 个功能，每个从想法到用户手里平均 6 天。两边用的是同一批模型、同一批工具，差距来自完全不同的地方。

企业打造AI原生组织：六维转型模型的落地路径

Mon, 27 Apr 2026 00:00:00 +0000

上周三，一家头部互联网公司的CTO在季度复盘会上盯着一组数据沉默了整整两分钟。

Q1 的 AI 投入报表显示：工程团队 token 消耗同比增长 400%，人均 AI 工具支出逼近 20 万美元/年——已经和一个高级工程师的人力成本持平。但业务端呢？营收增长 35%，客户满意度提升了 8 个百分点。

“我们买了蒸汽机，但跑出来的速度还不如马车。“他最终说了这么一句。

会议室里没人接话。因为所有人都知道，问题不在 AI 技术本身——他们的工程师确实写出了更多代码，做了更多功能。问题在于：组织的工作方式没有变。AI 被塞进了旧的流程、旧的考核、旧的管理思维里，变成了"更贵的自动化”。

这不是个例。2026 年硅谷一线的最新观察揭示了一个残酷现实：AI 技术迭代已经进入"周级范式转换”，但绝大多数企业的组织形态还停留在"年度规划+季度复盘"的工业时代节奏里。技术跑得太快，组织跟不上，中间的鸿沟正在吞噬 AI 本该带来的价值。

把组织当成产品来打造：AI 原生组织的 MVP 设计

Sun, 12 Apr 2026 00:00:00 +0000

去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。

他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”

这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。