上周一个老板问我：他想像同行那样，用 3 个真人带 30 个数字员工跑业务（这个比例是我们推演的示意，不是他的真实编制）。卡点在哪？
不是模型不够聪明，也不是工具不够多。卡在一个很朴素的地方：没有一个中层愿意把自己的判断标准写成文档。
审批到什么金额要上报、哪种客户投诉要升级、什么情况下可以破例——这些判断每天都在发生，但全装在某个管理者的脑子里。数字员工问他，他口头答；换一个场景，又得重新问。
于是 30 个数字员工，每一个都变成了「等他拍板」的排队窗口。
Agent Spec 是数字员工的劳动合同
Agent Spec Is the Labor Contract of a Digital Employee
前几天有人问我：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 不是软件描述，它是劳动关系的一份抽象。
Palantir 从本体长到 Agent，我们从 Agent 长回本体
Palantir Grows Agents from Ontology — We Should Grow Ontology Back from Agents
前几天有人抛了一个问题：「哪些客户的续约风险正在上升，今天由谁介入？」
我把它原样丢给了一个 AI 助手，想看看它怎么答。
它的回答很诚实：答不了。它列出了这个问题需要同时拉齐的五个系统——CRM 里的客户关系、合同系统里的到期日、产品日志里的用量变化、工单里的故障、财务系统里的回款——然后说：「任何一个单独看都不够，五个信号交叉才能定位谁在恶化。」
这个回答本身没问题。但它暴露了企业 AI 的真实现状：AI 不缺智能，缺的是跨系统取数的资格。 它能看到每一个系统，如果它有资格的话。
有意思的是，最近两篇文章，从两个完全不同的方向，撞上了同一个问题。一篇是 Carlos Perez 的企业版 OpenClaw 万亿清算论，一篇是《读懂 Palantir Ontology》的完结篇——后者举的范例决策，一字不差就是上面那个续约风险问题。
两篇文章各讲了企业 AI 的一半。把它们拼起来，你会看到一条没人明说的路线。
