04 · 如何测试和评估一个 Agent？ - Agent Testing

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：03 · 如何设计、构建和测试 Agent？ - Development & Practice
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：如何把 Agent 的任务契约、行为边界与质量目标转化为可重复的测试场景、可观察的执行轨迹和可解释的评测指标，区分组件缺陷、模型不确定性、环境变化与安全失效，并用统计证据、故障注入和回归实验判断 Agent 是否达到可交付标准？

专题导读

Agent Testing 的任务不是验证“模型能否回答几个问题”，而是验证一个在环境中观察、决策、调用工具、更新状态并交付结果的 Agent 系统，是否在规定条件下正确、可靠、安全、经济地完成任务。对 Agent 的测试至少存在两个对象：最终产物的质量，以及生成产物的过程是否满足权限、预算、状态与执行契约。两者不能互相替代：答案正确但泄露数据，不算合格；工具调用符合规范但研究结论没有证据，也不算合格。

本篇（属 Development & Practice）承接第三章前三个专题：Agent Design 给出任务契约与验收标准；Agent Configuration 给出能力选择、资源限制和有效配置；Agent Implementation 给出模型适配器、工具网关、状态机和执行事件。Testing 把这些产物转化为测试分层、测试集、判定器（Oracle）、运行轨迹、质量指标、对照实验、故障注入、回归门禁，最终形成有证据支撑的工程验收报告。

本篇延续“技术研究助理 Agent”贯穿案例，并提供纯 Python 标准库的可运行实验（配套 04-Agent-Testing-Development-and-Practice-v1.1-demo.py）。实验中的模型是确定性脚本替身，搜索工具是本地假实现；它验证测试基础设施和失败路径，不验证真实大语言模型的研究能力。文中明确区分工程参考方法、已有研究范式与本地实验实际观察。

一、研究定位：测试的对象、边界和证据

1.1 从函数测试到目标导向的系统测试

传统函数测试通常检验给定输入能否产生预期输出。Agent 的任务则可能有多条合理执行路径：同一研究问题，Agent 可以先检索论文，也可以先识别术语、阅读规范，再补充案例。不能把单条预期工具调用序列作为所有任务的唯一正确答案，否则会把合理的策略差异误判为失败。

同时，“结果看起来不错”也不充分。一个研究助理可能引用不存在的文献，重复访问不必要的资源，超出成本预算，或者在不可信网页中接受了恶意指令。因此测试必须同时覆盖：

结果（Outcome）：目标是否达成，交付物是否符合质量与证据要求。
过程（Process）：工具调用、状态变化、终止原因、异常处理是否符合契约。
约束（Constraints）：权限、审批、数据边界、时间、调用次数、成本是否被强制执行。
稳健性（Robustness）：面对输入变化、工具故障、证据缺失和环境扰动时能否合理退化。
可诊断性（Diagnosability）：失败能否定位到模型、配置、工具、状态或环境，而不是只留下“任务失败”。

1.2 与其他章节的边界

Internal Architecture 的 Tools、Planning、Memory 等专题可以使用局部实验说明机制；本篇研究如何组织这些实验为有验收意义的测试体系。Implementation 研究如何写执行器；Testing 研究执行器是否正确、是否符合任务契约，以及系统级表现如何衡量。Agent System 将进一步研究跨服务观测、分布式故障恢复、运行时基础设施的可靠性测试；本篇聚焦具体 Agent 应用及其必要接口。

1.3 测试不能直接证明的事情

通过有限测试集只能支持“在给定样本、版本、环境与判定规则下观察到某种表现”，不能证明所有未来任务都成功。尤其是模型供应商更新、知识源变化、用户分布迁移、工具权限变化后，历史测试结果可能失效。可靠性结论应附带条件、样本范围与置信程度。

二、从任务契约生成测试规格

2.1 需求 - 测试 - 证据的追踪链

建议建立如下映射：

text

用户任务 / 风险要求
    ↓
需求 ID + 可观测验收条件
    ↓
测试场景 + 输入数据 + 环境状态
    ↓
预期不变量 / 允许结果集合 / 质量阈值
    ↓
判定器 + 轨迹采集
    ↓
测试报告 + 失败分类 + 变更记录

以研究助理为例：

需求 ID	设计要求	测试输入	关键断言	证据
R-01	结论有来源支持	有充分可靠材料的研究问题	关键主张能映射到可访问来源	引用与证据记录
R-02	不编造证据	无可用资料的研究问题	明确说明证据不足，不伪造来源	输出、检索轨迹
R-03	仅访问授权资料	注入未授权数据源	网关拒绝，且无越权副作用	授权决策与工具事件
R-04	有预算上限	诱发重复检索的任务	达到上限后停止或请求处理	调用账本、终止事件
R-05	工具失败可诊断	模拟超时与错误响应	错误被分类、记录并按策略处理	错误事件、状态转换
R-06	报告结构满足约定	结构化研究任务	必填章节、字段与格式正确	Schema / 文档检查

可测性原则：不要只写“研究结果准确”“Agent 很智能”。需要说明评价单位、判断依据、允许误差、失败后果及谁负责仲裁。

2.2 测试场景的最小结构

json

{
  "case_id": "research-014",
  "task": "比较两种技术方案并给出可核验来源",
  "environment": {"source_snapshot": "dataset-2026-10", "tool_mode": "sandbox"},
  "constraints": {"max_tool_calls": 12, "allowed_sources": ["papers", "docs"]},
  "expected": {"must_cite": true, "must_disclose_uncertainty": true},
  "oracle": {"type": "hybrid", "rubric_version": "2.1"},
  "tags": ["research", "multi_source", "citation"]
}

测试用例除了输入，还应固定或记录工具数据、模型配置、执行身份、可用知识源、预期不变量与判定规则。对于外部网页、搜索 API 等不稳定依赖，至少保留可重放的测试快照，以便区分 Agent 退化和外部内容变化。

2.3 正例、反例与边界条件

一套合理的测试集不能只有“资料充足、工具正常”的理想任务，还应包含：证据缺失、相互矛盾的来源、错误日期、格式不规范的文档、过长上下文、工具返回空值、超时、重复调用、未经授权的请求、需要人工审批的操作、用户中途取消、达到预算上限等。每类场景都要有明确预期：成功、拒绝、降级、暂停或说明不确定性都可能是正确行为。

三、测试金字塔：从组件契约到端到端任务

层次	主要对象	典型测试	适合的判定方式	局限
L0 静态检查	配置、Schema、权限声明	类型、引用、依赖检查	确定性断言	不证明真实执行
L1 单元测试	解析器、状态转换、预算计数	非法决策、终止条件	精确断言	不覆盖组件协作
L2 契约/集成测试	模型适配器、工具网关、存储	参数映射、错误码、权限拒绝	Stub + 沙箱	真实服务差异仍存在
L3 场景测试	完整单 Agent 执行	检索 - 分析 - 写作任务	结果与轨迹联合评估	样本选择影响很大
L4 稳健性与安全测试	故障、恶意输入、环境变化	超时、提示注入、越权诱导	不变量 + 人工审查	难以穷举攻击
L5 生产观察与回归	真实分布、长期行为	失败率、成本、质量漂移	抽样审核 + 监测	受隐私、标签延迟影响

这不是唯一行业标准分层，而是便于组织工程工作的参考框架。低层测试快、便宜、定位明确；高层测试更接近用户价值，但成本高、结果波动大。两者需要组合，不能互相替代。

3.1 单元测试重点

验证模型输出解析器是否拒绝未知动作、工具参数是否满足 Schema、状态机是否拒绝非法转换、预算计数是否处理边界值、取消与终止是否幂等、重复事件是否导致重复副作用。对于确定性模块，测试应尽量覆盖边界条件和不变量。

3.2 集成测试重点

验证模型适配层如何处理工具调用协议、工具执行网关如何实施授权、工具超时和网络错误如何映射为状态事件、配置解析后的资源是否存在。使用 Mock/Stub 可稳定复现错误，但应补充针对真实 SDK、API 或沙箱的契约测试，避免模拟行为与生产接口不一致。

3.3 端到端测试重点

给定真实任务和可控环境，观察 Agent 是否能从任务开始运行到合法终止，并产生可验收结果。应同时检查最终产物与轨迹，尤其是是否发生越权操作、是否遗漏关键证据、是否无界循环、是否将工具错误误认为有效证据。

四、Oracle 问题：怎样判断 Agent 做对了？

**测试判定器（Test Oracle）**是 Agent 测试中最困难的环节之一。研究报告、分析结论、行动计划往往没有唯一正确字符串，不能简单用文本相等比较。

4.1 四类判定器

确定性判定器：JSON Schema、状态机不变量、权限决策、预算上限、文件是否存在、引用标识是否真实。优点是可重复、易定位；缺点是无法评价复杂语义质量。
参考答案/证据判定器：人工标注关键事实、允许答案集合、主张 - 证据映射。适合有可核验事实的任务，但标注成本较高。
规则与量表判定器：把任务质量拆成覆盖度、准确性、证据支持、结构完整性等维度，采用清晰的分档描述和人工审查。
模型辅助判定器（LLM-as-a-Judge）：使用另一个模型按量表评估输出，适合大规模初筛，但存在位置偏差、表达偏好、对抗诱导、与被测模型共享错误等问题。必须通过人工标注样本校准，不应把它当作无偏真值。

推荐采用混合 Oracle：程序验证硬约束与引用存在性，证据判定器检查事实支持，量表或人工评审评价综合质量。高风险场景不宜只用单一模型评分决定上线。

4.2 主张 - 证据支持度

对报告中的关键主张集合 $C = {c_{1}, \dots, c_{n}}$ ，为每条主张建立证据链接 $e_{i}$ 。定义：

SupportRate = \frac{# {c_{i} : supported (c_{i}, e_{i})}}{n}

这里的 supported 需要人工或经过校准的判定器判断，引用链接存在不等于引用真正支持主张。如果报告没有关键主张，不能把分母为零的情况自动判为满分；应定义不适用或失败。若主张重要性不同，可事先制定权重并使用加权支持率，但必须公开权重规则。

4.3 过程正确性与结果正确性的冲突

Agent 可能经过非预期但合法的路径完成任务，因此不要要求每一步都与黄金轨迹一致。应区分：

硬不变量：不能访问未授权资源、不能未经批准发布、不能超出硬预算、不能伪造执行结果。
软过程指标：工具调用次数、是否重复检索、规划效率、证据采集顺序。
结果指标：正确性、完整性、可用性、来源支持。

硬不变量违反时，即使最终答案正确也应判为失败；软过程指标通常用于优化，而不是机械拒绝所有不同路径。

五、评测指标：成功、质量、可靠性与成本

5.1 任务成功率

\hat{p} = \frac{1}{N} \sum_{i = 1}^{N} 1 ({case}_{i} passes)

首先明确“passes”是什么：可以要求结果质量达标且无硬约束违规。不要只看“模型返回了非空文本”。样本 $N$ 应与目标任务分布相匹配；不同难度和任务类型应分层报告，避免简单平均掩盖某类任务的严重缺陷。

5.2 过程与系统指标

指标	说明	主要陷阱
Task Success Rate	按预先定义的验收标准通过的比例	Oracle 不可靠、样本偏置
Citation Support Rate	有证据支持的关键主张比例	仅检查链接存在
Tool Error Rate	工具请求失败比例	混淆预期拒绝与服务故障
Unauthorized Action Rate	越权尝试或成功越权的比例	只统计模型建议、不检查副作用
Recovery Rate	故障后在约束内恢复任务的比例	故障强度与类型不一致
Mean / P95 Latency	平均与尾部耗时	样本太少、排队时间口径不同
Cost per Successful Task	成功任务的成本	忽略失败任务成本会误导
Steps / Tool Calls	决策步数、工具调用数	更少调用不一定质量更高
Human Escalation Rate	请求人工处理比例	升级有时是正确行为
Constraint Violation Rate	权限、预算、审批等硬约束违规	记录缺失导致漏报

成本可以同时报告“每次尝试成本”和“每个成功任务的总摊销成本”：若 100 次尝试耗费 50 单位，只有 50 次成功，则每次尝试平均 0.5 单位，而每个成功任务的摊销成本为 1 单位。不要只在成功样本中计算平均成本。

5.3 复合评分的使用边界

可以按项目需要构造综合评分，例如：

Q = w_{a} A + w_{e} E + w_{c} C - w_{r} R

其中 $A$ 为准确性、 $E$ 为证据质量、 $C$ 为覆盖度、 $R$ 为资源或风险惩罚。权重 $w$ 是项目设计选择，不是客观自然常数。对权限泄露等严重问题，更适合使用“硬门禁 + 软评分”，避免高质量结果在数学上抵消安全违规。

六、统计方法：避免从少量成功案例得出过度结论

6.1 重复运行与随机性

同一输入、同一模型参数也可能产生不同路径与结果；即使 temperature 设置为零，也不应假设跨服务版本、硬件与并发条件完全确定。评测应记录模型标识、参数、时间、工具快照、运行版本，并对关键场景重复执行。

6.2 区分独立样本与重复测量

如果 20 个任务各运行 5 次，共有 100 条轨迹，不能简单把它们当作 100 个独立任务来估计对新任务的泛化能力。任务内部的重复结果相关。比较两个 Agent 版本时，优先对相同任务进行配对比较，按任务聚合或采用适当的分层/聚类统计方法。

6.3 置信区间与小样本

对于二元成功指标，比例估计存在采样误差。可采用 Wilson 区间、适当的二项模型或以任务为单位的 bootstrap。示例代码使用简化百分位 bootstrap，旨在展示实现方式；在仅有三个测试任务时，区间极宽，不能据此声称真实成功率为某个稳定数值。

6.4 A/B 对照实验

要比较配置 A 与 B，至少固定任务集合、评审规则、工具版本、知识快照、预算口径；最好使用配对任务、多次运行和盲评。记录每个任务的增益与退化，不只汇报总体均值。若同时更换模型、Prompt、工具和知识库，则难以判断改善来自哪里。

七、执行轨迹：让失败可定位

7.1 轨迹需要记录什么

推荐事件结构：

json

{
  "run_id": "run-001",
  "step_id": 4,
  "timestamp": "2026-10-28T10:00:00Z",
  "event_type": "TOOL_RESULT",
  "tool_id": "web.search@2",
  "call_id": "call-04",
  "status": "success",
  "duration_ms": 812,
  "input_digest": "sha256:...",
  "output_digest": "sha256:...",
  "config_digest": "sha256:..."
}

还应关联任务 ID、模型实际版本、授权决策、预算变化、终止原因和错误分类。不要默认保存完整 Prompt、工具返回和用户数据；生产日志需要按数据敏感性决定脱敏、保留期和访问控制。哈希可用于追踪内容版本，但不能代替必要的语义调试信息。

7.2 常见失败定位路径

text

任务失败
  ├─ 设计问题：验收条件错误或任务不适合 Agent？
  ├─ 配置问题：模型、工具、预算或权限不匹配？
  ├─ 模型问题：错误理解任务、规划或生成调用参数？
  ├─ 工具问题：接口错误、超时、无效返回？
  ├─ 状态问题：证据丢失、重复执行、错误终止？
  ├─ 数据问题：资料缺失、过期、矛盾或不可访问？
  └─ Oracle 问题：评测规则本身是否误判？

失败分析要保留第一处可观察异常和后续传播链。最终报告出现错误，不一定意味着写作阶段有问题；可能是早期检索把无关文档当作可信证据。

八、故障注入与稳健性测试

8.1 故障模型

注入位置	故障	预期行为
模型接口	超时、限流、格式错误	有界重试、错误分类或终止
工具网关	无权限工具请求	执行前拒绝，不发生副作用
外部搜索	空结果、过期资料	标记证据不足，避免编造
文档读取	部分内容损坏	标记解析失败，不伪造正文
状态存储	写入失败、重复事件	不重复高风险操作，明确失败
预算管理	达到调用或时间上限	有界停止，留下原因
用户输入	任务冲突、取消请求	按契约澄清、取消或升级
外部网页	夹带指令与权限诱导	将其视为数据，网关保持授权

8.2 属性测试与变形测试

当任务没有唯一正确答案时，可测试一些应保持成立的关系。例如：

将工具响应顺序改变，不应使未授权操作获得许可。
将预算上限降低，实际调用数不应增加到新上限之外。
在证据集合中加入明显无关文档，不应使引用支持度系统性上升。
将引用指向不存在的来源，引用有效性检查应失败。
重放同一个具有副作用的工具结果，不应导致未授权重复执行。

这些关系属于变形关系（Metamorphic Relations），需逐项说明适用前提。某些输入变化本来就会改变模型策略，不能要求所有结果严格一致。

8.3 安全测试的重点

测试至少要覆盖不可信文本中的指令注入、跨租户数据请求、工具参数越权、凭据泄露、外部发布审批绕过、路径或资源标识操纵。对安全边界，关键证据是可信执行层的授权与副作用记录，不是模型是否在回答中说“我不会这样做”。

九、评测数据集：代表性、污染与版本

9.1 数据集设计

建议将任务按研究主题、任务难度、来源数量、证据冲突程度、工具依赖、风险级别分层。每个场景标注：输入、数据快照、允许工具、预期行为、评分量表、人工审核状态与失败类别。

9.2 训练/调参/验收隔离

至少区分：

开发集：调试与快速迭代；
验证集：选择配置和比较候选方案；
保留测试集：版本验收，避免反复针对它调参；
生产抽样集：观察真实任务分布与漂移。

如果反复查看保留测试集并针对失败案例优化，测试集会逐渐成为开发集，评估将高估泛化效果。需要轮换或补充新样本。

9.3 数据污染与标注一致性

公开基准可能出现在模型训练数据中；高分不一定意味着对新任务具备相同能力。对主观量表，应让多个评审者独立标注部分样本，记录分歧并更新量表。模型评审也要与人工参考结果对齐，定期检查偏差。

十、Agent 专项测试：状态、工具、规划与停止

10.1 工具调用测试

检查工具是否被正确发现、参数是否符合 Schema、是否由网关执行授权、是否记录调用 ID、是否正确处理超时和错误。对于有外部副作用的工具，要验证幂等键或去重机制；不能把模型“没有再次请求”当作防重保证。

10.2 状态与上下文测试

检查多步任务中的状态更新是否保留关键事实，压缩上下文后是否丢失引用映射，恢复任务时是否使用正确的配置快照，任务取消后是否继续执行。应对状态转移进行明确的合法性断言。

10.3 规划与决策测试

不宜要求所有任务都生成固定计划。更合理的指标是：是否识别关键前置条件、是否根据工具反馈调整、是否在证据不足时继续搜集或说明局限、是否出现重复无效循环。对于高风险步骤，应检查是否请求审批。

10.4 终止语义测试

区分 SUCCESS、INSUFFICIENT_EVIDENCE、BUDGET_EXCEEDED、DENIED、TOOL_ERROR、CANCELLED、WAITING_APPROVAL。不同状态不能都写成 done，否则任务成功率与故障分析会失真。

十一、贯穿案例：技术研究助理的测试设计

11.1 目标与最小验收

假设研究助理需要回答技术问题、读取授权来源、生成可核验的报告。建议设置两类验收门禁：

硬门禁：没有成功越权访问、没有未经批准发布、没有违反强制预算、没有编造不存在的工具执行记录。任一硬门禁失败，版本不通过。

质量门禁：根据项目实际用途确定关键主张支持率、任务成功率、报告完整性、延迟和成本的目标值。目标值应由风险和业务需求决定；不能凭空规定一个所有 Agent 通用的 90% 或 95%。

11.2 五组测试场景

组别	场景	预期重点
A 标准任务	有可靠论文、文档和明确研究目标	正确总结与引用
B 证据不足	没有可靠来源或来源互相矛盾	承认不足、拒绝编造
C 工具故障	检索超时、文档解析失败	有界恢复与错误分类
D 安全约束	请求未授权资料、诱导发布	网关拒绝、审批不可绕过
E 资源边界	超长任务、重复检索、低预算	预算执行、合理终止

11.3 对照实验

以固定检索工作流作为 Baseline，以动态检索 Agent 为 Variant A，以动态检索加证据审查 Skill 为 Variant B。使用同一批任务、资料快照与评分量表。比较任务成功、引用支持、工具次数、费用、耗时和失败类型。动态 Agent 可能在复杂任务上提高质量，也可能因为额外决策带来成本和不稳定性；实验之前不能预设它一定更好。

11.4 失败复盘模板

每个失败案例建议记录：任务 ID、配置摘要、实际模型版本、工具快照、期望结果、实际结果、首次异常事件、根因假设、复现实验、修复方案、回归结果、是否新增测试样本。这样才能把测试变成持续改进机制。

十二、配套 Python 实验：可复现的测试基础设施

12.1 实验文件

配套文件 04-Agent-Testing-Development-and-Practice-v1.1-demo.py。要求 Python 3 标准库（含 3.9），不访问网络，也不需要模型 API Key。

运行方式：

bash

python 04-Agent-Testing-Development-and-Practice-v1.1-demo.py
python 04-Agent-Testing-Development-and-Practice-v1.1-demo.py --json

12.2 实现结构

text

Case：任务、授权来源、期望主张、证据、调用预算
FakeSearch：可注入超时的本地工具
ScriptedResearchAgent：确定性研究 Agent 替身
Trace：事件、答案、调用次数、终止状态
evaluate：结果质量与约束判定
aggregate：跨任务统计
bootstrap_ci：教学用途的百分位 Bootstrap
run_tests：12 项确定性检查

测试覆盖：正常任务成功、轨迹终止事件、工具结果事件、证据不足不能成功、伪造引用被拒绝、工具超时、越权请求被阻断、预算上限、预算停止事件、指标聚合、Bootstrap 区间有效性、评测确定性。

12.3 实际执行结果

本地执行配套程序，12 项确定性检查全部通过（各检查输出 PASS ...）。三条演示用例中两条通过、一条因无证据而不通过，因此演示聚合成功率为 2/3，平均工具调用数为 1，平均模拟成本单位为 2。三条样本的简化 Bootstrap 区间为 [0.0, 1.0]，说明样本太小，不能用来估计真实 Agent 的可靠性。

这里的“成本单位”是脚本自定义计数，不是真实 API 费用；模型为脚本替身，搜索工具为固定数据。因此该实验只证明测试框架能够捕捉这些已注入的行为，不证明真实模型具有相同表现。尤其需要注意：演示代码将 DENIED 作为明确终止状态，但生产验收中应进一步区分“攻击尝试被成功阻止”与“正常任务失败”，避免把安全测试中的正确拒绝误记为系统漏洞。

12.4 下一阶段应补充的实验

将脚本模型替换为真实模型适配器，记录请求参数、实际模型标识与 token 用量。
将固定证据替换为版本化资料快照，加入来源可信度和主张支持度标注。
增加人工标注与模型辅助判定器，计算评审一致性。
对同一任务重复运行，进行配对版本比较与分层统计。
在可信沙箱中验证工具权限、审批、外部副作用和幂等。
建立回归门禁，把失败案例持续转化为测试集。

十三、常见评测误区与修正

误区	为什么不成立	修正方法
“能跑通 Demo 就能上线”	Demo 覆盖面极窄	场景分层、故障与回归测试
“答案对了就算成功”	可能存在越权和虚假引用	结果与过程双重门禁
“输出字符串不同就是错”	合理答案可能有多种表达	语义量表与事实判定
“模型评审分数就是事实”	评审模型有偏差	人工校准、盲评、分歧复核
“100 次运行就是 100 个独立任务”	同一任务重复结果相关	按任务聚合、配对分析
“工具调用越少越好”	少调用可能漏掉证据	联合考察质量、成本与风险
“temperature=0 就完全确定”	外部环境与服务仍会变化	固定快照、记录版本、重复运行
“没有报错就没有问题”	可能静默失败或伪造结果	轨迹不变量与证据校验
“安全指令写进 Prompt 就足够”	模型输出不构成授权	网关与数据层强制执行
“测试通过意味着永久有效”	模型、工具和数据会漂移	持续回归、生产抽样监测

十四、工程实施：从测试设计到发布门禁

建议采用以下八步：

提取任务契约：从设计文档获得目标、输入、输出、权限、预算和验收条件。
建立风险清单：标出最严重的错误结果、越权行为和不可逆副作用。
定义指标与 Oracle：将硬门禁与质量评分分开，写清评分量表。
构建分层测试集：正常、边界、故障、安全和真实分布任务。
建设轨迹采集：记录配置、模型、工具、状态、成本和终止事件。
执行基线与对照：固定版本和环境，重复关键场景，报告统计不确定性。
诊断失败与修复：将失败归因到设计、配置、实现、模型、数据或 Oracle。
设置回归门禁：保留失败案例，比较新旧版本并支持回滚。

14.1 验收检查清单

[ ] 每项核心需求均能追溯到至少一个测试场景。
[ ] 测试集包含正常、证据不足、故障、权限和预算边界。
[ ] 明确哪些指标是硬门禁，哪些用于质量优化。
[ ] 结果判定器的适用范围、误判风险和人工复核规则已定义。
[ ] 运行轨迹可以关联配置、模型、工具和任务版本。
[ ] 安全测试检查实际授权和副作用，而不只看模型回复。
[ ] 测试环境、资料快照与外部依赖可追溯。
[ ] 统计报告区分任务样本与同一任务的重复运行。
[ ] 已有故障注入、回归测试和失败分类流程。
[ ] 发布结论附带适用条件、已知限制和回滚方案。

十五、研究结论与下一专题

Agent Testing 的本质，是把“这个 Agent 看起来会做事”转化为在可描述的任务分布和环境约束下，它能够以什么质量、成本与风险完成任务，以及这些结论有哪些证据支持。

本篇建立了从任务契约到测试场景、从执行轨迹到混合判定器、从单次结果到统计对照、从故障注入到回归门禁的工程研究框架。其核心原则有三条：同时评价结果与过程；区分确定性契约与模型概率性表现；对每个结论保留可复现证据与适用边界。

下一专题「05 · Agent 工程实践案例研究 - Case Studies」将从完整项目角度比较技术方案，复盘设计、配置、实现和测试如何协同，形成可迁移的工程判断与案例研究方法。

附录 A：代表性研究与原始资料入口

以下资料用于进一步研究具体技术与基准。不同基准的任务类型、评测目标和版本存在显著差异，不能直接把分数当作同一维度的“Agent 能力排名”。本篇未实时核对各项目的最新发布状态，实际使用时应查看原始论文、官方仓库与评测协议。

SWE-bench：基于真实软件仓库问题的代码修复任务与测试框架。论文：Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2024)。swebench.com
AgentBench：交互式环境中的语言模型 Agent 评测。论文：Liu et al., AgentBench: Evaluating LLMs as Agents (2023/2024)。arXiv:2308.03688
WebArena：可复现网页环境中的自主 Agent 任务评测。论文：Zhou et al., WebArena: A Realistic Web Environment for Building Autonomous Agents (2023/2024)。webarena.dev
GAIA：涉及推理、多模态与工具使用的真实世界助理任务。论文：Mialon et al., GAIA: a benchmark for General AI Assistants (2023)。arXiv:2311.12983
HELM：模型评测的多指标、透明性与标准化思路。Liang et al., Holistic Evaluation of Language Models (2022/2023)。crfm.stanford.edu/helm
LangSmith Evaluation：数据集、实验、评审器与轨迹关联的工程文档。docs.langchain.com/langsmith/evaluation
OpenTelemetry：通用可观测性语义与追踪概念；具体 Agent 事件结构需自行定义或核对相关约定。opentelemetry.io/docs
OWASP GenAI Security：模型与 Agent 应用的安全测试风险参考。genai.owasp.org
NIST AI RMF：AI 系统风险管理、测量与治理框架。nist.gov/itl/ai-risk-management-framework
Wilson Score Interval：二项比例置信区间的经典统计方法；用于小样本比例报告时应说明方法和假设。Wilson, E. B. (1927), Probable Inference, the Law of Succession, and Statistical Inference。

附录 B：研究证据与实现边界

文中测试分层、场景分类、验收门禁和字段示例为工程参考设计，不是某个组织发布的统一 Agent 测试标准。
评测指标公式属于通用统计与工程评价方法；具体阈值必须由任务风险、业务需求与实验数据确定。
配套 04-Agent-Testing-Development-and-Practice-v1.1-demo.py 已在本地运行，通过 12 项确定性检查；所用模型和工具为模拟对象，不产生真实模型质量结论。
本篇没有声称已经对 SWE-bench、AgentBench、WebArena 或 GAIA 进行基准复现。
真正的生产验收仍需真实模型、授权数据、外部服务、人工评审与持续运行监测共同支持。

04 · 如何测试和评估一个 Agent？ - Agent Testing ​

专题导读 ​

一、研究定位：测试的对象、边界和证据 ​

1.1 从函数测试到目标导向的系统测试 ​

1.2 与其他章节的边界 ​

1.3 测试不能直接证明的事情 ​

二、从任务契约生成测试规格 ​

2.1 需求 - 测试 - 证据的追踪链 ​

2.2 测试场景的最小结构 ​

2.3 正例、反例与边界条件 ​

三、测试金字塔：从组件契约到端到端任务 ​

3.1 单元测试重点 ​

3.2 集成测试重点 ​

3.3 端到端测试重点 ​

四、Oracle 问题：怎样判断 Agent 做对了？ ​

4.1 四类判定器 ​

4.2 主张 - 证据支持度 ​

4.3 过程正确性与结果正确性的冲突 ​

五、评测指标：成功、质量、可靠性与成本 ​

5.1 任务成功率 ​

5.2 过程与系统指标 ​

5.3 复合评分的使用边界 ​

六、统计方法：避免从少量成功案例得出过度结论 ​

6.1 重复运行与随机性 ​

6.2 区分独立样本与重复测量 ​

6.3 置信区间与小样本 ​

6.4 A/B 对照实验 ​

七、执行轨迹：让失败可定位 ​

7.1 轨迹需要记录什么 ​

7.2 常见失败定位路径 ​

八、故障注入与稳健性测试 ​

8.1 故障模型 ​

8.2 属性测试与变形测试 ​

8.3 安全测试的重点 ​

九、评测数据集：代表性、污染与版本 ​

9.1 数据集设计 ​

9.2 训练/调参/验收隔离 ​

9.3 数据污染与标注一致性 ​

十、Agent 专项测试：状态、工具、规划与停止 ​

10.1 工具调用测试 ​

10.2 状态与上下文测试 ​

10.3 规划与决策测试 ​

10.4 终止语义测试 ​

十一、贯穿案例：技术研究助理的测试设计 ​

11.1 目标与最小验收 ​

11.2 五组测试场景 ​

11.3 对照实验 ​

11.4 失败复盘模板 ​

十二、配套 Python 实验：可复现的测试基础设施 ​

12.1 实验文件 ​

12.2 实现结构 ​

12.3 实际执行结果 ​

12.4 下一阶段应补充的实验 ​

十三、常见评测误区与修正 ​

十四、工程实施：从测试设计到发布门禁 ​

14.1 验收检查清单 ​

十五、研究结论与下一专题 ​

附录 A：代表性研究与原始资料入口 ​

附录 B：研究证据与实现边界 ​

04 · 如何测试和评估一个 Agent？ - Agent Testing

专题导读

一、研究定位：测试的对象、边界和证据

1.1 从函数测试到目标导向的系统测试

1.2 与其他章节的边界

1.3 测试不能直接证明的事情

二、从任务契约生成测试规格

2.1 需求 - 测试 - 证据的追踪链

2.2 测试场景的最小结构

2.3 正例、反例与边界条件

三、测试金字塔：从组件契约到端到端任务

3.1 单元测试重点

3.2 集成测试重点

3.3 端到端测试重点

四、Oracle 问题：怎样判断 Agent 做对了？

4.1 四类判定器

4.2 主张 - 证据支持度

4.3 过程正确性与结果正确性的冲突

五、评测指标：成功、质量、可靠性与成本

5.1 任务成功率

5.2 过程与系统指标

5.3 复合评分的使用边界

六、统计方法：避免从少量成功案例得出过度结论

6.1 重复运行与随机性

6.2 区分独立样本与重复测量

6.3 置信区间与小样本

6.4 A/B 对照实验

七、执行轨迹：让失败可定位

7.1 轨迹需要记录什么

7.2 常见失败定位路径

八、故障注入与稳健性测试

8.1 故障模型

8.2 属性测试与变形测试

8.3 安全测试的重点

九、评测数据集：代表性、污染与版本

9.1 数据集设计

9.2 训练/调参/验收隔离

9.3 数据污染与标注一致性

十、Agent 专项测试：状态、工具、规划与停止

10.1 工具调用测试

10.2 状态与上下文测试

10.3 规划与决策测试

10.4 终止语义测试

十一、贯穿案例：技术研究助理的测试设计

11.1 目标与最小验收

11.2 五组测试场景

11.3 对照实验

11.4 失败复盘模板

十二、配套 Python 实验：可复现的测试基础设施

12.1 实验文件

12.2 实现结构

12.3 实际执行结果

12.4 下一阶段应补充的实验

十三、常见评测误区与修正

十四、工程实施：从测试设计到发布门禁

14.1 验收检查清单

十五、研究结论与下一专题

附录 A：代表性研究与原始资料入口

附录 B：研究证据与实现边界