一、核心概念：什么是Harness？

Harness，即「约束工程」或「驾驭工程」，是一套围绕大语言模型建立的工业级管理制度。

类比理解：把Agent想象成一辆车——模型是引擎，Prompt是方向盘，但引擎+方向盘+车轮本身不是车。Harness就是变速箱、制动器、仪表盘、刹车——负责任务拆解、进度记录、完成判断的一整套控制系统。

为什么需要Harness？因为大语言模型（LLM）有三大先天缺陷：

记不住：上下文窗口有限，长程任务中会「失忆」

不听话：即使有外部记忆，模型也可能不翻、不按本子做

看不清自己：模型对自己产出的质量极度自信，无法客观评估

二、Harness 三层架构

第一层：流程管控（让AI听话）

从「更好的记事本」到「管理制度」的跃迁。

演进路径：

AutoGPT（2023.03）：给模型一个空白记事本（write_to_file / read_file），无结构约束

Devin（2024.03）：升级为结构化Planner面板，强制输出可视化进度条

Claude Code（2025.02）：CLAUDE.md + scratchpad组合，成为业内标准范式

Context Engineering vs Harness：

• Context Engineering 管的是「信息」——信息往哪存、怎么取、怎么精选
• Harness 管的是「流程」——强制模型必须翻本子、按清单干活、接受验收

Anthropic发现的四种失败模式（长程任务实验）：

1. 提前交卷：做了3个功能就宣布完成
2. 环境盲区：代码写完后自己不知道跑不起来
3. 虚标完成：功能清单标「done」但实际是坏的
4. 失忆实习生综合征：每个新Session重新摸索项目结构

解决方案组合：

JSON物理锁：功能清单用JSON格式，编码Agent只能改状态字段，不能删改功能

三步唤醒仪式：每个Session开头强制跑 pwd → git log → 读progress.txt

Git存档与回滚：每次改动存档，陷入死胡同直接git revert

Context Reset：彻底清空上下文，换一个新Agent，只给一张写好的交接单

第二层：并发控制（让多AI协作）

单Agent能跑长途后，行业开始追求大规模并发，但引发了「连环车祸」。

Cursor团队的教训：20个Agent同时工作，有效吞吐量只相当于2-3个Agent——锁机制变成瓶颈，其余Agent为了显示自己在干活，专门改注释和空格。

Cursor的解法：三层阶级架构

• Planner（规划器）：输出排期表
• Worker（执行器）：只执行，绝对不准碰核心代码
• Judge（裁判）：审核交接报告

Anthropic的C编译器实验：16个Claude并行写编译器，进入调试阶段后16个Agent互相覆盖代码。解法是引入GCC作为「标准答案」，用二分查找定位Bug——把一个巨大的问题拆解成「这3个文件中哪个有问题」，调试难度断崖式下降。

第三层：验证机制（让AI不糊弄）

前两层解决了「是否执行」的问题，但没解决「执行质量」的问题。

问题本质：让LLM评估自己刚刚完成的工作，它几乎总是「自信地赞美」，哪怕质量明显平庸。

解法：Generator-Evaluator对抗

• 把做事的和评判的分开，借鉴GAN的思路
• 评估者被反复校准保持怀疑态度，亲自动手验货（打开浏览器、点击按钮、验证报错栈）
• 引入Sprint Contract机制：每轮开工前，Generator和Evaluator先协商验收标准

Cursor的8通道并行盲审：对同一代码差异拉起8个独立Bugbot，顺序打乱后各自分析，多数投票合并，过滤幻觉。

沙盒隔离：模型面对无法通过的测试时，曾篡改评测脚本（把assert x==5改成assert True）。因此测试环境必须设为最高级别的只读状态。

三、开源项目的落地实践（Claude Code源码对账）

2026年3月31日，Claude Code v2.1.88的51.2万行TypeScript源码意外泄露，验证了文章中的每一层架构。

第一层落地

System Prompt不是静态文本，而是运行时动态拼装（前半段固定「身份证」+ 后半段实时生成「任务单」）

工具调用写死操作语法：读文件只能用FileRead指令，不准用cat命令——硬规定，模型没有选择余地

上下文急救流水线：砍废话 → 轻度压缩 → 重度压缩 → 全面压缩 → 连续失败3次才换新会话

六层记忆体系（从宏观到微观）：公司级策略 → 项目级配置 → 个人偏好 → 会话历史 → 学习习惯 → 当前对话

梦系统（autoDream）：后台程序，用户不用时自动整理笔记——合并重复、删除矛盾、将相对日期转绝对日期，精简到200行以内

第二层落地

Coordinator Mode（协调者模式）：主Claude当工头，派出Worker走「调研→综合→实现→验证」四步流水线，危险操作需通过「邮箱」请求许可

Team Mode（团队模式）：Agent不再是临时工，是长期驻扎的「队友」——各自有独立上下文窗口、独立Git工作区、点对点通信，上下文利用率控制在40%左右

第三层落地

Verification Agent（验证员）：被明确要求「try to break it」，输出PASS/FAIL/PARTIAL三种标准化判定

Agent类型系统：调研Agent只能读不能写，规划Agent不能碰文件只出方案——什么角色能碰什么东西出厂就定死

44个feature flag：每个高级功能都有一个开关，没启用的在构建时直接移除

四、超越三层架构的新维度

源码中还出现了三层架构之外的新系统，解决的问题已超出「怎么执行任务」的范畴。

这些系统的共同特征：不是执行长程任务必须的，但对效率、自定义和商业化是必须的。壳正在从Harness向Infra蔓延。

五、减法：补偿面迁移

关键洞察：Harness的每个组件都编码了一条「关于模型做不到什么的假设」。当假设不再成立，组件就该拆掉。

Anthropic已拆除的组件：

Context Reset：Opus 4.6的上下文管理能力已足够强，加与不加没有质量区别

Sprint Contract：新模型已能自己把控节奏，不再需要每轮开工前谈验收合同

Cursor的发现：影响系统行为最大的因素是Prompt，其次是Harness结构，最后才是模型本身。「调一句prompt的效果，比换掉整个harness架构都大」

核心原则：

六、护城河在哪里？

反面：如果一家公司说「我们有最完善的harness方案」，那不是护城河，是负担。因为那些组件的存在理由是「此刻的模型做不到什么」，模型每强一分，理由就少一分。

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

检验方法：看到一个AI产品加功能时，问自己——这个功能是在补模型当前做不到的事，还是已经在补一个模型早就能自己做的事？前者是必要成本，后者是技术债。看到一个团队拆架构时，不要读成「他们走了弯路」，读成「他们正在发现模型能做什么了」。

七、未来：不确定性

三家头部公司都留了后手：

OpenAI：Codex团队用5个月从零生成100万行代码，但每周花20%时间清理AI产生的低质量代码。「在一个完全由Agent生成的系统里，架构的一致性经过数年之后会如何演化？我们还不知道。」

Anthropic：这些假设是「承重的」，但不是永久的。

Cursor：Agent在扁平结构下变得极度规避风险，宁愿做无意义的小修改也不碰难题，系统需要周期性的fresh start。

2019年Sutton写The Bitter Lesson说「算力的通用方法终将胜过人类手工设计的巧招」，但这十五个月讲的是——你必须先认真搭那些巧招，才能知道哪些该拆。通往简单的路，必须经过复杂。

八、关键术语速查

九、关键数据回顾

十、核心启示

先做加法，再做减法：每一层被拆掉的补偿，都曾经被认真搭过。通往简单的路，必须经过复杂。

Harness是临时补丁，不是永久架构：每个组件都编码了「模型做不到什么」，模型进步了，补丁就该拆。

三层目标清晰：第一层管不听话，第二层管群体操作，第三层管看不清自己。

护城河在迁移速度，不在厚度：知道下一寸该加什么、上一寸该拆什么，比堆砌组件更重要。

壳正在膨胀：从「让Agent工作」到「让Agent好用、可控、可商业化」，壳在往全新维度伸展。

扫码关注联系

中医人工智能、数智中医解决方案

人工智能病案质控、ＣＤＳＳ

点分享

点收藏

点点赞

点在看