xancel的自留地
文章
技术

模型之外的关键：Harness工程体系

2026年5月19日 7 分钟阅读 浏览 1 喜欢 0 评论 0
AI 摘要

Harness是模型之外的一整套运行环境，决定了AI能看见什么、做什么、不能做什么以及如何纠错和验证。它的核心在于通过前馈（行动前规则）和反馈（行动后检查）来提升AI首次正确率并加速错误修正。本质上，Harness将非确定性的模型置于可控、可观测的系统中，并通过迭代设计，从个人到组织逐步优化工程基础设施。

mp.weixin.qq.com

Harness 完全指南：harness 是一切工作的核心（1.3万字）

本文内容摘取与李自然老师的文章，写的很好，推荐查看原文

1. harness 是什么？

Harness是模型之外的一整套运行环境。它决定AI能看到什么、能做什么、不能做什么、做完后如何验证、出错后如何修正、什么时候交还给人。

核心公式：Agent = Model + Harness

  • Prompt 是你对AI说什么
  • Context 是AI当下看见什么
  • Harness 是AI被放进了一个什么样的行动系统

模型是大脑。Harness是大脑之外的一切。

同一个模型，放在不同harness里，可以是两个不同的智能体。 LangChain实验证明：同一个模型不变，只调整模型外面的运行环境，编码智能体在Terminal Bench 2.0上的得分从52.8跳到66.5——13分的差距，完全来自harness那一项。

2. harness 解决了什么问题？如何解决？

问题：AI开始行动后，面对的不再是一个聊天框，而是一个带有不确定性的执行系统。

核心目标：让AI第一次更可能做对；做错后更快知道自己错了。

解决方式：

阶段手段具体内容
行动前引导前馈AGENTS.md规则、目录结构、类型系统、权限设置——告诉AI该往哪走
行动后检查反馈测试、CI、linter、运行日志、代码review——告诉AI刚才那步有没有偏

本质：把非确定性的模型，放进一个尽量可控、可观测、可复盘的系统。

3. harness 的思想是什么？

核心理念

  • 围栏是给跑得快的马用的。跑不起来的马，不需要围栏。

    • 早期模型跑不远、跑不稳，不需要harness。当模型能连续跑几小时、跨多个上下文窗口时，能犯的错误也变多了，这时harness才真正必要。

  • 能用代码强制的，就不要写成「请记得」。

    • Hook会执行，自然语言会被忘。确定性骨架兜住的地方越多，留给模型自由发挥的空间就越精准。

  • 补丁会消失。基础设施不会。

    • 模型变强会吃掉「为弥补模型能力不足而存在的壳」（提示词注入防御、静态命令校验），但反馈层、治理层、上下文层不会消失，只会变得更值钱。

  • 自由度只留给真正需要推理的地方。其他地方交给确定性系统。

    • 智能体节点负责需要判断和生成的部分；确定性节点负责检查、提交、测试、拦截。

底层逻辑

这是1948年维纳提出的控制论的核心——前馈给方向，反馈看偏差。AI没有让「控制」这件事过时，只是把它的对象从机器换成了一个比机器更不确定、行动空间更大的系统。

4. harness 的构成是什么？

Harness由六层构成：

层级总览

层级名称核心问题
第1层指令层给AI一张地图，不是一本手册
第2层上下文层AI只能理解他看得见的东西
第3层工具层AI的手越多，越需要设计
第4层边界层先设计爆炸半径
第5层反馈层AI需要感受到现实
第6层治理层谁来管这些AI

各层详解

第1层：指令层

  • 包括：系统提示词、项目规则文件、AGENTS.md 、CLAUDE.md 、skills
  • 原则：每一条规则都对应一次智能体真实犯过的错，不是「最佳实践大全」，更像踩坑记录
  • OpenAI风格：告诉AI「应该做什么」
  • Anthropic风格：告诉AI「不能做什么」（更推荐——说清红线，剩下的留给模型发挥）

第2层：上下文层

  • 问题：每次模型调用前，要决定塞哪些信息进上下文窗口
  • 挑战：信息太少AI不知道情况，信息太多AI被噪音淹没
  • 解法：结构化工作状态（如claude-progress.txt），让新会话像接班的工程师一样先读交接记录
  • 子智能体的核心价值：隔离噪音——只把干净摘要交回主智能体
  • 核心原则：不在上下文里的东西，对AI来说就不存在；不该进上下文的噪音，也会让AI做错判断

第3层：工具层

  • 包括：文件读写、命令行、Git、浏览器、数据库、内部API、MCP服务器等
  • 反直觉：工具越多，系统提示越长，智能体越容易分心
  • 解法：根据任务给AI一组相关工具，不是「以防万一」的全家桶
  • 核心原则：工具不是越多越好，而是越清楚越好

第4层：边界层

  • 包括：权限、沙盒、网络隔离、文件系统隔离、密钥管理、审批规则
  • 设计：拒绝优先（故障即安全）——命中拒绝规则就直接停下，不被其他允许规则覆盖
  • 核心原则：爆炸半径要在事故发生前设计好，不要等事故发生后再补救
  • 反直觉：边界设计得越清楚，人类越敢把更多事情交给AI

第5层：反馈层

  • 包括：测试、类型检查、linter、CI、运行日志、代码review、另一个模型的评估
  • 发现：错误消息应该写得像给智能体看的修复提示（不只是「类型不匹配」，要说「应该用 string[]，不是 string」）
  • 核心原则：代码质量基础设施，在智能体时代不是锦上添花。它是AI的传感器。
  • 没有反馈，AI只能猜。有反馈，他才能修正。

第6层：治理层

  • 包括：成本监控、运行日志、审计记录、人工升级、失败复盘、组织级模板、回归评估
  • 核心问题：
    • 每个任务最多允许重试几次？
    • 什么情况必须交还给人？
    • 哪些工具调用要记录？
    • 哪些权限需要审批？
    • 一次harness改动之后，如何确认没有造成退化？
  • 核心原则：harness不是一个人的prompt文件。它会慢慢变成组织资产。

5. 如何构建自己的 harness？

最小 harness：四件套

text 
project-root/
├── AGENTS.md / CLAUDE.md  规则
├── init.sh                启动入口
├── feature_list.json      任务状态
├── progress.md            进度日志
└── src/                   代码
文件职责
AGENTS.md/CLAUDE.md http://AGENTS.md/CLAUDE.md 管规则——技术栈、必须跑的命令、不能碰的地方、完成标准
init.sh http://init.sh 管开工前环境检查——安装依赖、检查环境、跑基础验证、确认项目能启动
feature_list.json管任务状态——状态机：not_started/in_progress/blocked/passing，同一时间只有一个任务处于in_progress
progress.md http://progress.md 管跨会话记忆——上一轮做了什么、哪些检查通过、哪里还没验证、下轮从哪里继续

核心原则：

  • 规则文件控制在50-80行以内，不要一上来写成200行
  • 一条规则最好对应一次真实失败
  • 不要让AI在坏环境里工作
  • 每次会话结束前做干净收尾，不要让下一轮AI替上一轮收拾残局

三层成熟度

Level 1：个人级

  • 适合独立开发者
  • 核心：四件套 + 常用命令 + 最小反馈循环 + 失败日志 + 干净收尾
  • 目标：让AI少犯重复错误，每次会话都能稳定接上

Level 2：团队级

  • 适合3到20人团队
  • 核心：共享规则 + 统一目录结构 + CI必跑项 + PR模板 + 共享脚本 + 共享子智能体
  • 原则：把团队共识变成AI也能执行的工程环境。以前靠口头约定和代码review传递的东西，现在要尽量变成规则、脚本、模板和测试

Level 3：组织级

  • 适合大公司或生产级智能体
  • 核心：工具注册中心 + 权限系统 + 沙盒环境 + 运行日志 + 成本监控 + 人工升级 + 回归评估
  • 目标：让智能体成为组织基础设施的一部分

验证方法：对照实验

做两轮对比：

  1. 第一轮：只给普通prompt，不给规则文件、不跑初始化、不准备功能状态表。记录AI花了多久、漏了什么、最后你花了多少时间收拾。
  2. 第二轮：给最小四件套，按固定会话流程工作。

比较指标：

  • 是否只做了一个功能，没有乱扩范围？
  • 是否跑了必要验证？
  • 是否留下了清楚的进度记录？
  • 是否减少了重复解释和返工？
  • 下一轮会话能不能直接接上？

最终原则

Harness不是设计出来的，是迭代出来的。从简单开始，让AI跑，看他在哪里摔，再在那里加护栏。每一次真实失败，都是下一版harness的材料。

6. 为什么需要 harness？

直接原因

当模型能连续跑几小时、跨多个上下文窗口接力完成任务时——他能创造的价值变大了，能犯的错误也变多了。

真正的问题不再是「让他更聪明」，而是：

  • 他应该看见什么？
  • 他能调用什么工具？
  • 他不能碰什么？
  • 他做完之后怎么知道自己错没错？
  • 他连续失败几次之后，什么时候该交还给人？

这些问题加在一起，就是harness engineering。

深层原因

视角结论
个人会写代码正在从核心技能，变成基础素养。下一个时代需要的能力，是为AI设计能稳定执行的环境
团队智能体吃掉的是这个组织已经建好的工程基础设施。没有测试、清楚文档、稳定CI、标准化环境，买再多AI账号也很难跑出效果
行业模型这一层会越来越普及。但模型外面的工程基础设施，不会自动普及。这会让组织之间的差距变大

核心判断

Harness将是一切工作的核心。

  • 工程化成熟的团队，AI会放大它的能力
  • 工程化混乱的团队，AI也会放大它的混乱

补充视角：Cherny vs Osmani 的争论

人物观点
Boris Cherny (Anthropic Claude Code负责人)harness会消失——模型变强后，提示词注入防御、静态命令校验等「弥补模型缺陷的壳」会被吸收
Addy Osmani (Google Chrome团队)摩擦没有消失，只是搬家了——从写代码搬到了review和verify。高AI渗透团队PR合并量翻了98%，但review时间膨胀了91%

最终结论：补丁层会被模型吸收。基础层会变得更重要。Harness不会消失，它在演化。

喜欢 0
评论区在赶来的路上...