测试开发为何被称为原始Harness

做了将近四年的测试开发工程师，我深刻理解质量保障的核心。

在一家互联网大厂的AI团队，我每天的工作就是为大模型的在线服务搭建测试基础设施——包括测试框架、Mock系统、断言体系以及压测平台。听起来这很符合"测试"的传统定义，对吧？

但最近一年，AI Agent领域涌现出一个备受关注的热词：Harness Engineering。

业界公认的核心公式是 Agent = Model + Harness——模型提供推理能力，而Harness则包含了模型之外的一切要素：系统提示词、工具接口、沙箱环境、编排逻辑、反馈循环以及可观测性。引用腾讯云社区的观点，Harness之于Model，如同操作系统之于CPU——无论CPU的性能多么强大，如果操作系统频繁崩溃，用户体验依然会很差。

在2025至2026年间，OpenAI、Anthropic、LangChain以及Martin Fowler团队各自发布了相关研究，最终得出了相同的结论：环境质量对Agent输出的影响，其重要性甚至超过了模型能力或Prompt技巧。Harness Engineering正是在这一共识的基础上，逐渐成为一门系统化的工程学科。

当我第一次看到这个概念时，感到一阵熟悉。

这不正是我每天在做的事情吗？

AI领域的公式是 Agent = Model + Harness——模型负责推理，Harness则是一个完整的工程系统来包裹模型。而在测试领域，同样存在一个等价的公式：稳定的服务 = 被测服务 + 测试保障体系。被测服务是核心能力，而测试框架、测试流程以及产研效能共同构成了包裹它的Harness。这两个公式是同构的：Model对应的是被测服务，Harness对应的是测试保障体系，而Agent则对应最终交付的稳定服务。

这里有一个关键问题：尽管Harness在AI Agent领域被当作一个全新的概念来推广，但测试工程师群体早就在实践中构建了结构完全相同的工程体系。如果我们不主动建立这种同构关系的认知连接，测试工程师就会在AI浪潮中逐渐失去话语权——明明做着相同的事情，却可能被排除在新叙事之外。

因此，本文将围绕一个核心观点展开：测试开发，就是最初的Harness Engineering。

测试开发的日常，就是Harness Engineering的最佳实践

传统测试开发的工作远不止"编写测试用例"这么简单。一个测试开发工程师的日常工作，通常覆盖三个核心板块：

测试流程设计与执行——从参与需求评审、技术评审，到主导测试评审、制定测试方案、设计和编写测试用例、执行测试、跟踪上线进度、关注线上监控数据以及进行事后复盘。测试工程师是质量的守门人，贯穿一个需求从提出到上线的完整生命周期。

测试效能提升——搭建并维护CICD流水线，开发流水线中各环节的自动化工具；建设功能测试框架、性能测试平台以及Mock服务；推进覆盖率分析、Diff测试、线上监控配置等。目标是让测试从手工劳动中解放出来，用工程化的手段来保障质量。

产研效能提升——配合产品和研发的需求，开发各种提效工具。例如，信息查询工具帮助研发快速定位问题，测试执行机器人自动完成重复性验证任务，数据构造工具批量生成测试数据。这些工具虽然不完全属于"测试"范畴，但它们是研发效能提升的重要组成部分。

回顾这些工作，会发现一个很有趣的事实：我们一直在构建一个系统，让"执行者"在受控环境中能够可靠地完成任务。这正是AI Agent领域所说的Harness。

当我第一次看到Harness Engineering的定义——模型之外的一切：系统提示词、工具接口、沙箱环境、编排逻辑、反馈循环、可观测性——我意识到这和测试开发的工作内容高度重合。同一个模型，仅仅改变Harness的设计，编码基准测试分数就能从6.7%跃升至68.3%。Harness的核心架构包含了上下文管理、架构约束、反馈循环和熵管理等关键支柱，而这些支柱与测试开发的日常实践之间，存在着近乎结构性的对应关系。

再回看那三个板块，每个板块都同时体现了Harness的四大支柱：

结论非常清晰：测试开发在实践中已经覆盖了Harness Engineering的全部四大支柱。我们并非"借鉴"了Harness，我们本就是Harness的原始实践者。

一个真实项目：用Harness思维搭建高效测试基础设施

光讲理论是不够的。下面通过一个真实的项目，展示测试开发中的Harness实践到底是什么样子。

一个复杂的AI调度系统

我接手的是一个大型大模型调度系统的测试体系建设。这个系统有几个显著特点：

• 下游依赖众多，多达31个子系统需要Mock
• 协议复杂，涵盖了HTTP、gRPC（一元调用/双向流式/服务端流式）、SSE、异步轮询等多种形式
• 业务迭代速度快，每次需求变更都需要快速完成验证

在接手之前，测试代码分散在各个仓库中，没有统一的框架，每个接口的测试方式都不一致。每次上线前，QA团队都需要花费大量时间进行手工验证。

核心问题是：如何搭建一个统一的测试基础设施，让不同业务方向的研发人员都能快速接入，并独立完成测试？

四层Test Harness架构

我设计了一套四层架构：

这四层并非凭空想出来的。每一层都对应着Harness工程的一个核心关注点：

接口层 = 上下文工程。它负责搞清楚"当前测试需要什么协议上下文"，并自动适配HTTP、gRPC还是SSE，让上层的引擎和用例无需关心具体的协议细节。

引擎层 = 架构约束。引擎通过注册表动态加载，每种测试类型都有且只有一种引擎实现。引擎之间通过上下文传递数据，不允许直接相互调用。这正是Harness中"让Agent在正确的轨道上运行"在测试领域的对应版本。

数据层 + 工具层 = 反馈循环。用例定义了"什么是对的"，断言工具验证"实际是不是对的"，Mock服务则保证"测试环境的行为是可预测的"。

坑一：31个下游依赖的Mock收敛

最开始，每个下游依赖各自维护着自己的Mock代码。结果呢？31个子系统意味着有31套不同的Mock逻辑，版本不一致、行为不一致、维护成本爆炸式增长。

踩过的坑：我试图让每个团队自己维护各自的Mock。结果根本没人愿意维护，Mock规则过期了也无人知晓，导致测试结果不再可信。

解决方案：将Mock逻辑收敛为单进程Mock服务。

# FastAPI Mock 服务示例（Python 3.10+, FastAPI 0.104+）from fastapi import FastAPIfrom pydantic import BaseModelapp = FastAPI()class MockRule(BaseModel):service: strendpoint: strresponse: dictconditions: dict = {}@app.post("/mock/rules")async def add_rule(rule: MockRule):"""添加 Mock 规则，支持远程热更新"""rules_db.upsert(rule)return {"status": "ok"}@app.post("/mock/record/{service}")async record_traffic(service: str):"""录制真实流量，用于回放"""recorder.start(service)return {"status": "recording"}

我们将Mock规则变成了代码，实现了版本化管理，并配备了PR审查流程。这其实就是Harness中的熵管理——如果放任Mock代码分散生长，系统必然会走向混乱。必须有一个集中的地方进行管理，设置写入门槛，并定期精简条件。

坑二：用注册表优雅解决多协议适配难题

gRPC的测试方式和HTTP完全不同。一元调用看起来像HTTP，但双向流式需要管理连接的生命周期，服务端流式则需要逐条接收消息。SSE是长连接，测试框架不能在第一个消息到达后就关闭连接。异步任务需要轮询，测试框架必须能够等待任务完成并检查中间状态。

踩过的坑：一开始我试图用一个通用的测试引擎来处理所有协议。结果导致代码里充满了if-else判断，每增加一种协议就多一层嵌套。

解决方案：回归到架构约束的思路。每种协议对应一个engine实现，通过注册表进行动态加载。每个引擎只关心自己的协议，不关心其他引擎的工作方式。

# 注册表：每种协议注册对应的引擎# Python 3.10+, pytest 7.xENGINE_REGISTRY = {"http": HTTPEngine, # requests 2.31+"grpc_unary": GRPCUnaryEngine,# grpcio 1.60+"grpc_stream": GRPCStreamEngine,"sse": SSEEngine, # sseclient-py 1.8+"async_poll": AsyncPollEngine,}# 运行时根据接口定义自动选择引擎engine = ENGINE_REGISTRY[interface.protocol](context)result = engine.execute(test_case)

效果：从2小时缩短到10分钟

完成搭建后，测试环境的搭建时间从原来的约2小时大幅缩短到了10分钟。研发人员可以独立完成核心接口的测试验证，QA团队也从重复性的手工劳动中解放了出来。

更重要的是，这套架构让"AI自测"成为了可能——在定义好Skill模板后，AI能够根据需求描述自动生成测试用例并执行，因为我们已经用Harness的方式将测试上下文、约束和反馈循环都准备就绪了。

你做的事比你以为的更加重要

回过头来看，测试开发与Harness Engineering之间的对应关系绝非巧合。

最本质的原因在于：两者都在解决同一个核心问题——如何让一个"执行者"（无论是测试用例还是AI Agent）在受控的环境中可靠地完成任务。

测试工程师天然具备Harness思维，因为我们每天都在与"不确定性"打交道。测试框架需要消除环境的不确定性（通过Mock），消除执行的不确定性（通过架构约束），消除结果的不确定性（通过断言反馈），还要消除自身的不确定性（通过熵管理）。

但我们也需要诚实地面对一些局限性：

第一，传统测试开发的Harness是"面向确定性"的。测试用例的行为是可预测的——输入A，期望输出B。然而，AI Agent的行为具有概率性，Harness需要处理更多的不确定性。这意味着测试工程师的Harness经验不能直接照搬，而需要进一步的进化。

第二，测试开发往往缺少对"上下文工程"的显式设计。我们确实做了上下文管理，但通常是隐式的——散落在框架代码和配置文件里。Harness Engineering将它提升到了第一性原理的高度，这非常值得测试工程师学习和借鉴。

第三，这个叙事对测试工程师群体具有重要的战略价值。在AI浪潮中，"测试开发"这个岗位的叙事正在被逐渐稀释——"AI都能写测试了，还需要测试开发吗？"但如果测试工程师能够清晰地说明"我们一直在做Harness Engineering，我们是这个领域最早的一批实践者"，那么叙事权就会重新回到我们自己手中。

这就是我写这篇文章的初衷。并非为了争夺某个概念的归属权，而是为了帮助测试工程师群体建立一个更加有力的自我叙事：

作为Harness的原始实践者，你所做的事情比你认为的更加重要。

与诸君共勉。

参考来源：

1. 腾讯云社区《Harness Engineering 深度研究报告》 — Mitchell Hashimoto 对 Harness Engineering 的操作性定义、Agent = Model + Harness 核心公式、数据引用（wuyangming 整理，2026-05-31）
2. AI Void Field Guide, Harness Engineering for AI Coding Agents: A Practical Guide — 六大组件定义、四大支柱框架（2026-06-18）
3. AgentPatterns.ai, Harness Engineering for Building Reliable AI Agents — 环境质量对 Agent 输出影响的收敛结论
4. SemaClaw 论文（arXiv:2604.11548） — Midea AIRC，Harness Engineering 学术定义（2026-04-13）