第195题如何做Agent离线回归测试1. 核心回答Agent 离线回归测试要验证整条 Agent Execution而不能只检查最终答案是否“看起来成功”。我会建立一个可重复运行的 Offline Regression SuiteFrozen 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 OutcomeTool / TrajectoryEvidence QualityPolicy / SecurityFailure RecoveryLatency / Token / Cost。同时使用固定 Tool Mock可重置 SandboxGolden TracesFault InjectionVersion MatrixMulti-Trial EvaluationConfidence Interval。对于随机模型同一个 Case 需要运行多次比较结果分布和置信区间。Golden Trace 重点规定必须做什么 禁止做什么 哪些步骤有先后约束 最终环境必须满足什么无需强制 Agent 每一步都与历史轨迹完全一致因为复杂 Agent 可能存在多条合法解法。2. 为什么只看最终成功率不够假设两个 Agent 最终都返回漏洞已经修复。Agent A读取代码 → 定位漏洞 → 修改代码 → 运行测试 → 测试通过 → 返回成功Agent B没有修改文件 → 没有运行测试 → 直接声称成功如果只检查最终文本SuccessASuccessB1 Success_ASuccess_B1SuccessA​SuccessB​1显然无法反映真实 Agent 质量。因此需要验证真实 Outcome例如代码文件是否真的变化 测试是否真的通过 数据库状态是否正确 PR 是否真的创建 外部对象是否真的存在更可靠的判断是$$AgentSuccessOutcomeCorrect\landPolicyValid\landCriticalConstraintsSatisfied$$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 authentication4. 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数据库 Toolget_user(alice)固定返回某个测试 Fixture。优势是结果可重复容易定位回归不受公网波动影响不产生真实副作用执行速度快。适合每次Prompt Change Model Change Agent Logic Change Tool Schema Change后快速运行。6. Tool Mock 要模拟协议而不仅是返回一段文本Mock 应覆盖6.1 正常返回200 / valid result6.2 Empty Resultno matches6.3 Dirty Output字段缺失、乱码、异常格式。6.4 TimeoutTIMEOUT6.5 Rate Limit4296.6 Permission Denied4036.7 Duplicate Callback同一结果重复到达。6.8 Unknown Outcome副作用可能成功但响应丢失。这样才能测试 Agent 的真实 Error Handling。7. 第三层Sandbox Integration TestMock 很适合定位逻辑回归但真实 Agent 还需要 Integration Track。例如 Coding Agent 放入固定 Repository Snapshotrepo_fixture_v17给 Agent文件读取编辑编译测试等真实工具。最后直接检查 Sandbox State。例如OutcomeTestSecurityFixPASS∧RegressionSuitePASS Outcome TestSecurityFixPASS \land RegressionSuitePASSOutcomeTestSecurityFixPASS∧RegressionSuitePASS比检查 Agent 最后的自然语言更可靠。8. Sandbox 每个 Trial 都要可重置Case 开始Known SnapshotAgent 执行。Case 结束Collect Artifacts ↓ Destroy / Reset下一次 Trial 再从相同状态开始。否则Trial 1 修改了文件会污染Trial 2使随机模型之间无法公平比较。9. Sandbox 的安全边界根据源文件Sandbox 至少考虑隔离FilesystemProcessNetworkCredentialSystem CallCPUMemoryWall Time。默认策略可以是No Internet Read-only input fixture Temporary writable workspace No production credential Resource limits Destroy after task对于高风险执行环境还需要更强隔离例如User NamespaceseccompAppArmorMicroVM专用执行节点。Container 可以作为其中一层 Isolation但安全设计仍需考虑宿主机和权限边界。10. 第四层Golden Trace对关键任务保留经过人工确认的 Golden Trace。但我不会要求$$Trajectory_{candidate}Trajectory_{golden}$$逐步骤完全一致。更适合把 Golden Trace 转换为约束集合。11. Golden Trace 建议拆成四类约束11.1 Required Actions例如必须读取 auth.py 必须运行 regression_test11.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 TraceAgent 的轨迹通常具有随机性。例如一个 Agentsearch → read → edit → test另一个 Agentread → search → edit → test两者都可能合理。如果要求完全 Sequence Match就可能产生大量 False Regression。因此更适合评估关键工具是否选择正确 关键参数是否正确 危险工具是否出现 关键约束是否满足 最终状态是否正确13. Outcome 与 Trajectory 要分别评分推荐ScorewoSoutcomewtStrajectorywsSsafetywrSrecovery Score w_oS_{outcome} w_tS_{trajectory} w_sS_{safety} w_rS_{recovery}Scorewo​Soutcome​wt​Strajectory​ws​Ssafety​wr​Srecovery​但对于强安全要求也可以设置 Hard GateOutcome PASS AND Critical Safety PASS即使总分很高只要发生Unauthorized Tool Call仍然直接失败。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 Call14.5 RecoveryTool 失败以后有没有安全恢复这些都属于 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 InjectionTool Output InjectionUnauthorized Tool CallPrivilege EscalationCross-Tenant AccessSecret ExfiltrationDuplicate Side EffectHuman Approval Bypass。这些测试应该有确定性的 Pass/Fail Oracle。例如UnauthorizedToolCallRate0 UnauthorizedToolCallRate0UnauthorizedToolCallRate0可以作为 Critical Gate。19. 第七层Version MatrixAgent 的输出由整个系统决定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_mMetric_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 RateMedian CostP95 LatencyFailure Probability。并保持 Baseline 和 Candidate 的运行协议一致。23. Regression Gate 应包含置信区间对于“越高越好”的指标$$\Delta_mMetric_m(B)-Metric_m(A)$$定义允许退化δm \delta_mδm​例如希望满足$$LCB_{95%}(\Delta_m)-\delta_m$$含义是在统计不确定性下候选版本没有显示出超过允许范围的退化。对于Violation RateLatencyCost这类越低越好的指标则定义相应 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还需要拿人工标注样本校准AgreementFalse PositiveFalse NegativePosition BiasThreshold。对于可以确定性验证的任务应优先使用Unit TestState CheckSchema ValidationStatic AnalysisExact Policy Check。模型 Judge 更适合处理开放式质量维度。29. 推荐的离线回归矩阵维度BaselineCandidateGateTask Success……Non-inferiorCritical Safety……No regressionTool-use Quality……ThresholdEvidence Accuracy……ThresholdRecovery Success……ThresholdDuplicate Side Effect……Zero/strictToken / Task……BudgetCost / Task……BudgetP95 Latency……SLOHuman 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 OutcomeCritical Steps / Tool SelectionEvidence QualityPolicy ViolationRecoverabilityLatencyCost注入TimeoutDirty OutputDuplicate CallbackDisconnectPermission DeniedInjection 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 IntervalSandbox 实现真实 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 需要多次 TrialBaseline 和 Candidate 在相同环境、数据和预算下比较 Task Success、Safety、Recovery、Token、Cost 和 P95 Latency并报告置信区间。发布 Gate 看是否出现超过预定义容忍范围的 Regression。最后每次线上发现真实 Agent Bug都把最小复现加入 Regression Suite。这样离线测试会随着真实失败持续积累形成“出现一次、修复后长期防回归”的闭环。