昨天给一家客户交付一个 HR 数字员工，交付物出乎对方意料：不是安装包，不是镜像，是一个配置文件。
对方技术负责人盯着屏幕看了半天，问了一句：「就这？」
就这。准确说，是一份 cordis.patch.yml——声明启用哪些插件、禁用哪些、端口开在哪、模型配哪个。客户自己改了一份，重启，一个财务数字员工就起来了。代码一行没动。
这让我确信一件事：上一篇讲的「Harness 自由，Contract 稳定」有了它的工程落地——DSH（DeepSeek Harness）的 profile 机制。而这背后是一套更像操作系统哲学的架构选择：微内核。
今年早些时候，我写过这样一个案例：一家电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价，部分商品以成本价以下售出，一天亏了 80 万。复盘会上——
运营说：是 AI 自动调的。技术说：是数据源有异常。数据团队说：数据是实时抓取的，跟我们无关。
没有一个人为这 80 万负责。（案例详见企业级 AI 必须设计成出错后可以追责到人）
那篇文章讲的是工程层面怎么追责：授权链、策略签名、审计日志。但写完之后，有一个更根本的问题一直挂着我：
为什么必须追到「人」？为什么不能追到 Agent 本身？
这个问题听起来像文字游戏，其实不是。它决定了你的数字员工部署从哪里画下第一根线——第一根线画错了，后面每一根都是错的。
前段时间我把这个问题的推导写成了一份内部文档。这篇文章是它的公开版：不做功能罗列，不列合规清单，从第一性原理出发，推导数字员工要成为组织成员必须满足什么条件。
让一个 Browser Agent 订一张机票。打开网站、登录、输入出发地和目的地、筛选时间、选航班、提取价格——听起来就六个动作。
但你真的去看第一代 Browser Agent 跑这个流程，会发现它的大部分时间根本没花在这六个动作上。它在登录——它新起的那个浏览器没有任何登录态；它在等待——等页面加载、等元素出现；它在定位 DOM——CSS 选择器又变了；它在重试——某一步失败，推倒重来。真正的业务逻辑，占比很小（这是我观察执行 trace 的估算，不同任务差异很大）。
问题不在模型不够聪明，在架构：浏览器是一次性工具，这些成本就永远摊不掉。
最近有人丢给我一个新产品 ego Lite 的资料，问值不值得试。我的第一反应和大多数人一样：又一个 Browser Agent？但把它的架构看完，我意识到这个理解是错的——它真正动的不是 Prompt，不是模型，而是浏览器在 Agent 系统里的角色。
过去 Browser 是 Tool。现在 Browser 开始变成 Runtime。
这是我认为 Browser Agent 最近一年最值得关注的技术方向。
上周整理数字员工的术语，有人在讨论里问了一个问题：
「数字员工背后的 Agent，具体实现上是一套什么东西？」
这个问题问得好。市面上大多数回答是这样的：一个模型加一段 Prompt，接一个知识库，套一个对话框。听起来也没错——demo 确实就是这么做出来的。
但 demo 和员工是两回事。我们做会议纪要数字员工的时候，第一版正是「模型 + Prompt + 转写」，能跑，但没人敢用：纪要里全是「小王跟进一下」，没人知道是哪个小王；待办派错了人，也没有任何机制能发现。
后来它变成一个真正能干活的数字员工，靠的不是换更强的模型——模型一直没换。靠的是在模型外面，一层一层搭起来的东西。
[Read More]上个月一个团队找我聊数字员工落地。
他们已经有 12 个 agent 在跑了。销售助手、客服助手、HR 问答、会议纪要……每个都是独立项目，独立部署，独立维护。
CTO 说：「我们想扩到 200 个。」
我问：「现在 12 个的权限怎么管的？」
他愣了一下：「每个 agent 一个 API key，配在环境变量里。」
「记忆呢？A 部门的 agent 会不会读到 B 部门的会议纪要？」
「……应该不会吧。」
「两个 agent 对同一件事判断冲突了，谁说了算？」
沉默。
12 个靠人盯，200 个靠什么？
而且这 12 个跑在半年前的模型上。模型半年一换代，agent 策略周级迭代——你还没把 12 个理顺，底座已经换了。这不是「多部署几个」的问题。这是架构问题。
前两天看到一篇文章，标题很刺激：「飞书被收编，钉钉要改名，企业微信慌不慌？」
核心论证链很锋利：互联网办公平台第一次降维打击了传统企业软件，然后 AI Agent 第二次降维打击了超级 App。结论是 To B 软件只剩两种位置——要么成为入口，要么成为入口背后绕不开的系统。
写得很好。但我读完之后一直在想一个问题： 他说的「绕不开的系统」，对钉钉来说到底意味着什么？
不是「钉钉也能活下来」这种防御性思考。而是：如果钉钉主动选择，它应该把资源押在哪里？
上周帮一个朋友调他的 AI Agent。需求很简单：自动登录一个美国政府网站，填三张表，提交。
他选了 VNC 路线——Agent 通过远程桌面连上一台真实 Mac，操作真实的 Chrome 浏览器。逻辑很对：真实浏览器没有 navigator.webdriver 标记，没有 CDP 连接痕迹，TLS 指纹是真的，Canvas 指纹是真的。从浏览器的视角看，就是一个正常用户坐在键盘前。
他很有信心。然后 Agent 在第二步就被拦住了。
不是被防火墙拦的，不是被反爬拦的。是 Cloudflare Turnstile 弹了一个无感验证，Agent 的鼠标 瞬移 到了按钮上， 零毫秒 完成点击。没有移动轨迹，没有加速度变化，没有人类手指的微颤。
一个人类不可能这样操作。而 Cloudflare 知道。
上个月一个团队来找我，说他们要做企业内部的 AI Agent，需要操作浏览器。
第一个问题就是：「用 Playwright 还是 Browser Use？」
我说这个问题本身就问错了。就像你问「盖楼用钢筋还是混凝土」——答案是都用，但用在不同的层。
Browser Automation 在 AI Agent 语境下，已经不是一道单选题。它是一张技术地图，九个梯队，各有适用场景。而真正在生产环境里跑通的企业 Agent，几乎都是 分层架构——API 优先，结构化浏览器控制居中，Vision 兜底。
昨晚十一点半，我盯着自己那个钉钉数字员工项目里的一段代码发呆。
那是 core 模块里的轮询逻辑——每隔 3 秒去 serve 端拉一次会话状态，判断任务是否完成、是否超时、是否需要 abort。旁边是 session 管理：维护一个内存里的 Map，记录每个会话的生命周期、重试计数、上下文快照。再往下是 abort 清理：当用户取消任务时，要优雅地终止正在执行的工具调用、回收资源、把中间状态写回。
加起来大概 200 行。写得挺漂亮，有状态机、有超时退避、有异常兜底。我三个月前写它的时候，serve 端还没有原生的会话生命周期管理，没有 SSE 事件流推送，没有内置的 abort 语义。这 200 行是当时唯一的选择。
但昨晚我突然意识到： 这些代码的保质期，可能只剩一年。
不是因为它们写错了，而是因为它们正在被模型和运行时从两端同时吞噬。
[Read More]上个月，一个 CEO 朋友给我看他的 AI Executive Assistant。
这个 Assistant 每天帮他看邮件、总结会议、安排董事会、订机票、写讲话稿。用了大半年，CEO 说：「它比我的真人秘书更懂我。」
然后他问了一个问题：「我想让它也帮其他高管安排行程、协调董事会会议、统一管理行政资源。行不行？」
我说：行。但你要意识到， 你正在把它从一个分身变成一个员工。
他笑了：「不就是多服务几个人吗？能力是一样的。」
我说：能力是一样的。但 身份、权限、审计、责任归属，全部要重来。你现在的 EA 出了错，你骂它一顿就行。总裁办的 EA 出了错，谁负责？你？行政总监？还是那个 Agent 自己？
他笑不出来了。
