从DeepSeek Harness，看懂大厂为什么越来越重视AI测试

关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集先算一笔账一个 Agent 跑复杂长任务API 成本会随任务长度放大一旦失控打转烧掉的不只是 token还有用户的信任和耐心。这是质量问题也是真金白银的经营问题——这正是大厂把 AI 测试推到前所未有高度的真实原因。我们从一个最近的现象级项目说起。一个信号Agent 开始干活了2026 年 8 月 13 日晚DeepSeek 发布了首款开源 Agent 产品 DeepSeek Harness简称 dshMIT 许可证开源约 42 小时破 10 万星目前已超 15 万星被称为 GitHub 史上最快涨星项目之一。热度只是表象真正的信号是方向这是 DeepSeek 第一次从造模型走向造 Agent 产品。社区实测它的能力覆盖文件操作、命令执行、检索、技能、任务编排和会话管理还提供标准、PTC、极简、创造多种运行模式。换句话说AI 不再只是陪聊而是开始动手干活。聊天机器人答错一句是体验问题Agent 做错一步可能就是事故。质量保障的权重从这一刻起完全不一样了。三个业务理由理由一非确定性让传统回归失效。 传统软件同样的输入永远给同样的输出一套用例能用很多年。模型产品不行同一个问题问两次答案可能完全不同。设想一个负责生成测试用例的 Agent这次生成的用例覆盖了优惠券叠加规则下次可能就漏掉了这条业务靠人工抽检再多双眼睛也追不上它的变化速度。这意味着断言精确值的测试范式失效质量保障从测试转向评估多次运行看分布、用基线用例集对比、靠通过率和语义打分判断能不能上线。谁掌握了评估能力谁就握住了 AI 产品的发布闸门。理由二成本让质量问题变成财务问题。 社区实测 dsh 的短板包括响应偏慢、API 成本随任务长度放大、偶发循环打转。打转一次浪费的不只是时间还有实打实的 token。更麻烦的是这种浪费是静默的它不报错、不告警只是悄悄出现在账单里等月底复盘时才发现就晚了。所以 AI 质量保障必须算token 经济账一个任务平均花多少钱、哪种行为模式预示着即将失控、什么时候该止损。这类成本回归在传统测试里不存在在 AI 产品里却是必修课。理由三安全合规让行为可控变成硬指标。 Agent 能执行命令、操作文件意味着它的错误带有真实副作用不是一句错话那么简单。这也是为什么 dsh 把 Revertible Effects 作为关键机制——对上下文的每次修改都留下反向方法卸载时按相反顺序撤销媒体称之为给自进化发的后悔药。尤其是当 Agent 走向自进化——自己在运行中编写、安装插件——行为的变化速度只会更快审计和回滚的需求只会更强。这个设计背后是行业共识AI 的行为必须可审计、可回滚、可验证在金融、医疗这类强监管场景里更是写进合规要求的硬指标而这些能力能不能真的兜住全靠测试说话。回归模型输出一个简化的示意思路要能落到代码上。下面是一个极简的回归评估示意固定一组 golden set每条用例多次运行看通过率再设一道发布门禁。简化示意模型输出的回归评估golden set 对比非 dsh 组件GOLDEN_SET [{“input”: “把列表 [3, 1, 2] 排序并给出结果”, “expect_keywords”: [“[1, 2, 3]”]},{“input”: “判断 ‘level’ 是不是回文串只回答 yes 或 no”, “expect_keywords”: [“yes”]},]def run_eval(model_call, golden_setGOLDEN_SET, runs_per_case5):report []for case in golden_set:passed 0for _ in range(runs_per_case): # 非确定性输出多次运行看分布output model_call(case[“input”])if all(kw in output for kw in case[“expect_keywords”]):passed 1report.append({“input”: case[“input”], “pass_rate”: passed / runs_per_case})return reportdef release_gate(report, threshold0.8):“”“发布门禁任一条目通过率低于阈值就不放行”“”bad_cases [r for r in report if r[“pass_rate”] threshold]assert not bad_cases, f评估不达标禁止发布: {bad_cases}真实业务里会比这复杂得多打分会引入语义评估用例集会随 bad case 滚动更新结果要接进发布流水线。但骨架就三样——基线、统计、门禁。这套思路和 dsh 的设计其实能对上它强调组件可检查会话日志本身就是可插拔、可检查的组件。评估体系需要的稳定观测面——每一步做了什么、调用了什么工具、花了多少轮次——正是从这些可检查的组件里来的。架构上把可观测性当一等公民评估才有可能做得扎实。落回求职JD 里正在出现的新要求顺着这个趋势去看大厂的测试开发岗位会发现几类要求出现的频率明显在涨。一是评估能力能设计评估集、熟悉多次运行的统计方法和语义打分二是 Agent 测试经验理解模型决策、工具调用、结果反馈这个循环会搭隔离的执行环境三是成本与性能意识能把 token 消耗、任务时长纳入回归指标四是安全与红队意识会为越权操作、注入攻击这类场景设计用例五是平台化能力把评估从一次性脚本做成持续运行的基础设施。对照几年前的 JD 看会更直观那时的高频词是熟练 pytest“熟练接口自动化”现在则越来越多地出现评估体系搭建经验有 LLM 应用测试经验这类表述——要求的变化就是行业重心的变化。对测试开发来说这是好消息AI 产品的质量保障比传统应用更复杂、更稀缺价值正在被重新定价。但前提是技能要跟上——只会接口自动化已经不够了懂模型、懂 Agent、懂评估才是下一张门票。我的建议是从小处起步找一个手头的模型接口建一个十条以内的 golden set跑多轮统计通过率再做成一道发布门禁。把这个闭环完整走一遍你就有了可以写进简历的评估实战。dsh 的爆火只是个序章当越来越多的 Agent 开始干活行业只会越来越需要那个能盯住它们的人。本文整理自霍格沃兹测试开发学社的原创分享更多测试开发与 AI 测试实战内容我们下一篇见。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。