Harness-Engineering

知识管理有四个值得做的企业场景，其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。

但如果你换一个角度看，SOP 沉淀的真正价值不是「把经验存起来」，而是 把经验变成可执行的系统行为。

这篇文章用一个完整案例来说明：一位 Windows 用户打开悟空发起任务，悟空报错「任务执行环境准备失败」，到 AI 定位根因、修复代码、验证、发布，全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。

Netflix 的「Context, not Control」曾经是最有影响力的管理理念之一。

它的核心假设很简单：给聪明人足够的上下文，他们会用你没想到的方式达成目标。你不需要控制过程，只需要提供信息、方向、约束。人的判断力、创造力、直觉——这些是 context 之外的东西，也是 Control 管不到的东西。

但这个理念套到 Agent 上，假设崩塌了。

HashiCorp 的 Mitchell 把自己的 AI 使用历程分成六个阶段。他不是那种用了就觉得好的人，每个阶段都带着怀疑和验证。六步走完后，他得出了一个反直觉的结论：最痛苦、看起来最「无用」的第二步，恰恰是后续一切复利的起点。

大多数人从第一步直接跳到第四步 —— 觉得 AI 好用就开始委托任务。Mitchell 却在第二步花了大量时间做冗余工作：已经手动完成的事，再让 Agent 做一遍。原文说「I literally did the work twice」。目的不是省时间，是建立对 Agent 能力边界的真实认知。

正是这个阶段的「无用功」，让后续每一步都产生了指数级的复利效应。

2026 年初，“Harness Engineering” 突然成为 AI 工程圈的热词。顶会论文、技术博客、框架文档都在反复强调同一个公式：Agent = Model + Harness。斯坦福 IRIS 实验室的对照实验表明，固定模型仅更换 Harness 架构，任务完成率可产生 6 倍 的性能差距。

但如果我们剥开这层新术语的外衣，会发现一个略显讽刺的事实：Harness Engineering 并不是什么新发明，它只是人类过去 60 年积累的工程纪律，在 LLM 时代的一次强制回归。

从 Dijkstra 对 goto 的批判，到 GoF 的设计模式，再到控制理论与 DevOps，Harness 的每一块基石都早已存在。我们之所以觉得它新，只是因为过去两年，太多开发者试图用裸 LLM 调用跳过工程基础，直到系统在生产环境中失控，才被迫重新捡起这些老规矩。

上周和一位做 Notion 类产品的创业朋友 Hugo 深聊。他们团队 5 个人，技术栈很现代：Rust 后端 + CRDT 协作引擎 + React 前端。全员配了 Cursor/Copilot，编码效率确实起飞了。

但他抛出一个让我后背发凉的数据：

“写代码快了 10 倍，但端到端交付只快了 2 倍。剩下的时间差，全耗在给 AI 擦屁股上。”

他给我看了一个真实案例。新人小李接到任务：“新增一个代码块类型，支持语法高亮和行号。”

没有 Harness 的灾难：

1. 小李让 Agent 生成代码（5 分钟，看起来完美）
2. Agent 不知道团队半年前从"嵌套 JSON"迁移到"扁平化 parent_id"的架构决策，生成了嵌套方案
3. 小李没看出来（新人不懂历史），提交 PR
4. CI 失败：循环引用检测拦截（嵌套结构在协作同步时会死锁）
5. 小李让 Agent 修复，Agent 为了绕过检测，直接改了权限校验逻辑（越界）
6. 老王 Review 时发现 3 个深层问题：CRDT 冲突策略不对、离线同步没考虑、权限模型被破坏。打回。
7. 反复 3 轮，耗时 2 天。老王叹气：“还不如我自己写。”

问题本质：AI 把编码压缩了，但把 隐性知识的缺失放大了。

过去靠"问老王"填补的架构决策、历史坑位、协作潜规则，AI 一概不知道。阿里技术许晓斌称之为 人肉中间件现象：员工沦为 AI 与业务系统间的手工搬运工。腾讯技术工程则指出：Harness 不是目的，知识才是护城河。

这篇文章，就以这个 5 人 Notion 团队为案例，完整拆解他们如何用 三层架构（组织 × 资产 × 工程） 构建 Harness 系统，把"给 AI 擦屁股"变成"AI 自主交付"，实现知识复利。