如何做Agent离线回归测试？-开发者社区

第195题：如何做Agent离线回归测试？

1. 核心回答

Agent 离线回归测试要验证整条 Agent Execution，而不能只检查最终答案是否“看起来成功”。

我会建立一个可重复运行的 Offline Regression Suite：

Frozen Eval Tasks ↓ Versioned Eval Harness ↓ Deterministic Tool Mock / Resettable Sandbox ↓ Agent Trial ↓ Trace + Artifacts + Final Environment State ↓ Outcome Grading + Trajectory Grading + Safety Grading + Recovery Grading + Cost/Latency Grading ↓ Baseline vs Candidate ↓ Statistical Regression Gate

核心检查六个维度：

Task Outcome；
Tool / Trajectory；
Evidence Quality；
Policy / Security；
Failure Recovery；
Latency / Token / Cost。

同时使用：

固定 Tool Mock；
可重置 Sandbox；
Golden Traces；
Fault Injection；
Version Matrix；
Multi-Trial Evaluation；
Confidence Interval。

对于随机模型，同一个 Case 需要运行多次，比较结果分布和置信区间。

Golden Trace 重点规定：

必须做什么 禁止做什么 哪些步骤有先后约束 最终环境必须满足什么

无需强制 Agent 每一步都与历史轨迹完全一致，因为复杂 Agent 可能存在多条合法解法。

2. 为什么只看最终成功率不够

假设两个 Agent 最终都返回：

漏洞已经修复。

Agent A：

读取代码 → 定位漏洞 → 修改代码 → 运行测试 → 测试通过 → 返回成功

Agent B：

没有修改文件 → 没有运行测试 → 直接声称成功

如果只检查最终文本：

SuccessA=SuccessB=1 Success_A=Success_B=1SuccessA=SuccessB=1

显然无法反映真实 Agent 质量。

因此需要验证真实 Outcome，例如：

代码文件是否真的变化 测试是否真的通过 数据库状态是否正确 PR 是否真的创建 外部对象是否真的存在

更可靠的判断是：

$$
AgentSuccess

OutcomeCorrect
\land
PolicyValid
\land
CriticalConstraintsSatisfied
$$

3. 第一层：建立冻结的 Regression Dataset

测试集应来源于：

历史真实任务；
线上失败案例；
Bug Regression；
安全红队案例；
Edge Cases；
人工构造的关键场景。

每个 Case 至少保存：

case_id task_input initial_environment expected_outcome required_constraints forbidden_actions grader_config risk_level tags dataset_version

例如：

case_id: security_fix_001 task: 修复认证绕过漏洞 initial_state: repo snapshot X expected_outcome: empty password rejected required: run security regression test forbidden: disable authentication

4. Capability Eval 与 Regression Eval 要区分

Capability Eval 回答：

新 Agent 能做到什么？

可以包含很多困难案例，Pass Rate 较低也有研究价值。

Regression Eval 回答：

以前已经稳定完成的能力，现在有没有退化？

这类测试应该长期保持较高 Pass Rate。

一个 Capability Case 被稳定解决以后，可以进入：

Regression Suite

以后模型、Prompt、Retriever 或 Tool 升级时持续执行。

5. 第二层：固定 Tool Mock

对于高频 CI，我会先建立 Deterministic Tool Mock。

例如：

search_code("auth")

固定返回：

fixture_auth_v3

数据库 Tool：

get_user("alice")

固定返回某个测试 Fixture。

优势是：

结果可重复；
容易定位回归；
不受公网波动影响；
不产生真实副作用；
执行速度快。

适合每次：

Prompt Change Model Change Agent Logic Change Tool Schema Change

后快速运行。

6. Tool Mock 要模拟协议，而不仅是返回一段文本

Mock 应覆盖：

6.1 正常返回

200 / valid result

6.2 Empty Result

no matches

6.3 Dirty Output

字段缺失、乱码、异常格式。

6.4 Timeout

TIMEOUT

6.5 Rate Limit

6.6 Permission Denied

6.7 Duplicate Callback

同一结果重复到达。

6.8 Unknown Outcome

副作用可能成功，但响应丢失。

这样才能测试 Agent 的真实 Error Handling。

7. 第三层：Sandbox Integration Test

Mock 很适合定位逻辑回归，但真实 Agent 还需要 Integration Track。

例如 Coding Agent 放入固定 Repository Snapshot：

repo_fixture_v17

给 Agent：

文件读取；
编辑；
编译；
测试；

等真实工具。

最后直接检查 Sandbox State。

例如：

Outcome=TestSecurityFix=PASS∧RegressionSuite=PASS Outcome = TestSecurityFix=PASS \land RegressionSuite=PASSOutcome=TestSecurityFix=PASS∧RegressionSuite=PASS

比检查 Agent 最后的自然语言更可靠。

8. Sandbox 每个 Trial 都要可重置

Case 开始：

Known Snapshot

Agent 执行。

Case 结束：

Collect Artifacts ↓ Destroy / Reset

下一次 Trial 再从相同状态开始。

否则：

Trial 1 修改了文件

会污染：

Trial 2

使随机模型之间无法公平比较。

9. Sandbox 的安全边界

根据源文件，Sandbox 至少考虑隔离：

Filesystem；
Process；
Network；
Credential；
System Call；
CPU；
Memory；
Wall Time。

默认策略可以是：

No Internet Read-only input fixture Temporary writable workspace No production credential Resource limits Destroy after task

对于高风险执行环境，还需要更强隔离，例如：

User Namespace；
seccomp；
AppArmor；
MicroVM；
专用执行节点。

Container 可以作为其中一层 Isolation，但安全设计仍需考虑宿主机和权限边界。

10. 第四层：Golden Trace

对关键任务保留经过人工确认的 Golden Trace。

但我不会要求：

$$
Trajectory_{candidate}

Trajectory_{golden}
$$

逐步骤完全一致。

更适合把 Golden Trace 转换为约束集合。

11. Golden Trace 建议拆成四类约束

11.1 Required Actions

例如：

必须读取 auth.py 必须运行 regression_test

11.2 Forbidden Actions

例如：

禁止关闭认证 禁止读取生产凭据 禁止执行网络上传

11.3 Partial Order

例如：

EditCode≺RunTests≺ClaimSuccess EditCode \prec RunTests \prec ClaimSuccessEditCode≺RunTests≺ClaimSuccess

意味着必须先修改，再测试，再宣告完成。

11.4 Outcome

最终：

security_test = PASS existing_tests = PASS

这样允许：

Path A

和：

Path B

两种不同但正确的求解路径。

12. 为什么不适合逐 Token 匹配 Golden Trace

Agent 的轨迹通常具有随机性。

例如一个 Agent：

search → read → edit → test

另一个 Agent：

read → search → edit → test

两者都可能合理。

如果要求完全 Sequence Match，就可能产生大量 False Regression。

因此更适合评估：

关键工具是否选择正确 关键参数是否正确 危险工具是否出现 关键约束是否满足 最终状态是否正确

13. Outcome 与 Trajectory 要分别评分

14. 关键步骤如何评估

可以从 Trace 中提取：

tool_name tool_args tool_result timestamp state_before state_after

然后检查：

14.1 Tool Selection

调用了正确工具吗？

14.2 Parameter Accuracy

参数是否正确？

14.3 Ordering

调用顺序是否满足依赖？

14.4 Efficiency

是否存在大量重复 Tool Call？

14.5 Recovery

Tool 失败以后有没有安全恢复？

这些都属于 Trajectory Quality。

15. Evidence Quality 也要加入

对于 RAG / Security Agent，最终 Label 正确仍可能来自错误理由。

例如：

结论：存在 SQL Injection

结果碰巧正确，

但引用的代码完全无关。

所以还要评估：

Claim ↓ Evidence Reference ↓ Source / Chunk / Artifact

是否真实支持结论。

可以单独报告：

EvidenceAccuracy EvidenceAccuracyEvidenceAccuracy

或 Claim-Level Support Rate。

16. 第五层：Fault Injection

源文件明确要求主动注入异常。

至少包含：

Timeout Dirty Output Duplicate Callback Disconnect Permission Denied Prompt Injection

还可以增加：

429 5xx Stale Result Malformed JSON Partial Tool Success Worker Crash Lost Response

目的在于验证：

Failure→SafeRecovery Failure \rightarrow SafeRecoveryFailure→SafeRecovery

而非只验证 Happy Path。

17. 一个具体故障案例

假设 Agent 调用：

create_ticket()

服务端已经成功创建，

但返回响应时网络断开。

Agent 看到：

TIMEOUT

如果它直接重新调用：

create_ticket()

可能产生重复工单。

正确回归测试应该检查：

TIMEOUT ↓ UNKNOWN ↓ Reconcile external state ↓ 发现 ticket 已存在 ↓ 不重复创建

因此：

可恢复性属于离线回归的一等指标。

18. 第六层：安全回归

至少加入：

Prompt Injection；
Tool Output Injection；
Unauthorized Tool Call；
Privilege Escalation；
Cross-Tenant Access；
Secret Exfiltration；
Duplicate Side Effect；
Human Approval Bypass。

这些测试应该有确定性的 Pass/Fail Oracle。

例如：

UnauthorizedToolCallRate=0 UnauthorizedToolCallRate=0UnauthorizedToolCallRate=0

可以作为 Critical Gate。

19. 第七层：Version Matrix

Agent 的输出由整个系统决定：

AgentVersion=(Model,Prompt,Tools,Retriever,Knowledge,Harness,Runtime) AgentVersion= ( Model, Prompt, Tools, Retriever, Knowledge, Harness, Runtime )AgentVersion=(Model,Prompt,Tools,Retriever,Knowledge,Harness,Runtime)

因此每次测试至少记录：

model_revision prompt_version tool_schema_version retriever_version knowledge_snapshot agent_harness_commit eval_dataset_version grader_version runtime_image

否则出现 Regression 时，很难知道变化来自哪里。

20. 推荐做 Baseline / Candidate 比较

例如当前生产版本：

A AA

候选版本：

B BB

在完全相同的：

Eval Cases Fixtures Sandbox Tool Configuration Grader Budget

上同时运行。

计算：

$$
\Delta_m

Metric_m(B)-Metric_m(A)
$$

不要仅保存 Candidate 的绝对分数。

因为：

92%

本身无法回答：

相对当前生产版本到底变好了还是退化了？

21. 第八层：随机模型要进行 Multi-Trial Evaluation

同一个 Agent：

同任务 同模型 同配置

也可能多次产生不同结果。

因此每个 Case 可以执行：

R RR

次 Trial。

例如得到：

PASS PASS FAIL PASS PASS

估计：

$$
\hat p_{success}

\frac{4}{5}
$$

然后在整个 Regression Suite 上计算总体和分 Slice 结果。

具体 Trial 数应根据成本、任务方差和所需统计精度确定。

22. 不应该用“最好一次”作为回归结果

如果跑：

10 1010

次，

只挑：

best run

会引入 Selection Bias。

应该预先定义聚合方式，例如：

Mean Success Rate；
Median Cost；
P95 Latency；
Failure Probability。

并保持 Baseline 和 Candidate 的运行协议一致。

23. Regression Gate 应包含置信区间

对于“越高越好”的指标：

$$
\Delta_m

Metric_m(B)-Metric_m(A)
$$

定义允许退化：

δm \delta_mδm

例如希望满足：

$$
LCB_{95%}(\Delta_m)

-\delta_m
$$

含义是：

在统计不确定性下，候选版本没有显示出超过允许范围的退化。

对于：

Violation Rate；
Latency；
Cost；

这类越低越好的指标，则定义相应 Upper Bound。

实际δm\delta_mδm必须来自业务风险要求。

24. 回归门禁不能只看 Overall Success

建议至少拆成：

Overall Tool-use Safety Recovery CWE / Task Type Simple vs Long-Horizon Normal vs Fault Injection

例如：

Overall: 95% → 96% Permission-Denied Recovery: 98% → 62%

整体分数虽然提高，

但这仍然属于明显 Regression。

25. Trace 是离线回归的核心 Artifact

根据源文件，一次任务应建立 End-to-End Trace。

模型调用、检索、工具、队列和状态提交分别形成 Span。

例如：

Task Trace ├─ Retrieval Span ├─ Model Span ├─ Tool Span ├─ Tool Span ├─ Queue Span ├─ State Commit Span └─ Grader Span

每个 Span 记录：

version latency tokens cost retry cache error_class policy_decision artifact_ref

这样失败以后才能定位：

到底是哪一个组件回归了？

26. Latency 应使用分位数

不能只报告：

Average latency

至少报告：

P50, P95, P99 P50,\ P95,\ P99P50,P95,P99

对于 Agent 还可以拆分：

$$
T_{total}

T_{queue}
+
T_{retrieval}
+
T_{prompt}
+
T_{model}
+
T_{tool}
+
T_{recovery}
$$

这样才能判断模型升级以后：

Task Success ↑

是否同时导致：

P95 latency ↑ Cost ↑

27. Golden Case 需要持续维护

发现线上真实 Bug 后：

Production Failure ↓ Root Cause ↓ Minimal Reproduction ↓ Add Regression Case

修复通过后，这个 Case 永久进入 Regression Suite。

于是测试集会逐渐积累：

Previously Broken → Fixed → Must Stay Fixed

这也是 Agent Regression Suite 最重要的长期价值。

28. Grader 自身也需要验证

如果使用 LLM-as-a-Judge，

还需要拿人工标注样本校准：

Agreement；
False Positive；
False Negative；
Position Bias；
Threshold。

对于可以确定性验证的任务，应优先使用：

Unit Test；
State Check；
Schema Validation；
Static Analysis；
Exact Policy Check。

模型 Judge 更适合处理开放式质量维度。

29. 推荐的离线回归矩阵

维度	Baseline	Candidate	Gate
Task Success	…	…	Non-inferior
Critical Safety	…	…	No regression
Tool-use Quality	…	…	Threshold
Evidence Accuracy	…	…	Threshold
Recovery Success	…	…	Threshold
Duplicate Side Effect	…	…	Zero/strict
Token / Task	…	…	Budget
Cost / Task	…	…	Budget
P95 Latency	…	…	SLO
Human Escalation	…	…	Monitor

这样发布决策就不依赖单个综合分数。

30. 一个推荐的 CI 流程

Pull Request ↓ Unit Tests ↓ Fast Deterministic Agent Evals ↓ Critical Safety Regression ↓ Baseline/Candidate Diff ↓ Pass? ├─ No → Block / Review └─ Yes ↓ Extended Sandbox Eval ↓ Fault Injection ↓ Statistical Regression Report ↓ Release Candidate

成本较高的 Sandbox / Multi-Trial 测试可以按 Nightly、Release Candidate 或重要模型升级运行。

31. 什么结果会推翻“离线回归体系有效”的主张

31.1 最终答案通过，但环境 Outcome 错误

说明 Grader 过度依赖自然语言输出。

31.2 合法替代路径大量被 Golden Trace 判失败

说明轨迹约束过度严格。

31.3 Tool Mock 全部通过，真实 Sandbox 大量失败

说明 Mock 与真实系统差距过大。

31.4 Prompt Injection、Timeout、重复回调没有进入测试集

说明 Failure Coverage 不充分。

31.5 单次运行的 PASS/FAIL 经常随 Trial 改变

说明需要 Multi-Trial 和统计聚合。

31.6 Overall 指标稳定，但关键安全 Slice 严重下降

说明聚合指标掩盖 Regression。

31.7 线上故障反复出现，却没有转成新的 Regression Case

说明测试体系没有形成闭环。

这些情况都需要调整 Eval Suite 和发布 Gate。

32. 当前资料能够支持到什么程度

根据原始题目表格，第195题明确支持：

使用固定 Tool Mock / Sandbox；
使用 Golden Traces；
做扰动和故障注入；
建立 Version Matrix；
同时评估：
- Task Outcome；
- Critical Steps / Tool Selection；
- Evidence Quality；
- Policy Violation；
- Recoverability；
- Latency；
- Cost；
注入：
- Timeout；
- Dirty Output；
- Duplicate Callback；
- Disconnect；
- Permission Denied；
- Injection Attack；
随机输出需要 Multi-Run；
使用 Distribution / Confidence Interval 比较；
Sandbox 需要隔离文件、进程、网络、凭据、系统调用和资源；
Trace 应覆盖 Model、Retrieval、Tool、Queue 和 State Commit；
记录 Version、Latency、Token/Cost、Retry、Cache、Error Class 和 Policy Decision；
验收还需要覆盖越权、重复执行、依赖故障、人工接管和 Rollback；
易错点是只看最终成功率，以及只做 Demo 手测。

当前源文件没有提供：

实际 Eval Case 数量；
Golden Trace 数量；
Trial 次数；
Regression Threshold；
当前 Baseline Pass Rate；
实际 Confidence Interval；
Sandbox 实现；
真实 Fault-Injection 结果；
实际线上 Regression 数据。

这些数据不能被描述成已经完成的实验结果。

33. 面试时可以压缩成下面这段

我会把 Agent 离线回归分成确定性 Mock、真实 Sandbox 和故障注入三层。固定 Tool Mock 用于高频 CI，隔离模型、Prompt、Tool Selection 和编排逻辑的变化；Sandbox 从固定 Snapshot 启动，真正执行文件、代码和工具，然后根据最终环境状态判断任务有没有完成。

评估时我不会只看最终回答。每个 Trial 都保留完整 Trace，同时检查 Outcome、关键 Tool Call、Evidence、Policy Violation、Recovery、Latency 和 Cost。Golden Trace 用来规定必须动作、禁止动作和关键先后约束，但允许 Agent 采用不同的合法路径。

对于 Timeout、Dirty Output、Duplicate Callback、Disconnect、Permission Denied 和 Prompt Injection，我会主动做 Fault Injection，验证 Agent 是否进入正确的 Retry、Degraded、Reconcile、Human Review 或 Stop 路径。

模型有随机性，所以同一 Case 需要多次 Trial，Baseline 和 Candidate 在相同环境、数据和预算下比较 Task Success、Safety、Recovery、Token、Cost 和 P95 Latency，并报告置信区间。发布 Gate 看是否出现超过预定义容忍范围的 Regression。

最后，每次线上发现真实 Agent Bug，都把最小复现加入 Regression Suite。这样离线测试会随着真实失败持续积累，形成“出现一次、修复后长期防回归”的闭环。

第195题：如何做Agent离线回归测试？

1. 核心回答

2. 为什么只看最终成功率不够

$$AgentSuccess

3. 第一层：建立冻结的 Regression Dataset

4. Capability Eval 与 Regression Eval 要区分

5. 第二层：固定 Tool Mock

6. Tool Mock 要模拟协议，而不仅是返回一段文本

6.1 正常返回

6.2 Empty Result

6.3 Dirty Output

6.4 Timeout

6.5 Rate Limit

6.6 Permission Denied

6.7 Duplicate Callback

6.8 Unknown Outcome

7. 第三层：Sandbox Integration Test

8. Sandbox 每个 Trial 都要可重置

9. Sandbox 的安全边界

10. 第四层：Golden Trace

$$Trajectory_{candidate}

11. Golden Trace 建议拆成四类约束

11.1 Required Actions

11.2 Forbidden Actions

11.3 Partial Order

11.4 Outcome

12. 为什么不适合逐 Token 匹配 Golden Trace

13. Outcome 与 Trajectory 要分别评分

14. 关键步骤如何评估

14.1 Tool Selection

14.2 Parameter Accuracy

14.3 Ordering

14.4 Efficiency

14.5 Recovery

15. Evidence Quality 也要加入

16. 第五层：Fault Injection

17. 一个具体故障案例

18. 第六层：安全回归

19. 第七层：Version Matrix

20. 推荐做 Baseline / Candidate 比较

$$\Delta_m

21. 第八层：随机模型要进行 Multi-Trial Evaluation

$$\hat p_{success}

22. 不应该用“最好一次”作为回归结果

23. Regression Gate 应包含置信区间

$$\Delta_m

24. 回归门禁不能只看 Overall Success

25. Trace 是离线回归的核心 Artifact

26. Latency 应使用分位数

$$T_{total}

27. Golden Case 需要持续维护

28. Grader 自身也需要验证

29. 推荐的离线回归矩阵

30. 一个推荐的 CI 流程

31. 什么结果会推翻“离线回归体系有效”的主张

31.1 最终答案通过，但环境 Outcome 错误

31.2 合法替代路径大量被 Golden Trace 判失败

31.3 Tool Mock 全部通过，真实 Sandbox 大量失败

31.4 Prompt Injection、Timeout、重复回调没有进入测试集

31.5 单次运行的 PASS/FAIL 经常随 Trial 改变

31.6 Overall 指标稳定，但关键安全 Slice 严重下降

31.7 线上故障反复出现，却没有转成新的 Regression Case

32. 当前资料能够支持到什么程度

33. 面试时可以压缩成下面这段

向量库时代结束了吗？ai-memory 的 file-first 设计与 Chroma 可编程记忆，两条路线谁更香？

BFE mod_tcp_keepalive 基础配置详解：DataPath 与 OpenDebug 的配置方法与实现原理

实现舒尔特注意力训练器：算法设计与前端实践

Octant 中的 OpenAPI v2 协议缓冲模型：gnostic openapiv2 的工程结构与落地方式

juniper_actix 版本演进全解析：actix-web 4.0 集成、WebSocket 订阅协议重构与 Context 兼容性迁移指南

Sharp Edges 分析：基于 Trail of Bits skills 仓库的 API 与配置安全审计方法论

$$
AgentSuccess

$$
Trajectory_{candidate}

$$
\Delta_m

$$
\hat p_{success}

$$
\Delta_m

$$
T_{total}