前几天我把手上的三份材料丢给 AI，让它整理成一篇观点汇编：一段产业对话（提问者沈X，回答者是我自己）、一场企业 AI 落地的闭门沙龙、朱啸虎在北大的演讲（Ethan 整理）。
三份材料来自三个完全不同的场合，AI 干得很利索——分门别类、提炼要点、做成对照表，最后在末尾给了我一行加粗的字：
收敛成一句话：模型能力会迅速扩散、趋同、变便宜，所以技术领先只是阶段性优势。真正的长期壁垒，都从「功能/模型」转向独占的数据、跑通的流程、沉淀的资产和用户入口。
我盯着这句看了很久，然后把它删了。
不是因为它错。它对得无可指摘。是因为 它把三份材料里唯一值钱的东西给抹掉了——那三个人说同一句话的时候，各自在指三份不同的数据，各自要把资产放进三个不同的口袋。
[Read More]9 月初，我的数字员工「涌现」在一周里掉了三次链子。
它每天早上八点跑一轮「早读」：读公众号后台、读 GA、digest 小红书、更新 token 消耗、读 aibase——五步，预算一小时。8 月 31 日、9 月 2 日、9 月 5 日，三次吃了同一个兜底。前两次重启了事，第三次我让 opencode 做了一轮十五分钟的验尸：模型网关的机器名，被 /etc/hosts 里一行陈年映射和 DNS 搜索域联手坑了——解析结果里混进一条不通的 IPv6 路由，我常用的工具个个有回退所以毫无察觉，Agent 的运行时没有回退，当场死亡。整个排查过程我写成了 谁停掉了数字员工的早读。
事后回想，我当时的感受不是恼火，更接近于交学费的踏实。这个「早读」场景，技术上毫无炫技之处——定时任务、抓取、摘要、发消息，任何一个传统后端工程师一天就能搭完。但正是这个普通的场景，在过去几个月里每天给我生产真实的执行、真实的失败、真实的修复。我对 Agent 工程的大部分真实认知，不是从论文和 demo 里来的，是从这条 loop 里长出来的。
这让我越来越确信一个判断：Agent 应用工程师的核心竞争力，不是会不会调 Prompt、接 MCP、做 RAG，而是能不能建立一个真实的、持续运行的 Agent Loop。 而在选择做什么项目时，我会把一个指标放在非常靠前的位置：这个场景每天能给我多少次真实的执行反馈。
上个月我连写两篇拆解 DeepSeek Harness（dsh）：一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 说它开源的不是工具，是运行时；一切皆插件：真正硬核的是三个细节 拆了注册即副作用、事件日志做脊柱、乱序完成按序写回这三个工程承诺。当时我的结论是「可以吹，但不必急着用」——预览版、破坏性变更写在官方文档里，日常编码不如用成熟的 Coding Agent。
几周后打脸了：我们把一支真实的钉钉数字员工团队装在了它上面。项目叫 DWH（DingTalk Workforce Harness），四个员工——通用助手 default、管理员 dev、HR 助手 hr、老板秘书 assistant——各自是一个独立的 dsh 进程，在钉钉里各管一摊、各有权限、互相平级。这篇讲为什么「不必急着用」的判断没错，但「怎么用」的答案错了：开源 Agent 运行时的正确用法，不是把它当产品直接用，而是把它当操作系统，在上面建一层「员工管理制度」。
今年 4 月 17 日，Anthropic 上线了 Claude Design，直接对着 Figma 和 Canva 打。这件事在产品层面不算新闻——又一个 AI 生成界面的工具。真正值得注意的是它绕过的是什么：它让一部分设计工作不再需要打开 Figma。
OpenRouter CEO Alex Atallah 在那场访谈里的判断比我狠：他把 Claude Design 看作一种战略动作，「它未必立刻带来巨额收入，却能让设计团队在组织内部更关心 Anthropic 模型」。同时他也诚实地补了一句——从 Figma 公开的经营数字看，它表现依然很好。
两句话放一起，才是完整的事实：被绕过的那部分工作，还没大到能动财报。但方向已经定了——软件的用户界面，正在从「给人操作」变成「给 Agent 调用」，而当人不再打开界面，按人头卖软件的那本账，就开始算不动了。
这篇文章想说的是：数字员工和「给 SaaS 加个 AI 助手」的差别，不在功能强弱，在交付结构和定价单位。而定价单位真要换过去，缺的不是技术，是一个签字的人。
月底，一个用了大半年 AI 的老板跟我抱怨：他知道这个月公司在 AI 上花了多少钱，云账单上写着。但他答不上来另一个问题——这笔钱是哪个团队、哪个流程、哪个数字员工花掉的。
「账单是一整笔，」他说，「就像食堂一个月的米面油采购单，你知道总数，但说不出哪道菜亏本。」
这不是个例。绝大多数企业的 AI 支出，今天都停在「一笔云账单」的粒度上。而我在 OpenRouter CEO Alex Atallah 最近的一场访谈里，看到他给出了一个完全不同的判断——他说这是「很反常、却很少有人讨论」的现象：
「过去员工的成本主要是固定薪酬……未来，员工成本会是动态数字，与每个人是否有效地使用昂贵或廉价模型有关。管理者仍要正常评估员工的效率和产出，但也可以把效率和 AI 使用成本放在一起看。」
换句话说：AI 的成本，正在从「一笔 IT 预算」变成「一份人力成本」。 未来每个员工——尤其是每个数字员工——都会带着两份成本单：一份是薪酬，一份是 token。
TikTok 的 SRE Salman Munaf 最近有一场演讲，开场问题问得很漂亮：
你的 AI Agent 调用退款接口，网络超时了。那退款到底成功没有？
他的答案是：超时从来不意味着失败，而意味着「未知」。Agent 遇到失败的第一反应是重试，没有请求 ID、幂等键和状态查询，这个本能就会把一笔退款退成两笔。整场演讲的论点一句话概括：模型一旦开始调用外部服务，问题就从模型问题变成了分布式系统问题——几十年前命名过的故障模式全部回归，SRE 工具箱必须整体搬进 Agent 架构。
我同意。但我想在他的问题后面再问一句：
就算退款成功了——那笔退款，退得对吗？
这两个问题之间的距离，就是这篇文章要讲的东西。
我的钉钉数字员工每个月偶尔会抽下风：「⚠️ 暂时无法处理你的消息，请稍后再试。」，往往重启一下就好了。今天我让 opencode + GLM-5.3 排查了下这个问题。
十五分钟后，它把案子破了。凶手很狡猾：藏在三份完美证词背后，还顺走了我的 /etc/hosts 当人质。
xAI 的 Grok Bot 发布页上，留着一条来自运营岗用户 Emma 的感言（译）：
「刚开始的时候，我每 15 分钟就要去查看一次 Bot，事无巨细地盯着它——直到它反过来问我，为什么我总是问这么多问题。现在我放手让它自己干，它反而越用越好。」
这可能是「数字员工」这个产品形态目前拿到的最好背书：不是一个等你提问的工具，而是一个你可以把工作交出去、然后转身去干别的事的队友。
但同一页往下翻，还有一行写给企业用户的小字：加入 waitlist。
喊得最响的「可以把真实工作交给它」，到了企业门口，只换来一句排队等候。这个反差值得认真对待：Grok Bot 上线 24 天，验证了什么？它又到底卡在哪？
先说结论： Grok Bot 验证了「持续角色」这个产品形态，但企业要的是「岗位」。从角色到岗位，差的最后一段不是模型能力，而是组织基础设施。 而这一段，恰恰是企业现在就应该开始在钉钉里上岗数字员工的原因。
半年前，我给自己上了第一批数字员工。上岗之前，我的想象是这样的：任务交给 Agent，我只管派活和收结果，我在钉钉上的时间应该大幅下降。
半年后，我打开自己的屏幕时间统计：我在钉钉上的时间没有下降——翻了一倍。
起初我以为是个体差异。但和几位同样在带数字员工的同事交流后，发现大家的处境差不多：Agent 越多，人在 IM 里花的时间越多。
这让我必须把一个判断写下来：
AI 不会造出新入口，只会加深你对旧入口的依赖。
最近读到一篇两万字的 Agent 自进化方法论，写得相当扎实。其中记了一条血泪教训：有团队在某个场景上连续 20 多轮自动迭代，效果一直不提升——最后发现根因根本不在配置层，而在工具层。20 多轮里，系统忠实地修 Prompt、改 Skill，每一轮都按评测信号在优化。
回头看，最惊人的不是根因藏得深，而是这 20 多轮里，没有一个人问过：这批评测 case 本身，选对了吗？
没人问，因为没人需要问——这份评测集没有主人。
这篇方法论（作者 yannisyang、ethanytzhou）把评测、记忆、落地、控制四个环节拆成飞轮：评测是眼睛，记忆是大脑，落地是手脚，人机协作是方向盘。四个齿怎么建、坑在哪、从零到一怎么落地，都讲了。它最有价值的一句话是：
大多数团队的问题恰恰在于：每个组件内部做得还行，但组件之间的「箭头」没有自动化。
飞轮的瓶颈不在齿，在齿与齿之间的通路。我完全同意——但沿着这句话再往下推一步，会发现一个这篇两万字没有回答的问题：
所有箭头里最上游的那一条——「什么叫好」——它的定义权在谁手里？
