從 Harness Engineering 看 Agent 工程化落地的關鍵問題

简介： 本文探讨AI Agent在真实项目中落地难的根源，指出问题不在模型能力，而在于缺乏工程化保障——即Harness Engineering（智能体工程化）。它通过环境约束、可观测性、质量验证等机制，确保Agent可靠执行任务。对测试工程师而言，需从“测软件”转向“测Agent”，关注执行合规性、权限安全与结果可复现性。

一个 AI Agent，在演示环境里可以自动分析需求、生成代码、调用工具，甚至完成一轮自动化测试。

但把它接入真实项目，情况就不一样了。

测试账号过期，它反复尝试登录；页面元素发生变化，它不断生成新的定位表达式；自动化脚本执行失败，它没有检查失败原因，反而直接修改代码；任务执行到最后，测试报告生成了，实际断言却没有跑完。

这种情况在 Agent 项目中并不少见。

很多团队最初会把问题归结为模型能力不足，于是换模型、调 Prompt、增加工具，甚至重新设计整套工作流。折腾一圈，Agent 还是会犯相似的错误。

问题出在哪里？

2026 年，OpenAI、Anthropic、LangChain 等团队陆续公开了自己的 Agent 工程实践，一个值得关注的技术方向逐渐进入开发者视野：Harness Engineering（智能体工程化）。

它关注是怎样让模型在真实的软件工程环境中完成任务，并且能够被约束、被观察、被验证。

这件事和软件测试有什么关系？

一、Harness Engineering 究竟在解决什么问题？
先看一个简单的例子。

我们准备开发一个 AI 自动化测试 Agent，要求它根据用户输入的业务需求，自动完成以下工作：

分析业务需求，拆分测试场景。
生成 Playwright 自动化测试脚本。
调用浏览器执行测试。
根据页面反馈和执行日志分析失败原因。
修复可自动修复的问题。
重新执行测试并生成报告。
如果只使用大模型加一段 Prompt，理论上也能完成部分工作。

但真实项目还需要处理浏览器环境、测试账号、登录状态、测试数据、脚本执行权限、异常恢复、测试报告等问题。

模型本身不会自动拥有这些能力。

Harness 就是围绕 Agent 建立的运行环境和工程机制。它负责把模型、上下文、工具、记忆、权限、执行环境和质量评估连接起来。

图片
AI Agent 的 Harness 工程架构
这套架构没有统一的标准答案，不同团队会根据业务场景选择不同的组件。

例如，做代码开发的 Agent，需要关注代码仓库、终端、文件修改和代码审查；做自动化测试的 Agent，则需要重点考虑浏览器控制、测试数据、执行环境和结果验证。

不要把 Harness 理解成某个新框架。它更像一套围绕 Agent 建立的工程运行机制。

二、为什么很多 Agent 项目，越做越复杂？
我把实际工程落地中值得警惕的问题归纳为三个层面。

1. Prompt 写得越来越长，执行能力却没有同步提升
   不少团队优化 Agent，首先想到的就是修改 System Prompt。

原来只有几百字，后来逐渐增加到几千字，里面写满了任务要求、操作步骤、异常处理和输出规范。

比如：

修改文件前必须备份。
执行脚本前必须检查依赖。
测试失败后必须分析原因。
不允许修改指定目录。
任务结束前必须执行回归测试。
这些要求都合理，但有个问题：写在提示词里，不代表模型每次都能严格执行。

假设我们要求 Agent 修改自动化测试脚本之前必须备份文件。

仅仅告诉它「请先备份」，并不能保证备份操作真的发生。

更可靠的做法是提供备份工具，或者在文件修改接口中增加前置检查。没有完成备份，就不允许继续修改。

两种方式的差别很明显：

Prompt 告诉模型应该怎么做。
工程约束决定模型能不能绕过这项要求。
当一项规则涉及数据安全、权限或关键操作时，不能只寄希望于模型记住它。

1. 把 LangGraph、LangChain 当成完整的 Harness
   LangChain、LangGraph、CrewAI 都是常见的 Agent 开发工具。

以 LangGraph 为例，可以把一个自动化测试任务拆成多个节点：

工作流看起来已经很完整了。

但真正运行时，还会遇到不少框架本身无法替你解决的问题：

浏览器进程意外退出，谁负责重新启动？
测试账号失效，如何识别并处理？
数据库连接失败，是否允许重试？
Agent 修改了错误的文件，如何拦截？
任务执行到一半服务重启，能否恢复进度？
LangGraph 可以承担流程编排，Playwright 可以完成浏览器操作，MCP 可以连接外部工具。

但项目的权限策略、执行隔离、状态持久化和质量验收，仍然需要开发团队自己设计。

工具选型只是开始，后面的工程工作一点也不少。

1. Agent 记住了很多信息，却不一定记对了
   记忆系统也是一个容易被低估的模块。

很多团队给 Agent 接入向量数据库，把历史对话、项目文档和执行记录全部存进去，就认为解决了长期记忆问题。

实际运行时，麻烦才刚刚开始。

例如：

项目 A 使用 Java + TestNG，项目 B 使用 Python + Pytest。

项目 A 曾经使用过一个测试环境地址，但三个月前已经废弃。

某次 Agent 分析接口问题时，模型推测了一个原因，这条推测又被写进了长期记忆。

下一次执行任务，Agent 检索到了这些信息，并将它们当成当前项目的有效配置。

这类问题很难靠增加向量检索数量解决。

记忆至少需要区分：

记忆类型
保存内容
管理要求
会话记忆
当前任务进度、中间结果
任务结束后按策略清理
项目记忆
接口规范、技术栈、环境配置
按项目隔离，及时更新
团队记忆
编码规范、测试标准
统一维护，保留版本
还应该记录信息来源、更新时间和可信程度。

用户明确确认过的业务规则，和模型根据上下文推测出来的内容，不能使用同样的可信等级。

1. Agent 效果不好，第一反应就是换模型
   这是一个很典型的技术决策问题。

同样一个 Agent，换模型可能有效，但也可能只是增加成本，没有解决原来的问题。

2026 年 2 月，LangChain 公布了一项很有参考价值的实验。

他们使用 GPT-5.2-Codex，在保持模型不变的情况下，调整 Agent 的 System Prompt、Tools 和 Middleware，将 Terminal-Bench 2.0 的成绩从52.8%提升到了66.5%，提高了13.7个百分点。

来源：LangChain，2026-02-17。实验结果不代表所有 Agent 场景都能获得同等提升。

这个实验值得测试开发人员关注。

如果一个接口测试 Agent 经常执行失败，先看它有没有拿到正确的接口文档、工具是否正常返回、测试数据是否准备好、断言是否完整。

不要一看到失败就升级模型。

模型能力当然重要，但在很多工程场景中，工具质量、上下文完整性和执行反馈同样会影响最终结果。

1. Agent 执行过程没有记录，出了问题就无法复盘
   传统自动化测试，我们会保留请求响应、日志、截图、执行时间和错误堆栈。

AI Agent 需要记录的东西更多。

一次任务可能涉及十几次模型调用和工具调用。如果最终只保留一个 PASS 或 FAIL，出了问题基本无从排查。

以 Playwright Agent 为例，建议保留以下信息：

记录类别
具体内容
模型调用
模型版本、输入输出、Token 消耗
工具调用
工具名称、参数、返回值
浏览器状态
URL、页面快照、截图
执行轨迹
操作顺序、任务状态、重试次数
异常信息
Console、Network、超时、错误堆栈
测试结果
断言结果、Trace、最终报告
这里可以结合 OpenTelemetry、LangSmith 等工具建设追踪体系。

尤其要注意，模型输入输出和工具参数可能包含账号、密钥或业务数据，记录时需要做好脱敏和访问控制。

AI Agent 的执行追踪与故障定位
图2：AI Agent 的执行追踪与故障定位

Agent 出错之后，工程师应该能够还原它看到了什么、调用了什么、得到了什么结果，而不是重新运行一遍碰运气。

1. 让 Agent 自己给自己打分，质量很难有保障
   AI 写完代码，再问它一句「你觉得这段代码有没有问题」，这种自检有一定价值，但不能作为最终验收。

Anthropic 在2026年3月公开了一项长周期应用开发实验。

其中采用了 Planner、Generator、Evaluator 三类 Agent：

Planner 负责拆分任务。
Generator 负责生成应用。
Evaluator 负责检查生成结果。
评估器还会通过 Playwright MCP 实际操作运行中的页面，检查功能、API 和数据库状态，而不是只阅读生成器给出的解释。

这套设计很适合借鉴到 AI 测试平台。

比如：

生成 Agent 负责写测试脚本，评估模块负责独立执行脚本、检查断言、验证实际页面状态。

如果测试脚本写得很漂亮，但运行后发现断言根本没有覆盖目标业务，就不能算完成任务。

当然，评估 Agent 本身也需要校准。它的评分标准应该尽量落到真实执行证据上，而不是再让另一个模型主观判断。

1. 测试 Agent 只看最终通过率，会漏掉很多问题
   假设一个 Agent 接到任务：

「修改登录模块之前，先备份原文件，再修改代码，最后执行回归测试。」

它最终确实把代码修改好了，测试也通过了。

但它中间跳过了备份。

如果评估系统只检查代码是否正确、测试是否通过，这次任务就会被判定为成功。

MiniMax 在2026年发布的 OctoCodingBench，专门研究了 Coding Agent 执行过程中的规范遵循情况。

它使用两个指标：

CSR：单项规则的遵循比例。
ISR：一次任务中全部规则都得到遵循的比例。
在其公布的榜单中，Claude 4.5 Opus 的 CSR 为91.2%，ISR 为36.2%。也就是说，单项规则遵循率较高，并不代表一次任务能够同时满足所有要求。

这个区别很重要。

软件测试人员过去主要关心功能是否正确，现在还要检查 Agent 有没有按要求完成操作。

例如：

是否跳过了规定的测试步骤？
是否调用了不允许使用的工具？
是否修改了授权范围之外的文件？
是否在没有验证的情况下报告成功？
是否在失败后正确保留了现场？
一个最终结果正确、但执行过程违反工程规范的 Agent，仍然存在质量风险。

1. 复制别人的 AGENTS.md，不代表自己的项目就有了工程规范
   OpenAI 在2026年2月公开的 Harness Engineering 实践中，介绍了他们如何利用代码仓库承载 Agent 所需的项目知识。

他们的实验中，Codex 不仅生成业务代码，也参与生成测试、CI 配置、文档、可观测性和内部工具。

团队强调，项目架构、开发规范和关键约束应该能够被 Agent 在仓库中发现，并且重要规则应该通过静态检查、结构测试等机制落实。

这给了我们一个很实际的启发。

AGENTS.md、CLAUDE.md 这些文件，不应该成为所有项目规范的简单堆积地。

比如一个 Playwright 项目，可以将规则拆分为：

project/
│
├── AGENTS.md
│
├── docs/
│ ├── architecture.md
│ ├── api-specification.md
│ └── test-strategy.md
│
├── skills/
│ ├── api-test/
│ ├── ui-test/
│ └── bug-analysis/
│
├── tests/
│ ├── api/
│ └── e2e/
│
└── reports/
入口文件告诉 Agent 项目如何组织、执行任务时应该读取哪些资料；具体规则放在对应文档和 Skill 中。

项目不同，规范也应该不同。

一个金融系统的测试 Agent，需要关注数据权限、操作审计和测试数据安全；一个普通 Web 项目，则可能更关注浏览器兼容性、页面交互和接口覆盖。

直接复制别人的配置，往往会把不适用的规则也带进来。

1. Harness 设计完成后，就不再需要调整了？
   这个想法也不现实。

模型版本会更新，工具能力会变化，项目架构也会演进。

Anthropic 在长周期 Agent 研究中就提供了一个很有意思的例子。

早期使用 Sonnet 4.5 时，他们需要通过上下文重置和任务交接机制，帮助 Agent 在长任务中维持执行方向。

后来切换到 Opus 4.5，发现模型自身已经能够更好地处理上下文增长，原来的一部分重置机制便不再需要。

这说明 Harness 不是规则越多越好。

今天有效的控制机制，随着模型能力提升，可能变成额外的复杂度。

工程团队应该定期检查：

哪些规则仍然有效？
哪些工具已经不再需要？
哪些约束可以交给程序执行？
哪些机制已经被模型自身能力覆盖？
新出现的失败模式是否需要加入回归评测？
不要把过去解决问题时增加的所有配置，永久留在系统里。

三、企业落地，还有两个问题不能回避

1. 只要求 Agent 遵守规范，却没有要求团队遵守工程规范
   这件事在企业里很容易被忽略。

假设产品经理给出的需求只有一句话，验收标准没有明确；开发人员没有提供接口文档；测试环境也没有准备好。

团队却希望 AI Agent 自动分析需求、生成用例、执行测试，最后给出一份准确的测试报告。

这很难实现。

Agent 不是业务需求的创造者，也不能凭空补齐团队没有提供的信息。

需求评审、接口规范、测试数据管理、代码审查、质量门禁，这些基础工作仍然需要有人负责。

如果团队原本就没有统一的工程标准，Agent 只会让不同人的工作方式更快地被复制出来。

1. 企业权限和安全机制，不能等 Agent 上线后再补
   个人开发环境和企业生产环境有很大区别。

一个测试 Agent 可能需要访问代码仓库、测试数据库、接口平台、内部文档和 CI/CD 系统。

假设它拥有数据库写权限，在分析测试数据时错误地连接了生产库，后果就不只是一次测试失败了。

企业级 Harness 应该从一开始就考虑这些问题：

管控项目
需要解决的问题
身份认证
当前是谁在发起任务？
项目权限
Agent 能访问哪些项目？
数据权限
能查询、修改哪些数据？
操作审批
删除、发布等高风险操作是否需要确认？
环境隔离
能否避免测试任务误操作生产环境？
审计追踪
谁发起了任务，Agent 执行了什么？
异常恢复
任务失败后能否恢复现场？
尤其是企业内部的多项目、多角色场景，不能让所有 Agent 使用同一套无限制权限。

Agent 可以拥有执行能力，但执行范围必须由系统控制，而不是由模型自己决定。

四、软件测试工程师，接下来要测试的不只是软件
把上面的11个问题放在一起看，会发现 Agent 工程化和传统自动化测试之间存在很多联系。

过去，我们关注的是：

页面功能是否正常？
接口响应是否正确？
数据库结果是否符合预期？
自动化脚本能否稳定执行？
现在，AI Agent 也成为了新的测试对象。

一个测试 Agent 即使能够生成脚本，也要验证它有没有理解正确的需求；即使能够调用 Playwright，也要验证它有没有选对页面元素；即使生成了测试报告，也要确认报告中的结果确实来自真实执行。

可以把新的测试范围整理成下面这张图。

图片
AI Agent 测试质量评估体系
图3：AI Agent 测试质量评估体系

求解析准确率任务拆分合理性工具选择准确性参数及返回值处理执行规范遵循异常恢复能力上下文连续性断言正确性结果可复现测试证据完整性权限边界数据安全操作审计

如果团队正在建设 AI 测试平台，我建议优先把以下几项指标纳入评估：

指标
评估内容
任务完成率
Agent 是否完成指定任务
工具调用成功率
工具选择、参数和执行是否正确
过程合规率
是否遵循任务和项目规范
异常恢复率
遇到错误后能否正确恢复
结果准确率
最终结果是否符合业务预期
权限安全性
是否发生越权操作
执行成本
Token、耗时和工具调用成本
这些指标需要结合具体业务场景设计，不能简单用一个综合分数代替所有质量判断。

对于软件测试人员来说，接下来值得投入时间的技术方向也会发生变化：

Playwright、Selenium 等自动化测试技术仍然重要。
MCP、Skills 和工具调用需要理解。
LangGraph 等 Agent 编排技术需要掌握。
RAG、Memory 和上下文管理需要了解。
Agent 评测、Trace 和异常诊断需要具备实践能力。
企业权限、安全和审计机制也会逐渐进入测试范围。
不一定每个测试工程师都要成为大模型开发者，但至少要知道 Agent 是怎么执行任务的，哪些地方可能出错，以及如何证明它的结果可信。

写在最后
我一直认为，软件测试的核心工作不是证明系统能够运行，而是尽可能找到它在什么条件下会出问题。

AI Agent 也是一样。

Demo 能跑通，只能证明它在当前演示条件下完成了任务。换一个用户、换一套测试数据、换一个浏览器环境，甚至增加一个异常分支，都可能暴露出新的问题。

Harness Engineering 把这些原本容易被忽略的工程环节重新摆到了台面上：上下文从哪里来，工具能做什么，任务如何恢复，结果由谁验证，出了问题如何追踪。

模型会继续升级，Agent 能做的事情也会越来越多。

但一个团队如果没有测试标准、没有权限边界、没有执行记录，也没有独立验收机制，那么模型能力越强，错误执行的影响范围可能越大。

AI Agent 可以替人执行越来越多的工作，但工程团队必须始终掌握验证结果的能力。

这才是 Harness Engineering 对软件测试行业最值得关注的地方。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。