为什么我认为测试开发是原始的 Harness

我做了将近四年的测试开发。

在一家互联网大厂的 AI 团队，我的工作是给大模型在线服务搭建测试基础设施------测试框架、Mock 系统、断言体系、压测平台。听起来很"测试"，对吧？

但最近一年，AI Agent 领域出现了一个热词：Harness Engineering。

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

OpenAI、Anthropic、LangChain 和 Martin Fowler 团队在 2025-2026 年间各自发布研究，最终收敛到同一个结论：环境质量对 Agent 输出的影响，大于模型能力或 Prompt 技巧。Harness Engineering 正是在这个共识下被系统化的工程学科。

我第一次看到这个概念的时候，愣了一下。

这不是我一直在做的事吗？

AI 领域说 Agent = Model + Harness ------模型提供推理能力，Harness 是包裹模型的完整工程系统。测试领域也有一个等价的公式：稳定的服务 = 被测服务 + 测试保障体系。被测服务是核心能力，测试框架、测试流程、产研效能构成了包裹它的 Harness。两组公式是同构的：Model 对应被测服务，Harness 对应测试保障体系，Agent 对应最终交付的稳定服务。

我遇到了一个问题：Harness 在 AI Agent 领域被当作一个全新概念来推广，但测试工程师群体早已在实践中构建了结构相同的工程体系。如果我们不主动建立这个同构关系的连接，测试工程师就会在 AI 浪潮中失去话语权------明明你做的就是同一件事，却被排除在叙事之外。

所以这篇文章，我想聊聊：为什么我认为测试开发是最初的 Harness。

测试开发的日常，就是 Harness Engineering

传统测试开发的工作远不只是"写测试用例"。一个测试开发工程师的日常，大致覆盖三个板块：

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

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

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

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

当我第一次看到 Harness Engineering 的定义------模型之外的一切：系统提示词、工具接口、沙箱环境、编排逻辑、反馈循环、可观测性------我意识到这和测试开发的工作内容高度重合。同一个模型，仅改变 Harness 设计，编码基准测试分数可以从 6.7% 跃升至 68.3%。Harness 的核心架构包含上下文管理、架构约束、反馈循环和熵管理等支柱，而这些支柱和测试开发的日常实践之间，存在一种几乎是结构性的对应。（如果大家有兴趣，后面我会专门写一下我对 Harness 这四大支柱的理解。）

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

	架构约束	上下文管理	反馈循环	熵管理
测试流程	规范的流程约束产品节奏和人为操作，防止因不规范操作导致质量问题	测试前置到需求、后置到上线观测，每个阶段有明确的输入输出，像渐进式披露的上下文	线上问题通过 Case Study 反哺流程调整，形成新的约束	实践中废弃无用流程、引入新流程，保持流程有效性
测试效能	框架分层架构（interface/engine/data/utils）定义代码边界，CI 强制校验	框架按协议类型和测试场景自动加载对应上下文（L0/L1/L2）	四层断言体系（通用校验、链路追踪、服务调用、请求级别）即时反馈对错	定期清理失效用例、精简冗余断言、合并重复测试场景
产研效能	工具接口规范和使用边界（查询工具限定查询范围，机器人限定触发条件）	工具按使用者角色提供差异化信息（产品看需求状态，研发看覆盖率）	工具使用数据本身就是反馈（哪些功能用得多、哪些没人用）	定期评估工具有效性，下线低频工具，合并功能重叠的工具

结论很清晰：测试开发在实践中已经覆盖了 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 服务。

python 复制代码

# FastAPI Mock 服务示例（Python 3.10+, FastAPI 0.104+）
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class MockRule(BaseModel):
    service: str
    endpoint: str
    response: dict
    conditions: 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 def record_traffic(service: str):
    """录制真实流量，用于回放"""
    recorder.start(service)
    return {"status": "recording"}

Mock 规则变成代码，版本化管理，有 PR 审查流程。这其实就是 Harness 中的熵管理------如果放任 Mock 代码分散生长，系统必然走向混乱。必须有一个集中的地方管理，有写入门槛，有精简条件。

坑二：用注册表解决多协议适配

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

我踩的坑：一开始试图用一个通用的测试引擎处理所有协议。结果？代码里全是 if-else，每加一种协议就多一层嵌套。

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

python 复制代码

# 注册表：每种协议注册对应的引擎
# Python 3.10+, pytest 7.x
ENGINE_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 的原始实践者，你做的事比你以为的更重要。

诸君共勉。

参考来源：

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