返回文章

Harness Engineering：给 AI 装上工程护栏

从 Prompt、Context 到工具权限、验证门禁和反馈回路，解释 Harness Engineering 如何把 AI coding agent 纳入可控的软件工程流程。

方法论 11 分钟阅读 AI 产品测试开发记录 更新于 2026/06/16
AI工程AI测试质量工程自动化测试

一句话定义：Harness Engineering 是为 AI coding agent 构建“可执行、可约束、可验证”的工程系统，让模型输出不只停留在回答层面，而能进入真实软件交付流程。

如果只看聊天窗口，AI 编程助手像是一个会写代码的模型。但在真实工程里，模型只是系统的一部分。

它能不能读到正确文件？能不能调用 shell？能不能改数据库？失败后是否会重试？提交前是否必须跑测试？跑完测试后如何判断“已经完成”？这些都不属于模型权重本身，却直接决定最终质量。

Harness Engineering 讨论的就是这一层“模型外部的工程系统”。它不是给 AI 写一段更长的咒语，而是给 AI 装上一套外骨骼：任务入口、上下文、工具权限、执行流程、验证门禁、状态记录、反馈回路，以及必要时让人接管的安全阀。

为什么现在需要 Harness

很多团队使用 AI coding agent 的路径很相似。

第一阶段是 Prompt Engineering：学会把需求写清楚，告诉模型按什么格式输出，要求它先分析再动手。

第二阶段是 Context Engineering：发现模型不知道现场，于是开始给它代码、日志、文档、接口契约和团队规范。

第三阶段就会遇到更硬的问题：即使 prompt 写得清楚、context 给得充分，AI 依然可能改错边界、漏跑测试、误判完成、拿过期信息做决策，或者在高风险操作上过于自信。

这时问题已经不是“模型有没有听懂”，而是“模型如何被放进工程流程”。Harness Engineering 正是解决这个问题。

和 Prompt / Context / Test Harness 的关系

这几个概念容易混在一起，可以按层级理解。

Prompt Engineering 关注“怎么说”。它控制任务表达、角色设定、输出格式和约束语气。好的 prompt 能减少误解，但它本身不能保证 agent 真的执行完整流程。

Context Engineering 关注“看什么”。它决定模型能看到哪些代码、文档、日志、检索结果和历史决策。上下文不是越多越好，而是要在合适时机提供高信号材料。太少，模型会猜；太多，模型会被噪声淹没。

Harness Engineering 关注“怎么做、做到什么程度、如何证明做对了”。它把 prompt 和 context 放进更大的系统里，再加上工具权限、执行流程、验证门禁、状态记录、失败恢复和人类审批。

传统 Test Harness 则是它的近亲。测试领域的 harness 会用 driver、stub、mock、fixture 让被测程序在可控环境中运行，喂入输入，收集输出，并判断是否符合预期。AI agent harness 的对象从“被测程序”变成了“会行动的模型”。共同点是：都不相信裸执行，都通过环境、输入、约束和观测来获得可重复、可判断的结果。

一句话概括：

  • Prompt 让 AI 听懂任务。
  • Context 让 AI 看见现场。
  • Harness 让 AI 在现场按规矩干活，并用证据证明结果。

一个工程比喻：自动化工厂

可以把 AI coding agent 想成工厂里的机器人手臂。它很灵活，能拿工具、装零件、修问题，但不能直接丢进生产线就指望稳定交付。

在工厂里，生产指令对应 prompt，原材料和图纸对应 context，机械臂能力对应 tools，生产流程对应 harness，质检站对应 verification gates，生产记录对应 state and logs，车间主管对应 human review。

没有 harness 的 AI，就像没有工艺流程和质检站的工厂：产能看起来很高，但你很难相信每件成品都能出厂。

Harness 的价值不是限制 AI，而是让 AI 的能力进入可治理的生产系统。工程组织真正需要的不是偶尔一次神来之笔，而是同类问题下次也能被正确处理。

一个 AI Agent Harness 通常包含什么

一个实用的 harness 不一定庞大，但通常包含八个模块。

1. 任务入口

任务入口负责把自然语言需求变成工程任务单。它至少要描述目标、范围、验收标准、禁止修改区域、风险等级和退出条件。

“优化登录”不是好入口。“复现登录失败，定位根因，最小改动修复，补充失败路径测试，跑类型检查和相关测试，说明未覆盖风险”才更接近可执行任务。

2. 上下文装配

上下文装配决定给 agent 什么信息。典型来源包括相关代码文件、接口契约、失败日志、最近 diff、领域规则、测试策略和仓库说明。

关键不是把整个仓库塞给模型，而是按任务动态筛选。好的上下文装配会区分事实和假设，也会避免把过期文档当成当前约束。

3. 工具与权限

Agent 的能力来自工具，但风险也来自工具。读文件、写文件、运行测试、打开浏览器、访问数据库、调用外部 API、创建 PR、修改 CI 配置，都应该有明确权限边界。

读代码可以默认开放；写文件限定在工作区；执行测试命令可以允许；删除文件、改 CI、改数据库、发布生产环境必须人工确认。权限设计要比提示词更硬。

4. 执行流程

执行流程定义 agent 如何推进任务。一个健康流程通常是：理解任务、制定计划、定位代码、小步修改、本地验证、总结变更、提交审查。

没有流程约束时，模型很容易直接跳到“看起来能修”的代码改动。Harness 要把“一次生成”变成“多步工程流水线”。

5. 验证门禁

验证门禁是 Harness Engineering 的分水岭。没有验证，AI 只是生成文本；有验证，AI 才开始进入工程。

门禁可以包括 lint、type check、unit test、API test、E2E test、契约测试、安全扫描、覆盖率阈值、快照比对、性能基线。核心原则是：不是 AI 说“完成了”，而是系统证明“通过验证”。

6. 状态记录

复杂任务不是一次消息能完成的。Harness 需要记录 agent 做了什么、为什么这么做、改了哪些文件、跑了哪些命令、哪些测试失败过、失败后如何修复。

好的状态记录能回答三个问题：现在在哪里，为什么到这里，接下来最小的可靠动作是什么。

7. 反馈回路

失败不是终点，而是系统输入。Agent 忘记跑测试，就把测试命令做成强制门禁；agent 总是改错配置，就收紧可修改目录；agent 经常误解业务术语，就补充领域词典；生成的用例不稳定，就加入稳定性规则和反模式检查。

Harness Engineering 的核心习惯是：每次失败都要变成下一次的防线。

8. 人类接管

好的 harness 不追求“完全无人”。它应该明确什么时候必须停下来叫人：需求冲突、风险过高、验证无法通过、需要产品判断、涉及数据迁移、触碰安全策略、修改公共 API、连续失败超过阈值。

人类接管不是失败，而是系统安全边界的一部分。

配图建议

AI Agent Harness 执行闭环结构图
Harness 将任务入口、上下文、工具权限、验证门禁和反馈回路串成闭环。

文章配图可以画成一个“外骨骼 + 闭环流程”的结构图：

Task Entry

↓

Context Assembly

↓

Agent Execution Core

↓

Tools & Permissions

↓

Verification Gates

↓

State / Logs / Report

↓

Feedback Update

↺ 回到 Context / Rules / Gates

旁路：高风险、不确定、权限不足、验证无法收敛 → Human Takeover

视觉上不要把 AI 画成一个全能大脑。更好的画法是：AI 在中间，外面包着任务、上下文、权限、验证、日志和反馈。重点是“AI 周围的工程约束很清楚”。

测试开发和质量工程怎么落地

如果你做测试开发或质量工程，Harness Engineering 很贴近日常工作，可以从五件事开始。

第一，把任务入口结构化。为 agent 任务定义模板：背景、目标、影响范围、验收标准、必须执行的测试、禁止修改的目录、输出格式。不要让 agent 从一句模糊需求开始猜。

第二，建立项目级规则文件。把测试命名规范、用例分层原则、页面对象模型约定、接口断言规则、数据清理策略、等待策略、失败重试原则写成 agent 会优先读取的规则。规则要短、具体、可执行。

第三，把验证命令产品化。不要只告诉 agent“记得测试”。提供固定命令，例如 `pnpm test`、`pytest -m smoke`、`ruff check`、`playwright test`、`mvn test`。最好让 harness 自动收集退出码、失败日志和报告路径。

第四，给工具分级授权。低风险任务可以自动完成，高风险动作必须人工确认。尤其是数据库写入、生产部署、批量删除、外部消息发送、CI 配置修改，不要交给一句提示词兜底。

第五，建立失败模式库。记录 agent 常犯的问题：断言太弱、滥用 sleep、测试数据污染、只修 happy path、跳过失败用例、误删边界判断、改了公共方法却没补回归。每类失败都应该对应一条规则、一个检查或一个门禁。

常见误区

第一个误区是把 Harness Engineering 当成高级提示词。提示词只是其中一层。没有权限、流程、验证和反馈，提示词再漂亮也很难稳定。

第二个误区是上下文越多越好。上下文泛滥会稀释重点，也会把过期信息带进决策。好的 harness 会筛选、排序和压缩上下文。

第三个误区是迷信全自动。越接近真实生产系统，越需要分级授权和人类接管。无人值守不是成熟标志，知道何时停下来才是。

第四个误区是只看模型，不看系统。同一个模型，在不同 harness 里表现可能差很多。工具描述、默认流程、验证门禁、错误反馈、工作区设计，都会改变 agent 的实际能力边界。

第五个误区是没有复盘机制。Agent 犯错后只说“这次模型不行”，下次还会错。Harness 的价值在于把一次失败固化为下一次的防线。

结语

AI coding agent 的出现，并不意味着工程纪律可以减少。恰恰相反，模型越能行动，外层工程系统就越重要。

过去我们主要关心人如何写代码。现在还要关心 agent 在什么环境里行动、能看到什么、能做什么、如何证明做对了、失败后系统如何变得更好。

工程师的价值不会消失，而是在扩展：从“亲手写每行代码”，扩展为“设计能稳定产出正确软件的系统”。

Harness Engineering 的核心意义，正是把 AI 从“会写代码的模型”，变成“可以纳入工程体系的执行单元”。未来更重要的问题也许不是“AI 会不会写代码”，而是“我们有没有能力设计一个让 AI 持续写对代码的系统”。

参考资料