早上 8 点整，没有人给「涌现」发消息，它已经起床干活了。
涌现是我的钉钉数字员工。每天早上 8 点整，任务消息准时到达，日程表上排着五项早读：读公众号后台、读 GA、digest 小红书、更新 token 消耗、扫一遍 aibase，预算一小时。中午 12:05，下一班任务照样准点到——它安静干完活，报告发进群，日志里一行 ok=True，一条兜底都没有。（这是我在 谁停掉了数字员工的早读？ 里给它验完尸之后的日常。）
没有人 @ 它，没有人提问。它是被自己的日程叫醒的。
这个细节值得停一下：聊天机器人被消息召唤，员工被日程叫醒。而被日程叫醒只是起点——一个真正意义上的员工，还得记得昨天答应过什么，知道十点该跟进谁，干完活主动来汇报。这些都不是「回答得更聪明」的问题，是架构问题。
而这两年，全行业的力气都花在把 Agent Loop 做得更大、更聪明上。我的判断是：数字员工缺的不是一个更大的 Loop，是另一个 Loop。
上个月我连写两篇拆解 DeepSeek Harness（dsh）：一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 说它开源的不是工具，是运行时；一切皆插件：真正硬核的是三个细节 拆了注册即副作用、事件日志做脊柱、乱序完成按序写回这三个工程承诺。当时我的结论是「可以吹，但不必急着用」——预览版、破坏性变更写在官方文档里，日常编码不如用成熟的 Coding Agent。
几周后打脸了：我们把一支真实的钉钉数字员工团队装在了它上面。项目叫 DWH（DingTalk Workforce Harness），四个员工——通用助手 default、管理员 dev、HR 助手 hr、老板秘书 assistant——各自是一个独立的 dsh 进程，在钉钉里各管一摊、各有权限、互相平级。这篇讲为什么「不必急着用」的判断没错，但「怎么用」的答案错了：开源 Agent 运行时的正确用法，不是把它当产品直接用，而是把它当操作系统，在上面建一层「员工管理制度」。
前天写 一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 时，我说 DeepSeek 开源的不是工具，是运行时。当时主要看的是官方页面和仓库门面。这两天陆续有人把整个仓库拉下来逐包分析，翻出来的东西比我想的更硬。
其中有一份源码深扒（作者 @Ai 学习的老章，文末有出处）把 200 多个包从启动配置翻到 Agent Loop、事件管线、上下文压缩，再加上我自己读了一遍官方架构文档，发现「一切皆插件」这句话真正站得住，靠的不是插件数量，而是三个很容易被忽略的细节。
这三个细节，恰好是「运行时」和「工具」的分界线。
上个月我们团队换了一次 agent loop。从 Claude Code 切到 OpenCode。
切换本身很轻——prompt 改改，工作流调调，两天上手。切完第三天，周一早上打开 dashboard，CI 全绿。我松了口气，泡了杯咖啡，随手点开一条 PR 的 review 记录。
空的。
再点开一条。还是空的。咖啡没喝完就放下了。
不是代码质量出了问题。是 pipeline 里有一条规则：检测注释里的 // Generated by Claude Code 标记，命中就触发额外的 AI 代码 review 流程。OpenCode 不打这个标记。于是这条规则永远不触发，review 流程形同虚设。CI 是绿的，但绿得没有意义。
一条规则，把整个团队锁死在一个工具上。不是我们选择了 Claude Code，是基础设施绑架了我们。
我在 代码是 AI 写的了，品味住在哪里 里说，品味从代码搬到了工程系统——CI pipeline、release 节奏、事故响应。但那篇文章用的词是「harness」，而且只讨论了 harness 和 agent loop 的关系。
三个月后我意识到，那个框架已经不够用了。
2026 年的前沿 Agent 系统，不再是「一个模型 + 一个循环」的结构。它是 Foundation Model、Agent Policy、Runtime 三层的协同设计。品味不住在任何一层里，它住在三层之间的契约里。
上个月面试一个候选人，简历很漂亮，做过三年 LLM 应用开发。我问他：「你觉得你做的东西，本质上是在交付什么？」
他说：「交付模型能力。把 LLM 的能力封装成 API，让业务方能用。」
我又问：「如果业务方说，我要一个能自主完成端到端任务的系统，不只是回答问题——你交付的东西能做到吗？」
他愣了一下：「那得加很多工程，不只是调 API。」
我说：对，这就是我今天想聊的——当交付物从「模型能力」变成「自主系统」时，你的工程标准该是什么样。
[Read More]