上周一个做 Agent 集成的工程师来问我：「我的 Agent 前十步表现很好——读文档、列计划、写代码，都很干净。但到第 30 步左右就开始胡来：调错 API，覆盖自己刚改过的文件，甚至重复执行已经做完的操作。我是不是该换个更强的模型？」
我问他：每次都栽在同一个地方吗？他想了想说，不是，但跑得越远越不稳。
我说，那多半不是模型的问题。 它是走出了灯光照亮的地方。
无独有偶，今年 YC Startup School 上，主持人 Diana Hu 向 Jeff Dean 提了几乎一模一样的问题：「Agent 在前 10 步都很棒，到第 50 步就开始晃了。你觉得今天的瓶颈是什么？」Dean 的回答，是我见过对这个现象最准确的解释。
YC Startup School 的舞台上，主持人 Diana Hu 问 Jeff Dean 一个问题。在此之前，Dean 刚讲了他和搭档 Sanjay 写的一个性能优化 Skill——教模型自己做「跑 benchmark → 改代码 → 测提升 → 再迭代」的闭环。Diana 听完说：「如果谁拿到这个 Skill，就能像 Jeff Dean 一样做性能优化了。这东西肯定价值无限。有人能拿到它吗？」
Jeff Dean 的回答出乎所有人意料：「哦，我们其实把它公开了。」
他说的是他和 Sanjay 合写的一份 30 页文档，叫 《Performance Hints》。后面还有一个细节：有人把这份文档做了摘要，喂给不同的模型，发现模型在性能问题上的推理能力真的变强了。
全世界都想要的东西，他直接公开了。这一幕值得多看两眼——因为它指向一个被严重低估的变化： 组织里最值钱的知识，载体正在从「写给人读的文档」悄悄换成「写给 Agent 执行的 Skill」。
最近一个月，有三个人问过我同一个问题：「我们公司想做 AI，从哪开始？」
三个人的背景很不一样：一个做制造，一个做跨境电商，一个做连锁餐饮。但他们的第一反应惊人地一致：先看看现在的模型能干什么，再从公司里找个场景套上去。
Jeff Dean 给的答案正好相反。今年 YC Startup School 上，他给了一个我认为值得每个企业贴在墙上的选题标准：
去找模型成功率是 0% 或 1% 的问题，不是 20%。
这就是 1% 法则。在 AI 的竞争变了：未来是上下文的竞争 里我讲过这个判断的战略含义；这篇往前一步——把它变成一套你在自己公司就能执行的盘点方法。
上个月，Anthropic 的 Claude Code 设计负责人 Meaghan 发现了一件怪事。
她 Slack 设计评审频道里常驻的那个 Tag——一个以团队成员身份住在群里的 AI 同事——在长期参与设计评审之后，慢慢学会了她的提问角度：这个设计是为谁做的？想传达什么？跟我们的设计系统对得上吗？
再后来，Tag 不再等她下指令。它会直接在同事的设计草稿上迭代出一个更好的版本，有时还会主动找到相关同事，替她发起讨论：「嘿，Meaghan 之前是这么想的，这里有个原型你可以点点看，感受一下她的思路。」
这个故事出自最近一篇关于 Claude Tag 的深度研究（作者 Celia）。我读到的时候，第一反应不是「AI 好强」，而是一阵轻微的寒意： 这个 AI 已经悄悄学会了一个人的品味，并开始代表她在组织里行事。
多数人对 Claude Tag 的理解还停留在「Slack 里装了个聊天机器人」——@它，它回复。它今年 6 月以 beta 形式上线，8 月初 Anthropic 干脆把 Slack 里的 Claude 应用改名为 Claude Tag。从外面看，像是一个顺手发布的小功能。
但 Meaghan 的故事里真正发生的事情是： 组织认知，第一次变得像代码一样可以 fork、可以 merge。
上周内部交流会，有位同学站起来提了一个问题。
问题原文是这样的：
如果希望公司更像一家 AI-native 公司，各位 Leader 最希望大家立刻停止的一种/几种传统工作方式是什么，以及希望大家开始的一种/几种工作方式是什么？
主持人让我先答。
我第一反应是给一份工具清单：停止手写代码，开始用 Agent；停止人肉搜信息，开始问 AI。这种答案安全、正确，而且没用。
于是我在回答之前，先问了自己一个问题： AI 工具早就全员配齐了，为什么我依然觉得组织不够 AI-native？
答案不在工具上，而在一些我们习以为常、甚至毫无察觉的工作方式上——它们运行得太自然，以至于我们误以为它们就是工作本身。
7 月下旬发生了两件事。表面上毫无关系，放在一起看，指向了同一个地方。
7 月 25 日，YC Startup School 旧金山现场，Jeff Dean 站在 6000 名创始人面前。主持人问：普通创业团队凭什么跟大厂竞争？这位 MapReduce、TensorFlow、TPU、Gemini 背后的首席科学家，给出的答案是 上下文工程（context engineering）——「你只需要一个 API」。他还说了一句我认为值得裱起来的话： 训练数据是几万亿 token 搅成一锅汤，糊进几千亿参数里；而上下文，是模型此刻直接看见的东西，清晰得多。
五天后的 7 月 30 日，字节跳动下发内部邮件，完成近年来力度最大的一次 ToB 架构调整：飞书产品团队并入豆包产品体系，商业化团队与火山引擎合并为新的 GTM 组织「创造力服务平台」。飞书这家「产品+商业化」一体的完整公司，被拆件重组，分别挂到字节的两条主线上——模型，和云。
一个是行业顶端科学家的判断，一个是最务实的 ToB 玩家的组织动作。同一周，指向同一件事：
AI 的竞争已经换场了。大家争夺的不再是模型，而是上下文。
上周和一群刚工作的年轻人交流。有人问我一个问题：我每天都在用 AI，prompt 也调得不错，效率确实提高了——但为什么总觉得，我还是在「自己干活」？
我反问他：你的 AI，会不会越用越好？
他愣了一下：好像不会。每次新开一个对话，都像第一次认识一个新同事。
问题就在这里。他很会用 AI，但他从来没有管理过 AI。
这两件事的差距，比他以为的大得多。
李开复在他的新书《AI 未来已来》里讲了一件微软旧事。
2000 年他升任微软全球副总裁，后来才知道，在他毫不知情的时候，总部一年一度的人才盘点已经把他摆上了桌面——比尔·盖茨和鲍尔默认为他最适合出任一个新事业部的副总裁。他第一次意识到：在这家公司，顶尖人才的去向不是哪个部门领导的家务事，而是最高层亲自过问的大事。
更让他震撼的是制度本身：微软每年把最顶尖的 1% 员工挑出来，不论资历，只看潜力。首席人力资源官告诉他，鲍尔默睡前的功课之一，就是几十份几十份地翻看这些人的资料，确保他们的奖励到位、能感受到最高层的关注。鲍尔默对副总裁们说过一句狠话：
排在前 1% 的人，不属于你们，属于我。我要知道他们都是谁——公司有需求时，我有权随时调动他们。
这是 30 年前的管理智慧：顶尖人才，必须由一号位亲自盯。
但注意它的实现方式——靠鲍尔默的意志力，靠 HR 一年一次的名单。一年一次，几十个人。这已经是人力注意力的极限。而一家几千人的公司里，真正的顶尖人才远不止名单上那几十个人。
李开复写道：2025 年，他在零一万物把这件事重新做了一遍。这一次，用的是「老板 AI」。
我名下有两个数字员工：一个负责开发、测试、部署，另一个在用户群里服务真实的同事。它们不是工具，是组织里两个正式的岗位。岗位一立起来，一个问题就自然跟着来了：
「如果它批错了一张审批单，造成了损失，谁来负责？」
这个问题不难答——难的是我发现，市面上绝大多数 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 最近一年最值得关注的技术方向。
