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 自己把它做出来。这篇文章讲讲为什么，以及它的边界和风险。
一、两种范式：人拼 Agent，还是 Agent 拼 Agent
先看传统 Agent Builder 的基本范式：人选择模型，然后逐一配置 Prompt、Knowledge、Tools、Workflow，最后发布 Agent。本质是：人来拼 Agent。
而 Harness 的范式是：人只定义目标、Spec 和 Evals，然后由 Coding Agent 自主阅读代码、修改组件、运行测试、运行 Evals、发现问题、继续修改，直到达标。本质变成：Agent 自己拼 Agent。
这不是程度差异，是范式差异。Builder 范式下，人是实现者，AI 是助手；Harness 范式下，人是定义者和验收者，AI 是实现者——这正是我在组织架构没变，就别谈 AI 原生里说的「人从执行者移到验收位」，在数字员工开发这件事本身上的重演。
Agent Builder 的时代，是人拼 Agent；Agent Harness 的时代，是 Agent 自己拼 Agent。
二、为什么是 Harness：Agent 终于可以被拆成工程部件
为什么 Agent 自己拼 Agent 以前做不到？因为传统 Agent 是「配置态」的——一堆 Prompt、工具、知识库挂在平台上，没有代码可读，没有接口可换，Coding Agent 面对它无从下手。
Harness 改变的就是这一点。以 DSH 为例，它的架构叫 Everything is a Plugin：基于一个叫 Cordis 的插件内核，模型、工具、技能、会话、沙箱、存储、调度循环、UI，全部是可插拔、可重组的插件。用一份配置文件就能增删替换任何能力，不用改源码。
更重要的是它的可追溯设计：模型看到的一切——系统提示、推理、工具调用和结果、子 Agent 调度、每次上下文注入——都写进一份只增不改的会话日志。出问题的每一步都能回放。
这两件事合起来，意味着数字员工从一个「配置出来的黑盒」变成了一套 可编程、可替换、可测试、可迭代的工程系统。数字员工不是一个 Prompt，而是一套完整的软件系统，可以拆成：
Digital Employee
│
├── Identity 企业账号 / 岗位 / 汇报关系 / 权限
├── Context Knowledge / Memory / DWS Events / 组织上下文
├── Reasoning Model / Planner / Agent Loop
├── Action MCP / Browser / Shell / DingTalk APIs
├── Control Approval / Permission / Guardrail / Sandbox
├── Evaluation Task Evals / Safety Evals / Regression Evals
└── Learning Feedback / Trace / Memory Update
# generated by hugo AI
Coding Agent 可以只修改某一个部件——换工具、改循环、加记忆——而不是每次从头重新构建整个 Agent。这就是 Harness 之于数字员工的价值：它让「Agent 拼 Agent」有了可以拼的零件。
三、Spec 是岗位定义，Evals 是验收标准
这套范式里有三个东西必须分开：
Spec = What the employee is（这个员工是什么）
Eval = Whether the employee is good enough（够不够格上岗）
Code = How the employee works（它实际怎么工作）
# generated by hugo AI
不要把 Spec 理解成 Prompt。我在 Agent Spec 是数字员工的劳动合同 里论证过：Spec 定义的是岗位本身。它应该回答这些问题：
role:
name: 电商运营
responsibilities:
- 分析销售数据
- 发现异常商品
- 生成补货建议
permissions:
read:
- orders
- inventory
write:
- purchase_request
approval:
- purchase > 10000
constraints:
- cannot_delete_order
- cannot_modify_price
# generated by hugo AI
岗位是什么、为什么存在、负责什么、不负责什么、可以访问什么、可以执行什么、什么事情需要审批、什么事情绝对不能做、什么结果算成功——九件事，缺一不可。
Evals 则回答另一个问题：这个岗位到底有没有资格「上岗」。
于是数字员工的开发方式，从 Prompt Engineering 变成了 Eval-driven Engineering：
| 传统：Prompt Engineering | 新范式：Eval-driven Engineering | |
|---|---|---|
| 起点 | 写一段 Prompt | 定义 Spec + Evals |
| 迭代方式 | 试一下 → 觉得不好 → 改 Prompt | 跑 Evals → 失败案例 → 分析 Trace → 改实现 |
| 交付标准 | 「看起来还行」 | Eval 通过率 + 生产反馈 |
| 工程形态 | Prompt → Chat → 调参数 | Spec → Code → Test → Eval → Regression → Deploy |
这就是我说「数字员工开发开始接近软件工程」的含义——它有了软件工程的全部要素：规格、实现、测试、回归、部署。
四、钉钉的位置：不做 Harness，做 Runtime
那么钉钉在这场范式转移里扮演什么角色？这里有一个我认为非常关键的判断：
钉钉不需要成为 Agent Harness。
DSH、Claude Code、Codex、OpenCode，以及未来出现的任何 Harness，都可以用来开发数字员工——就像今天任何 IDE 都能开发跑在同一个操作系统上的软件。
钉钉真正应该提供的是 Digital Employee Runtime / Organization Runtime：
Identity 企业身份
Organization 组织结构
Permission 权限
DWS Event 组织事件
MCP 能力接入
Knowledge 企业知识
Memory 组织记忆
Approval 审批
Audit 审计
Sandbox 沙箱
Production Eval 生产评估
# generated by hugo AI
这样就划出了一条非常清晰的边界：
Harness 负责「Agent 怎么思考、怎么实现、怎么迭代」。
Runtime 负责「Agent 以谁的身份、在什么组织里、拿什么权限、基于什么企业上下文工作」。
这条边界的意义在于：钉钉不用和全世界的 Harness 竞争开发体验，而是成为所有 Harness 产出的数字员工最终「入职」的地方。
五、入职的关键：DWS Event
一个 Agent 如果只是「用户 → Chat → Agent → Answer」，它仍然更接近 Chatbot。真正的数字员工要进入企业的 Event Loop：
IM / 审批 / 文档 / 任务 / 组织变化 / 业务系统事件
↓
DWS Events
↓
Digital Employee
↓
Think → Act → Verify
↓
IM / Approval / MCP / 业务系统
# generated by hugo AI
事件是组织的神经信号。数字员工不是等人来问才工作，而是感知组织里正在发生的事，然后思考、行动、验证。让组织可编程里我说过，DWS 是组织的控制面；对数字员工来说，DWS Event 就是它进入企业组织的神经系统。
六、八件套：从 Agent 到员工
把前面拆开的部件对照着看，「员工」和「Agent」的差距就清楚了。Agent 只需要推理和行动，员工还需要另外六样东西：
Identity = 我是谁
Knowledge = 我知道什么
Memory = 我记得什么
MCP = 我能做什么
DWS Event = 什么事情正在发生
Sandbox = 我在哪里工作
Approval = 什么事情需要问老板
Evals = 我的工作做得好不好
# generated by hugo AI
这八样组合起来，才真正接近「员工」。缺了身份，行动无处归属；缺了事件，只能等人来问；缺了审批，没人敢放它进生产。这也是我在 数字员工的第一准则不是可控性 里推导的结论的组织侧版本：员工的构成性条件不是能力，而是它在组织问责结构里的位置。
七、FDE 的角色：从配置者到工程师
范式变了，人的角色也跟着变。
传统的 FDE（Forward Deployed Engineer）：配置 Agent、配置 Workflow、配置 Knowledge、配置 Tool——本质是 Agent Configurator。
新的 FDE：理解岗位 → 定义 Job Spec → 定义 Evals → 让 Coding Agent 实现 → 观察失败案例 → 修改 Spec / Eval / 架构 → 部署 → 持续运营——本质是 Digital Employee Engineer。
我在 Agent 应用工程师——AI 时代增长最快的新岗位 里写过一个真实场景：五个 Java 后端工程师用 Coding Agent 两小时写完一个采购审批 Agent，然后集体沉默——ERP 怎么接、权限怎么配、跑飞了谁兜底，没人知道怎么办。那篇文章的结论是：稀缺的是「把 Agent 从 Demo 变成生产系统」的能力。
Eval-driven 范式把这个能力进一步前置了：真正稀缺的不再是写实现，而是定义岗位和验收标准。 理解业务、定义岗位、定义正确的验收标准——这三样，恰恰是任何 Harness 都替代不了的。
八、四个必须讨论的反方
写到这里，必须停下来泼冷水——这个范式有四个真实的风险，一个都不能回避。
风险一：Harness 的自由度和企业生产安全存在矛盾。 Harness 越自由，Agent 能改的东西越多；而企业越需要权限、审计、回滚、安全边界和确定性。解法不是二选一，而是分层：开发可以自由，生产必须受 Contract 约束。
风险二：Spec + Evals 不能完全描述一个岗位。 企业里有大量隐性知识、组织上下文、人际关系、潜规则，还有「老板真正想要什么」——这些写不进 Spec。所以企业上下文和组织记忆仍然是数字员工的核心基础设施，Runtime 提供的 Knowledge 和 Memory 不是锦上添花，是刚需。
风险三：Eval 可能被优化，而不是被满足。 只优化 Eval 分数，Agent 会学会「通过考试」而不是「做好工作」。所以验收不能只有一层：Task Eval + Safety Eval + 生产反馈 + 人类反馈 + 真实业务结果，五层一起看。
风险四：Harness 可能过度工程化。 给 Agent 太多自由，一个简单岗位可能被实现成一套复杂的 Agent 架构，代码量大、难以维护。所以正确的组合是 Opinionated Runtime + Flexible Harness——运行时要有强烈的意见，开发工具才需要自由。
九、一条架构原则：Harness 自由，Contract 稳定
把八个部分合起来，可以提出一条核心原则：
Harness 可以自由，Employee Contract 必须稳定。
开发阶段，任意 Model、任意 Harness、任意 Agent 架构、任意代码；生产阶段，必须满足统一的 Digital Employee Contract：
DSH / Codex / Claude / OpenCode
│
▼
Agent Implementation
│
▼
Digital Employee Contract
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Identity Permission Eval
↓ ↓ ↓
DWS Event MCP Audit
└──────────────┼──────────────┘
↓
DingTalk Organization
# generated by hugo AI
这条原则的价值在于解耦：数字员工的「怎么造」和「怎么入职」从此互不绑定。Harness 生态可以无限卷，组织的入口只需要稳定。
十、结尾：五个判断
最后，把这篇文章的判断收束成五句：
- Agent Builder 的终局，可能不是更好的 Builder，而是 Spec → Agent Compiler。
- 未来数字员工的开发方式，更接近软件工程，而不是 Prompt Engineering。
- Harness 的价值，是让 Agent 自己完成 Agent 的工程化。
- 钉钉不应该和所有 Agent Harness 竞争，而应该成为所有 Agent 最终进入企业组织的 Runtime。
- 真正的数字员工不是「一个会聊天的 Agent」，而是「一个通过 Spec 和 Evals 验收、拥有企业身份、权限、上下文和执行能力的软件实体」。
用一句话作为整篇文章的主线：
过去，我们教人怎么配置 Agent；下一阶段，我们给 Agent 一个岗位，让 Agent 自己把这个岗位做出来。
而钉钉真正要解决的，是最后一步：
让这个 Agent 不只是「运行起来」，而是真正「入职一家企业」。
你怎么看数字员工的开发范式之争？你在用哪种 Harness？欢迎留言讨论。