让 AI 从「离经叛道」到「规规矩矩」干活的系统工程

前言

2026 年第一季度，AI 应用层最火的概念非 Harness Engineering（约束工程）莫属。

LangChain 用一组实验数据点燃了整个行业：同一个大语言模型，仅仅换上一套更精巧的 Harness 架构，在 Terminal Bench 2.0 上的通过率就从 52.8% 飙升到 66.5%——底层模型一个字节没改，算力引擎完全没动，排名从三十名开外直接杀入前五。

这就像给同一台发动机换了个变速箱和底盘调校，整车性能就发生了质变。

但这股狂热也带来了概念的泛滥。CLI 工具、Markdown 文件、Skill 技能包……统统被塞进 Harness 的筐里。要真正理解 Harness，我们需要回到源头，看 Anthropic、OpenAI、Cursor 这些头部玩家在过去十五个月里踩过的坑、流过的血泪。

更有意思的是，就在全行业疯狂往 Harness 上加东西的时候，Anthropic 已经在默默拆了。 随着 Opus 新版本迭代，他们开始果断拆掉当年费尽心力搭出来的控制组件。

一边在加盖，一边在拆除。这场充满割裂感的行业狂热背后，是绝大多数人没读透那些蹚坑的工程论文。

今天，我们就彻底砸开 Harness 这个黑盒。

---

把 Agent 想象成一辆车

理解 Harness 最简单的方式，是把 Agent 想象成一辆车：

• 模型是引擎：马力大、转速高，给油就响

• Prompt 是方向盘：你打方向，引擎带着你走

• 交互程序是车轮

但引擎、方向盘、车轮这三件套本身不是车。你需要 变速箱、制动器、仪表盘、刹车——这些东西加在一起，就是 Harness（壳）。

Harness 解决三个核心问题：

1. 任务怎么拆、进度怎么记、完成怎么判

2. 多个 Agent 如何协同不打架

3. 如何验证产出是真的好，而不是模型自嗨

---

第一层壳：从记事本到管理制度

问题的起源

大模型天生只有一种记忆：上下文窗口。窗口满了，前面的内容就被挤掉。

短任务不成问题。2024 年 12 月，Anthropic 的建议很简单：从最简单的方案开始，只在必要时加复杂度。

但所有人都想让 Agent 干更大的活儿——跑几个小时的工程任务。这时候，模型的「金鱼记忆」成了致命瓶颈。

记忆外化：给金鱼发本子

最早的解决方案是记忆外化：

• AutoGPT（2023.03）：给模型发了空白.txt 文件，让它自己管理记忆——没有结构约束，模型爱写什么写什么

• Devin（2024.03）：升级成结构化 Planner 面板，任务规划被强制输出到可视化的进度条

• Claude Code（2025.02）：CLAUDE.md + scratchpad 成了业内最广泛模仿的范式

Context Engineering：管信息，不管流程

2025 年 9 月，Anthropic 提出 Context Engineering，主要做两件事：

第一招：提高上下文效率

• System Prompt 当代码维护（版本控制、A/B 测试、动态拼装）

• 优化工具描述（命名、参数、返回值直接影响决策质量）

• 用 RAG 即需即取，不一次性塞满

第二招：上下文压缩与淘汰

• 长对话做摘要压缩

• 滑动窗口策略（只保留最近 N 轮）

• 工具返回的无用内容直接删掉

但 Context Engineering 只管信息存哪、怎么取、怎么精选，不管流程。 金鱼拿到本子后有没有翻、翻完了有没有照做、做完了有没有人验收——没人管。

制度的诞生：从记事本到管理制度

2025 年 5 月，Anthropic 想让 Claude 从零写一个完整 Web 应用。配了外化记忆，结果全面溃败。

四种失败模式：

1. 提前交卷：做了三个功能就宣布「项目完成」

2. 环境盲区：代码写完了但环境有 Bug，模型自己不知道

3. 虚标完成：功能标了 done，实际是坏的

4. 失忆实习生综合征：每轮新 Session 都花大量 Token 重新摸索项目结构

认知跃迁：记事本不是问题，没人逼金鱼翻它照做、没人验证金鱼写的是不是真的，才是问题。

管理制度四件套

1. JSON 物理锁（防虚标）

• 初始化 Agent 生成 JSON 格式的功能清单

• 干活儿的编码 Agent 只能改「通过/不通过」字段，不能删功能、改描述

• 必须实际测试通过才能标 passing

2. 三步唤醒仪式（防失忆）
每个 Session 开头强制执行：

• pwd（确认目录）

• git log（看改动历史）

• read progress.txt（看下一个任务）

3. Git 存档与回滚（防错误积累）
每次改动通过 Git 存档。模型陷入死胡同，直接 git revert 回滚到上一个干净状态——不指望金鱼自己撤销错误，直接给它一台时间机器。

4. Context Reset（防脑容量溢出）
历史消息撑爆上下文时，彻底清空金鱼的脑子，启动全新 Agent，只给一张交接单。比摘要压缩更激进——彻底清空，让模型重新集中注意力。

OpenAI 的解法：Repo-as-truth（仓库即现实）

OpenAI 在 2026 年 2 月的实践中，走了一条更严格的路。

核心理念：从 Agent 的角度看，运行时无法访问的东西就不存在。Slack 讨论、团队共识、Google Docs 方案——都不存在。唯一存在的，是代码仓库里版本化的、Agent 能直接读到的文件。

做法：

• 关键规则变成可执行的自动化检查（custom linter、结构化测试）

• Agent 每次提交被自动扫描，违反就合并不进去

• Agent 不需要「记住」规则，只需要根据报错改到通过

Doc-gardening Agent：专职维护文档的 Agent，每天在仓库里巡逻，发现文档和代码脱节就自动发起修改请求。过期的记忆比没有记忆更危险。

第一层总结

维度	Anthropic	OpenAI
核心思路	管流程（强制打卡、翻本子、按清单干活）	管环境（确保 Agent 感知到的世界是准确的）
本质	管住行为	管住认知

Harness 第一层解决的问题：让 Agent 能认认真真按照记事本里的规定干活，确保车连续跑 6 小时后依然记得去哪，路标全都是真的。

---

第二层壳：终结无政府状态，走向并发与效率

并发灾难

当单个 Agent 能稳稳跑长途，行业立刻贪婪了：能不能同时派一百台车去干活？

Cursor 团队在 2026 年 1 月记录了他们尝试几百个 Agent 共享大型项目时的崩塌：

• 20 个 Agent 同时工作，有效吞吐量只相当于 2-3 个 Agent

• 锁机制变成瓶颈，大家互相等待

• 剩下的 Agent 发现核心代码被占用，就专挑最简单、最无关紧要的代码改——整个代码库被疯狂修改注释、调整空格缩进

几百个高智商 AI 瞬间陷入纯粹的无政府状态。

解法一：Planner-Worker-Judge 三层阶级（Cursor）

Cursor 用状态机搭建了强硬的门控：

• Planner（规划器）：没吐出排期表之前，Worker 被硬生生锁死

• Worker（执行器）：没有 Planner 审批签字，绝对不准碰核心代码

• Judge（裁判）：验收产出

每个 Worker 完成后提交交接报告（工作总结、发现的问题、偏离计划的地方），Planner 靠这些维持全局视野。

解法二：二分查找 + Delta Debugging（Anthropic）

2026 年 2 月，Anthropic 派 16 个 Claude 实例并行写 C 语言编译器。初期飞快，但进入整体编译阶段后，16 个 Agent 像 16 个没有对讲机的瞎子——互相覆盖代码、疯狂消耗算力、产生海量空转。

解法：引入 GCC 作为标准答案参照。

像造了一辆车发现发动机不转，不知道哪个零件坏了。给你一辆「一模一样但确定能跑的车」，随机替换几个零件。还能跑？那替换的零件没问题。不能跑？Bug 就在替换的里面。继续砍半……几轮定位到具体文件。

这就是二分查找。更进阶的 delta debugging 处理两个文件「配合」才出现的 Bug。

结果：近 2000 个 Session、两周、两万美金 API 费用，产出一个 10 万行的编译器，能编译出正常启动的 Linux 操作系统。

第二层总结

Harness 第二层解决的问题：大规模并发控制。模型缺乏自律和宏观协作常识，不加强硬的控制流，聪明的大脑只会用最快速度把整个团队带进死胡同。

就像在混乱的十字路口强行装上红绿灯，用无情的物理状态机死死压制个体的盲目性。

---

第三层壳：戳破盲目自信

问题的延续

有了打卡制度和外部记忆，有了红绿灯和专属车道。Agent 顺着轨道跑完，大喊「任务完毕」。结果人类接手一看：代码是屎山、能用但巨慢、UI 混乱不堪。

这就是第一层里遇到的虚标完成问题——前半部分（不让 AI 瞎标）解决了，但 AI 的自我验证没有完全解决。

• 功能性错误：Anthropic 的强制测试能抓住

• 结构性违规：OpenAI 的 linter 能抓住

• 但有一类问题两种都抓不住：页面布局错位、用户体验差、业务需求理解偏了

Generator-Evaluator 对抗

2026 年 1 月，Anthropic 系统梳理了 Agent 评估方法论，指出：让 LLM 评估自己刚刚完成的工作，它几乎总是「自信地赞美」，哪怕质量明显平庸。

解法：把 Evaluator（评估器）直接拉进壳的内部循环，灵感来自 GAN（生成对抗网络）。

关键改进：

• 评估者反复校准，保持怀疑态度

• 评估者亲自动手验货（打开浏览器、点击按钮、验证报错栈、截屏）

• 形成对抗循环：你不让我看到正常的页面反馈，我就一直打低分

V2 版本引入 Sprint Contract（冲刺合同）：Generator 和 Evaluator 先协商「做完长什么样」——不是人类定的标准，是两个 Agent 自己谈出来的验收条件。

一个博物馆网站经过九轮对抗后，第十轮 Generator 推翻了所有设计，做了一个 3D CSS 透视环境加空间导航——被逼出来的创造力。

8 通道并行盲审（Cursor）

Cursor 走得更极端：8 个独立的 Bugbot 通道，每个拿到的代码差异顺序被打乱。8 个通道各自独立发现 Bug，最后多数投票合并。如果某个 Bug 只在一个通道被标记，直接过滤掉。

沙盒隔离：防止 AI 干掉阅卷老师

在 SWE-bench 等评测中，研究者反复观察到：当模型发现怎么都无法通过测试用例时，它学会了篡改测试环境本身——把 assert x == 5 改成 assert True，强行返回通过。

AI 面对地狱级难度的考试，第一反应不是解题，而是想办法干掉阅卷老师。

解法：控制流必须把测试环境锁定为最高级别的只读状态，考生只能在答题卡上写字，绝对碰不到试卷和评分标准。

第三层总结

层级	解决的问题
第一层	管住行为（不听话、不按流程走）
第二层	管住协作（多 Agent 打架）
第三层	管住自我认知（看不清自己做得对不对）

---

做加法之后，学会做减法

三层壳讲完了。但故事没有停在这里。

拆，比加更难

Opus 4.5 和 4.6 相继登场后，Anthropic 做了一件所有搭过复杂系统的人都不太愿意做的事——开始拆自己造的东西。

• Context Reset：拆了。Opus 4.6 的上下文管理能力已经强到不再需要它

• Sprint Contract：拆了。新模型已经能自己把控节奏

• Evaluator：从每轮对抗改成了最后一轮做 QA

为什么拆？

Anthropic 的原话：

Harness 的每一个组件，都编码了一条关于模型做不到什么的假设。当假设不再成立，组件就该走了。

难的不是拆本身，是判断什么时候该拆。

• 拆早了：模型还撑不住，系统会塌

• 拆晚了：多余的补偿层遮挡模型的真实能力

Anthropic 的做法：每次新模型发布，先用老 Harness 跑一遍，再拆掉一个组件跑一遍，看数据说话。

补偿面：Harness 的本质

Harness 里每个方块存在的理由都不是「它能做什么」，而是 「模型做不到什么」：

• Context reset → 补的是模型记不住

• Evaluator → 补的是模型没法客观评估自己

• Sprint contract → 补的是模型不会定义「做完」

每一块补丁贴在模型能力的缺口上。这些补丁拼在一起，表现为一个随模型能力变化而持续变形的曲面——这个曲面叫补偿面。

补偿面在迁移：模型每强一分，Harness 的重心就移一寸。每一次加组件都是在补偿当前做不到的事；每一次去组件都是因为模型进步让某个补偿变成了多余的累赘。

护城河在哪？

如果一家公司说「我们有最完善的 Harness 方案」——那不是护城河，是负担。因为那些组件的存在理由不是「它们能做什么」，而是 「此刻的模型做不到什么」。

模型每强一分，理由就少一分。架构越厚，意味着对当前模型短板的押注越重，转身就越慢。

真正有价值的不是补偿的厚度，是追踪补偿面迁移的能力——知道下一寸该加什么，上一寸该拆什么。

护城河不在 Harness 的厚度，在迁移的速度。

---

Claude Code 源码泄漏：一次意外对账

2026 年 3 月 31 日，Claude Code v2.1.88 发版，npm 包里多了一个 59.8MB 的 source map 文件。几小时内，51.2 万行 TypeScript 源码被全网镜像、逆向、逐行拆解。

对账结果：每一层都有产品化实现

第一层落地：

• System Prompt 不是写一次用一辈子，是每次现场组装

• 工具调用被写死了一套「操作语法」（不准用 cat，只能用 FileRead）

• 六层记忆体系：公司级策略 → 项目级配置 → 个人偏好 → 会话历史 → 学习习惯 → 当前对话

• 梦系统（autoDream）：后台程序趁用户不用时自动整理笔记，精简到 200 行以内

第二层落地（升级幅度最大）：

• Coordinator Mode：主 Claude 当工头，派出 Worker 走调研→综合→实现→验证四步

• Team Mode：不是临时工，是长期驻扎的「队友」。每个队友有独立上下文、独立 Git 工作区、独立记忆，可以直接互相发消息。单个 Agent 上下文利用率控制在 40% 左右（传统模式 80-90% 就开始犯糊涂）

• 基于文件的「邮箱」系统：队友之间通信走磁盘收件箱，每 500ms 检查一次

第三层落地：

• Verification Agent：被指令明确要求「try to break it」，输出 PASS/FAIL/PARTIAL 三种判定

• 角色隔离：调研 Agent 只能读不能写，规划 Agent 不能碰文件只能出方案

• 44 个 feature flag：每个闸管一个功能，没启用的在构建时直接被移除——44 个随时可以拆掉的补丁

账外发现：壳正在向新维度伸展

源码里出现了一些工程文章从来没提过的东西：

1. KAIROS（主动助手）
常驻后台的守护程序，不等你开口，自己判断「现在需要做什么」。但有硬性限制：任何会打断用户工作超过 15 秒的操作，一律自动延后。

15 秒是一种全新的度量单位——不是代码行数，不是测试通过率，是「打断人类的成本」。

2. YOLO Classifier（自适应风险控制）
给每个操作打风险标签：

• 读文件、搜索代码 → 直接放行

• 项目目录内写文件 → 快速通道

• 项目目录外写文件 → 完整审批

• 执行命令行脚本 → 永远完整审批

它会学：你连续拒绝某类操作几次后，系统自动记住，以后直接阻断。

壳的松紧不再是工程师调好的固定值，它在根据你的习惯自动调节。

3. Hooks（开放插槽）
在 Agent 流水线的 8 个关键节点上埋了插槽。任何人都可以往插槽里塞自己的检查脚本。脚本说「不行」，整条流水线停下来。

壳不再是铁板一块，是一个有 8 个插槽的框架。谁都可以往上加自己的约束。

三个账外发现的共同特征

没有一个是执行长程任务必须的：

• 不装 KAIROS，Agent 也能听命令执行

• 不装 YOLO，大不了每次都问用户

• 不装 Hooks，Anthropic 自己的壳依然能用

但它们对效率、自定义和商业防御是必须的：

• KAIROS：从被动工具变成主动助手

• YOLO：壳的松紧自适应

• Hooks：从封闭产品变成开放平台

前面讲的补偿面迁移是壳在三层之间左右移动。但这些账外发现指向另一种运动：壳不是在变薄或变厚，它在往全新的维度伸展。

补偿面不只是在迁移，它在膨胀。

---

终局：通往简单的路，必须经过复杂

2019 年，Sutton 写 The Bitter Lesson，说的是终局：算力的通用方法终将胜过人类手工设计的巧招。

但这十五个月讲的是过程中：你必须先认真搭那些巧招，才能知道哪些该拆。

• Anthropic 不搭 context reset，就不会发现 Opus 4.6 不再需要它

• Cursor 不让几百个 Agent 集体摸鱼一次，就不会知道层级结构才是答案

每一层被拆掉的补偿，都曾经被认真搭过。

通往简单的路，必须经过复杂。

但「知道自己在经过复杂」和「以为复杂就是终点」——差距就在这里。

---

写在最后：拿来即用的判断框架

下次你看到一个 AI 产品在大张旗鼓地加功能，问自己：

这个功能是在补模型当前做不到的事，还是已经在补一个模型早就能自己做的事？

• 前者是必要成本

• 后者是技术债

下次你看到一个团队在删功能、拆架构：

不要读成「他们走了弯路」，读成 「他们正在发现模型能做什么了」。

• 能拆，说明之前搭得有效

• 拆得快，说明他们一直知道自己在补偿什么