DeepSeek Harness给软件测试工程师的启发：从生成用例走向可验证闭环

这篇文章把 DeepSeek Harness 当作一个观察样本。要讨论的不是某个模型写得好不好，而是：当一个 AI 不再只是“给建议”，而是被装进一个能观察、能执行、能校验、能安全停止的系统之后，软件测试的玩法会怎么变。全文围绕一条主线展开——测试工程师的设计对象，如何从“生成用例”走向“设计可验证闭环”。

---

一、先说结论：真正值得测试工程师关注的，不是“又一个会写用例的 AI”

如果只把 DeepSeek Harness 理解成“给 DeepSeek 模型套了一个界面”，很容易错过重点。

模型擅长理解和生成，但软件测试不是一道答完就结束的问答题。一个真实测试任务通常要经历：读需求、查代码和接口、准备环境与数据、执行、观察结果、区分环境问题和产品缺陷、补充证据、选择回归范围，最后还要把风险交接给团队。中间任何一步拿不到真实反馈，最终报告都可能只是“看起来合理”。

Harness 的价值，正是把模型放进一个受控的工作系统：

目标与约束
    ↓
模型判断下一步
    ↓
调用被授权的工具
    ↓
环境返回真实结果
    ↓
结果进入会话与上下文
    ↓
模型修正计划、继续执行或请求人工决定
    ↓
由可验证证据触发停止

对测试工程师来说，最重要的启发可以浓缩成一句话：

不要只优化“AI 生成了多少条测试用例”，而要设计一个能观察、能执行、能校验、能追责、能安全停止的测试闭环。

---

二、哪些是 DeepSeek 官方已经说明的，哪些只是工程推论

先把事实和推论分开，避免把一个刚开放预览的项目写成已经成熟落地的平台。

已核实的官方信息

截至本文整理时，DeepSeek 官方仓库明确说明：

• DeepSeek Harness（命令名 dsh）是由 DeepSeek AI 开发的开源 agent harness，采用 MIT 许可证；
• 它由 Cordis 驱动，核心设计是“一切皆插件”；
• 官方将它标记为 Developer Preview，项目仍在快速迭代，并明确提示未来会有破坏兼容性的变化；
• 模型适配器、工具注册、会话日志和 agent loop 本身都被设计成可替换的插件；
• 官方架构包含持久化、沙箱、审批策略、设置、凭据和遥测等能力；
• 一次 step 包含一次模型请求及其工具调用，一次 turn 可以包含多个 step；工具调用经过执行前、执行中、执行后的管线，结果会写入会话事件；
• 会话日志采用追加式事件记录，并作为模型上下文、恢复、转录、遥测等能力的事实来源；
• 当前 Web UI 可以配置模型、选择工作区并发起任务；官方指南称 agent 可在权限策略约束下读取或编辑文件、执行命令、委派工作和维护计划。

这些信息能够证明它已经提供了一个可扩展的智能体运行框架，但不能证明它已经适合企业测试生产环境。

本文基于上述机制做出的通用工程推论

下面这些观点不是 DeepSeek 官方承诺，而是对 Agent/Harness 架构迁移到测试领域后的工程判断：

• 可以把需求、代码差异、接口契约、历史缺陷和执行日志组织成测试上下文；
• 可以通过工具插件连接需求平台、测试环境、API 客户端、浏览器自动化、日志平台和缺陷系统；
• 可以把测试执行结果送回模型，形成“设计—执行—观察—修正—验证”的闭环；
• 可以用沙箱、审批、最小权限和事件日志约束测试智能体；
• 可以把每次测试过程沉淀为可审计的证据包，辅助回归与交接。

能不能做好这些事，取决于团队自己的工具、数据质量、权限模型、测试判定标准和评估体系。DeepSeek Harness 的插件化架构提供了实现空间，但没有替团队完成这些工程建设。

---

三、Harness 的四个关键机制

本节把官方架构事实和工程推论放在一起讲：涉及 Harness 已有机制的部分以官方文档为依据，涉及测试工程落地的处理方式，沿用第二节的推论视角。

1. 模型：负责判断，不负责为事实背书

模型可以理解需求、拆解任务、提出测试点、选择工具、归纳失败模式。但它的输出本质上仍是概率生成，可能误读需求、调用错误参数，也可能把环境异常解释成产品缺陷。

因此模型适合承担：

• 从多份输入中提炼风险；
• 规划下一步要查什么、测什么；
• 根据执行反馈动态调整；
• 生成候选用例、脚本或诊断假设；
• 汇总证据并暴露不确定项。

模型不应该单独承担：

• 定义业务正确性的最终判定标准；
• 绕过权限读取生产敏感数据；
• 自行批准破坏性测试；
• 在证据不足时宣布“测试通过”；
• 替代责任人做上线 Go/No-Go 决策。

2. 工具：把“我认为”变成“我执行过”

没有工具时，模型最多能建议“应该检查登录失败五次后的锁定逻辑”。有工具后，它才可能真正完成：

• 查询接口契约；
• 创建隔离测试账号；
• 调用登录接口五次；
• 查询账号状态；
• 检索服务日志和追踪链路；
• 运行确定性的断言；
• 保存请求、响应、时间戳和环境版本。

工具不是越多越好。一个名称模糊、参数无约束、结果不结构化的工具，会放大模型的不确定性。对测试工具至少要定义：输入 schema、权限范围、超时、重试、幂等性、输出 schema、错误分类和审计字段。

3. 上下文：决定模型此刻看见什么

测试上下文不等于把整个仓库、全部需求和几年缺陷记录一次性塞给模型。更实用的上下文应该按任务动态选取：

• 当前需求及验收标准；
• 本次代码和配置变更；
• 受影响接口、页面与数据表；
• 对应的历史缺陷与回归用例；
• 当前环境版本、开关和测试数据；
• 已执行步骤、真实结果和仍未解决的问题；
• 权限边界、停止条件与输出格式。

上下文过少会漏风险，过多则会让关键信息被噪声淹没。Harness 要解决的不只是“上下文够不够长”，而是每一步该把哪些事实送给模型、哪些内容应该摘要、哪些证据必须保留原文。

4. 执行反馈闭环：让计划接受现实检验

一个合格闭环至少包含五类反馈：

反馈类型	例子	系统应该如何处理
工具反馈	API 返回 401、浏览器元素不存在	判断参数、权限、版本或产品行为是否异常
环境反馈	服务未部署、依赖超时、数据过期	标记阻塞，避免误报产品缺陷
断言反馈	实际状态与明确预期不一致	生成缺陷候选并补充复现证据
过程反馈	多次重复无进展、Token 或时间超限	停止循环，转人工处理
人工反馈	测试负责人否决预期或扩大授权	更新目标、判定标准或权限后再继续

真正的闭环不是“失败后让 AI 再试一次”，而是失败必须改变下一步决策，并且重试次数、替代策略、停止条件都可观察、可限制。

---

四、为什么 Harness 不等于模型能力提升

给同一个模型接上搜索、终端和浏览器之后，它完成任务的概率可能上升，但这不代表模型参数变聪明了。变化发生在系统层：

维度	只使用模型	使用 Harness 后
信息来源	依赖提示词与已有知识	可读取当前需求、代码和环境状态
行动能力	给出文字建议	可调用受控工具产生真实影响
纠错方式	靠再次提示	可依据执行结果调整下一步
记忆方式	依赖有限对话历史	可借助会话事件、摘要和外部状态恢复
安全边界	主要靠文字约束	可叠加权限、审批、沙箱和工具守卫
完成判定	模型说“完成了”	由测试、断言和证据决定是否完成

Harness 能放大模型的能力，也能放大模型的错误。工具权限过大，错误就从一段回答变成一次真实操作；上下文污染，错误可能在多轮循环里持续传递；验证标准模糊，智能体甚至可能通过放宽断言来“完成任务”。

所以评估时不能只问“哪个模型分数高”，而要问：

• 它读到了什么上下文？
• 它能调用哪些工具？
• 每个工具有什么权限？
• 失败后如何归因和重试？
• 谁定义通过标准？
• 最终结论能否由证据复核？

这也是 Harness 给测试工程最直接的提醒：质量属于整个“模型—工具—上下文—环境—验证”系统，而不是单独属于模型。

---

五、测试方法论的变化：从“生成用例”转向“设计可验证闭环”

过去谈 AI 测试，常见入口是把需求粘贴给模型，让它生成几十条用例。这个动作有帮助，但只解决了测试设计中的一小段，而且很容易出现三种假繁荣：

• 用例数量很多，却没有绑定具体需求和风险；
• 步骤写得完整，却没有可执行的数据和环境；
• 自动化脚本能跑，却用错误的断言把错误行为判成通过。

Harness 思维要求把质量目标重新定义为：

覆盖不是“写到了”
而是“目标被关联、场景被执行、结果被判定、证据可追溯”

于是测试工程师的设计对象也发生变化：

过去主要设计什么	Harness 时代还要设计什么
测试用例	上下文装配规则
自动化脚本	工具契约和权限策略
测试数据	数据生命周期与隔离机制
断言	可机器验证的测试 oracle
测试计划	循环、重试、停止和人工接管条件
测试报告	可重放的执行轨迹与证据包

AI 是否能生成用例仍然重要，但更高价值的问题变成了：系统怎么知道该测什么、如何安全执行、凭什么判断、失败如何归因、何时必须交给人。

---

六、覆盖测试全流程的具体实践

1. 需求分析：先产出“可验证契约”，再产出用例

让智能体读取需求时，不要直接下达“生成测试用例”的指令，而应先要求它产出结构化分析：

• 需求目标、非目标和角色；
• 每条验收标准对应的可观察结果；
• 模糊词、冲突项和缺失项；
• 状态转换、权限规则和异常路径；
• 依赖系统、数据影响和回滚要求；
• 无法从现有材料确认的问题。

然后用规则校验：每条测试必须关联需求 ID 或风险 ID；没有明确 oracle 的场景不能自动进入“通过/失败”判定，只能标记为待确认。

2. 测试设计：让风险、证据和停止条件进入用例

一条适合闭环执行的测试，不应只有“步骤 + 预期结果”，还应包含：

case_id
关联需求 / 风险
前置环境与数据
允许调用的工具
输入与操作
机器可判定的 oracle
需要保留的证据
清理动作
失败分类规则
最大重试次数
人工接管条件

模型可以扩展边界值、组合和异常场景，但覆盖矩阵应由确定性规则检查。例如 12 条验收标准中有 2 条没有任何测试关联，应直接报“覆盖缺口”，而不是让模型凭感觉评价“覆盖充分”。

3. 环境与数据：把准备、使用、清理都纳入闭环

环境和数据是 AI 测试最容易被低估的部分。建议把工具按风险拆开：

• 查询类：读取部署版本、开关、日志和数据状态，默认可用；
• 创建类：只允许在隔离命名空间创建测试账号、订单或设备；
• 修改类：必须限定表、字段、租户和有效期；
• 清理类：只允许删除本次运行创建且带有唯一标签的数据；
• 生产类：默认拒绝，临时授权也必须由人审批并记录原因。

每次执行前先做环境预检。预检不通过就停止，不要让智能体在错误环境上继续制造“产品缺陷”。

4. 执行：确定性框架跑主流程，智能体处理变化

高频回归不必每次都让模型逐步操作。更稳妥的分工是：

• Playwright、pytest、接口测试框架负责稳定、重复、可断言的执行；
• Harness 负责选择测试、准备上下文、调度工具、分析失败和补充探索；
• 只有当页面变化、数据不满足或结果异常时，模型才介入诊断；
• 模型提出的脚本或定位器修复先形成候选变更，不能通过放宽断言让测试“变绿”。

这样既控制成本，也避免把本来确定性的回归执行变成不可复现的自然语言操作。

5. 缺陷定位：先分层归因，再生成缺陷单

一次失败至少要区分：

• 测试脚本或工具错误；
• 环境、依赖或测试数据错误；
• 需求或 oracle 不明确；
• 产品真实缺陷；
• 暂时无法判断。

智能体可以查询日志、追踪 ID、最近变更和历史缺陷来生成候选根因，但缺陷报告必须附带原始请求响应、关键日志片段、环境版本、数据标识和最小复现步骤。没有证据时只写“待定位异常”，不要自动升级成产品缺陷。

6. 回归：根据影响与证据选集，而不是让模型拍脑袋

回归选择可以综合：代码依赖、接口调用链、需求关联、历史缺陷、关键用户路径和本次失败位置。模型适合解释“为什么选这些”，而底线由规则保证：

• P0 核心链路不能被模型自行移出回归集；
• 修复涉及权限、金额、状态机时，强制加入对应专项测试；
• 新生成或自愈的脚本必须先跑原场景和邻接场景；
• 回归缩减比例异常时触发人工复核；
• 最终报告同时列出“已执行”和“因何未执行”。

7. 交接：交付证据包，而不是一段 AI 总结

一次运行至少应保存：

• 任务目标、需求版本和代码版本；
• 环境、配置与测试数据快照；
• 测试选择理由和未覆盖范围；
• 工具调用、审批、重试和人工干预记录；
• 断言结果、日志、截图或追踪链接；
• 缺陷候选及其证据强度；
• 剩余风险、阻塞项和建议负责人。

总结可以由模型生成，但上述字段应来自可追溯的结构化记录。换一个测试工程师接手时，应该能够复核结论，而不是只能相信上一轮对话。

---

七、人类测试工程师的新职责与权限边界

Harness 不会让测试工程师消失，反而把“质量判断”和“控制系统”的责任放大了。

人必须负责的事情

• 定义业务风险和不可接受的失败；
• 把验收标准转成可靠的 oracle；
• 决定哪些证据足以支持通过、失败或阻塞；
• 审批生产访问、外部通信、批量写入和破坏性操作；
• 处理需求冲突、伦理、隐私和合规判断；
• 对上线 Go/No-Go 和剩余风险签字；
• 定期评估智能体的漏报、误报、越权和不可复现问题。

可以逐步交给智能体的事情

• 整理材料、建立需求—风险—用例关联；
• 在批准范围内准备隔离数据；
• 调度已有自动化套件；
• 聚类失败、检索日志和生成诊断假设；
• 生成报告草稿和交接清单；
• 对低风险、可回滚的步骤执行有限重试。

一个简单的权限矩阵

操作	默认策略	原因
读取需求、代码、测试日志	允许或按项目授权	低风险，测试所必需
在隔离环境执行测试	允许但限时、限资源	可控且可清理
创建带标签的测试数据	允许，必须自动过期	防止污染与泄漏
修改测试脚本	生成候选变更，人工评审	防止改变测试意图
修改断言或验收标准	默认禁止	可能掩盖真实缺陷
写入缺陷系统	先草稿，人工确认	避免误报影响协作
访问生产敏感数据	默认禁止，例外审批	隐私与合规风险高
删除、压测、故障注入	明确授权 + 范围校验 + 监控	可能造成不可逆影响
决定上线	永远由责任人完成	需要业务与组织责任

权限设计要能真正落地为“可追责”，还需要配套的记录机制：谁在什么权限下执行了什么操作、谁批准了什么、结论由谁复核，都应沉淀到事件日志和审批记录里。记录缺失时，权限矩阵再细致也无法追责。

原则不是“AI 能不能做”，而是“一旦做错，是否可发现、可停止、可恢复、可追责”。

---

八、分阶段采用路径：先证明可控，再扩大自治

阶段 0：建立基线，不让智能体执行

选择 20—50 个历史需求或缺陷，记录现有人工流程的耗时、覆盖缺口、误报、返工和交接成本。让模型只做需求分析和测试建议，不接工具，不改系统。

进入阶段 1 的门槛： 团队能够量化它在哪些任务有帮助、在哪些任务容易犯错。

阶段 1：只读 Harness，做影子运行

开放需求、代码差异、用例库和日志的只读工具。智能体生成测试计划、回归建议和失败归因，但不触发真实执行；与人工结果对比。

关注指标： 需求关联完整率、风险召回率、错误归因比例（越低越好）、证据引用正确率、人工修订比例。

阶段 2：受控执行低风险任务

开放隔离环境、测试数据工厂和已有自动化套件。限定工作区、账号、资源、时间、重试次数和审批点。

关注指标： 可复现率、环境误报率、工具失败率、平均人工接管次数、清理成功率、单位有效结果成本。

阶段 3：进入 CI/CD，但不接管发布决策

让 Harness 根据变更选择测试、运行回归、聚类失败并生成证据包。关键链路仍由固定门禁保证，测试负责人保留最终签字权。

关注指标： 漏报率、逃逸缺陷、回归耗时、稳定性、权限违规次数、同输入多次运行的一致性。

阶段 4：有限自治和持续评估

只对低风险、可回滚、已有稳定 oracle 的任务提高自治等级。每次模型、插件、提示词、工具或权限策略变化，都视为测试系统变更，重新跑评估集。

降级条件： 出现越权、证据不可重放、错误清理、异常漏报或指标连续恶化时，自动降级到上一阶段。

---

九、一个小型示例：验证“连续输错 5 次密码后锁定 30 分钟”

把上面的原则落到一个具体例子上。假设需求写着：用户连续五次输入错误密码后，账号锁定 30 分钟；锁定期间即使密码正确也不能登录；管理员可以解锁。

1. 先定义任务契约

下面是概念性伪配置，不是 DeepSeek Harness 官方配置语法：

goal: 验证登录失败锁定机制
requirement_id: AUTH-217
environment: qa-auth-03
allowed_tools:
  - account.create_test_user
  - auth.login
  - account.get_status
  - logs.query_by_trace_id
  - account.cleanup_test_user
forbidden:
  - production_access
  - change_requirement
  - weaken_assertion
limits:
  max_login_attempts: 8  # 执行上限，非业务锁定阈值
  max_retries_per_step: 1
  timeout_minutes: 10
approval_required:
  - admin.unlock_account
evidence:
  - request_response
  - trace_id
  - account_status_timeline
  - environment_version

2. Harness 驱动的执行过程

• 模型先发现需求没有说明“30 分钟从第五次失败前还是失败后开始计时”，将其标记为待确认，但不妨碍先验证锁定行为；
• 工具在 QA 环境创建唯一测试账号，并返回数据标签和过期时间；
• 自动化连续执行四次错误密码，断言仍未锁定；若断言失败（例如第四次就已锁定），提前进入缺陷调查分支（步骤 7）；
• 第五次错误密码后，查询账号状态并断言为 LOCKED；
• 使用正确密码登录，断言被拒绝且错误码符合契约；
• 保存每次请求响应、trace ID、服务器时间和账号状态时间线；
• 若步骤 3 的断言失败，即账号提前锁定，模型查询对应日志和最近认证服务变更，形成“疑似计数偏移”的缺陷候选；
• 管理解锁属于写操作，需要人工批准。若未批准，系统把该分支记为“未执行”，不能写成通过；
• 最后清理本次创建的数据，并验证清理成功。

3. 最终交付不只是一句“发现 Bug”

下面展示的是异常分支的交付结果；若第 5 次失败才锁定且正确密码被拒，则核心锁定行为判定为通过，证据包的结论与归因部分相应调整。

合格证据包应包含：

结论：核心锁定行为失败，管理员解锁分支未执行
环境：qa-auth-03 / auth-service 4.18.2
复现：第 4 次错误密码后账号已变为 LOCKED
证据：5 组请求响应、trace ID、状态时间线、相关日志
初步归因：失败计数疑似从 0/1 边界处理错误，仍需开发确认
已排除：测试账号初始失败计数为 0；执行期间无并发登录
未覆盖：30 分钟自动解锁、管理员解锁（缺少审批）
建议回归：密码重置、验证码失败计数、并发登录、管理员解锁

这个示例里，模型并没有凭空获得更强的认证测试知识。真正提升可信度的是：上下文明确、工具受控、每一步有反馈、结论有 oracle、操作有权限、结果可复核。

---

十、团队落地检查清单

目标与判定

• [ ] 每个任务有明确目标、非目标和停止条件
• [ ] 每条关键验收标准都有可机器验证或人工确认的 oracle
• [ ] “通过、失败、阻塞、未执行、无法判断”被严格区分
• [ ] 禁止智能体通过删除测试、放宽断言来达成完成状态

上下文与数据

• [ ] 输入材料有版本和来源，可追溯到需求与代码变更
• [ ] 上下文按任务选取，不把无关仓库和全部历史记录一次性注入
• [ ] 敏感信息在进入模型前完成最小化、脱敏或隔离
• [ ] 测试数据有唯一标签、作用域、过期时间和清理验证

工具与权限

• [ ] 工具有明确 schema、超时、重试和错误分类
• [ ] 读取、写入、删除、外部通信使用不同权限等级
• [ ] 默认最小权限，高风险操作必须审批
• [ ] 工具参数和返回值进入审计日志，密钥不得进入模型输出
• [ ] 沙箱范围、资源上限和网络访问范围可验证

执行与反馈

• [ ] 环境预检失败时会停止，而不是继续误报
• [ ] 每次重试有原因、上限和结果，不允许无限循环
• [ ] 产品缺陷、环境问题、数据问题、脚本问题和未知问题分开统计
• [ ] 关键结论能由确定性测试、日志或人工审批复核
• [ ] 智能体失败时有清晰的人工接管入口

评估与治理

• [ ] 有来自真实历史任务的固定评估集
• [ ] 同时衡量漏报、误报、越权、成本、耗时和可复现性
• [ ] 模型、插件、工具、提示词或权限变化后重新评估
• [ ] 保存运行版本、事件轨迹、人工干预和剩余风险
• [ ] 出现严重越权或不可重放结果时能够自动降级或停用

---

十一、写在最后

DeepSeek Harness 现在最值得关注的，并不是它能否立刻变成企业 AI 测试平台。官方已经明确说它仍处于开发者预览阶段，兼容性会变化；在测试成熟度、稳定性、覆盖率提升和生产安全性方面，目前也没有足够的官方证据支持乐观结论。

但它把一个重要趋势摆到了测试工程师面前：

AI 测试的竞争焦点，正在从“谁能生成更多用例”转向“谁能把模型装进一个可观察、受控制、可验证的质量系统”。

未来优秀的测试工程师，不只会设计测试，也会设计模型看到什么、工具能做什么、失败如何归因、何时必须停止、什么证据才算完成。模型负责提出和探索，确定性工具负责执行和校验，人负责业务判断、权限边界与最终责任。

这不是把测试交给 AI，而是用测试工程的老本行——怀疑、验证、留证和控制风险——去约束一个更强、也更不确定的执行者。

---

参考资料

• DeepSeek Harness 官方仓库与中文 README
• DeepSeek Harness 官方架构文档
• Anthropic：Trustworthy agents in practice
• AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents

---

本文是"肖恩的博客"系列文章之一，首发于 seanwalter.top。如需转载，请注明出处。