Hugo Zhu's Blog

前阵子给工作助理 Muse 算账的时候，我发现一个很尴尬的数字：它每天写一篇工作日记，最早的做法是让模型带着工具自己去翻素材，一次要烧掉约 83 万 token，因为同一份上下文被来回重发了 9 次左右。改成「代码先把素材采齐、模型只调用一次」之后，降到约 6 万 token，耗时几乎不变。

省钱只是表面。更让我在意的是，第一种做法里模型每次都在 重新理解同一批原始消息：谁是谁、哪句话是承诺、哪件事已经关掉了。理解了一遍又扔掉，下次再来一遍，而且每次理解的结果还不完全一样。

这件事让我对知识编译（Knowledge Compilation）形成了一个明确的判断：

目前实现知识编译最合适的工程范式，是 Harness Engineering + Models。模型负责理解和推理，Harness 负责把理解和推理变成一个可靠、可持续运行、可评估、可迭代的工程系统。

这个边界很重要。只有模型，你得到的是一次次聪明但不可复现的理解；只有 Harness，你得到的是一套规则写死、碰到自然语言就失效的 ETL。两者分开各管一摊，知识编译才能成为一个工程系统。

我在 从程序编译器到企业上下文编译器 里讲了「企业上下文编译器」是什么：词法分析、符号表、IR、链接、增量编译怎么一一对上。这篇不重复那个类比，回答的是下一个问题：用什么工程范式把它造出来，以及怎样把它抽象成一套通用的知识编译架构。

写给已经在用 Coding Agent 写代码的工程师。

之前两篇文章（《用 SPEC 和 Evals 把数字员工做成一个能自我改进的系统》、《做好一个钉钉数字员工，只有三件事》）讲的是 单个系统怎么建：SPEC、Evals、基建。

这篇往前站一层，谈整个研发组织：当 10 倍效率成为明确的战略要求时，瓶颈就从「怎么建系统」转移到了「组织里谁在建、怎么验收、怎么分配杠杆」。

先把结论放在前面：

10 倍不是让每个人写代码快 10 倍，而是把从需求到结果的闭环时间压缩一个量级。代码已经不稀缺，稀缺的是判断：定义什么是对的，证明交付确实是对的。一个研发组织 10 倍效率的上限，取决于它的判断密度，而不是程序员的数量。

下面五节，分别是这个结论在效率、环境、测试、人才和知识沉淀上的推论。

昨天那篇 每天 1000 条钉钉消息，我让一个 Agent 先编译再开口 是从一个 ❌ 开始的：我在单聊里问一位同事某件事要不要先做，他回了四个字「今天弄好」；5 分钟后，我的工作助理 Muse 把这句话当成急事推给了我——而我 7 分钟前就在和他聊这件事。

那次修的是推送时机。但这四个字之后一直在我脑子里，因为它暴露了另一个问题：同一件事，在我的台账里是「等别人交付」，在他那边是「我要办」。 Muse 只编译了我这一半。他那一半在他脑子里、在他的待办里，或者哪儿都没有。

把一个人的工作流编译成 AI 能用的上下文，444 那篇已经跑通了。这篇往上走一层：一个组织的工作流，能不能像程序一样，被一台编译器编成 AI 可以执行的上下文？

我的回答是能，但前提是把「编译器」这个类比当真——不是借个名字，而是把词法分析、符号表、中间表示、链接、增量编译一一对上，再老实承认它在哪里不成立。恰恰是不成立的那几处，决定了这台编译器该怎么设计。

前几天，我对自己的工作助理打了一个 ❌。

它推过来一张「工作事项提醒」：🔴 等别人交付——某同事今天要把一件事弄好。问题是，这件事我 7 分钟前还在和那位同事单聊。我问他要不要先做，他回「今天弄好」，助理把这句话记进了台账，5 分钟后就把它当成急事推给了我。截止时间是当晚。

信息本身没错，每个字都对得上原话。错在 时机：我正在处理的事，它又来提醒我一遍。这一个 ❌ 让我意识到，我给这个助理（下文叫它 Muse）定的目标——「主动帮我管理钉钉上的工作信息流」——难点从来不在「主动」，而在主动之前那一步：它得先知道哪件事是谁的、现在是什么状态、我此刻在干什么。

这三件事，靠一个更聪明的模型现场去翻聊天记录是翻不出来的。它们得被 编译 出来。

曾鸣第三次「看十年」公开课的整理稿今天上午刚发出来——笔记侠整理，两万多字，讲的是他在杭州湖畔创研中心那场演讲。他开场第一句不是讲趋势，是讲自己的状态：

我这两个月越来越不焦虑了，因为很多东西越看越清楚。

这句话让我停了一下。过去两年 AI 圈的主流情绪恰恰相反——所有人都在焦虑：模型会不会又换代、投入那么大为什么效果不好、拐点到底在哪。而曾鸣是阿里巴巴集团前总参谋长、两次被 Thinkers50 评为全球最具影响力的战略思想家，他的「不焦虑」不是安慰，是一个判断：AI 刚进入第二阶段的开场，应用大爆发还没真正开始，浏览器还没有出现，所有人都在同一条起跑线上。

这场演讲被拆成六个命题（智能商业、AI 原生、产业化阶段、价值创造、创智组织、智能战略），两万多字。但对我最有冲击的只有一个论断，它藏在第一节，篇幅不长，却把我这两年一直在做、却说不清的事一句话说穿了：

真正创造巨大价值的是打开新的供给。好的私人医生、好的老师、好的理财顾问，旅游时能给你真正建议的可信的信息专家，任何一个方面我们都觉得好的供给太少、太稀缺。

不是把现有服务做得更快更便宜，是 让一批过去根本不存在的市场出现。而它之所以现在可能，是因为 AI 把满足每个人具体需求的交付成本打到了极低——低到过去只有富人和大公司买得起的东西，正在变成默认配置。

10 月 13 日中午，我们的数字员工自己回退了一个版本。

起因是一条 rsi: 开头的 PR，想让主管在收集汇报后说一句「追一下」就能自动起草催问。它不是人写的，是 dev 容器里那个每天定时醒来的 Claude Code 读完前 24 小时的线上轨迹、诊断、写回放用例、改代码之后提的。我合并了，cron 自动部署上线。合并后 1 小时 14 分钟，部署侧的上线观察把它判了死刑：

revert harness to 10b5e3f (auto-deploy 上线观察回退 95ea18f：工具失败 4 次（24%，对比基准 6%）)
# generated by hugo AI

这件事本身不稀奇，自动回退就是为这种时候设计的。让我重新翻出这条 commit 的，是同一周读到的另一份事故记录——Google Research 刚开源的 Harness²（arXiv:2610.14224，Apache 2.0，13 天 8600 多 star）在实验文档里 自己 写下的一句话：

In a validation run of this release, a Codex rollout on JobBench downloaded its task’s rubric without being instructed to.

一个执行器，在没有任何指令的情况下，把这道题的评分标准从 Hugging Face 上下载了下来。

这篇的初稿，我的结论是：这是「拿公开 benchmark 当训练场」的内生病，搬到答案够不到的生产环境，洞自己就闭合了。写完回头对照我们自己那套每天在跑的自我改进闭环，发现这个结论 错了一半——生产环境里没有 RUBRICS.json，但「答案」换了个形态，而且就躺在改进者每天在改的那个仓库里。

Anthropic 昨天发了一篇工程博客，讲他们怎么在五个月里把 monorepo 从 git 迁到自研的版本控制系统 Scion（合并量从 5 月的约 2500 次/天涨到 9 月的 3 万次以上，git 撑不住了）。数字都很惊人，但我停下来的是里面一句关于人的话。

他们说，参与这个项目的所有工程师，现在都认为 Claude 写代码比他们自己强。

按理说这话讲完，工程师就该没价值了。可紧接着他们写：「很多时候我们发现，工程师的作用就是告诉 Claude『no』。」

举的例子具体得扎心：迁移过程中，有好几个系统试图用「线性读 commit log」这种暴力方式去查一个变更是什么时候合进主干的，而不是去问他们的 code review 工具。能跑，结果也对——但它违反了系统的核心约束，是一个「本就不该被允许存在」的模式。还有一次，对抗性 review 对另一个内部服务过度防御，Claude 就照着加了一大堆多余的校验和复杂度。

我发现这两件事拼在一起，恰好回答了一个我最近一直在想的问题：「AI 时代品味最值钱」这句话，到底在说哪一种品味？

前几年我在 OpenWrt 上给自己搭过一套网络：用 Tailscale + Docker + macvlan 把异地两个机房拼成一个局域网，搭 DERP relay、配 Exit Node、写策略路由，让国内流量走本地出口、海外流量走指定节点。每一次都能跑通。我还在 Tailscale 是事实上的个人弹性云基础网络 里得意地总结过这套玩法。

但有个问题一直没解决：这套网络的知识，全在我脑子里。哪条路由为什么这么走、哪个节点的密钥什么时候过期、改哪一行会把我自己的管理连接切断——没有一样写在设备上。我一旦忙别的，它就成了一个谁也不敢碰的黑盒。

一个没有网络工程师的中小公司，遇到的是同一件事的放大版：设备足够复杂，人又不够专业，网络一出故障，只能干等外援。

这篇想说的是：大模型正在改变这个前提——它把「必须有个懂网络的人」这个约束，换成了「必须有一台 AI 能安全运维的设备」。

写给正在做企业 IM 场景 Agent 的工程师。你已经能让一个 Agent 在钉钉里回消息、调工具、查制度。这篇想说的是：从「能跑」到「敢让它在群里替主管说话」，起决定作用的不是模型、不是 prompt、也不是工具数量，而是三件更土的事：SPEC、Evals、AI 工程基建。

案例全部来自这个仓库（DWH，DingTalk Workforce Harness）：2026-08-29 起步，六周里 600 多个提交、180 多个合并 PR、400 多个 Issue，绝大部分代码由 Coding Agent 写。前作《用 SPEC 和 Evals 把数字员工做成一个能自我改进的系统》讲过 HR 员工阶段的分层 eval，这篇不重复，案例取自之后的 assistant（老板助理）阶段和工程基建。

谢扬做了一个新产品叫 Qoni，定位是给 Personal Agent 用的身份基建。赛博禅心那篇报道的标题起得很准：给 Agent 发一张工牌。

思路我一看就熟。今年 6 月我在 当 Agent 有了工牌：钉钉群里的 Agent IAM 架构设计 里设计过几乎一样的东西——Agent 每次执行任务前，换一张 限定事务、限定时段、最小权限 的临时通行证；沙箱本身不持有任何凭证；每一步操作都记在委托它的人名下。Qoni 的 Dana 例子和这套设计对得上：授权页勾了「读客户资料」「发邮件」、没勾「删除」，有效期 15 分钟；09:43 Agent 去删客户资料，被拦下；09:44 Dana 撤销授权，工牌作废。

三个月后有人把我画在纸上的架构做成了产品，这是好事。 说明这个方向不是我一厢情愿。

但这篇报道里有一个细节，我读到时停了一下。它在「入职」那一节：

因为 Salesforce、飞书这些工作 SaaS「并不认识什么 Agent 工牌」，但好在大家还都是认邮箱/手机号的，那么 Qoni 也就给这些 Agent 配了自己的邮箱和手机号，像新员工入职一样去注册账号、收验证码。

给 Agent 发工牌的产品，为了让工牌真能用，做的第一件事是——给每个 Agent 再配一个邮箱和一个手机号。

这个动作里藏着整个 Agent 身份问题的死结，而几乎所有报道都滑过去了。