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 工具、覆盖了多少人、token 消耗增长了几倍。然后有人扔出了这么一句：
企业组织架构不变、流程不变、人才要求不变，就别谈 AI 原生。
乍一听很极端，但细想会发现它的厉害之处：它把「AI 原生」从一个技术采购问题，变成了一个组织事实问题——原生与否，不看买了什么，看结构动没动。
这个类比很精确。cloud-native 的反面不是「没用云」，而是 lift-and-shift——把单体应用原封不动搬上虚拟机，然后宣称自己上云了。今天绝大多数所谓的「AI 转型」，就是 AI 版的 lift-and-shift：把 AI 塞进旧流程、旧考核、旧管理思维里，然后管这叫原生。
上周，一位做软件外包的朋友跟我吐苦水。
他给公司三十多个工程师全部配了 AI 编程工具，钱花了不少，工程师也很买账。半年后他拉数据，想看看交付速度提升了多少——结果发现，项目平均交付周期几乎没变。工程师写的代码确实多了，但代码堆在评审环节；评审通过了，又堆在测试和发布环节。
他问我：「是不是工具不够好？要不要换一个更贵的？」
我说：工具没问题。问题是 AI 把每个人手里的活干快了，但活和活之间的缝隙，一点没变窄。代码从「写完」到「上线」，中间隔着评审、测试、审批、排期——这些环节里没有一个 AI，全是人在等人。
昨天读到汪小东的一篇长文，标题是《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 恰好证明了，最难的那一层，从数据侧爬不上去。
前天我写了一篇文章，说 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 以一年前无法想象的速度编写代码，但围绕代码的流程并没有以同样的速度改变。
翻译成我们前天讨论的语言：代码产出快了，围绕代码的组织流程没变。一家造出世界上最锋利锤子的大厂，公开承认墙不在锤子上。
这份手册值得每个关心组织效率的人认真读一遍。这篇文章不是翻译，是我读完之后的一份解读笔记：它印证了什么、它给出的工程答案是什么、以及它没覆盖的地方在哪里。
想知道一家 AI 公司把赌注押在哪里，别看发布会，看它的 release notes。
上周有两份发布说明摆在一起，对比堪称黑色幽默：Claude Code 的 v2.1.239 版本写了 40 多条变更，跨机器通信、预算上限、企业云适配密密麻麻；同一周，Codex 的 release notes 只有五个字——「Release 0.x.y」，功能演进一个字不提，却日更 162 个二进制资产。
同一个行业，同一个星期，一家把底牌全摊开，一家把底牌全藏起来。发布说明是产品策略的 X 光片：什么功能被做成一等公民、什么被顺手带过、什么被刻意藏起来，全写在里面。
我把六大主流 Coding Agent 的八月发布记录拉了一遍——OpenClaw、Hermes Agent、OpenCode、Claude Code、Codex、DeepSeek Harness——发现一件有意思的事：
六家公司，朝着几乎相同的方向走，但走的路线完全不同。
相同的去处暴露了行业共识；不同的路线暴露了各家的底牌。这篇文章把这张 X 光片拆开给你看。数据来自我的 开发者双周观察（2026.08.23）。
今年早些时候，我写过这样一个案例：一家电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价，部分商品以成本价以下售出，一天亏了 80 万。复盘会上——
运营说：是 AI 自动调的。技术说：是数据源有异常。数据团队说：数据是实时抓取的，跟我们无关。
没有一个人为这 80 万负责。（案例详见企业级 AI 必须设计成出错后可以追责到人）
那篇文章讲的是工程层面怎么追责：授权链、策略签名、审计日志。但写完之后，有一个更根本的问题一直挂着我：
为什么必须追到「人」？为什么不能追到 Agent 本身？
这个问题听起来像文字游戏，其实不是。它决定了你的数字员工部署从哪里画下第一根线——第一根线画错了，后面每一根都是错的。
前段时间我把这个问题的推导写成了一份内部文档。这篇文章是它的公开版：不做功能罗列，不列合规清单，从第一性原理出发，推导数字员工要成为组织成员必须满足什么条件。
前几天有人问我：Agent Builder 的终局是什么？
我没直接回答，先让他做了个实验：在 Builder 里输入一句话——「帮我创建一个采购数字员工」。
Builder 吐出来一份 YAML：
employee:
role: 采购专员
mission:
- 处理采购申请
context:
- ERP
- DingTalk
- Supplier DB
permissions:
- read_inventory
- create_purchase_draft
boundaries:
- cannot_approve_purchase
evals:
- ...
# generated by hugo AI
我问他：你觉得这份 YAML 是什么？
他说：Agent 的配置文件。
我说：逐字段再看一遍。
他看了几秒，声音不太确定了：「这……是一份 JD？」
对。这就是这篇文章的核心判断：Agent Spec 不是软件描述，它是劳动关系的一份抽象。
前几天有人抛了一个问题：「哪些客户的续约风险正在上升，今天由谁介入？」
我把它原样丢给了一个 AI 助手，想看看它怎么答。
它的回答很诚实：答不了。它列出了这个问题需要同时拉齐的五个系统——CRM 里的客户关系、合同系统里的到期日、产品日志里的用量变化、工单里的故障、财务系统里的回款——然后说：「任何一个单独看都不够，五个信号交叉才能定位谁在恶化。」
这个回答本身没问题。但它暴露了企业 AI 的真实现状：AI 不缺智能，缺的是跨系统取数的资格。 它能看到每一个系统，如果它有资格的话。
有意思的是，最近两篇文章，从两个完全不同的方向，撞上了同一个问题。一篇是 Carlos Perez 的企业版 OpenClaw 万亿清算论，一篇是《读懂 Palantir Ontology》的完结篇——后者举的范例决策，一字不差就是上面那个续约风险问题。
两篇文章各讲了企业 AI 的一半。把它们拼起来，你会看到一条没人明说的路线。
