关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集
如果你最近在准备 AI Agent、AI 测试、测试开发相关岗位，面试里很可能会遇到一个新问题：
什么是 Harness 工程？
第一次听到这个词，很多人可能会有点懵。
Harness Engineering，有人翻译成“驾驭工程”，也有人直接叫 Agent Harness。
它不是一个单独的软件工具，也不是某个大模型厂商独有的功能，更不是把 prompt 写得更长一点。
它真正讨论的是一个更现实的问题：
当 AI Agent 开始进入真实工程项目之后，我们到底应该怎么让它稳定、可控、可验证地完成任务？
以前我们用 AI 写代码，大多是一次性交互。
你描述需求，模型生成代码，你复制到项目里，然后由你自己判断能不能用。
但现在不一样了。
Claude Code、Codex 这类 Coding Agent 已经不只是生成一段代码，而是可以读取代码库、编辑文件、运行命令、修复报错、生成测试，甚至参与提交 PR。Claude Code 官方文档也明确提到，它可以读取代码库、编辑文件、执行命令，并和开发工具集成；OpenAI 对 Codex 的介绍里，也强调它可以支持功能开发、重构、测试、代码 review 和工程交付流程。([Claude Code][4])
这意味着一个变化：
AI 不再只是“回答问题的人”，而是开始变成“参与工程流程的人”。
问题也随之来了。
模型再强，如果不知道项目怎么启动，不知道测试怎么跑，不知道哪些目录不能改，不知道失败日志在哪里，不知道代码评审标准是什么，它一样会犯低级错误。
所以 Agent 时代真正缺的，不只是更强的大模型，而是一套能让 Agent 正常工作的工程环境。
这就是 Harness 工程要解决的问题。
目录
什么是 Harness 工程？
为什么 Agent 时代需要 Harness 工程？
Harness 工程到底解决了什么问题？
Harness 工程包含哪些核心内容？
Harness 工程和 Prompt 工程有什么区别？
为什么软件测试从业者更应该懂 Harness 工程？
面试中怎么回答这道题？
一个真实项目里怎么落地 Harness 工程？
一、什么是 Harness 工程？
面试时可以这样回答：
Harness Engineering，也可以叫 Agent 驾驭工程，是围绕 AI Agent 构建工作环境的一套工程方法。
它主要包括：
上下文管理；
工具调用；
任务状态管理；
沙箱环境；
权限控制；
测试验证；
日志观测；
代码评审；
反馈回路；
人工干预和回滚机制。
它的目标不是让模型“回答得更好看”，而是让 Agent 在真实工程系统里：
能理解任务；
能读取必要上下文；
能调用合适工具；
能安全修改代码；
能运行测试验证；
能观察日志和失败原因；
能根据反馈继续修复；
能在边界内完成交付。
简单讲：
Prompt 是你怎么跟模型说话，Harness 是你怎么给 Agent 搭工作台。
如果说大模型本身提供的是推理和生成能力，那么 Harness 提供的就是工程环境、工具系统、反馈机制和安全边界。
所以现在有一种很常见的理解：
Agent = Model + Harness。
模型负责“想”和“生成”。
Harness 负责让它“能做事、做得对、出问题能被发现”。
这也是为什么只讨论模型能力已经不够了。
因为真实工程不是写一段代码就结束，而是要能验证、能回滚、能评审、能交付。
二、为什么 Agent 时代需要 Harness 工程？
以前程序员用大模型写代码，大多数场景是这样的：
你问一句；
模型答一段；
你复制进去；
你自己判断对不对。
这种方式，本质上还是“AI 辅助写代码”。
但 Coding Agent 的工作方式已经变了。
它会进入你的项目，读取仓库，分析文件，修改代码，运行命令，处理失败信息，再继续修复。
也就是说，它不是只给你建议，而是可能真的开始动你的工程资产。
这时候问题就来了。
一个项目里真正重要的信息，往往不在 prompt 里。
比如：
项目该怎么启动；
测试命令在哪里；
哪些模块不能跨层调用；
哪些接口必须保持兼容；
哪些日志必须打印；
哪些异常不能直接吞掉；
哪些页面必须真实打开验证；
哪些任务必须补测试；
哪些文件不能被 Agent 修改；
哪些操作必须人工确认。
这些东西，以前很多都靠老员工经验、团队约定和人工 review 兜底。
但 Agent 不知道这些隐性规则。
所以你会发现，很多时候不是模型不会写代码，而是它不知道你们项目的上下文和边界。
这也是为什么模型越强，越需要 Harness 工程。
因为 Agent 的能力越强，动作越快，能改的东西越多，风险也越大。
没有 Harness 的 Agent，就像一个很聪明但刚入职的新同事：
学习能力强，但不了解历史包袱；
执行速度快，但不知道哪些地方不能碰；
愿意主动修问题，但不一定知道什么叫修对；
能跑测试，但不一定知道该跑哪一批测试；
能写总结，但不一定符合团队交付标准。
Harness 工程的作用，就是把这些隐性经验变成 Agent 能读取、能执行、能验证的工程机制。
三、Harness 工程到底解决了什么问题？
在真实项目里，AI Agent 最容易出问题的地方，通常不是语法错误，而是工程上下文缺失。
比如：
团队架构规则只存在于老员工脑子里；
项目启动方式没有标准化；
测试入口散落在不同目录；
接口文档和真实实现不一致；
日志和错误堆栈没有暴露给 Agent；
UI 问题需要浏览器验证，但 Agent 只看了代码；
代码评审标准没有自动化，只能靠人最后兜底；
权限边界不清晰，Agent 可能改到不该改的文件；
任务完成标准不明确，Agent 容易“自认为完成”。
这些问题在传统研发里本来就存在。
只不过以前是人来兜底。
现在 Agent 参与进来了，这些问题会被进一步放大。
所以 Harness 工程解决的不是一个单点问题，而是一个完整闭环问题：
一个好的 Harness，不是保证 Agent 第一次就做对。
而是让 Agent 能进入一个持续修正的循环：
理解任务 → 执行修改 → 观察反馈 → 定位失败 → 继续修复 → 再次验证 → 输出证据。
这才是 Agent 真正进入工程现场的关键。
四、Harness 工程包含哪些核心内容？
为了方便理解，可以把 Harness 工程拆成两大部分：
引导系统 和 反馈系统。
引导系统解决的是：
Agent 执行前，怎么知道该怎么做。
反馈系统解决的是：
Agent 执行后，怎么知道有没有做对。
一、引导系统：让 Agent 少猜一点
引导系统的核心，是把项目里的隐性规则显性化。
常见内容包括：
AGENTS.md；
CLAUDE.md；
README；
架构文档；
编码规范；
目录结构说明；
项目启动脚本；
测试命令说明；
API 文档；
领域知识；
业务规则；
示例任务；
Skills；
任务拆解模板；
团队 review checklist。
比如 AGENTS.md 或 CLAUDE.md 里可以写清楚：
项目主要目录是什么；
后端服务怎么启动；
前端页面怎么启动；
单元测试怎么跑；
接口测试怎么跑；
E2E 测试怎么跑；
哪些文件不能修改；
哪些依赖不能随便新增；
提交前必须执行哪些检查；
遇到失败日志应该看哪里；
代码风格遵守什么规则。
OpenAI Codex 官方文档里就有 AGENTS.md 的使用说明，可以在全局或仓库级别放置工作约定，比如修改 JavaScript 文件后运行测试、提交 PR 前运行 lint、公共工具变更时更新 docs 等。([OpenAI开发者][3])
Claude Code 官方文档也提到，CLAUDE.md 可以放在项目根目录中，用于配置编码标准、架构决策、推荐库和 review checklist；同时还可以通过 Skills、hooks、MCP 等方式扩展工作流。([Claude Code][4])
不过这里一定要注意：
AGENTS.md / CLAUDE.md 只是 Harness 的入口，不是 Harness 的全部。
如果只写一堆说明文，但没有测试、日志、权限、评审和自动化验证，Agent 还是很容易出错。
因为自然语言约束，永远不如可执行约束稳定。
二、工具系统：让 Agent 真的能做事
Agent 不是只靠嘴回答问题。
它需要工具。
比如：
读取文件；
搜索代码；
修改文件；
执行 shell 命令；
运行单元测试；
运行接口测试；
启动本地服务；
访问数据库；
读取日志；
打开浏览器；
调用内部平台；
查询需求系统；
创建或更新工单。
这些工具决定了 Agent 能不能真正进入工程流程。
如果没有工具，Agent 只能“猜”。
如果工具太散，Agent 会不知道选哪个。
如果工具没有边界，Agent 又可能做危险操作。
所以工具系统的关键不是越多越好，而是要围绕工作流设计。
比如测试开发场景里，不要给 Agent 暴露一堆零散接口：
查用例；
查环境；
查接口；
查数据；
跑自动化；
查报告；
提缺陷。
更好的方式是封装成更符合任务目标的工具：
执行指定模块回归测试；
生成接口变更影响分析；
基于失败日志定位疑似原因；
根据需求文档生成测试点；
根据 Swagger 生成接口用例；
对某个页面执行 Playwright 验证。
工具越贴近真实工作流，Agent 越不容易乱选。
三、反馈系统：让 Agent 知道自己错在哪里
反馈系统是 Harness 工程里最关键的部分。
因为 Agent 最大的问题，不是不能生成结果，而是不知道结果到底有没有通过真实验证。
反馈系统常见内容包括：
单元测试；
接口测试；
端到端测试；
类型检查；
linter；
静态扫描；
架构测试；
安全扫描；
浏览器自动化；
运行日志；
metrics；
traces；
错误堆栈；
代码评审 Agent；
LLM Judge；
人工 review。
对测试开发同学来说，这部分应该非常熟悉。
因为这就是我们过去一直在做的事情：
把质量标准变成可执行检查。
只不过以前这些检查主要服务于开发团队。
现在它们还要服务于 AI Agent。
如果一个项目没有测试、没有日志、没有自动化检查、没有质量门禁，那么 Agent 改完代码之后，只能“自我感觉良好”。
但如果项目有完整反馈体系，Agent 就可以根据失败信息继续修复。
这就是 Harness 工程和测试开发之间最重要的连接点：
测试体系越完善，Agent 越容易被驾驭。
四、权限和沙箱：让 Agent 有边界地工作
Agent 可以动代码，就一定要有边界。
真实项目里，不能让 Agent 随便：
删除文件；
修改生产配置；
访问敏感数据；
新增高风险依赖；
执行危险命令；
改动核心链路；
绕过测试；
直接操作线上环境。
所以 Harness 工程里必须设计权限和沙箱。
比如：
只允许 Agent 修改指定目录；
敏感文件只能读取，不能修改；
生产配置禁止访问；
数据库操作必须走 Mock 或测试环境；
危险命令需要人工确认；
依赖新增必须 review；
提交 PR 前必须通过 CI；
失败不能强行跳过检查。
这部分对测试开发和质量团队也非常重要。
因为 Agent 时代的质量保障，不只是“结果有没有 bug”，还包括：
它有没有越权；
有没有误改；
有没有跳过验证；
有没有引入供应链风险；
有没有破坏架构边界；
有没有留下不可追溯的变更。
五、Harness 工程和 Prompt 工程有什么区别？
这道题非常容易被面试官追问。
你可以这样回答：
Prompt 工程偏向输入设计，主要解决“这一次怎么让模型回答得更好”。
Harness 工程偏向系统设计，主要解决“怎么让 Agent 在工程环境里长期可靠地工作”。
举个例子。
你在 prompt 里写：
请遵守项目架构，不要跨层调用。
这是 Prompt 工程。
但如果你把架构边界写进 custom linter，每次 Agent 改完代码都会被自动检查，违反规则就失败。
这就是 Harness 工程。
再举一个例子。
你在 prompt 里写：
修改完成后请运行测试。
这仍然只是提示。
但如果系统在 Agent 准备结束任务前，自动要求它执行测试、读取完整输出、失败后重新修复，并把测试结果附在最终报告里。
这就是 Harness 工程。
所以 Prompt 工程和 Harness 工程不是对立关系。
更准确地说：
Prompt 可以是 Harness 的一部分，但 Harness 远远不止 Prompt。
只会写 prompt 的人，可能能把一次回答调好。
但真正要把 Agent 用进复杂项目，必须考虑工具、环境、验证、权限和反馈。
因为真实工程不是靠一句“请仔细检查”就能稳定交付的。
六、为什么软件测试从业者更应该懂 Harness 工程？
很多测试同学看到 AI Agent，会下意识觉得：
这不是开发工具吗？
其实不是。
AI Agent 越深入工程流程，测试开发的价值反而越重要。
原因很简单：
Agent 最缺的不是生成能力，而是验证能力。
它能写代码，但需要有人定义什么叫写对。
它能改页面，但需要有人定义哪些路径必须验证。
它能生成用例，但需要有人判断覆盖是否足够。
它能修 Bug，但需要有人确认有没有引入回归风险。
它能提交 PR，但需要有人把质量门禁自动化。
这恰恰是测试开发最擅长的地方。
过去测试开发关注的是：
自动化测试；
接口测试；
性能测试；
持续集成；
质量门禁；
测试平台；
日志分析；
缺陷定位；
覆盖率分析；
回归策略。
到了 Agent 时代，这些能力不会消失，而是会变成 Agent 的 Harness 能力。
也就是说，测试开发不只是“测 Agent 的结果”，而是要参与设计 Agent 的工作环境。
比如：
你能不能给 Agent 提供稳定的测试入口？
你能不能把业务验收标准变成自动化检查？
你能不能让 Agent 通过日志定位失败原因？
你能不能把 UI 验证接入 Playwright？
你能不能让接口契约、Mock、测试数据自动准备？
你能不能设计一套 Agent 修改后的回归验证策略？
你能不能让质量规则在 PR 前自动执行？
这些都是测试开发可以切入的地方。
所以 Harness 工程对测试人来说，不是一个遥远的新概念。
它更像是：
把测试开发能力升级成 AI Agent 时代的工程基础设施。
七、面试中怎么回答这道题？
如果面试官问：
什么是 Harness 工程？
可以按下面这个结构回答。
一、先给定义
Harness 工程是围绕 AI Agent 构建工作环境的一套工程方法。
它通过上下文、工具、状态管理、沙箱、权限、测试、日志、评审和反馈回路，让 Agent 在真实工程项目中更可靠、更可控地完成任务。
二、再讲背景
以前我们用大模型写代码，更多是一次性交互。
现在 Coding Agent 会读取代码库、修改文件、运行命令、处理错误，甚至参与 PR 和代码评审。
这就要求我们不能只关注模型本身，还要关注模型外部的工程环境。
三、讲它解决的问题
Harness 工程主要解决四类问题。
第一，Agent 缺上下文，所以需要结构化项目知识。
第二，Agent 缺工具，所以要暴露启动、测试、日志、浏览器、数据库、需求系统等工程工具。
第三，Agent 缺反馈，所以要接入测试、linter、静态扫描、日志、metrics、traces 和 review。
第四，Agent 缺边界，所以要通过权限、沙箱、架构规则和质量门禁限制风险。
四、讲核心组成
我会把 Harness 分成两部分：
执行前的引导系统；
执行后的反馈系统。
引导系统包括 AGENTS.md、CLAUDE.md、架构文档、编码规范、启动脚本、测试命令、API 文档、领域知识和任务拆解模板。
反馈系统包括单元测试、接口测试、端到端测试、linter、静态分析、运行日志、metrics、traces、代码评审 Agent 和人工 review。
五、结合测试开发岗位
对测试开发来说，Harness 工程非常重要。
因为测试开发本来就负责构建自动化验证、质量门禁、测试平台、日志分析和反馈体系。
Agent 时代，这些能力会变成 Agent 能否可靠工作的基础设施。
所以我理解的 Harness 工程，不是替代测试，而是把测试开发能力前置到 Agent 的工作闭环里，让 Agent 每次修改都能被验证、被观测、被约束。
八、一个真实项目里怎么落地 Harness 工程？
如果只讲概念，面试官可能觉得你是在背资料。
最好补一个真实落地例子。
比如在一个前后端分离的业务项目里，我们希望 Coding Agent 帮忙修 Bug、改接口、补测试、处理页面问题，可以这样设计 Harness。
具体可以这样落地。
一、用 AGENTS.md 或 CLAUDE.md 做统一入口，告诉 Agent 项目结构、常用命令、关键约束和禁止事项。
二、把详细架构文档放到 docs 目录，让 Agent 按需读取，而不是每次都塞进 prompt。
三、用 linter、类型检查和架构测试限制跨层调用，避免 Agent 改出“能跑但不符合架构”的代码。
四、提供标准化启动脚本，比如 start-backend、start-frontend、run-unit-test、run-api-test。
五、对接口任务接入 Swagger、OpenAPI、Postman Collection 或自动化接口测试。
六、对前端任务接入 Playwright，让 Agent 不只是看代码，而是真的打开页面验证。
七、暴露运行日志、metrics 和 traces，让 Agent 失败后能看到原因，而不是凭空猜。
八、在任务结束前加入 checklist，要求它确认需求点、测试结果、修改范围和风险点。
九、对复杂任务引入独立 Review Agent 或人工 review，避免单 Agent 自说自话。
十、关键仓库必须配置权限和沙箱，限制 Agent 能访问什么、能修改什么、能执行什么命令。
这样一套机制搭起来之后，Agent 就不是“随便帮我改一下代码”的工具，而是进入了一个可控的工程闭环。
九、写在最后
很多人看到 Harness 工程，会觉得这是不是又来了一个新概念。
但如果你是测试开发从业者，其实不用太焦虑。
因为 Harness 工程背后的很多能力，本来就是测试开发一直在做的事情。
比如：
自动化测试；
质量门禁；
日志观测；
测试数据准备；
接口契约验证；
CI/CD 流水线；
缺陷定位；
回归验证；
评审流程；
测试平台建设。
只不过过去这些能力主要服务于人。
到了 Agent 时代，这些能力还要服务于 AI。
未来工程团队的核心竞争力，可能不只是“谁更会用 AI 写代码”，而是：
谁能把 AI 放进一套稳定、可验证、可观测、可回滚的工程体系里。
所以 Harness 工程不是要替代工程师。
它真正的意义，是把过去依赖老员工经验、口头约定和人工兜底的东西，变成 Agent 也能理解、执行和验证的工程机制。
对于测试开发来说，这反而是一个很重要的机会。
因为 Agent 越会写代码，团队就越需要有人设计验证体系。
Agent 越能自动修改，团队就越需要有人设计质量边界。
Agent 越深入研发流程，测试开发就越不能只停留在“执行测试”的角色，而要往“质量基础设施”和“Agent 工程环境设计”上升级。
如果面试官问你：
为什么测试开发要懂 Harness 工程？
你可以这样收尾：
因为 AI Agent 时代，质量保障不只是测试最后的结果，而是要嵌入 Agent 的整个工作过程。Harness 工程就是把上下文、工具、权限、测试、日志和评审连接起来，让 Agent 在真实工程里可控地完成任务。测试开发如果能设计好这套反馈和验证体系，就能从测试执行者升级为 Agent 时代的质量基础设施建设者。
这才是这道题真正想考察的点。
推荐学习
还在手工写用例？RAG+知识图谱+GraphRAG三大技术，从文档解析到可执行用例全链路打通。基于搜索、向量、图谱的三种用例生成技能，直接落地自动化测试。来学社，把AI测试能力变成你的核心竞争力。
👉 扫码进群，报名学习！
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。
学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。
我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。
在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。
同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。