4. 失败任务诊断基础
在金融智能体的评测体系中，“失败”并不是一个简单的“对/错”标签，而是一个需要被精确定义、分层归因、可复现验证的诊断对象。很多团队在评测时只记录“任务未完成”，却无法回答“为什么失败、失败在哪一层、下次如何避免”，导致评测报告沦为分数看板，无法驱动迭代。本节将建立失败诊断的基础框架：先定义什么是失败，再按数据、模型、逻辑、交互、环境五个维度分类，最后给出可落地的诊断流程与原则。
一、核心原理：失败的定义与判定边界
在金融智能体场景中，失败应被定义为：在给定输入、工具、权限与时限条件下，智能体未能达成任务预设的可验证目标，或达成过程违反了合规、安全、成本等约束。这个定义包含三个关键点：
- 可验证目标：目标必须能被客观判定，例如“正确提取财报中的净利润并计算同比增长率”，而不是“回答得比较好”。
- 约束条件：金融场景中，即使结果正确，若泄露了客户隐私、绕过了风控校验，仍应判定为失败。
- 条件边界：失败判定必须绑定输入、工具版本、权限和时限，否则同一任务在不同条件下结论不可比。
因此，诊断的第一步不是“找bug”，而是确认失败判定本身是否成立。若判定标准模糊，后续所有归因都会失去意义。
诊断原则一：先确认判定，再分析原因。建议在评测集中为每个任务显式声明成功条件、约束条件和超时阈值，形成可执行的判定脚本。
二、失败分类：五层归因模型
金融智能体的失败通常不是单一原因，而是多层耦合。为便于定位，我们将其分为五类，每类有典型的观测信号和排查入口。
| 失败类型 | 典型表现 | 常见根因 | 排查入口 |
|---|---|---|---|
| 数据失败 | 输入缺失、字段错位、行情延迟、文档解析乱码 | 数据源变更、格式不兼容、时间戳时区错误 | 原始输入快照、解析日志 |
| 模型失败 | 数值计算错误、幻觉引用、意图理解偏差 | 上下文超限、提示词歧义、模型能力边界 | 模型输入输出、统计 |
| 逻辑失败 | 步骤跳漏、条件判断错误、工具调用顺序颠倒 | 规划器缺陷、状态机设计漏洞 | 执行轨迹、状态转移记录 |
| 交互失败 | 多轮对话丢失上下文、工具返回未处理、用户意图漂移 | 会话管理缺陷、接口协议不匹配 | 对话历史、工具调用链 |
| 环境失败 | 接口超时、权限拒绝、限流、依赖服务不可用 | 网络抖动、配额不足、配置错误 | 网关日志、监控指标 |
需要强调的是，五类失败并非互斥。例如一次“财报问答错误”可能同时包含数据解析错误（数据层）和模型幻觉（模型层）。诊断的目标是找到主因与触发链，而不是强行归入单一类别。
三、诊断的基本流程
失败诊断应遵循可复现、可证据化、可验证的流程。推荐六步法：
- 复现失败：固定输入、工具版本、模型版本和权限，确认失败可稳定复现。若无法复现，先归类为环境或随机性问题。
- 定位层级：对照五层模型，检查各层观测信号，确定失败首次出现的层级。
- 提取证据：收集输入快照、执行轨迹、工具调用日志、模型输入输出、环境指标。
- 归因主因：区分主因与触发链，避免把表象当根因。
- 验证修复：修改后重跑同一用例，并补充边界用例防止回归。
- 沉淀用例：将失败用例加入回归集，形成组织记忆。
实用技巧：在诊断日志中为每个任务分配唯一 trace_id，并将输入快照、工具返回、模型输出按时间戳串联。这样即使失败发生在多轮交互中，也能快速还原完整链路。
四、案例与误区复盘
案例：某金融智能体在“计算某公司近三年营收复合增长率”任务中返回错误结果。初步判断为模型计算错误，但深入诊断发现：数据层解析时把“营业收入”与“营业总收入”字段混淆，导致输入数值错误；模型层在此基础上正确执行了公式，逻辑层和交互层均正常。若只修复模型提示词，问题仍会复现。最终修复方案是增加字段映射校验，并在数据层加入单位与口径检查。
常见误区：
- 把失败等同于模型能力不足：大量失败实际发生在数据层和交互层，模型只是“背锅”。
- 只看最终输出，不看执行轨迹：轨迹能揭示步骤跳漏、工具误用等逻辑问题。
- 忽略环境因素：超时、限流、权限拒绝常被误判为模型不稳定。
- 修复后不做回归：单点修复可能引入新的边界失败，必须用回归集验证。
复盘提醒：诊断报告应回答三个问题——失败发生在哪一层？主因是什么？如何验证已修复？缺少任一环节，诊断就不完整。
掌握失败的定义、五层分类与六步诊断流程，是后续开展金融智能体评测与迭代的基础。只有把“失败”从模糊感受转化为可定位、可证据化、可验证的工程对象，评测才能真正驱动系统质量提升。