我名下有两个数字员工：一个负责开发、测试、部署，另一个在用户群里服务真实的同事。它们不是工具，是组织里两个正式的岗位。岗位一立起来，一个问题就自然跟着来了：
「如果它批错了一张审批单，造成了损失，谁来负责？」
这个问题不难答——难的是我发现，市面上绝大多数 AI 产品，从来没准备回答这个问题，因为它们压根不是「员工」。
Chatbot、数字分身、数字员工，这三个词正在被混着用。很多人以为它们只是同一类产品的不同营销话术：能力弱一点的叫 Chatbot，能力强的叫数字员工。
但我的判断是： 它们是三代不同的东西。 区分代际的不是模型有多聪明，而是两个更根本的问题：
它的 Source of Truth 是什么？它出了错，谁来负责？
想清楚这两个问题，很多关于企业 AI 的争论会立刻变得清晰。
[Read More]让一个 Browser Agent 订一张机票。打开网站、登录、输入出发地和目的地、筛选时间、选航班、提取价格——听起来就六个动作。
但你真的去看第一代 Browser Agent 跑这个流程，会发现它的大部分时间根本没花在这六个动作上。它在登录——它新起的那个浏览器没有任何登录态；它在等待——等页面加载、等元素出现；它在定位 DOM——CSS 选择器又变了；它在重试——某一步失败，推倒重来。真正的业务逻辑，占比很小（这是我观察执行 trace 的估算，不同任务差异很大）。
问题不在模型不够聪明，在架构：浏览器是一次性工具，这些成本就永远摊不掉。
最近有人丢给我一个新产品 ego Lite 的资料，问值不值得试。我的第一反应和大多数人一样：又一个 Browser Agent？但把它的架构看完，我意识到这个理解是错的——它真正动的不是 Prompt，不是模型，而是浏览器在 Agent 系统里的角色。
过去 Browser 是 Tool。现在 Browser 开始变成 Runtime。
这是我认为 Browser Agent 最近一年最值得关注的技术方向。
上周有人请我整理一套数字员工的术语，用途是整理会议纪要。
整理的时候我意识到一件事：会议纪要看起来是最容易交给 AI 的岗位。语音识别模型足够强，转写免费，人人会用。按常理，它应该是数字员工最先上岗的岗位。
但我们真动手做的时候，发现不是这样。
第一版会议纪要机器人，把会议里的每一句话都转写出来了。问题是，没人看得懂：
「关于上次说的那件事，就按讨论的办。」——哪件事？怎么讨论的？
「这个意见我同意。」——谁的意见？
「后续小王跟进一下。」——哪个小王？
而且，转写本身也不总是干净的。真正容易出错的，不是通用技术术语，而是企业自己的语言——项目代号、产品名、客户简称、组织缩写、内部黑话。比如「北极星二期」「天穹计划」「A17 客户」「P0 升级」「DWS」「飞鹰版本」，通用模型根本不知道这些词代表什么，转写很容易出现同音字或拆词错误。
看起来是两个问题：术语转不准；就算转准了，也没人看得懂。
其实是同一个问题：缺上下文。术语转不准，是因为模型的词典里没有你公司的词；看不懂，是因为纪要里没有这些人是谁、属于哪个项目、上次讨论了什么决定、谁负责什么事。
这次经历让我们得到一个后来反复验证的判断： 数字员工不是任何岗位都能做，只有「上下文充分」的岗位才能做好。
判断一个岗位是否适合数字员工，只需要看五件事。
上周整理数字员工的术语，有人在讨论里问了一个问题：
「数字员工背后的 Agent，具体实现上是一套什么东西？」
这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。
但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。
后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。
[Read More]上周我让一个 Coding Agent 给一个 Web 应用实现登录功能。三轮迭代之后，它汇报：「完成了，所有测试通过。」
我打开浏览器一看：登录按钮不见了。
我把截图丢回去，它看了一眼，回复：「抱歉，上一轮我把按钮组件误删了。」
有意思的不是 Agent 会犯错——犯错很正常。有意思的是： 它直到看见那张截图，才知道自己犯了错。 那三轮迭代里，它有编译反馈，有测试报告，但它没有任何办法知道最终页面长什么样。它的「世界」是残缺的。
这件事让我更确认了一个琢磨了很久的判断：
[Read More]对于 Coding Agent，最重要的基础设施不是更聪明的模型，不是 Benchmark，而是端到端（E2E）Test Harness。
上周我刚发布《数字员工是下一个十年的故事》。今天读到一篇 36 氪 首发：清华背景的团队奇点逃逸完成千万级种子轮融资，做 AI 原生团队协作操作系统 Nexus。
读完之后我的第一反应不是「又一个竞品」，而是：
这个命题，正在从一个人的判断，变成一个被资本定价的方向。
这不是巧合。当一个论点独立地从不同起点被推导出来——我做企业协作基础设施，他们做多智能体研究——它大概率触到了某个真实的结构。
[Read More]我的钉钉组织里有两名不领工资的「员工」。一个负责开发、测试、部署另一个；另一个在用户群里服务真实的同事。两个的主管都是我。
经常有人问我：这两个东西到底是什么？Agent？机器人？助手？
我的答案是： 它们是岗位。
这个回答背后，藏着一个我琢磨了很久的判断：
Agent 能解决能力问题，而数字员工解决组织问题。AI 真正进入企业，不是因为模型更聪明，而是因为它第一次拥有了组织身份。
模型能力的竞赛已经足够激烈，也足够拥挤。但企业 AI 真正的瓶颈从来不在能力——而在 信任。能力决定一个 AI 会不会干活，身份决定它能不能上岗。下一个十年的故事，不是造出更聪明的 Agent，而是让 AI 以「岗位」的形式，真正进入组织。
[Read More]上个月，我们团队一位产品经理花了两周写了一份 40 页的 PRD，描述一个智能审批 Agent 的需求。用户故事、流程图、异常分支、验收标准，写得滴水不漏。
她把 PRD 丢给 Coding Agent，说：「按这个做。」
三天后 Agent 交付了。代码能跑，测试通过，接口对齐。但她试了五分钟就皱眉：「这不是我要的东西。」
哪里不对？她说不清。审批流程是对的，权限校验是对的，消息通知是对的。但 Agent 处理「领导已读不回超过 48 小时」的策略，不是她脑子里想的那个。PRD 里写的是「超时后自动提醒」，Agent 就老老实实给所有超时审批发了一轮提醒——包括那些「领导出差没看手机」的非紧急件。她真正想要的是「先判断这条审批是否紧急，紧急的才提醒，不紧急的等下次汇总」。
这个判断，她没写进 PRD。因为她觉得这是「常识」。
Agent 没有常识。Agent 只有你给它的判据。
太平洋汽车的内容被豆包、千问和 DeepSeek 引用之后，合计触达了 1237 万用户。
这个数字是太平洋汽车 App 自有流量的 113.8 倍。
一百一十三倍。超过一百倍的用户通过 AI 平台「消费」了太平洋汽车的内容——他们在豆包的聊天窗口里问了一个关于买车的问题，豆包引用太平洋汽车的评测给出了答案，用户满意地关掉了对话。
然后呢？ 太平洋汽车什么都没得到。 没有访问，没有注册，没有广告展示，没有用户画像。内容被吃干抹净，连渣都没剩。
这个故事来自极客公园上周的一篇报道，讲的是 AI 时代互联网流量的大崩塌。但让我想了很久的不是流量问题——而是一个更底层的问题：
如果内容本身不是最有价值的资产，那什么才是？
上个月和一位做 HR SaaS 的朋友吃饭。他刚花了两百万买了一批行业测评数据，准备训练自己的垂直模型。
我问他：「竞品如果也买同样的数据呢？」
他愣了一下：「那……我们还有先发优势。」
「先发多少？」
「大概……半年？」
半年。这就是原始数据作为护城河的保质期。
三个月前，我写了一篇 中国 SaaS 厂商的护城河应该怎么建，核心公式是：
护城河 = 垂直行业数据资产 × 行业 Know-How × 客户成功体系 × 生态协同
那篇文章里，我把「数据壁垒」放在七大维度的第一位，画了一个数据飞轮：客户使用 → 数据沉淀 → 模型训练 → 更精准的服务 → 更多客户使用。
三个月后，我要修正自己。
飞轮里转的不是数据，是 eval。
