摘要：当 agent 进入真实仓库，最难的问题已经不再是“模型会不会写代码”，而是软件工程里原本默认由人承担的四类责任，能不能被重新写进系统：约束怎么显式化，执行在什么运行时里发生，完成之后谁来判定可用，这套系统最后又由谁维护和治理。
Harness Engineering讨论的，正是这四类责任如何从人脑、习惯和聊天记录，迁移成 agent 能稳定遵守的工程链路。一句话判断：Harness Engineering，不是 Prompt 的延长线，而是把原本靠人兜底的约束、验证与治理，写成 agent 必须遵守的执行系统。
过去一年，如果你认真把 AI coding 放进真实项目，而不只是让它写几段 demo 代码，你很快就会碰到一个更硬的问题：模型能力在变强，但工程系统对它的容忍度并没有同步变强。
它会生成 patch，但不知道哪些目录不能改、哪些接口不能动；会调用工具，但不知道仓库真正认可的是哪套命令、脚本和流程；当前 session 里看起来很聪明，跨任务、跨会话就接不上团队默认的知识、验证纪律和维护分工。
这正是 Harness Engineering 被反复提起的原因。不是因为行业又发明了一个新热词，而是因为 agent 一旦进入代码库，原本默默由人承担的几类工程责任，突然没有了默认承担者。
最先暴露出来的，通常是四个位置：
-
1. 哪些约束必须被显式写出来；
-
2. agent 在什么运行时里执行；
-
3. 完成之后由什么信号判定可用；
-
4. 这套系统最后如何维护和治理。
模型会不会写代码，已经不是最难的问题；更难的是，谁来替 agent 承担这四类工程责任。
下文就沿这四个位置展开。
为什么 Harness Engineering 首先是执行系统问题
如果只把 AI coding 看成提示词问题，很容易把 Harness Engineering 误读成 Prompt 的补丁。可一旦 agent 真的进仓库，问题马上就换了形状：它不是在回答一道题，而是在参与一条执行链。约束有没有读对，工具是不是从正确入口启动，中断后能不能继续，交付前能不能接受独立验证，这些都不属于“怎么提问”的范畴，而属于执行系统设计。
Prompt Engineering 解决的是这次怎么说，Context Engineering 解决的是这次该看什么，Harness Engineering 解决的是之后怎么做、怎么继续、怎么验收。前两者主要服务一次任务的启动，后者开始接管多步执行里的约束、工具、状态和验证。
边界一旦切到这里，agent 这个词也需要重新理解。它不是更强的 model，而是被放进执行系统里的 model。model 负责推理和局部决策，真正把它变成 agent 的，是外部那套 harness。
Mitchell 的定义，则把这套 harness 的目标说得更具体：如果 agent 犯过一次错，就把系统补到它以后不再犯同类错误。这已经不是提示技巧，而是软件工程最熟悉的动作：把事故转成系统，把一次失败转成长期约束。
Harness 值得投入，不只因为这次更稳，更因为它能积累。一次失败如果只在聊天里被口头纠正，收益只属于这一次；只有当纠偏被写进规则、脚本、校验、评测或状态工件，它才会变成下一次执行的默认能力。所谓复利，不来自模型自动变强，而来自团队把一次纠偏留在系统里。
需求与上下文层：为什么约束必须外化
在传统软件团队里，需求和上下文从来不只存在于一段任务描述里。
它们还存在于架构图、模块边界、代码所有权、评审习惯、构建命令、完成标准、风险升级规则这些看似“默认”的地方。
人类工程师能靠经验补齐这些空白。agent 不会。
它只会消费看得见的东西。
这就是为什么一旦 agent 进入真实仓库，第一步不是再给它塞更多背景，而是要决定：哪些约束必须被外化成机器可读的契约。
如果说 Context Engineering 关心的是“给模型看什么”，这一层真正要回答的则是：哪些信息不能只临时塞进上下文，而必须稳定地写进仓库。
这类契约的形态可以很朴素：
-
•
AGENTS.md告诉它项目级指令和禁区； -
• 架构地图告诉它关键模块和依赖边界；
-
• 任务说明告诉它本次的范围、停止条件和不该碰的区域；
-
• 风险规则告诉它哪些动作必须停下来让人确认。
这里最容易犯的错，不是写得太少，而是写得太多。
一个巨大的 AGENTS.md 往往和没有 AGENTS.md 一样糟。问题不在于 agent 不愿意读，而在于上下文预算是稀缺的。当所有东西都被标成“重要”，它反而失去了重点。
所以，需求层的 harness 不是“信息灌输”，而是“信息分层”。
你要给它地图，不要给它百科全书；给它执行边界，不要给它理念宣言；给它本次必须遵守的契约，不要给它一大堆没有优先级的背景噪音。
从软件工程看，这并不新鲜。
我们一直都知道，隐性知识一旦不显式化，团队规模一上来就会出问题。现在只是换成了 agent，这个问题被更快地放大了而已。
需求与上下文层真正被 harness 化的，不是“让 agent 知道更多”，而是“让它只看见那些足以约束行动的关键信息”。
而且这里有一个经常被低估的代价：过时的约束比缺失的约束更危险。
一份陈旧的架构图、一段过期的构建命令、一个早就失效的完成标准，对人类工程师来说也许还能靠经验纠偏；对 agent 来说，它们会直接进入执行链路。
所以，约束外化本身就是维护责任，而不是一次性文档工作。
实现层：为什么 agent 需要运行时，而不只是对话框
软件工程从来不是纯推理活动。它依赖工具链、执行环境、隔离机制、可恢复状态和可重复入口。人类工程师之所以能持续工作，不只是因为会写代码，更因为他们总是在某个具体运行时里工作。
到了这一层，Agent = Model + Harness 才会变得具体。Model 负责推理和局部决策，真正把它变成 agent 的，是外部那套运行时：工具入口、执行环境、状态延续和 handoff 机制。
Prompt 只是启动信号，真正决定执行上限的，是它被放进了怎样的运行时。
这也是为什么越往深处走，你越会发现：对 agent 来说，真正的执行单元已经不是那段 Prompt，而是下面这一组东西的组合：
-
• 固定工具入口；
-
• sandbox / worktree 这类隔离执行环境；
-
• 可读取的仓库状态；
-
• 可恢复的任务工件；
-
• 跨 session 可以继续的 handoff 机制。
头部产品之所以会把 harness 做成运行时，而不是继续堆更长的系统提示，本质上是在承认：
一旦任务开始跨文件、跨命令、跨环境、跨会话，工程问题的核心就从“输出什么文本”变成“如何组织一次执行”。
Anthropic 对长任务的处理方式很能说明问题。它真正解决的不是“怎么让模型别忘事”，而是“怎么让任务连续性脱离聊天历史，变成结构化工件”。
初始化脚本、feature list、进度日志、只允许改某个状态字段的强约束，这些东西听起来都不像 AI 魔法，反而像很传统的软件工程纪律。
但正因为它们传统，才有效。
因为一个没有状态工件的 agent，本质上等价于：每一轮都会换来一个失忆的新工程师。
OpenAI 在这条线上也给了很强的证明。随着代码吞吐上来，他们补的不是一句“请更认真地理解任务”，而是执行环境本身：tooling、隔离 worktree、浏览器访问、日志查询、指标读取、线程状态管理。
这说明实现层的 harness，本质上不是“给 agent 更多能力”，而是“把执行环境做成它能够稳定消费的样子”。
把前面两层压成一张团队落地时最常用的记忆卡片，就是四个词：
规则、工具、状态、验证。
规则让约束可读，工具让执行可复现，状态让任务可接力，验证让完成可判定。它们不是 harness 的全部，但足够解释多数团队为什么会先在这些地方掉链子。
当然，这里也有一个典型误区：太早把 harness 平台化。
如果任务模式还没稳定，失败模式还没收敛，团队还不知道最常复发的是哪类错误，就急着造一个“大一统 runtime”，大概率只会先造出一层抽象债。
实现层 harness 真正适合优先投入的，永远是那些高频、重复、失败代价高的路径。
验证层：为什么真正的瓶颈不是生成，而是可用性判定
真正的瓶颈通常出现在这里。
代码生成并不等于问题解决。对软件工程来说，最昂贵的环节始终是判定它到底能不能用。
这也是为什么很多团队会出现一种非常典型的反差：
demo 很强，进入生产却很弱；patch 开得很快，真正能放心合并的却不多；生成能力在增长，QA 和 review 却越来越像瓶颈。
按工程分类看，最先能被 harness 化的，通常是“可维护性”：
-
• 代码风格；
-
• 复杂度；
-
• 重复代码；
-
• 架构边界；
-
• 类型错误；
-
• 静态规则。
这些东西虽然不容易，但至少相对容易变成机器可读、可机械执行的质量门槛。
真正困难的是“行为正确性”这一层。
也就是：这次改动是否真的满足需求，页面是否真的按预期运作，日志和指标是否真的说明问题已被解决，端到端体验是不是闭环。
这类问题之所以难，不是因为模型不够聪明，而是因为它本来就是软件工程里最难被彻底形式化的部分。
所以，验证瓶颈主要落在 harness，而不主要落在 model 本身。模型可以持续提高生成质量，但“能不能判定真的可用”依赖的是测试、运行信号、审批链和验收机制。
OpenAI 后来把浏览器、日志、指标都变成 agent 可直接读取的信号，这本身就很说明问题。不是他们突然迷上可观测性，而是代码吞吐一上来，人类 QA 很快就会成为瓶颈。要继续放大 agent 的产出，这些验证信号就不能只留在人类 QA 手里，而要进入 agent 的执行链路。
但这并不意味着“让 agent 自己评自己”就够了。
恰恰相反，验证层最重要的原则是：不要让执行者兼任最终验收者。
一个更可靠的质量闭环，至少应该包含几类独立信号：
-
1. 构建和语法有没有通过；
-
2. 定向测试和关键用例有没有通过；
-
3. 浏览器、日志、指标这些运行信号有没有对上；
-
4. 高风险改动是否仍然需要人工审批或人工抽检。
这一层的判断只有一句：
生成代码是供给问题，可用性判定才是裁决问题。
前者可以被模型能力持续推高，后者却需要质量信号、验证机制和组织责任一起跟上。
这也是为什么很多团队越往后越会发现：真正稀缺的，不是再让 agent 多开几个 patch，而是建立一套足以判定“它真的可用”的证据系统。
维护与治理层：为什么 harness 最终会变成新的工程基础设施
当前三层一旦开始稳定复用，第四层就会出现：治理。
一旦 harness 开始有效，它就不会长期停留在“个人工作流技巧”这一级，而会不可避免地向平台层、治理层移动。
因为约束文件、工具协议、权限边界、状态工件、可观测性和评测基线，一旦被证明能提高稳定性，就会从“某个团队的好习惯”变成“全组织都想复用的承重件”。
换句话说，真正需要治理的，不是抽象意义上的 model，而是 model 外围那套 harness：规则文件、工具协议、权限边界、状态工件和评测基线。
也正因为这些东西会复利，组织才会自然想把它们平台化、标准化、跨团队复用。反过来，复利越强，随之而来的治理责任和平台债也会一起增长。
这也是为什么今天看似分散的很多动作，最后会越长越像工程基础设施：
-
• 规则文件开始跨工具复用；
-
• 工具入口开始需要统一约定；
-
• 权限和审批节点开始进入 agent runtime；
-
• 质量信号开始从人工经验迁移成平台能力；
-
• 文档和状态工件开始需要专门 ownership。
但这绝不意味着 harness 是免费午餐。
它会带来新的债：
-
•
AI slop会累积成新的维护成本； -
• 过期知识会变成新的误导源；
-
• 权限配置会产生新的安全面；
-
• 可观测性和评测会带来新的平台负担；
-
• 最关键的是，团队必须重新回答：谁拥有 harness，谁维护它，谁为它的漂移负责。
所以，Humans steer 真正的意思从来不是“人退出系统”，而是“人的位置上移了”。
人不再主要花在重复敲实现细节上，而要更多地负责架构边界、风险判断、验证设计、平台 ownership 和治理策略。
也因此，不是每一类任务都值得急着 harness。
真正适合被重度工程化的，往往是这些任务：
-
• 会重复发生；
-
• 失败代价高；
-
• 接收标准相对稳定；
-
• 跨人、跨 session、跨工具的交接成本很高。
而那些一次性探索、需求本身高度模糊、业务判断仍占主导的任务，保持人主导、让 harness 辅助，通常反而更健康。
收住全文，也只需要一句话：
真正的问题不再是 agent 会不会写代码，而是组织能不能把足够多的软件工程显式化，显式到一个概率系统也能安全参与其中。
Harness Engineering 不是给 AI 再套一层壳。
它是在把原本靠工程师经验兜底的约束、验证与治理，固化成一套可执行、可审计、可维护的工程系统。
AI求索者-未来 出品
