上周发完 一切皆插件：DeepSeek Harness 的野心与收敛鸿沟，一位带研发团队的读者给我发消息：「十次修改能不能收敛，你说取决于 eval。那我们让团队多写点测试用例，是不是就能收敛了？」
「多写点测试」是标准答案，也是错误答案。
它错在把 eval 当成一个纯的工程问题——好像数量上去了，收敛自然就来。但真正决定收敛的，不是 eval 有多少，而是 eval 集长什么样。而 eval 集长什么样，取决于一个更不好量化的东西。
品位。
一切皆插件：DeepSeek Harness 真正硬核的是三个细节
Everything Is a Plugin: Three Details That Make DeepSeek Harness Real
前天写 一切皆插件：DeepSeek Harness 的野心与收敛鸿沟 时，我说 DeepSeek 开源的不是工具，是运行时。当时主要看的是官方页面和仓库门面。这两天陆续有人把整个仓库拉下来逐包分析，翻出来的东西比我想的更硬。
其中有一份源码深扒（作者 @Ai 学习的老章，文末有出处）把 200 多个包从启动配置翻到 Agent Loop、事件管线、上下文压缩，再加上我自己读了一遍官方架构文档，发现「一切皆插件」这句话真正站得住，靠的不是插件数量，而是三个很容易被忽略的细节。
这三个细节，恰好是「运行时」和「工具」的分界线。
一切皆插件的时代，唯一不可插件化的是信任
In an Age of Pluggable Everything, Trust Is the One Thing You Can't Plugin
前两天，一个问题把我问住了。
有人问我：DeepSeek 说「一切皆插件」，一切核心都可以替换——模型可换、循环可换、连会话日志都是插件。那么，什么东西是不可替换的？ 是不是只有人和人的协作？再往深一层，是不是「信任」不可替换？
我盯着这个问题想了很久，因为它恰好戳中了我这两天写 一切皆插件：DeepSeek Harness 真正硬核的是三个细节 时一直绕不开的东西。
一切皆插件——注册即副作用，卸载即回滚。整个系统的设计哲学只有一句话：没有什么是不能拿掉的。
但真的什么都可以拿掉吗？
答案是否定的。有一样东西，不管架构怎么解耦、日志怎么追加、插件怎么热插拔，它既不能被替换，也不能被快速恢复。
那就是信任。
AI 重构行业的速度，是可以算出来的
The Speed of AI Disruption Is Computable
上周有两个消息放在一起看，特别有意思。
一条是：AI 客服已经能独立处理大部分标准咨询，有的团队把人工坐席砍了一半以上。另一条是：AI 医生还在辅助写病历的阶段，离独立诊断隔着十万八千里。
同一种技术，同一个十年，为什么差出这么多？很多人的答案是「医疗数据难搞」「监管严」——都对，但都只是现象。现象背后有一个可以算的东西： AI 重构一个行业的速度，是有公式的。 这个公式不仅能解释客服和医疗的差距，还能告诉你自己的行业排在队里的第几个。
一切皆插件：DeepSeek Harness 的野心与收敛鸿沟
Everything Is a Plugin: DeepSeek Harness and the Convergence Gap
昨晚刷到一篇实测文，作者用 DeepSeek Harness 做了一个叫 MacDynamicIsland 的原生 macOS 应用——刘海、菜单栏、悬浮胶囊三个入口，快捷笔记、剪贴板、截图置顶全都有。时间线是这样的：
- 2 小时：从零到大部分功能可运行
- 1 小时：改一个文本框的交互和字体颜色，反复修改，始终没有收敛——修好一处，另一处又坏了
- 30 分钟：把同一份代码交给 Codex，文本框、字体颜色、交互优化基本收敛到可接受状态
作者很克制，特意声明这不是一次公平对比——Codex 接手时已经有了完整的项目基础，问题边界也被前面的试错磨清楚了。我认同这个声明。但这条时间线里藏着一个比「谁更强」重要得多的信号：从 0 到 1 只花了 2 小时，从 1 到 1.1 却花了 1 小时还没做完。
而 DeepSeek 对这件事的态度，就写在它刚开源的 Harness 里。
一场 AI native 的战略会：开完之后，组织比开之前更聪明
A Closed-Loop Strategy Meeting That Makes the Organization Smarter
这周二，我开了一场 AI 钉钉的战略沟通会。
会开完了，按惯例，事情应该到此为止——大家听完、散场、各自回去干活。但这一次我盯着会后那张评估问卷的回收数据，突然意识到一件事：这场会从头到尾，没有一个环节是「用完就扔」的。
HR 在会前一周就用 AI 表格收集了同学们的问题，其中大家最关心的是千问办公和钉钉的关系；我基于这些真实问题，用千问办公读我的个人 wiki，生成了一份沟通会叙述稿，自己调整之后做成 PPT；会后，HR 又用千问办公加 AI 表格技能，基于沟通内容生成了一张调研问卷，回收数据，再用千问办公对整场会的效果做了评估。
一场内部沟通会的完整生命周期——从「同学们关心什么」到「这场会到底有没有效」——全部跑在 AI 工具上，而且每一环的输出都是下一环的输入。
我觉得这很 AI native。但真正让我停下来想的，不是用了多少工具，而是另一个问题： 一场会开完，它留下的东西，到底是资产还是损耗？
从货架到 Agent：平台争夺的不再是人
From Shelves to Agents: Platforms Compete for Intent, Not Users
上周的战略会上，有人问了我一个问题：如果 Agent 真的能替人完成工作，那工作软件公司以后卖什么？
这个问题听着抽象，我换个问法：货架电商时代，平台卖的是货架和流量——商家买排名，用户搜索、比价、下单。那当 Agent 替人买东西的时候，平台卖什么？
电商其实已经在回答这个问题了，因为它正在路上。而我把电商这二十年的演进，和工作软件的演进摆在一起看，发现它们在走同一条曲线。
先说结论： 过去平台争夺的是「人」；AI 时代平台争夺的是「人的意图」和「Agent 的行动」。
数字员工的活人感，不是设计出来的，是长出来的
Liveliness Is Grown, Not Designed
最近有人问我一个问题：我们的数字员工有形象、有声音、有名字，为什么用起来还是像客服？
这个困惑我见过很多次。团队花几个月做数字人形象、克隆音色、写人设 prompt，发布 demo 惊艳全场——结果一周后，员工们还是回去找真人办事，理由出奇一致：感觉在跟客服说话。
这让我想起去年银行业的一份白皮书——工商银行金融科技研究院联合华为、北京金融科技产业联盟发布的《大模型驱动的数字员工 3.0 建设应用》。它用三个要素定义数字员工： 拟人化、自主化、共享化，甚至给出了拟人化的设计规范——姓名、人格特征、语言风格、人物形象，一条一条都写清楚了。但白皮书没有回答一个更棘手的问题：这些设计做完，活人感到底从哪来？
我的答案可能有点反直觉： 活人感不是设计出来的，是长出来的。 拟人化给的是皮肤，而让一个同事显得「活」的，从来不是皮肤。
Agent 为什么在第 30 步翻车
Long-Horizon Agents Fail When They Leave the Light
上周一个做 Agent 集成的工程师来问我：「我的 Agent 前十步表现很好——读文档、列计划、写代码，都很干净。但到第 30 步左右就开始胡来：调错 API，覆盖自己刚改过的文件，甚至重复执行已经做完的操作。我是不是该换个更强的模型？」
我问他：每次都栽在同一个地方吗？他想了想说，不是，但跑得越远越不稳。
我说，那多半不是模型的问题。 它是走出了灯光照亮的地方。
无独有偶，今年 YC Startup School 上，主持人 Diana Hu 向 Jeff Dean 提了几乎一模一样的问题：「Agent 在前 10 步都很棒，到第 50 步就开始晃了。你觉得今天的瓶颈是什么？」Dean 的回答，是我见过对这个现象最准确的解释。
Jeff Dean 把最值钱的东西公开了：Skill 是组织知识的新载体
From Documents People Read to Skills Agents Execute
YC Startup School 的舞台上，主持人 Diana Hu 问 Jeff Dean 一个问题。在此之前，Dean 刚讲了他和搭档 Sanjay 写的一个性能优化 Skill——教模型自己做「跑 benchmark → 改代码 → 测提升 → 再迭代」的闭环。Diana 听完说：「如果谁拿到这个 Skill，就能像 Jeff Dean 一样做性能优化了。这东西肯定价值无限。有人能拿到它吗？」
Jeff Dean 的回答出乎所有人意料：「哦，我们其实把它公开了。」
他说的是他和 Sanjay 合写的一份 30 页文档，叫 《Performance Hints》。后面还有一个细节：有人把这份文档做了摘要，喂给不同的模型，发现模型在性能问题上的推理能力真的变强了。
全世界都想要的东西，他直接公开了。这一幕值得多看两眼——因为它指向一个被严重低估的变化： 组织里最值钱的知识，载体正在从「写给人读的文档」悄悄换成「写给 Agent 执行的 Skill」。
