副标题：从一个退款 Agent 的越权风险，看 AI 测试开发该如何逐步落地
凌晨的大促结束后，售后 Agent 还在处理退款。
回归集全部通过：它能识别订单号，能解释退款规则，也能在大多数对话里正确回答“已为您发起退款”。但真正危险的缺陷不在答案里——某次会话中，它在身份核验完成前就调用了退款工具；另一次，它把“工具调用失败”说成了“退款已成功”。
传统自动化看见的是页面、接口和数据库；普通 LLM 评测看见的是“回答像不像正确答案”。可对一个能调用工具、改变业务状态的 Agent 来说，真正需要验证的是：
它是否在正确的上下文里，以正确的顺序，调用了正确的工具，并留下了可复盘的证据。
这是我对 DeepSeek Harness 的核心判断：它未来不会替代 Playwright、pytest 或接口自动化框架；它更可能成为 AI 测试的“运行时可观测层”和“可执行质量合同载体”。
DeepSeek Harness 的官方设计是“能力皆插件”，模型、工具、Skills、会话、沙箱、存储、循环等组件都可替换；更关键的是，一次运行中模型看到的上下文、工具调用及结果等会进入可追溯轨迹。对测试而言，这意味着原先黑盒的 Agent 行为，第一次有机会被拆成可断言、可回放、可回归的工程对象。DeepSeek Harness 官方说明
一、AI 测试的对象，已经不只是“最终答案”
过去我们写自动化用例，大体是：
输入 → 接口/页面响应 → 断言结果
接入 Agent 后，链路变成：
用户任务 → 上下文注入 → 模型规划 → 工具调用 → 工具结果
→ 再规划 → 最终回复 → 真实业务状态变化
如果测试只断言最终回复，就会出现一种很危险的“假通过”：
- 回复说“已退款”，实际
refund.create调用失败； - 退款金额正确，但身份核验发生在退款之后；
- Agent 调用了过期插件，却凭历史上下文编出正确答案；
- 同一订单被重复调用两次退款工具，页面仍只显示一次成功。
所以，AI 测试至少要同时验证四类合同：
| 合同 | 退款 Agent 的例子 | 失败后怎么处理 |
|---|---|---|
| 结果合同 | 最终确实生成退款单 | 阻断 |
| 过程合同 | 先验身份，再查规则，再退款 | 阻断 |
| 边界合同 | 金额不超过可退金额，不重复退款 | 阻断 |
| 轨迹合同 | 每次工具调用都有对应结果、可关联到同一任务 | 告警或阻断 |
Harness 的价值，不是让 Agent “更会测”，而是让测试团队终于能问出过去问不了的问题：这个结论是怎么得出来的？它中间做过什么？为什么这次和上次不一样？
二、不要一上来把 Harness 当生产框架，要先把它当“证据采集器”
DeepSeek Harness 仍处于开发者预览阶段，官方明确提示后续会有破坏兼容性变更；它也尚未经过安全审计，不能作为生产环境唯一安全控制。项目 README 安全说明
因此，落地的第一原则不是“把所有 Agent 接进 Harness”，而是：
先让 Harness 记录证据，再让测试系统根据证据做判断。
在测试架构上，我建议把原始轨迹和质量判断分开保存：
DSH 原始轨迹
↓
版本固定的适配层
↓
标准化事件（tool.call / tool.result / assistant.message）
↓
质量规则引擎
↓
CI 门禁、回归报告、缺陷复盘
这样做有两个好处：
- DSH 的内部插件和日志格式变化时，只改适配层，不推翻全部测试规则；
- 原始轨迹保持不可篡改，质量判断可随规则迭代重新计算。
三、一个能进 CI 的退款轨迹质量门禁
下面这段 TypeScript 不是为了展示语法，而是一个可直接放进 CI 的“退款 Agent 行为门禁”。
它故意不依赖 DSH 内部 API：你只需要按当前锁定的 DSH 版本，把导出的会话轨迹适配成 Event[]。测试规则就不会跟着预览版接口一起失控。
// refund-trace-gate.ts
type ToolName =
| "order.get"
| "identity.verify"
| "refund.policy"
| "refund.create";
type ToolCall = {
type: "tool.call";
seq: number;
callId: string;
name: ToolName;
args: Record<string, unknown>;
};
type ToolResult = {
type: "tool.result";
seq: number;
callId: string;
ok: boolean;
data: unknown;
};
type AssistantMessage = {
type: "assistant.message";
seq: number;
content: string;
};
type Event = ToolCall | ToolResult | AssistantMessage;
type Finding = {
level: "block" | "warn";
rule: string;
message: string;
};
const asRecord = (value: unknown): Record<string, unknown> =>
value && typeof value === "object" && !Array.isArray(value)
? (value as Record<string, unknown>)
: {
};
const asNumber = (value: unknown): number | undefined =>
typeof value === "number" && Number.isFinite(value) ? value : undefined;
export function evaluateRefundTrace(events: Event[]) {
const findings: Finding[] = [];
const calls = new Map<string, ToolCall>();
let order:
| {
id: string; refundableCents: number; state: string }
| undefined;
let identityVerified = false;
let policy: {
approved: boolean; maxRefundCents: number } | undefined;
let refundCall: ToolCall | undefined;
let refundResult: ToolResult | undefined;
let finalReply = "";
for (const event of [...events].sort((a, b) => a.seq - b.seq)) {
if (event.type === "tool.call") {
calls.set(event.callId, event);
if (event.name !== "refund.create") continue;
if (refundCall) {
findings.push({
level: "block",
rule: "NO_DUPLICATE_REFUND",
message: `检测到重复退款调用：${
refundCall.callId} 与 ${
event.callId}`,
});
}
refundCall = event;
const amount = asNumber(event.args.amountCents);
const orderId = String(event.args.orderId ?? "");
if (!identityVerified) {
findings.push({
level: "block",
rule: "VERIFY_BEFORE_REFUND",
message: "调用 refund.create 前未完成身份核验",
});
}
if (!order || order.id !== orderId || order.state !== "PAID") {
findings.push({
level: "block",
rule: "VALID_ORDER_REQUIRED",
message: "退款调用没有对应的已支付订单证据",
});
}
if (!policy?.approved) {
findings.push({
level: "block",
rule: "POLICY_REQUIRED",
message: "退款调用前没有获得规则引擎批准",
});
}
if (
amount === undefined ||
!order ||
!policy ||
amount > order.refundableCents ||
amount > policy.maxRefundCents
) {
findings.push({
level: "block",
rule: "REFUND_AMOUNT_BOUNDARY",
message: `退款金额越界：请求=${
amount}，订单可退=${
order?.refundableCents
}，规则上限=${
policy?.maxRefundCents}`,
});
}
}
if (event.type === "tool.result") {
const call = calls.get(event.callId);
if (!call) {
findings.push({
level: "block",
rule: "ORPHAN_TOOL_RESULT",
message: `工具结果 ${
event.callId} 找不到对应调用`,
});
continue;
}
const data = asRecord(event.data);
if (call.name === "order.get" && event.ok) {
const refundableCents = asNumber(data.refundableCents);
if (typeof data.id === "string" && refundableCents !== undefined) {
order = {
id: data.id,
refundableCents,
state: String(data.state ?? ""),
};
}
}
if (call.name === "identity.verify") {
identityVerified = event.ok && data.verified === true;
}
if (call.name === "refund.policy" && event.ok) {
const maxRefundCents = asNumber(data.maxRefundCents);
if (maxRefundCents !== undefined) {
policy = {
approved: data.approved === true,
maxRefundCents,
};
}
}
if (call.name === "refund.create") {
refundResult = event;
}
}
if (event.type === "assistant.message") {
finalReply = event.content;
}
}
if (refundCall && (!refundResult || !refundResult.ok)) {
findings.push({
level: "block",
rule: "REFUND_RESULT_REQUIRED",
message: "已发起退款，但没有成功的工具结果作为业务证据",
});
}
if (/退款已成功|已为您退款/.test(finalReply) && !refundResult?.ok) {
findings.push({
level: "block",
rule: "NO_FALSE_SUCCESS_CLAIM",
message: "最终回复宣称退款成功，但轨迹没有成功证据",
});
}
const refundId = asRecord(refundResult?.data).refundId;
if (refundResult?.ok && refundId && !finalReply.includes(String(refundId))) {
findings.push({
level: "warn",
rule: "WEAK_USER_EVIDENCE",
message: "退款已成功，但最终回复未提供可核验退款编号",
});
}
return {
passed: !findings.some((item) => item.level === "block"),
findings,
};
}
CI 调用只需要把失败变成非零退出码：
const report = evaluateRefundTrace(traceEvents);
console.table(report.findings);
if (!report.passed) {
process.exit(1); // 阻止该 Agent 配置、Skill 或提示词进入下一环境
}
这段代码真正解决的是：提示词、模型、工具、Skill 任意一个变更后，团队仍能用业务不变量守住底线。
模型换了可以测，提示词改了可以测，退款插件升级了同样可以测。测试资产不再是一组“问什么、答什么”，而是一份可执行的业务合同。
四、逐步落地，不要让 AI 评测先变成新的噪声源
我建议按四个阶段推进：
| 阶段 | 做什么 | 退出条件 |
|---|---|---|
| 轨迹观察 | 选 20–30 个高风险任务，只记录轨迹，不拦发布 | 每条关键工具调用都能关联任务、参数和结果 |
| 离线回归 | 用 Mock 工具重放任务，先验证退款、权限、金额等硬规则 | 硬规则零“无法解释”的失败 |
| 预发门禁 | 将硬规则接进 CI；语气、效率、推荐质量只做告警 | 团队能处理失败报告，而不是绕过门禁 |
| 生产抽检 | 对真实流量做脱敏采样，新增事故自动沉淀为回归任务 | 新事故能在下一轮回归中复现 |
这里最容易犯的错，是把“LLM 打分低”直接当阻断条件。
真正适合阻断的，应该是权限越界、错误写入、重复扣款、金额越界、工具结果缺失这类确定性业务不变量。至于回答是否自然、步骤是否更优、耗时是否更低，先作为趋势指标和人工复核对象。
五、测试开发工程师接下来该补什么能力
DeepSeek Harness 带来的变化，不是让测试人员去背一套新命令，而是要求测试资产升级：
- 把真实故障改写成可重放的任务夹具；
- 为工具调用设计 Mock、状态机和幂等性验证；
- 把“最终答案断言”升级为“过程、边界、轨迹断言”；
- 为模型、Prompt、Skill、工具配置建立可回归的版本组合；
- 把每次线上异常沉淀为新的质量合同，而不是只留一张缺陷单。
未来最有价值的 AI 测试开发，不是谁最会让 Agent 跑起来，而是谁能回答这个问题：
当 Agent 做错事时，我们能不能准确知道它错在模型、上下文、Skill、工具、权限，还是业务规则本身？
DeepSeek Harness 让这个问题第一次有了工程化的入口。但别急着把它当成万能测试平台：先让它留下足够完整的轨迹，再用测试工程的方式，把轨迹变成质量证据。
把执行交给 Agent，把证据和判断留在工程体系里。AI 测试真正要守住的，不是一次回答，而是一条业务链路。
