简介：传统软件测试习惯断言最终输出，但智能体可能经历大量无效工具调用后仍给出看似正确的答复。本文对比“答案断言”与“旅程断言”两种评测思路，分析它们在目标、证据、风险覆盖、自动化方式与发布门禁上的差异，并给出从人工读 Trace 到布尔门禁的落地路径，帮助测试团队更早发现智能体的昂贵失败。
在传统接口测试、页面测试或模型输出评测中，团队通常默认一个前提：只要最终响应满足预期，过程可以被忽略。这个前提在确定性系统中往往成立，因为函数调用路径相对固定，中间状态异常通常会直接反映到返回值或异常栈中。
但智能体系统的运行方式不同。智能体通常由推理模型、工具调用、记忆状态和多步决策组成。一次用户请求可能触发十几次工具调用，中间可能发生参数缺失、重复请求、错误工具选择、缓存误用、权限绕过等问题，而模型仍可能在最后生成一段看似合理的自然语言回复。换句话说，最终输出的“正确”并不能证明执行过程的“可信”。
因此，评估智能体时存在两条明显不同的路径：一条是继续围绕最终答案做断言，另一条是围绕完整执行轨迹做旅程断言。理解它们之间的差异，是建立可靠发布门禁的前提。
答案断言指测试用例只检查智能体最终返回给用户的文本是否包含某些关键词、满足某种格式，或者通过一个模型评分器判断回复是否相关、流畅、有用。它通常不关心智能体调用过哪些工具、调用顺序是否合理、是否读取了正确数据源、是否产生重复或冲突操作。
这种方式的优势是上手成本低，测试用例易于编写，也很容易接入现有持续集成流程。但它会系统性地遗漏过程性风险，尤其是涉及成本、权限、数据来源和副作用的风险。
旅程断言则把智能体的一次执行视为一段业务旅程。测试不仅判断最终答案，还要检查关键业务节点是否发生、是否按约束发生、是否产生不该发生的动作。典型断言包括：
旅程断言不是要求智能体每一步都走在固定路径上，而是确认它在灵活决策过程中没有越过业务风险边界。
尽管答案断言和旅程断言在实现方式上差异很大，但它们并非完全对立。二者共享一些基础目标：
都以用户任务是否完成作为基本判断依据。 无论看最终答案还是看执行过程，最终目的都是判断智能体是否真正解决了用户问题。
都需要明确“成功”的定义。 如果产品需求只写“用户能够查询退款状态”，两种断言方式都无法落地。只有把需求拆成可验证的承诺，测试才有意义。
都依赖可观测数据。 答案断言依赖最终响应文本，旅程断言依赖执行记录、工具返回、参数变化和状态切换。没有日志或 Trace，二者都无法实施。
都可以纳入自动化流程。 答案断言易于自动化，旅程断言在经过结构化改造后也可以形成自动化门禁。
答案断言只覆盖“回复是否看起来正确”，而旅程断言额外覆盖：
这些风险不会必然反映在最终文本中，但会影响系统稳定性、用户信任和运行成本。
答案断言依赖的结果证据非常单一，通常是一段文本或一个结构化字段。旅程断言依赖的是过程证据，包括：
过程证据可以回答“为什么通过”，而答案证据只能回答“通过没有”。
智能体最容易出现的一类问题是“礼貌地失败”：模型在多次内部失败后，仍然生成一段通顺的答复。答案断言对这类失败基本不敏感。旅程断言则可以通过工具调用序列、重复次数和异常分支识别出问题。
答案断言几乎可以立即写成自动化脚本。旅程断言则需要先经过一个人工判读阶段，明确哪些业务节点是必须的、哪些行为是不可接受的，然后才能抽象成可计算的规则。这个过程更慢，但可复用性更强。
答案断言维护成本低，但容易出现大量“假通过”。旅程断言维护成本更高，因为业务规则会随产品演进，但它能持续保护真正重要的风险边界。
旅程断言的第一步不是写测试代码，而是把产品需求改写成可失败判断。例如“用户能够查询退款状态”不能直接测试，需要改写为：
每个句子都对应一种证据。缺少证据，就判失败。
测试团队可以把关键旅程列成矩阵，行是业务承诺，列是证据来源与失败表现。例如：
| 业务承诺 | 必须有证据 | 不可接受行为 |
|---|---|---|
| 身份确认 | 认证记录 | 未认证即查询 |
| 订单标识 | 参数来源可追溯 | 用空参数继续调用 |
| 数据隔离 | 权限过滤 | 读取非本人数据 |
| 可信状态 | 订单服务返回 | 使用缓存猜测 |
| 失败兜底 | 人工入口或明确拒绝 | 生成模糊回复 |
这张表不要求智能体每次路径完全一致，但约束了不可逾越的行为边界。
直接追求自动评分容易忽略关键失败模式，因为团队尚未理解智能体真实会怎么走。先人工阅读完整执行轨迹，可以发现：
这些观察是后续规则设计的基础。没有这个阶段，门禁规则往往过于宽松或过于机械。
人工识别出的规律可以逐步结构化为布尔规则，例如：
这些规则不依赖模型输出风格，只依赖事件序列和状态数据，因此可以进入自动化流程。
传统评测很少把成本作为通过条件。但在智能体场景中，Token 消耗、工具调用次数、端到端延迟和外部动作副作用都应纳入发布门禁。例如，一次查询如果重复调用同一工具多次却未改变输入参数，就应视为异常；若总延迟超过用户可接受阈值，即使答案正确也不能通过。
如果团队刚接触智能体评测，尚未看清典型失败模式，可以先从答案断言起步，但不应止步于此。答案断言适合快速回归和基础可用性检查。
如果业务涉及资金、权限、跨系统操作或高成本工具调用，则必须引入旅程断言。尤其是面向生产环境的发布决策，应优先以旅程门禁作为最终依据。
条件化地看：
从答案断言迁移到旅程断言时，需要关注几个问题：
日志完整性。 如果执行记录不包含工具参数、返回状态和耗时，旅程断言无法实施。需要先补齐可观测能力。
规则粒度。 规则过细会把智能体限制成固定流程，规则过粗会漏掉重要风险。应以业务不可接受行为为边界，而非以标准路径为模板。
误报控制。 旅程规则可能因为合法变化而误判。需要引入人工复核机制，并定期回顾规则的命中率。
连续集成兼容。 旅程断言需要执行完整智能体任务，耗时通常高于单接口测试。可以在发布前作为独立阶段运行，而不是与轻量回归混在一起。
答案断言和旅程断言代表了两种不同的质量观。答案断言关注“用户看到的结果是否正确”，旅程断言关注“智能体是否以可信、合规、经济的方式完成任务”。在智能体系统中，最终文本的礼貌与正确可能掩盖执行过程的风险。因此，把成功定义从“回复像不像答案”转向“旅程是否满足可验证承诺”，是建设发布门禁的关键一步。测试团队可以先人工读 Trace 认识失败，再把人工判断结构化，逐步形成可自动执行的布尔门禁。