DeepSeek Harness 不是测试工具：它会把 AI 测试推进到“验轨迹”的阶段

从一个退款 Agent 的越权风险，看 AI 测试开发该如何逐步落地

凌晨的大促结束后，售后 Agent 还在处理退款。

回归集全部通过：它能识别订单号，能解释退款规则，也能在大多数对话里正确回答“已为您发起退款”。但真正危险的缺陷不在答案里——某次会话中，它在身份核验完成前就调用了退款工具；另一次，它把“工具调用失败”说成了“退款已成功”。

传统自动化看见的是页面、接口和数据库；普通 LLM 评测看见的是“回答像不像正确答案”。可对一个能调用工具、改变业务状态的 Agent 来说，真正需要验证的是：

它是否在正确的上下文里，以正确的顺序，调用了正确的工具，并留下了可复盘的证据。

这是我对 DeepSeek Harness 的核心判断：它未来不会替代 Playwright、pytest 或接口自动化框架；它更可能成为 AI 测试的“运行时可观测层”和“可执行质量合同载体”。

DeepSeek Harness 的官方设计是“能力皆插件”，模型、工具、Skills、会话、沙箱、存储、循环等组件都可替换；更关键的是，一次运行中模型看到的上下文、工具调用及结果等会进入可追溯轨迹。对测试而言，这意味着原先黑盒的 Agent 行为，第一次有机会被拆成可断言、可回放、可回归的工程对象。[DeepSeek Harness 官方说明]

一、AI 测试的对象，已经不只是“最终答案”

过去我们写自动化用例，大体是：

输入 → 接口/页面响应 → 断言结果

接入 Agent 后，链路变成：

用户任务 → 上下文注入 → 模型规划 → 工具调用 → 工具结果
       → 再规划 → 最终回复 → 真实业务状态变化

如果测试只断言最终回复，就会出现一种很危险的“假通过”：

• 回复说“已退款”，实际 refund.create 调用失败；
• 退款金额正确，但身份核验发生在退款之后；
• Agent 调用了过期插件，却凭历史上下文编出正确答案；
• 同一订单被重复调用两次退款工具，页面仍只显示一次成功。

所以，AI 测试至少要同时验证四类合同：

Harness 的价值，不是让 Agent “更会测”，而是让测试团队终于能问出过去问不了的问题：这个结论是怎么得出来的？它中间做过什么？为什么这次和上次不一样？

二、不要一上来把 Harness 当生产框架，要先把它当“证据采集器”

DeepSeek Harness 仍处于开发者预览阶段，官方明确提示后续会有破坏兼容性变更；它也尚未经过安全审计，不能作为生产环境唯一安全控制。项目 README 安全说明

因此，落地的第一原则不是“把所有 Agent 接进 Harness”，而是：

先让 Harness 记录证据，再让测试系统根据证据做判断。

在测试架构上，我建议把原始轨迹和质量判断分开保存：

DSH 原始轨迹
    ↓
版本固定的适配层
    ↓
标准化事件（tool.call / tool.result / assistant.message）
    ↓
质量规则引擎
    ↓
CI 门禁、回归报告、缺陷复盘

这样做有两个好处：

1. DSH 的内部插件和日志格式变化时，只改适配层，不推翻全部测试规则；
2. 原始轨迹保持不可篡改，质量判断可随规则迭代重新计算。

三、一个能进 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 评测先变成新的噪声源

我建议按四个阶段推进：

这里最容易犯的错，是把“LLM 打分低”直接当阻断条件。

真正适合阻断的，应该是权限越界、错误写入、重复扣款、金额越界、工具结果缺失这类确定性业务不变量。至于回答是否自然、步骤是否更优、耗时是否更低，先作为趋势指标和人工复核对象。

五、测试开发工程师接下来该补什么能力

DeepSeek Harness 带来的变化，不是让测试人员去背一套新命令，而是要求测试资产升级：

• 把真实故障改写成可重放的任务夹具；
• 为工具调用设计 Mock、状态机和幂等性验证；
• 把“最终答案断言”升级为“过程、边界、轨迹断言”；
• 为模型、Prompt、Skill、工具配置建立可回归的版本组合；
• 把每次线上异常沉淀为新的质量合同，而不是只留一张缺陷单。

未来最有价值的 AI 测试开发，不是谁最会让 Agent 跑起来，而是谁能回答这个问题：

当 Agent 做错事时，我们能不能准确知道它错在模型、上下文、Skill、工具、权限，还是业务规则本身？

DeepSeek Harness 让这个问题第一次有了工程化的入口。但别急着把它当成万能测试平台：先让它留下足够完整的轨迹，再用测试工程的方式，把轨迹变成质量证据。

把执行交给 Agent，把证据和判断留在工程体系里。AI 测试真正要守住的，不是一次回答，而是一条业务链路。