AI Agent 的 Harness 到底是什么：规则、约束，还是别的
基于 Hermes v0.20.0 + deepseek-v4-flash 实测（2026-08，36 次受控实验）。
📖 摘要：Harness Engineering 是 AI 圈 2026 年最热的概念之一，但「Harness 到底是什么」很少有人讲透——是规则？是约束？是环境？还是别的？本文不玩概念，直接解剖：先划清 Harness 不是框架、不是平台、也不是提示词；再给出一个可检验的定义——Harness 是围绕 agent 决策三时刻（决策前、执行中、出错后）的约束与能力边界；最后用一个真实 agent（Hermes）拆开看它由哪几层组成、每一层怎么起作用、什么写法有效什么写法失效（36 次受控实验数据作证据），以及 Harness 管不住什么。
一、都知道这个词，但它是「什么」
做 AI 应用交付这一年，我们几乎每天都要和「让 agent 按规矩干活」这件事打交道。Agent 不是聊聊天就完了——它要写代码、改配置、调接口、出报告，动不动就自己发挥。管住它，靠什么？
圈子里给出的词是 Harness Engineering——直译过来是「马具工程」。OpenAI 说推理模型是大脑，harness 是手和脚；Terraform 的作者 Mitchell Hashimoto 的说法更朴素：每次 agent 犯一次错，就工程化一个方案，让它再也犯不了同样的错。
概念听多了，一个尴尬的问题浮出来：它到底是「什么」？ 是一套框架？一个平台？一份规则文档？还是一种写法？
我们试过按自己的理解去落地，也看过各种说法——发现大多数讨论停留在比喻层：「harness 就是约束」「harness 是环境」。比喻很好听，但落不到工程上。你没法对着一个比喻写代码、配系统。这篇文章想把这个问题讲透：Harness 是什么、不是什么、由什么组成、在真实 agent 上怎么生效、以及它管不住什么。
二、先划边界：它不是什么
要搞清楚一个东西是什么，先排除它不是什么。我们踩过的坑，一半来自把 Harness 错认成别的东西。
它不是一套框架。 没有「安装 harness」这个动作，没有 SDK，没有版本号。你说「我们的项目用了 Spring」是有明确含义的；说「用了 harness」没有任何安装行为可以对应——这提示我们，它更像是一种组织方式，而不是一个组件。
它不是平台。 有些文章把 agent 运行平台（执行环境、沙箱、工具运行时）叫 harness。平台是「agent 跑在哪里」，而 harness 讨论的是「agent 被什么管着」——两者可以分开存在：同一个平台上的 agent，一个被管得死死的，一个自由发挥。
它不是提示词。 这是最容易混的一点。把约束塞进 system prompt 确实能影响行为——但提示词是「每次请求都要重新说的话」，它随着对话膨胀、稀释、被遗忘。约束文件是「每次启动都重新加载的静态资产」——生命周期完全不同。两者都能约束，但一个是一次性的软话，一个是持久的硬结构。
它不是「规则清单」。 规则只是载体之一。真正的 harness 里还有身份定义、能力声明、记忆组织——只有规则的那一份，往往是最容易失效的（后面实验部分会看到，为什么「铁律清单」反而会坏事）。
排除完这四个，剩下的是什么？我们给出的工作定义是：
Harness = 围绕 agent 决策三时刻的约束与能力边界。
三、本质：决策三时刻，harness 在每个时刻做什么
agent 的一次任务，拆到最细，是无数个决策。但宏观上看，每个决策都落在三个时刻之一：决策前、执行中、出错后。Harness 的全部工作，就是在这三个时刻各守一道：
决策前——决定「它敢做什么」：边界与能力声明。 agent 动手之前，需要知道自己是谁（身份）、能调什么（能力清单）、不能碰什么（禁区）。这一层决定的是「可选集」：一个没有身份和能力边界的 agent，理论上什么都能试——而什么都能试，往往意味着在错误的方向上花掉大量 token。约束文件先于任务存在，agent 每次启动都要先读它——这就是「决策前」的闸门。
执行中——决定「它怎么做」：流程与格式约束。 agent 执行任务的过程中，harness 管的是过程：先做什么后做什么（流程）、输出长什么样（格式）、什么时候必须停下来确认（门禁）。这一层管的不是「能不能」，是「像不像样」——同样的任务，有流程约束的 agent 交出来的是一份可验收的结果，没有的是自由发挥的半成品。
出错后——决定「它下次还犯不犯」：错误经验的固化。 这是 Harness 区别于「普通项目管理」的关键，也是 Hashimoto 那句「每次犯错就工程化一个方案」的落点。agent 犯过的错——写代码没自测、从局部日志推断整体、跳过加载直接凭记忆写——被固化成约束文件里的新条目，变成它下一次的行为边界。Harness 本质上是错误经验的载体：文件里每一条纪律，都对应过去的一次事故。这就是为什么它越长越值钱，而不是越长越啰嗦——前提是每一条都钉在错误上。
三个时刻合起来，Harness 干的事情是同一件：把 agent 的行为空间，从「模型自由发挥」收窄到「组织可接受的轨道」——然后让收窄本身可积累、可复用。
四、解剖一个真实 agent：它由哪几层组成
定义是骨架，落到真实系统才能看见血肉。拿我们自己用的 agent（Hermes Agent，跑在 WSL 上的一个开源执行体）当解剖样本——它的 harness 由五层组成，每层管一件事。
第一层：约束层——管输出形态与流程。 对应项目根目录那份约束文件（AGENTS.md，业界通用约定）。它管的是「这份工作交出来该是什么样」：格式要求、汇报结构、流程纪律。这一层是项目级的——换一个项目，这一层跟着换。
第二层：身份层——管角色与价值观。 agent 的「人设」：它是什么角色、坚持什么原则、什么情况下可以反驳用户。这一层看起来虚，实际决定行为下限——没有身份层的 agent 是个「有问必答的工具」，有身份层的 agent 会主动纠正用户的错误假设。区别不在能力，在立场。
第三层：能力层——管它会干什么。 技能与工具声明：agent 拥有哪些能力包、什么任务必须调用什么工具、禁止绕开工具凭记忆硬写。这一层的存在意义是「让能力可被发现、被强制使用」——agent 的模型知识是潜在的，能力层把「会用」变成「必用」。
第四层：记忆层——管它知道什么。 持久化的信息：环境事实、用户偏好、历史结论。注意记忆和纪律的区别——记忆是信息（用户喜欢什么格式），纪律是行为（动手前必须加载技能）。把纪律写进记忆层是常见错误：记忆是弱触发的背景信息，纪律需要强触发的前置动作。
第五层：执行约束——管流程中的门禁。 任务执行到关键节点时的强制检查：写完代码必须跑测试、汇报前必须核对数据来源、涉及范围/数量的结论必须看完整来源。这一层往往以「检查清单」的形态嵌在流程里——它不是约束文件的附属，是独立的一道闸。
这五层合起来，就是我们在用的真实 harness。拆开看每一层都不神秘——但五层各司其职、且错误经验能顺着「出错后」固化成新约束时，它们合起来的效果是单个提示词永远做不到的：agent 的行为边界可以像代码一样被版本管理、被审计、被复用。
五、它怎么生效：机制，不是玄学
约束文件放在那里，为什么就能改变 agent 的行为？我们做过 36 次受控实验（3 种写法 × 4 个约束敏感型任务 × 3 轮，在 Hermes v0.20.0 + deepseek-v4-flash 上）——实验本是回答「约束文件怎么写」的，但结果反而把「怎么生效」的机制照清楚了。
三种写法：A 基线（无约束）、B 精简铁律（<500 字、全是要求句）、C 结构化（分节 + 要求/禁止成对表格）。
机制一：约束靠「加载」生效，不是靠「记住」生效。 agent 每次任务启动时读约束文件——读没读到，效果天差地别。实验里有个技能纪律测试（要求动手前先加载对应技能），A 写法 0/3 次加载，B 写法 2/3，C 写法 3/3——结构化写法下约束文件被完整读取并执行，而「无约束」的 agent 在 3 轮里没有一次主动加载技能。约束文件的第一个秘密是让 agent 每次都读它——所以它必须短（800-1500 字，超过 3000 字稀释上下文，agent 只看开头），必须有结构（分节后关键纪律不会被淹没）。
机制二：「要求」会被字面执行，「要求+禁止」才会收敛。 这是实验里最反直觉的发现。B 写法写「测试要全面」，agent 就真的把整个项目翻出来测——T2 任务平均烧掉 766k tokens，是基线的 3 倍，成本飙到 2.28 倍，产出反而更差。C 写法把同样一条写成「要求：写完代码立即验证；禁止：跳过测试直接交付」——行为收敛，成本降到 1.44 倍，达标率 100%。只写要求不写禁止，agent 会把要求推向极端——因为模型在「满足字面要求」上从不吝啬。禁止条款才是真正划定边界的部分。
机制三：同样的约束，放在不同层，触发强度不同。 实验中同样的纪律放在两层对比：放进身份层（身份文件）的纪律，内化执行，成本 1.59 倍；放进项目约束文件当普通条目，字面执行，成本 2.28 倍。原因是触发时机不同——身份层的原则每次决策都参与，项目文件的条目只在相关任务时才被想起。行为纪律要放在强触发的层，格式要求放在项目层——放错层，效果差一个量级。
机制四：事实完整性靠显式禁止，不靠模型自觉。 实验里 B 写法出现过一次典型的「自信错误」：agent 从局部日志推断整体，把「3 种写法 36 轮实验」说成「双变体 24 轮」——它没撒谎，它是真觉得自己对。C 写法下同样的任务每次都读完整方案文件、说对。「禁止从局部推断整体」从此写进我们的纪律——模型的事实错误不是靠提醒能解决的，要靠结构（强制核对完整来源）才能拦住。
这四个机制合起来回答了一个问题：为什么有的约束文件有用、有的没用？——因为它要生效，必须同时满足：短到每次都读、结构到不淹没重点、要求与禁止成对、纪律放对层、事实类用结构拦。缺一条，约束就从「缰绳」变成「摆设」。
六、落地：一份能用的约束体系长什么样
机制讲完，给一份可复用的浓缩写法（详细模板与更多实验数据见文末相关文章的「AGENTS.md 怎么写」篇）：
- 分节：身份 / 执行纪律 / 输出格式 / 禁忌——四节各管一摊，别混在一坨
- 纪律用表格，要求与禁止成对：
| 纪律 | 要求 | 禁止 |——只有要求没有禁止 = 给极端执行留了门 - 「事实完整」纪律必带：涉及范围、数量、结论的事实必须核对完整来源，禁止从局部推断整体
- 分层放置：行为纪律放身份层（强触发），格式要求放项目约束文件（随项目走），信息（偏好/环境）放记忆层——放错层的纪律等于没有
- 长度控制：800-1500 字——每写一条，问自己：删掉它，agent 会犯错吗？不会，就删
- 错误驱动迭代：每次 agent 犯错，把事故固化成一条新纪律——harness 是长出来的，不是写出来的
七、边界诚实：Harness 管不住什么
把 Harness 讲得再清楚，也得说它管不住什么——不然又是一篇概念爽文。
它管不住模型的能力上限。 约束文件写得再好，模型不会的它还是不会。Harness 是缰绳，不是引擎——它保证马走正道，不保证马跑得快。
它管不住概率性失效。 模型行为有随机性——同一份约束，这次执行和下次执行可能有细微差异。Harness 能把失败率压低（我们的实验里从 75% 失败风险压到结构化后的稳定通过），但压不到零。所以 Harness 体系里永远要留一道「验证」闸——约束管行为，验证管结果，两者不能互相替代。
它管不住没说出口的需求。 约束文件写的都是「已知的错」——agent 犯过的、我们预见到的。全新的错误类型、没说清的业务目标，Harness 无从约束。这也是为什么它要「长出」而非「写出」：每遇到一类新错误，就补一条。
诚实划完边界，结论反而更清楚：Harness 不是银弹，它是把 agent 从「每次自由发挥」变成「在可积累的轨道上收敛」的工程手段——它回答的从来不是「agent 能不能更聪明」，而是「agent 能不能更可靠」。在交付里，后者往往比前者值钱。
常见问题
Harness 和提示词（prompt）有什么区别？
提示词是每次请求都要重复的对话内容，随对话膨胀、稀释、可能被遗忘；Harness 是 agent 每次启动都重新加载的静态资产——约束文件、身份定义、能力声明在任务开始前就位，与单次对话无关。约束靠「加载时机」生效（每次任务启动必读），提示词靠「当前上下文」生效（这次对话有没有提到）——生命周期不同，不能互相替代。
AGENTS.md 就是 Harness 吗？
AGENTS.md（项目约束文件）是 Harness 的一个组成部分——管输出形态与流程纪律的那一层。完整 Harness 还包括身份层（角色与原则）、能力层（技能/工具声明）、记忆层（持久信息）和执行约束（流程门禁）。只有一份规则清单的「Harness」，恰恰是最容易失效的那种（见文中 2.28 倍成本实验）。
Harness 能解决 agent「不听话」的问题吗？
能解决「约束类不听话」——行为越界、跳过流程、从局部推断整体、不按格式输出，这些靠结构化约束显著改善（36 次实验：结构化写法达标率 100%）。解决不了「能力类问题」——模型不会的还是不会，概率性失效也压不到零。判断标准一句话：这个错是「它没按规矩来」还是「它没这个本事」？前者归 Harness，后者归模型选型。
相关文章：Hermes Agent 调优实录（零）：AI Agent 靠不靠谱？我用 200 次对照实验告诉你（实验体系总览，本文 36 次实验的上一级框架）｜Hermes Agent 调优实录（一）：AGENTS.md 怎么写，AI Agent 才真的听话？（约束文件写法的完整实验与模板，本文第六节的展开版）
