Agent-Spec

前几天有人问我：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 的一半。把它们拼起来，你会看到一条没人明说的路线。