夜雨聆风缰绳工程，AI 落地的第三层
━━━━━━━━━━━━━━
如果你最近在用 AI 代理（Agent）做一些稍微复杂的事，大概率会碰到这种情况：第一次跑对了，第二次搞砸了，第三次又不知道为什么好了。这不是模型的问题，是你缺少 Harness。
一匹野马和一套缰绳
Harness，英文原意是驾驭马匹的那套装备：缰绳、马鞍、胸带。把这个词放进 AI 工程的语境里，意思很直白：你拿到了一匹跑得飞快的马，但没有缰绳，它能带你去哪儿，完全靠运气。
2026 年，软件工程社区开始用 "Harness Engineering" 这个词，指代 Agent 系统外围那套让模型行为变得可控、可重复、可追责的基础设施。不是提示词写法，不是给模型喂什么数据，而是围绕模型的那一圈工程机制。
骑马类比 · 理解三层工程范式
提示词工程你对马说的话：「向右转」「加速」
上下文工程你给马看的地图和路标
Harness 工程缰绳、马鞍、围栏、道路——跑偏时能拉回来的整套物理设施
Phil Schmid 有个更工程化的比喻：模型是 CPU，Harness 是操作系统。CPU 再快，操作系统一团乱，整台电脑跑起来也是烂的。
三层嵌套，不是并列关系
搞清楚这三层范式的逻辑很重要，因为很多人把它们当成竞争关系，其实是包含关系：
判断自己遇到的是哪层问题，有个简单方法：单次输出跑偏，改提示词或者补信息通常能修。如果单次输出没问题，但多次使用后架构一致性越来越差、老是重复犯同样的错，那就不是提示词的事了，是 Harness 层出了问题。
Harness 由哪些东西组成
Harness 不是单一工具，是五类机制的组合：
知识管理
把团队分散的项目背景、规范、约定，转成 Agent 能找到的结构化文档（比如 CLAUDE.md / AGENTS.md）。Agent 不了解项目，不是它不聪明，是没人告诉它。
约束系统
用机械化规则替代口头约定。报错信息本身要能当修复指南。「这个不让做」得写进系统，不能靠每次提示词重申。
反馈回路
让目标任务可以被量化测量，Agent 执行完能自己判断对没对，而不是等人来看结果。
熵管理
Agent 快速迭代之后，技术债务会比人写代码积累得更快。要设计自动化的"垃圾回收"机制，不然架构会在几周内变得一团糟。
状态与记忆
跨会话、跨上下文窗口的任务，信息怎么连续传递。靠结构化进度文件加版本化存储，不靠模型"自己记住"。
数据说话：Harness 比换模型更有效
说这套东西有用，不能只靠类比，得看数字。
实验数据
30 → 5 名LangChain 仅优化 Harness，编码 Agent 在 Terminal Bench 2.0 排名从第 30 升至第 5，模型未变。
6.7% → 68.3%同一模型只改了编辑工具的输出格式（属于 Harness 层），性能差距超 10 倍。
这两个数字值得多看一眼。前者说的是：排名提升不是换了更好的模型，是改了围绕模型的工程设计。后者更极端：10 倍的性能差距，来自格式这种"小事"。
这是 Harness 工程里一个反直觉的结论：工程设计对 Agent 性能的影响，经常超过模型本身的差距。
· · ·
工程师的角色在变
Harness Engineering 的出现，改变的不只是技术栈，是工程师干什么这件事。
以前写代码，是一行一行砌砖。现在的工作越来越像：定义规则、设计约束、建立反馈、管理 Agent 行为的边界。这更接近架构师和制度设计者，而不是执行层的编写者。
这个转变让很多人不舒服，因为"写代码"是可见的、可度量的，而"设计 Agent 的行为系统"摸起来没那么扎实。但数据在那里：你的 Harness 设计得好不好，最终会直接反映在 Agent 的稳定性上。
缰绳的目的从来不是限制。是让潜能更安全、更彻底地释放出来。
— Harness Engineering 核心理念
提示词写得再好，也挡不住一个没有约束机制的 Agent 在长任务里飘走。这不是悲观，是设计前提。Harness 工程要做的，就是把"碰运气"变成"可重复"。
· · ·
