先算一笔账：一个 Agent 跑复杂长任务，API 成本会随任务长度放大，一旦失控打转，烧掉的不只是 token，还有用户的信任和耐心。这是质量问题，也是真金白银的经营问题——这正是大厂把 AI 测试推到前所未有高度的真实原因。我们从一个最近的现象级项目说起。
一个信号：Agent 开始"干活"了
2026 年 8 月 13 日晚，DeepSeek 发布了首款开源 Agent 产品 DeepSeek Harness（简称 dsh），MIT 许可证开源，约 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_set=GOLDEN_SET, runs_per_case=5):
report = []
for case in goldenset:
passed = 0
for in range(runs_per_case): # 非确定性输出，多次运行看分布
output = model_call(case["input"])
if all(kw in output for kw in case["expect_keywords"]):
passed += 1
report.append({"input": case["input"], "pass_rate": passed / runs_per_case})
return report
def release_gate(report, threshold=0.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 开始干活，行业只会越来越需要那个能"盯住"它们的人。
