前几天有人问我：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 不是软件描述，它是劳动关系的一份抽象。
Agent 不是源代码
先说清楚这个判断在讨论什么。Agent Builder 的完整技术栈有三层，每一层都是一个编译器加一份产物：
Human Intent
↓
┌──────────────┐
│ Spec Compiler│ 输入：「帮我创建一个采购数字员工」
└──────┬───────┘ 输出：Identity / Role / JD / Context /
↓ Tools / Permissions / Policies /
Agent Spec Boundaries / Evals
↓
┌──────────────┐
│Agent Compiler│ 输入：Agent Spec
└──────┬───────┘ 输出：Agent Program / Agent Graph /
↓ Skills / Tool Calls / Routing /
Agent Program Model Selection / Execution Policies
↓
┌──────────────┐
│ Agent Runtime│ 承载：Model / Context / State /
└──────┬───────┘ Tools / Sandbox / Execution
↓
Digital Employee
# generated by hugo AI
如果只能选一个概念来命名 Agent Builder 的终局，我的选择是 Spec Compiler，不是 Agent Compiler。
原因在层级关系里：Agent 本身不是被编译的「源代码」。Research Agent → Analysis Agent → Browser Agent → Approval Agent 这样的编排，是 Agent Program，是 编译产物。Builder 真正要解决的问题在上游——把一句话的意图，编译成那份完整的 Spec。
用一句话概括：Agent as Code 是实现形式，Agent Spec 才是抽象本体。
但「本体是什么」这个问题，还可以再往下推一层：Spec 这份本体，它的性质到底是什么？
逐字段读一遍：这不是配置，是入职材料
回到那份采购专员的 YAML。把它当成软件配置读，和把它当成员工材料读，是两种完全不同的体验：
| Spec 字段 | 当「软件配置」读 | 当「员工材料」读 |
|---|---|---|
| employee / role | 实体与类型 | 工号与岗位 |
| mission | 任务列表 | 岗位职责（JD） |
| context | 数据源连接 | 工作范围：能接触哪些系统和信息 |
| permissions | API 授权 | 工作授权 |
| boundaries | 约束条件 | 权限红线 |
| evals | 测试用例 | 绩效考核标准 |
注意一个事实：这份 YAML 里 没有一个字段在说「怎么实现」。全部字段都在回答另外四个问题——这个人是谁、能干什么、不能干什么、怎么考核。
而这四个问题，恰好是组织定义一个员工的全部内容，不是 系统定义一个程序的内容。系统定义程序靠接口、依赖、调用序列；组织定义员工靠岗位、授权、红线、考核。这份 Spec 用的全是后一套词表。
这不是巧合。它说明 Spec 的设计者——不管是有意识还是无意识——在写的东西根本不是软件规格书，而是 入职材料。
劳动合同的三份合同
劳动合同拆开来看，从来不是一份文件，是三份合同叠在一起。Agent Spec 的字段结构，恰好和这三份合同一一对应：
第一份：社会契约。 mission 和 role 是岗位说明书——组织对这个角色的期待是什么。采购专员的 mission 是「处理采购申请」，这就是岗位存在的理由。
第二份：法律契约。 permissions 和 boundaries 是授权书——能签字的范围在哪，越权的红线在哪。cannot_approve_purchase 翻译成人话就是「不得越权审批」——这句话在每家公司的采购管理制度里都能找到原文，一字不差。
第三份：绩效契约。 evals 是考核标准——干得好不好的客观尺度。Evals 是新的 PRD 讲的是它在需求侧的含义，这里的含义是：evals 就是这个员工的绩效考核表。
把三份合同合起来看：劳动合同的本质就是这三样——你是谁、你被授权做什么、你怎么被问责。所以那个结论可以改写得更准确：
Spec Compiler 编译的不是代码，是劳动关系。
再看技术栈的最后一行，你会发现它早就泄露了答案——流水线的终点写的不是「一个跑起来的 Agent」，是 Digital Employee。编译目标本来就是员工，不是程序。
编译过程就是入职流程
这个视角还能解释一件产品设计上的事：为什么 Spec Compiler 必然是对话式的。
传统编译器的输入是形式化的源代码，编译是确定性变换——同一份 C 代码永远编出同一份二进制。Spec Compiler 不一样，它的输入是半结构化的意图，所以它的核心工作不是变换，是 消歧：
- 「这个采购专员，能自主审批吗？」
- 「预算上限多少？」
- 「供应商白名单归谁维护？」
这些问题不回答，Spec 就编译不完整。而这一问一答的过程，有个现成的名字叫：HR 办理入职。
这直接推出 Agent Builder 的产品形态判断：这个赛道的赢家不会是又一个 IDE——没有人用 IDE 办入职。赢家的形态是 入职流程：提 JD、批权限、定考核、上岗、评估。今天大量 Builder 产品还在优化「怎么搭 graph、怎么配 tool」，那是在优化编译器的下半段，而真正的产品战场在上半段——怎么把一句话意图，谈成一份权责清晰的合同。
两个最尖锐的反方
「这是不是把配置文件过度诠释了？合同有甲方、有合意、有违约责任，一份 YAML 哪来这些？」
这个挑战问到了点子上，但答案恰恰在 Spec 里。违约机制是存在的：boundaries 会被编译进运行时成为 强制护栏——cannot_approve_purchase 不是写在 prompt 里的建议，AI 可以选择性遵守；它是编译出来的约束，越权动作根本执行不了。evals 会编译成验收门禁——持续不达标的 Agent 会被下线，这就是「不胜任」。
配置是建议，可以被违反；Spec 里的 boundaries 是强制，没有商量的余地。这也是「编译」这个词的分量所在：把意图变成可强制的结构。 合同之所以是合同，就因为它有强制力——Spec 有，所以它是合同，不是配置。
「模型会越来越强，将来直接消费原始意图，中间不需要 Spec 这一层。」
这是更强的反方，但它错在一个前提上：Spec 层不是为模型存在的，是为 组织 存在的。就算未来的模型能完美消费一句话意图，组织仍然需要一份白纸黑字的治理工件——这个 Agent 是谁、能干什么、出事谁负责。我在Anthropic 领先行业 6 个月——但只有前两层算数里论证过：上下文可以重建，责任不能。 模型进步消灭不了 Spec 层，只会让 Spec Compiler 的下半段越编越顺。
合同模板归谁：入职权就是问责入口
最后一个推论，也是最锋利的。
如果 Spec 是劳动合同，那么合同的甲方是组织。起草劳动合同的工具，天然应该长在拥有那套词表的地方——工号、岗位、审批链、考核制度，这些词组织平台用了二十年，模型厂商一个都没有。
按「Agent 是软件」的视角，Spec Compiler 应该归模型厂商，因为它们在做 Agent Compiler，顺手往上吃。但按「Agent 是员工」的视角，答案反过来了：谁定义了数字员工的劳动合同范本，谁就掌握了入职权——而入职权就是问责的入口。 没有入职记录的数字员工，出了问题无法追责；反过来，谁手里握着入职档案，谁就是组织问责体系的一部分。
这也回答了拟人化的数字员工里那条分界线：功能（Bot）和角色（数字员工）的区别不在能力上限，在行为模式——现在可以补上完整的答案：让一个 Bot 变成角色的，就是那份劳动合同。 签了合同，它才从「一个功能」变成「一个要对结果负责的岗位」。
结尾
回到开头那个问题。Agent Builder 的终局，不是做一个更好的 Agent 生成器——那是 Agent Compiler 的事，而且是模型厂商的主场。终局是做一个 数字员工的入职系统：把一句话意图，谈成一份权责清晰、可强制执行、可考核问责的劳动合同。
一个问题留给你：你组织里的数字员工，现在是签了合同入职的，还是只是「跑起来了」？
欢迎留言聊聊。