上周整理数字员工的术语，有人在讨论里问了一个问题：
「数字员工背后的 Agent，具体实现上是一套什么东西？」
这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。
但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。
后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。
一、不是一个模型，是一套闭环系统
先把答案放在前面：
数字员工背后的 Agent，是一套以组织身份为锚点、以上下文供给为燃料、以 Eval 为验收标准、以学习信号回流为进化机制的闭环系统。
拆开看，它是五层基础设施的叠加：
┌─────────────────────────────────┐
│ ⑤ 学习层 纠错回流 Memory / Skill │
├─────────────────────────────────┤
│ ④ 验收层 Eval 上岗考试 ≥95% │
├─────────────────────────────────┤
│ ③ 执行层 JD 边界 + Harness │
├─────────────────────────────────┤
│ ② 上下文层 连接器 × 一方数据 │
├─────────────────────────────────┤
│ ① 身份层 工号 / 岗位 / 审计 │
└─────────────────────────────────┘
模型在第三层里做决策
# generated by hugo AI
注意图里的最后一行：模型只是第三层里的一个决策引擎。它很重要，但它不是数字员工本身。就像发动机很重要，但发动机不是公司。
在数字员工是下一个十年的故事里我说过，Agent 改变软件，数字员工改变组织。这篇把那句话落到工程层面：改变组织靠的不是模型，是模型外面这五层——它们全部由组织提供。
下面逐层拆。每层都用会议纪要数字员工做例子，因为它是我们亲手搭过一遍的。
二、第一层：身份层——组织里的一等成员
身份层回答的问题是：这个 Agent 是谁？
不是比喻。是字面意义上的：它有没有自己的账号、工号、岗位和汇报线；它的权限是不是按岗位 scope 授予的；它做的每一件事能不能被审计。
反面教材是「借用身份」：Agent 拿着某个工程师的 token 到处调接口。这样干有三个洞——审计断层（这个操作到底是谁做的？）、权限越界（它继承了那个人的全部权限）、协同不透明（同事不知道 AI 替谁干了什么）。我在Agent 的身份问题里详细拆过这个结构。
会议纪要数字员工的身份层长这样：它有自己的 Agent 账号和岗位（会议纪要专员），权限 scope 限定在日历、听记、通讯录、相关项目群的只读 + 待办的写入。每一次生成纪要、每一次创建待办，审计日志里记的都是双轨——谁触发的、Agent 执行的。
这一层是组织给的，不是模型给的。 模型造不出工号，也造不出审计链。
三、第二层：上下文层——Source of Truth 是组织本身
身份解决「它是谁」，上下文层解决「它看得见什么」。
纪要里写「小王跟进一下」，模型不知道是哪个小王——不是它笨，是它的视野里没有通讯录。在五个问题，判断一个岗位能不能交给数字员工里我把这个叫做上下文供给，这一层就是它的工程实现：
- 日历——知道为什么开会、谁参加；
- 通讯录——知道「小王」是哪个小王、汇报线是什么；
- 项目群聊——知道「上次说的那件事」是哪件事；
- 文档——知道决策的前因；
- 待办——知道谁在负责什么。
连 ASR 的术语错词也是这一层解决的：接一路术语表（公司、行业、项目的专有名词），转写遇到生僻读音就知道正确写法。
注意这一层和「知识库」的区别。知识库是死的——人工整理，整理完就开始腐烂。上下文层是活的，因为它接的是组织每天在跑的数据：组织变了，它看见的就变。
这也是为什么我反复说：Source of Truth 是组织本身，不是模型的参数。模型参数里的知识是训练时冻结的；组织里的上下文是实时的。数字员工答得准，不是因为它背得多，是因为它连得对。
四、第三层：执行层——JD 是边界，Harness 是后果
上下文拿到了，Agent 开始干活。这一层有两个组件：岗位说明书（JD）定义边界，Harness 让每一步行动有可验证的后果。
JD 就是你的下一个下属，不需要工位里的八个问题：做什么、在哪做、对谁做、用什么做、做到什么程度、出了问题找谁、谁能看到、谁有权改。对会议纪要数字员工来说，这八个答案就是它的运行时约束——它只在这些边界内行动，遇到边界外的情况升级给人，而不是自由发挥。
Harness 的部分，我在对 Coding Agent 最友好的，是端到端测试 Harness里讲过它的核心机制：模型负责决策，Harness 负责让决策有后果。 对 Coding Agent，Harness 是 Build、Test、截图；对会议纪要数字员工，Harness 是「纪要生成 → 参会人确认 / 修改 → 待办被认领或被驳回」这条回路。
没有 Harness 的 Agent，每一步都是盲投；有 Harness 的 Agent，每一步都知道自己投没投中。
五、第四层：验收层——Eval 集是上岗考试
执行层保证「每一步有后果」，验收层回答「整体上能不能上岗」。
Eval 集就是数字员工的上岗考试，具体怎么建，在 #331 里写过：取 50 场历史真实会议，人工标定每场的标准纪要（决策点、责任人、跟进项），让数字员工逐场重放，对照计分。我们的准入基准是：迭代几轮后完成率稳定达到约 95%（这是我们内部的实践基准，不是行业标准——你的组织可以用自己的线，但必须有一条线）。
这一层还有两个细节值得强调：
- 待办是最严的评分项。 摘要写歪了能纠回来，待办是行动承诺：责任人、截止日期、交付物，三项全对才算对。
- Eval 的错误点是补上下文的路标。 达不到线的时候去看错在哪——十有八九不是模型笨，是上下文缺一角。纪要把「小王」归错了人，多半是发言人识别没接上。
在Evals 是新的 PRD里我说过，PM 的核心产出正在从需求文档变成 eval 集。对数字员工，这句话有个更硬的版本：没有 eval 集的岗位，不配上岗。
六、第五层：学习层——模型可以换，学习资产不动
前四层让数字员工「能干活」，第五层让它「越干越好」。
每一次人类的纠错、确认、追问、驳回，都是学习信号：「这个决定写得不对」「这句话是张总说的，不是李总」「这条跟进应该归王五」。这些信号被结构化捕获，带上完整的组织上下文——谁、什么场景、什么反馈、Agent 原来做了什么、结果是什么——回流到它的 Memory 和 Skill。
在企业最有价值的 AI 训练数据，不是你写了什么里我把这类信号叫做隐性知识：30 条精准纠错，比 3 万条原始记录更能让 Agent 懂你的企业。学习层就是捕获和回流这些信号的管道。
这一层有一个关键的设计原则： 学习资产属于企业，不属于模型。 Memory、Skill、Eval 都存在组织的租户里，可审计、可导出、可迁移。明天换一个更强的基座模型，数字员工积累的纠错和技能原封不动——它只是换了一颗更强的心脏，记忆还在。
反过来看那些没有学习层的「数字员工」：每次对话从零开始，去年的错误今年照犯。那不是员工，是一块不会走的表。
七、五层是乘法，不是加法
先回应一个可能的质疑：这不就是 Agent 工程的老几样——记忆、工具、评测，换了个说法吗？
零件确实眼熟，差别在锚点。Agent 工程的零件可以全部锚定在一次对话上：记忆锚在会话里，工具锚在开发者的 API key 上，评测锚在单个任务上。这套东西做得出好用的助手，长不出员工。这里的五层，每一层都锚定在组织上：身份锚在通讯录和审计链，上下文锚在组织数据，边界锚在 JD，验收锚在带组织标注的 Eval，学习锚在带组织上下文的反馈信号。同一堆零件，锚在会话里是助手，锚在组织里才是员工。
再说依赖关系：这五层不是功能清单，是乘法——任何一层缺失，它就不再是数字员工，而是塌成别的东西。
| 缺失的层 | 塌成什么 |
|---|---|
| 身份层 | 权限越界的幽灵，没人敢让它碰真业务 |
| 上下文层 | 很贵的聊天机器人，什么都答不上来 |
| 执行层 | 没有边界的实习生，勤快但危险 |
| 验收层 | 没人知道它能不能用，永远停在 demo |
| 学习层 | 不会进化的表，去年的错今年照犯 |
所以「数字员工背后的 Agent 是一套什么东西」，完整的答案是：
模型给的是能力，组织给的是身份、上下文和问责——三者合在一起，才是一个数字员工。
这也回答了开头的疑问：为什么 demo 和员工是两回事。demo 只有第三层里的模型，员工有五层全部。
而五层里有四层——身份、上下文、验收标准、学习信号——只能由组织提供，模型厂商提供不了。这就是为什么我说数字员工是组织问题，不是技术问题；也是为什么在五个问题里，准入门槛考的五件事，件件都在组织这一侧。
你的组织里，这五层哪一层最薄？欢迎留言聊聊。