简介：本文围绕 AI Agent 测试与评估展开，解释为什么自然语言输出让传统断言失效，并系统介绍行为测试、人机评审、轨迹评估与指标量化等常见方法。读者可以理解 Agent 评估的核心难点、可落地的测试策略以及如何避免“看起来合理但实际不可用”的评估偏差。
普通函数的测试通常非常直接。例如：
def add(a: int, b: int) -> int:return a + bassert add(1, 2) == 3
这里的输入、输出、执行路径都是确定的，断言结果也唯一。只要函数逻辑不发生变化，测试结果就稳定可复现。
但 AI Agent 的行为并不具备这种确定性。Agent 的输出通常不是单一数值或固定字符串，而是自然语言文本、工具调用序列、任务规划，甚至是多轮对话中的某一环节。更关键的是，同一个输入在不同轮次运行时，可能生成语义相近但措辞不同的结果。
例如：
输入：请帮我写一封回复客户的邮件，说明发货延迟。第一次输出：尊敬的客户，非常抱歉，您的订单将延迟两天发货。第二次输出：您好，由于仓库调度原因，您的包裹预计推迟 48 小时发出，敬请谅解。
从传统断言角度看，这两个字符串完全不相等。但从任务完成情况看，二者都正确传达了“发货延迟”这一核心信息。
因此，Agent 测试的核心难点并不在于“代码是否正确执行”，而在于“行为是否满足预期”。这要求测试方法从确定性校验转向概率性、语义性和过程性评估。
Agent 测试与评估是指通过一组系统化方法，判断 AI Agent 在开放任务中的输出质量、行为合理性、工具使用正确性以及任务完成度。它不是简单地比较输出文本是否一致，而是从语义、流程、约束满足、用户反馈等多个维度进行综合判断。
从技术视角看，Agent 评估可以理解为：在非确定性的自然语言交互环境中，为 Agent 的行为建立可观测、可量化、可复用的质量信号。
从业务视角看，Agent 评估要回答的问题是：这个 Agent 是否值得部署到真实业务中？它在多大比例的任务上表现可靠？哪些失败模式需要人工兜底？
从使用视角看，Agent 评估帮助开发者决定：当前版本能否上线？下一次迭代应该优先修复什么？引入记忆、工具或人机协作模块后是否真的变好了？
传统软件测试依赖三个前提：输入可枚举、输出可预期、行为可隔离。Agent 在这三个层面都面临挑战。
用户向 Agent 发出的自然语言指令几乎无限。即使从语法上限定为“邮件处理”场景，用户也可能说“帮我看看这封邮件重不重要”“回复一下，语气正式一点”“先判断是不是垃圾邮件，不是的话再回”等表达。输入组合无法用固定用例完全覆盖。
同一任务可能存在多种合理回复。一个回复是否“好”，取决于语境、用户偏好、业务风险甚至文化习惯。断言某个输出必须等于某个固定文本，会把大量可接受结果误判为失败。
Agent 通常不是单步计算，而是“理解输入→规划→调用工具→观察结果→再规划→生成最终输出”的多步过程。中间任何一步出现偏差，都可能导致最终结果异常。仅测试最终输出，无法定位问题发生在推理、规划、工具选择还是生成环节。
因此，Agent 测试需要从“验证结果”转向“验证行为”，从“一次性断言”转向“多维度评估”。
一个相对完整的 Agent 评估体系，通常覆盖以下几个维度。
任务完成度是最直接的评价指标。它衡量 Agent 是否完成了用户指定的目标，而不关心过程是否优雅。
例如，在邮件分类任务中，任务完成度可以定义为：是否将邮件正确分类为“需要回复”“仅需知悉”“垃圾邮件”等类别。这个维度通常通过人工标注或规则比对来量化。
输出质量关注生成内容本身是否通顺、准确、符合场景要求。对于邮件回复，输出质量可能包括：
输出质量评价往往需要借助人工评分或大型模型辅助判断。
当 Agent 拥有工具调用能力时，评估还需要关注它是否选择了正确的工具、参数是否合理、调用顺序是否符合逻辑。例如，查询天气时应调用天气接口，而不是本地数据库；发送邮件前应先确认收件人，而不是默认使用最近联系人。
工具调用错误通常比文本生成错误更危险，因为它可能直接产生不可逆的外部副作用。
安全维度关注 Agent 是否执行了危险操作、泄露敏感信息或产生违规内容。例如，邮件 Agent 不应自动将内部讨论转发给外部联系人，也不应在未确认的情况下群发消息。
安全测试通常需要设计对抗性用例，主动诱导 Agent 执行不应执行的操作，以验证其边界控制能力。
响应效率包括推理耗时、工具调用次数、生成长度等。即使输出正确，如果每次任务都要执行十几次无效工具调用，也会显著影响可用性。效率评估在批量处理和高并发场景下尤为重要。
行为测试不直接比较输出文本，而是定义若干行为规则，检查输出是否满足这些规则。
示例：
def test_reply_contains_apology(email_reply: str):assert any(word in email_reply for word in ["抱歉", "歉意", "敬请谅解"])
这种测试的优点是直观、易写、可批量执行。缺点是规则覆盖面有限，而且容易与自然语言的多样性产生冲突。例如，一封合理回复可能使用“非常遗憾”而不是“抱歉”，导致测试误报。
人工评审是最可靠的评估方式之一。评审者根据预设标准对 Agent 输出进行打分，例如 1 到 5 分。人工评审适合作为最终上线前的关卡，也常用于构建评估基准数据集。
人工评审的优点是能够捕捉语义、语气和场景适配性等难以量化的维度。缺点是成本高、速度慢、评审者之间可能存在主观差异。
为降低主观性，通常需要制定明确的评审标准，并让多名评审者独立打分后取平均值。百度智能云等平台也提供数据标注与人工审核相关能力，可用于支撑这类评估流程。
轨迹评估关注 Agent 完成任务过程中的每一步决策，而不仅是最终输出。它包括：
轨迹评估能够帮助定位具体失败环节。例如，如果 Agent 最终回复错误是因为第一步邮件分类错误，那么仅看最终输出很难发现问题；通过检查轨迹，开发者可以快速发现是分类模块或提示策略需要调整。
自动评分器使用另一个模型对 Agent 输出进行质量打分。其基本思路是：由评分模型阅读任务描述、Agent 输出以及参考标准，然后给出分数和理由。
自动评分器的优点是速度快、成本低、可以覆盖大量样本。缺点是评分模型自身也存在偏差，可能对某些风格或结构过于敏感或过于宽容。因此，自动评分通常用于开发阶段的快速反馈，上线前的最终判断仍建议结合人工评审。
为 Agent 构建一个持续增长的回归测试集，是团队实践中较为有效的方式。每次发现新的失败案例，就将其加入测试集，并在后续迭代中自动运行。这样可以逐步积累对 Agent 行为边界的认知。
测试集中的每条数据通常包含：
例如：
{"input": "帮我回复这封邮件，对方询问产品价格。","should_do": ["生成回复", "包含价格信息"],"should_not_do": ["直接发送", "编造价格"]}
对于开发者或小型团队，可以按照“先人工、再自动、后回归”的路径逐步建设。
第一步，先定义 20 到 50 个典型任务，人工评估当前 Agent 的表现。重点不是追求分数多高，而是识别主要失败模式。
第二步，将典型任务固化为测试集，并抽象出可以自动检查的行为规则。例如“回复必须包含道歉词”“不得泄露用户手机号”“工具调用次数不超过 5 次”等。
第三步，引入自动评分器进行大规模回归。当自动化评估结果与人工评审结果的相关性达到可接受水平后，可以显著降低人工成本。
第四步，根据业务风险设置不同评估等级。低风险任务可以采用自动评估，高风险任务强制人工评审。这种分层策略在真实业务中非常实用。
Agent 测试与 LLM 评测并不完全相同。LLM 评测通常关注模型在公开数据集上的知识、推理、生成能力，例如数学题、阅读理解或代码生成。Agent 测试则关注模型在特定任务环境中的整体行为，包括工具使用、任务规划、上下文记忆和外部副作用。
Agent 测试也与传统端到端测试不同。传统端到端测试验证的是系统在固定流程下的功能正确性，而 Agent 的端到端行为具有自适应特性，很难用固定路径完全描述。因此，Agent 测试需要引入语义判断和行为约束等新手段。
在实施 Agent 测试与评估时，需要特别注意以下几点。
第一，避免只测试最终输出。很多失败发生在中间步骤，只看最终文本容易产生误判。建议至少对关键任务保留轨迹日志。
第二，测试集不能固定不变。Agent 会随着提示策略、记忆模块或工具配置的变化而改变行为，测试集也需要持续更新，尤其是补充新的失败案例。
第三，不要过度依赖单一指标。任务完成率、文本质量、工具正确性、安全性等维度应综合看待。一个指标很高而其他指标很差，往往意味着 Agent 在实际场景中不可用。
第四，自动评分器的结果需要定期校验。可以抽取部分样本进行人工复评，观察评分模型与人工判断的一致性。若偏差较大，应调整评分提示或标准。
第五，评估环境应尽量接近生产环境。例如，邮件 Agent 在测试中使用模拟收件箱和真实数据分布，可能会得到完全不同的表现。评估环境与真实环境的差异越大，评估结论的参考价值越低。
Agent 测试与评估的核心，是在自然语言输出和不确定性行为中建立可观测的质量信号。它无法依靠传统断言完成，而需要综合使用行为测试、人工评审、轨迹分析、自动评分和回归测试集等方法。
一个可靠的 Agent 评估体系，不只是上线前的检查清单，更是团队理解 Agent 行为边界、发现失败模式、指导后续迭代的基础设施。随着 Agent 能力从单一文本生成扩展到工具调用、长期记忆和人机协作，评估方法也需要持续演进，从“是否输出正确”走向“是否值得信任”。