1. 版本迭代背后的测试逻辑重构DeepSeek Harness 0.2 这个版本号看起来只是个小版本跳动但从我拿到更新日志到实际跑完三轮回归测试的体验来看它带来的变化远不止版本号上那点数字。Harness 在测试圈子里一直被当作模型行为验证的脚手架工具来用0.1 时代大家主要拿它做单轮问答的断言校验写几条 case、跑一遍、看通过率基本就完事了。但 0.2 把整个执行链路重新拆了一遍引入了多轮会话状态保持、工具调用链路的中间态捕获、以及输出稳定性的统计采样机制。这意味着测试工程师面对的不再是一个输入-输出的黑盒而是一个有内部状态、有分支路径、有概率分布的灰盒系统。我之所以强调灰盒这个词是因为很多同行第一反应还是拿老思路去套——写几条 prompt、比对一下输出文本、跑完收工。但 0.2 的 Harness 在底层加了执行轨迹记录之后你会发现同一个输入在不同轮次里可能走出完全不同的工具调用路径最终文本输出却看起来差不多。这种表面一致、内部发散的情况恰恰是测试中最容易漏掉的风险点。所以这篇文章我想聊的不是0.2 有哪些新功能这种说明书式的罗列而是从一个天天跟测试用例和失败日志打交道的人的角度把这次更新后真正需要盯住的七个风险逐一拆开讲。这篇文章适合几类人看一是正在用 Harness 做模型行为回归的测试工程师二是负责搭建 CI 流水线、需要把 Harness 集成进去的工程同学三是对模型测试方法论感兴趣、想了解灰盒测试在 AI 场景下怎么落地的人。不管你是刚接触 Harness 还是已经跑过几百条 case 的老手下面这些内容应该都能帮你少踩几个坑。我会尽量把每个风险的成因、表现、排查手段和规避方案都讲透能贴配置的地方贴配置能算参数的地方把计算过程写出来。2. 风险一多轮会话状态污染导致的断言漂移2.1 状态保持机制到底改了什么0.1 版本的 Harness 每次执行 case 都是独立的会话之间不共享任何上下文你写一条 case 就是一次干净的单轮调用。0.2 引入了session_persistence配置项默认开启同一个测试套件内的多条 case 会共享一个会话上下文。这个设计的初衷是好的——真实用户场景下多轮对话本来就是连续的测试也应该模拟这种连续性。但问题在于很多老 case 是按独立单轮的假设写的断言里隐含了模型看不到之前对话这个前提。一旦会话状态被保持前面 case 的内容就会作为上下文注入到后面 case 的请求里导致断言结果发生漂移。我实测过一个很典型的例子套件里有两条 case第一条问帮我列三个水果断言检查输出里是否包含苹果第二条问刚才提到的第一个是什么断言检查输出是否等于苹果。在 0.1 下第二条必然失败因为模型没有上下文。但在 0.2 默认配置下第二条会通过因为会话状态被保持了。反过来如果你有一条 case 断言输出不应包含某个词而前一条 case 恰好把这个词作为上下文注入了这条断言就会莫名其妙地失败。这种漂移不是模型的问题是测试隔离性被破坏导致的。2.2 隔离策略与配置取舍要解决这个问题核心是在模拟真实连续性和保证 case 独立性之间做取舍。我的做法是按套件维度拆分把需要连续上下文的 case 归到一个session_group里显式声明它们共享状态把需要独立验证的 case 放到单独的 group并在配置里关掉状态保持。Harness 0.2 支持在 case 级别覆盖session_persistence配置大概长这样suite: fruit_chain_test session_persistence: true session_group: chain_a cases: - id: case_001 input: 帮我列三个水果 assert_contains: [苹果] - id: case_002 input: 刚才提到的第一个是什么 assert_equals: 苹果 session_persistence: true --- suite: isolated_negative_test session_persistence: false cases: - id: case_101 input: 介绍一下机器学习 assert_not_contains: [苹果]这里有个细节要注意session_persistence在 suite 级别设了 true 之后case 级别设 false 是可以覆盖的但反过来不行——如果 suite 级别是 falsecase 级别设 true 不会生效。这个优先级规则在文档里写得很隐蔽我是踩了一次坑才确认的。所以建议的做法是 suite 级别统一设 false需要连续上下文的 case 单独开 true这样默认行为是隔离的符合大多数回归测试的预期。提示每次修改 session 相关配置后务必跑一遍全量套件而不是只跑改动的那几条 case。状态污染的影响是跨 case 的单跑一条看不出来。2.3 断言漂移的排查手法当你怀疑某条 case 的失败是状态污染导致的最快的排查方式是在 case 执行前后打印会话快照。Harness 0.2 提供了--dump-session参数可以把当前会话的完整上下文导出成 JSON。我的习惯是在 CI 里对失败 case 自动触发 dump然后对比预期上下文和实际上下文的差异。如果实际上下文里多出了前面 case 的内容基本就能确认是污染问题。另一个辅助手段是给每条 case 加一个context_fingerprint断言检查注入的上下文哈希值是否符合预期。这个哈希值在 case 第一次通过时记录下来后续如果上下文变了哈希就会变能提前发现污染。这个做法稍微重一点但对核心回归套件来说值得。3. 风险二工具调用链路中间态捕获不全3.1 中间态为什么重要0.2 最大的卖点之一是工具调用链路的可视化Harness 会记录模型在回答过程中调用了哪些工具、传了什么参数、拿到什么返回。但我在实际使用中发现默认配置下捕获的中间态是不全的——它只记录了成功返回的工具调用对于超时、重试、被模型放弃的调用默认是不记录的。这就带来一个隐患你看到一条 case 通过了但模型可能是试了三次工具调用、前两次都失败了、第三次才成功而你的断言只检查了最终输出完全没覆盖这个重试过程。从测试的角度看这种结果对但过程脏的情况是必须盯住的。因为重试意味着额外的延迟和资源消耗如果生产环境对响应时间有要求这种隐藏的重试会直接导致超时。我遇到过一条 case最终输出完全正确但中间有一次工具调用超时了 8 秒才重试成功整条 case 耗时 12 秒而断言里根本没检查耗时。如果这种 case 混在回归套件里性能回归是发现不了的。3.2 开启完整链路记录的配置要捕获完整的中间态需要在 Harness 配置里显式打开trace_level。默认是result_only改成full之后会记录所有工具调用的尝试、参数、返回和耗时。配置如下harness: trace_level: full trace_retries: true trace_abandoned_calls: true trace_timeout_ms: 30000trace_abandoned_calls这个选项特别关键它记录的是模型发起了工具调用但中途放弃的情况。这种半途而废的调用在日志里很容易被忽略但它往往暗示模型在工具选择上存在犹豫是行为不稳定的信号。打开这个选项后日志量会明显增大建议只在排查阶段或者核心套件上开全量回归时用result_only加失败重跑的方式控制成本。3.3 链路断点的定位方法拿到完整链路记录后怎么快速定位断点我的做法是把链路按时间轴画出来标出每个工具调用的开始、结束和状态。Harness 导出的 trace 是 JSON 格式我写了个小脚本把它转成时间轴文本大概长这样[0ms] request_start [120ms] tool_call: search_flights(params{...}) [3200ms] tool_timeout (retry 1/3) [3300ms] tool_call: search_flights(params{...}) [5100ms] tool_success (result_size2.3KB) [5200ms] tool_call: book_flight(params{...}) [5400ms] tool_abandoned (reason: model_switched_strategy) [5600ms] tool_call: search_hotels(params{...}) [7800ms] tool_success [8000ms] response_complete从这条时间轴能一眼看出问题第一次 search_flights 超时了模型重试了一次book_flight 被发起了但又被放弃说明模型在订票和查酒店之间改了主意。这种链路如果只看最终输出是完全看不出来的。定位到断点后就可以针对性地加断言比如工具调用总次数不超过 N 次、单次工具调用耗时不超过 X 毫秒。注意trace_level: full会显著增加内存占用长会话套件下建议配合trace_buffer_size限制单条 case 的记录条数避免 OOM。4. 风险三输出稳定性采样不足引发的假通过4.1 概率系统的测试困境模型输出本质上是概率采样同一个输入跑两次可能得到不同的文本。0.1 时代 Harness 默认每条 case 只跑一次通过就通过失败就失败。这种单次采样在概率系统上是有很大风险的——一条 case 可能 70% 的概率通过单跑一次恰好命中了通过的那 70%你就以为它是稳定的实际上它在回归里会间歇性失败。0.2 引入了sample_count配置允许一条 case 跑多次取统计结果这是好事但默认值还是 1很多人没改等于没享受到这个能力。我做过一个实验拿 20 条 case每条跑 10 次统计通过率。结果发现有 6 条 case 的通过率在 60% 到 90% 之间也就是说它们都是不稳定的但单次跑的时候有相当概率显示通过。这 6 条 case 如果混在回归套件里就会造成这次 CI 绿了、下次红了的诡异现象排查起来非常痛苦。4.2 采样次数怎么定sample_count设多少合适这取决于你对置信度的要求和成本预算。从统计角度讲如果你想让通过率估计的误差控制在 ±10% 以内至少需要跑 30 次以上。但实际测试中不可能每条 case 都跑 30 次成本扛不住。我的经验做法是分层套件类型sample_count通过率阈值说明冒烟测试1100%只验证基本可用性接受单次采样核心回归580%关键路径容忍少量波动稳定性专项2095%专门验证输出稳定性成本高但必要边界探索360%探索性测试关注失败模式而非通过率这个分层不是拍脑袋定的。冒烟测试跑 1 次是因为它只回答系统能不能用不回答稳不稳定。核心回归跑 5 次、阈值 80%是因为 5 次里允许 1 次失败能过滤掉偶发抖动但又不至于太严格。稳定性专项跑 20 次、阈值 95%是因为这个套件的目标就是量化稳定性采样不足就没有统计意义。4.3 通过率断言的写法Harness 0.2 支持在 case 级别配置通过率断言写法如下cases: - id: stability_001 input: 总结这段文本 sample_count: 20 assert_pass_rate: 0.95 assert_contains: [关键词A, 关键词B]这里有个容易踩的坑assert_pass_rate和assert_contains是配合使用的前者定义多少次采样里有多少次满足后者。如果你只写assert_pass_rate不写具体断言Harness 会报配置错误。另外通过率断言失败时Harness 默认只报告通过率 0.85 低于阈值 0.95不会告诉你哪些采样失败了。要看到失败样本需要加--dump-failed-samples参数把失败的采样输出单独导出。这个参数在排查不稳定 case 时非常有用我基本每次跑稳定性专项都会带上。提示稳定性专项套件建议单独跑不要和功能回归混在一起。因为它的耗时是普通 case 的 20 倍混跑会拖慢整个 CI 流水线。5. 风险四环境依赖漂移造成的不可复现5.1 环境漂移的三种来源测试最怕的就是在我机器上能过、在 CI 上过不了。Harness 0.2 的环境依赖比 0.1 复杂了不少漂移来源主要有三个一是模型版本0.2 支持多模型切换如果配置里没锁定模型版本不同时间跑可能命中不同的模型快照二是工具依赖Harness 调用的外部工具比如搜索、计算器如果版本变了返回结果也会变三是运行时依赖Python 版本、依赖库版本、甚至系统时区都可能影响输出。我遇到过一次很典型的漂移一条 case 断言输出里包含某个日期本地跑一直通过CI 上却间歇性失败。排查了半天发现是时区问题——本地是东八区CI 容器是 UTC模型在生成日期时参考了系统时间导致输出差了一天。这种问题在 0.1 时代不太常见因为 0.1 的工具调用少、模型行为简单0.2 引入更多外部依赖后环境敏感度明显上升。5.2 锁定环境的配置清单要保证可复现核心思路是把所有可变因素都锁死。我的做法是维护一份env_lock.yaml在每次跑测试前由 Harness 加载并校验env_lock: model_version: deepseek-v2.5-20240115 python_version: 3.11.6 timezone: Asia/Shanghai tool_versions: search_tool: 1.4.2 calc_tool: 2.0.1 random_seed: 42random_seed这个字段特别重要。模型采样本身有随机性但 Harness 0.2 支持设置随机种子设置之后同一输入在相同环境下会得到相同输出前提是模型本身支持确定性采样。这样就能把模型随机性这个变量控制住让测试结果可复现。不过要注意设了 seed 之后测试就失去了验证稳定性的能力所以 seed 和 sample_count 是互斥的用法——要复现就用 seed要测稳定性就用 sample_count别混着用。5.3 漂移检测的自动化手段光锁定还不够还得有检测机制。我在 CI 里加了一个前置步骤跑测试前先执行harness env-check它会对比当前环境和env_lock.yaml的差异有差异就报警并终止。这个检查很快几秒钟的事但能拦住大部分环境漂移问题。另外我建议对核心 case 记录环境指纹——把模型版本、工具版本、运行时版本拼成一个哈希和 case 结果一起存下来。下次跑的时候如果指纹变了但结果没变说明环境变化对这条 case 没影响如果指纹变了结果也变了就能快速定位是环境导致的。这个做法稍微重但对那些必须稳定的核心 case 来说值得。6. 风险五断言粒度过粗掩盖真实缺陷6.1 从包含关键词到结构化断言0.1 时代大家写断言基本就是assert_contains和assert_equals两板斧检查输出里有没有某个词、或者输出是不是完全等于某个字符串。这种粗粒度断言在 0.2 下越来越不够用了因为 0.2 的输出结构更复杂——可能包含工具调用结果、多段结构化文本、甚至嵌套的 JSON。如果还用包含关键词这种断言很容易出现关键词在但结构错了的假通过。举个例子一条 case 要求模型返回一个 JSON包含name和age两个字段。粗粒度断言写assert_contains: [name, age]只要输出里出现这两个词就通过。但模型可能返回的是{name: 张三, age: unknown, error: missing}age 字段的值是错的断言却通过了。这就是断言粒度过粗导致的漏检。6.2 结构化断言的写法Harness 0.2 支持 JSONPath 断言可以对输出做结构化校验cases: - id: json_output_001 input: 返回用户信息 assert_jsonpath: - path: $.name exists: true type: string - path: $.age exists: true type: integer gte: 0 lte: 150 - path: $.error exists: false这种断言能精确到字段级别类型、范围、存在性都能校验。assert_jsonpath支持的操作符包括exists、type、equals、contains、gte、lte、matches正则基本覆盖了常见需求。对于非 JSON 的结构化文本可以用正则断言assert_matches但正则写起来容易出错我一般只在 JSON 不好使的时候才用。6.3 断言分层策略我的经验是把断言分成三层第一层是存在性断言检查关键字段或关键词是否存在这层最宽松用来快速过滤明显失败的 case第二层是正确性断言检查字段的值是否正确、类型是否匹配这层是主力第三层是一致性断言检查多个字段之间的逻辑关系比如end_time必须大于start_time、total必须等于各项之和。第三层最容易漏但往往能抓到最隐蔽的缺陷。举个第三层的例子一条 case 要求模型计算订单总价输出包含items数组和total字段。前两层断言检查 items 和 total 都存在、类型正确但不会检查 total 是否真的等于 items 之和。加一条一致性断言assert_sum: {source: $.items[*].price, target: $.total}就能抓到total 算错这种缺陷。Harness 0.2 内置了assert_sum、assert_order、assert_unique几个一致性断言用起来很方便。注意一致性断言依赖输出结构的稳定性如果模型输出的字段名会变比如有时叫 total 有时叫 sum一致性断言会误报。建议在 prompt 里明确要求字段名或者在断言前加一层字段名归一化。7. 风险六并发执行下的资源竞争与结果串扰7.1 并发带来的新问题0.2 的 Harness 支持并发执行 caseconcurrency配置项默认是 1但很多人为了提速会调到 4 或 8。并发确实能大幅缩短回归时间但也引入了新的风险资源竞争和结果串扰。资源竞争是指多个 case 同时调用同一个外部工具工具可能有限流或状态导致部分 case 失败结果串扰是指多个 case 共享了某些全局状态比如会话上下文、临时文件导致结果互相污染。我实测过一个串扰场景两条 case 并发执行都往同一个临时目录写文件文件名恰好相同结果后写的覆盖了先写的导致其中一条 case 读到了错误的内容。这种问题在串行执行时永远不会出现一旦并发就暴露了。更隐蔽的是会话串扰——如果session_persistence开着并发执行时多个 case 可能共享同一个会话上下文互相注入结果完全不可预测。7.2 并发安全的配置原则要安全地并发核心原则是每个 case 有独立的资源空间。具体来说会话隔离并发执行时session_persistence必须关掉或者每个 case 用独立的session_group。文件隔离case 的临时文件路径要包含 case id避免文件名冲突。工具限流如果外部工具有限流concurrency不能超过工具的 QPS 上限或者给工具调用加重试和退避。随机种子隔离如果用了random_seed每个 case 的 seed 要不同否则并发时可能产生相同的随机序列。配置示例harness: concurrency: 4 session_persistence: false temp_dir_template: /tmp/harness/{case_id} tool_rate_limit: search_tool: 10 # QPS calc_tool: 50temp_dir_template里的{case_id}会被替换成实际 case id保证每个 case 有独立目录。tool_rate_limit是 Harness 0.2 新增的配置用来控制对每个工具的并发调用数避免触发外部限流。7.3 并发问题的排查并发问题最难的地方是偶发——跑十次可能只失败一次很难复现。我的排查手法是先把concurrency降到 1确认串行下全部通过然后再逐步提高并发观察从哪个并发度开始出现失败。如果并发 2 就失败说明有严重的资源竞争如果并发 8 才失败可能是限流问题。定位到并发度之后再针对性地检查那个并发度下哪些资源是共享的。另一个手段是给每条 case 加执行日志记录开始时间、结束时间、使用的资源标识。并发失败时对比失败 case 和同时段其他 case 的日志往往能发现资源冲突的线索。Harness 0.2 的--log-timing参数会输出每条 case 的详细时间线排查并发问题时很有用。8. 风险七回归基线更新导致的隐性退化8.1 基线更新的陷阱回归测试的核心是和基线对比基线是上一次通过的输出。0.2 时代基线管理变得更复杂因为输出结构变了、断言方式变了很多团队会重新生成基线。但重新生成基线这个动作本身有风险——如果新基线是在一个有缺陷的版本上生成的那么后续所有测试都会以这个有缺陷的输出为标准隐性退化就被合法化了。我见过一个案例某次更新后模型的输出格式从日期: 2024-01-15变成了日期: 2024/01/15团队重新生成了基线测试全绿。但下游系统是按-分隔解析日期的格式变了之后下游全挂了。测试没抓到这个问题因为基线跟着变了断言也跟着变了等于把缺陷当成了新标准。8.2 基线变更的审核流程要避免这种问题基线更新必须走审核流程不能自动覆盖。我的做法是基线变更时Harness 生成一份 diff 报告列出所有变化的 case 和具体差异。diff 报告需要人工审核确认每个变化都是预期的改进而不是意外的退化。审核通过后才更新基线审核记录存档。Harness 0.2 提供了--baseline-diff参数可以生成结构化的 diff 报告。报告里会标出三类变化新增 case、删除 case、输出变化 case。输出变化 case 是重点需要逐条看。对于输出变化我建议按语义变化和格式变化分类——语义变化要重点审格式变化如果下游有依赖也要审。8.3 防止隐性退化的断言策略除了审核流程断言设计上也能防一手。核心思路是加不变量断言——那些无论版本怎么变都不应该变的属性。比如输出长度不应该突然翻倍或减半。关键字段的数量不应该变化。输出的语言不应该变化中文 case 不应该输出英文。工具调用的次数不应该显著增加。这些不变量断言不依赖具体输出内容所以基线更新时不需要改能持续起到哨兵作用。Harness 0.2 支持assert_invariant配置可以定义这类断言assert_invariant: - type: output_length min: 10 max: 5000 - type: field_count path: $ min: 2 max: 20 - type: language expected: zh - type: tool_call_count max: 10这些不变量断言在每次回归时都会跑一旦违反就报警不管基线有没有更新。我实测下来这类断言抓到了好几次基线更新掩盖退化的情况非常值得加。提示不变量断言的阈值不要设得太紧否则正常波动也会触发报警。建议先用历史数据统计出正常范围再在范围边界留 20% 余量。9. 七个风险的优先级与应对节奏七个风险讲完了但实际工作中不可能同时盯住所有风险得有优先级。我的排序逻辑是看影响面和发现难度两个维度影响面大且难发现的排前面影响面小且容易发现的排后面。风险影响面发现难度优先级建议应对节奏状态污染高中P0每次改 session 配置后全量回归中间态捕获不全高高P0核心套件常开 full trace输出稳定性采样不足高高P1稳定性专项每周跑一次环境依赖漂移中中P1CI 前置 env-check断言粒度过粗中低P2新 case 强制结构化断言并发资源竞争中高P2并发度调整后专项验证基线更新隐性退化高低P1基线变更强制人工审核P0 的两个风险是必须马上处理的因为它们直接导致测试结果不可信。P1 的三个风险需要建立机制来持续防控。P2 的两个风险在特定场景下才触发按需处理即可。我自己的节奏是每次 Harness 配置变更后跑一次全量回归覆盖 P0每周跑一次稳定性专项覆盖 P1 的采样问题每次基线更新走审核流程覆盖 P1 的基线问题CI 里常驻 env-check覆盖 P1 的环境问题。P2 的两个风险在新增并发配置或新增 case 时专项检查。最后分享一个我踩过的坑有段时间我为了提速把concurrency调到 8结果稳定性专项的通过率从 95% 掉到了 78%排查了两天才发现是并发导致的工具限流。后来把并发降到 4通过率恢复到 94%。这个教训是——并发度和稳定性是有 trade-off 的不能为了快牺牲准。测试的第一目标是可信第二目标才是快。