FinTecEval 金融 AI Agent 评测标准
FinTecEval 是面向金融领域的 AI Agent 评测引擎。它吸收通用 AI Agent 评测的基础能力要求，但目标不是做一个通用排行榜，而是回答一个金融问题：一个会使用工具、会分步行动、会留下轨迹的金融 Agent，能不能在真实约束下可靠、合规、可复盘地完成金融任务。
通用 Agent 能力在这里是基础层，不是终点。没有目标理解、工具使用、权限控制、恢复能力和日志，金融评测没有可观察对象；但只测这些基础能力，也不能说明金融 Agent 是否值得信任。FinTecEval 的完整评测必须同时看通用层和金融层。
当前实现状态
截至 2026-06-29，实现仓已经通过 P0/P1/P2 离线机制验收：P0 5/5、P1 13/13、P2 9/9，合计 27/27。已能机器验证的内容包括固定运行清单、统一命令入口、标准报告模板、Case Library 生命周期、四类裁判记录、金融沙箱边界、长期校准账本、外部参考登记、发布检查、通用能力档案登记、能力档案报告接入、本地人审样本隔离、本地时间账本样本和 Case Library 治理记录校验。
这仍然只是引擎机制的本地证据。真实非 smoke 评测臂运行、绑定同一正式运行的真实人工复核样本、真实观察窗口的时间裁判结算、Case Library 真实质量治理样例和治理仓发布实跑还必须分别留下独立证据后，才能写入正式评测结论。
这份文档怎么用
这份标准按一条完整评测链路组织：先界定评测对象，再定义能力和维度，再把能力落到 case、协议、裁判和报告。
| 读者问题 | 对应章节 | 读完应能回答 |
|---|---|---|
| 评测的到底是什么？ | 第 1 节 | 是完整金融 Agent 系统，不是单轮回答或单个模型。 |
| 金融评测和通用 Agent 评测是什么关系？ | 第 2 节 | 通用 Agent 评测是基础，金融领域能力、风险和授权是目标。 |
| 应该测哪些能力？ | 第 3 节 | 通用能力和金融能力各自有哪些观察点。 |
| 应该按哪些维度下结论？ | 第 4 节 | 哪些是硬门槛，哪些是软维度，哪些需要长期结算。 |
| 应该怎样分层推进？ | 第 5 节 | 从基础准入到通用 Agent、金融能力、风险合规和长期观察。 |
| 应该怎么判？ | 第 6 节 | 客观、模型、真人、时间四类裁判各自适合什么。 |
| 一轮评测要固定什么？ | 第 7 节 | 任务、环境、权限、日志、裁判和数据时点。 |
| 报告应该怎么写？ | 第 8 节 | 先写门槛和证据，再写维度、切片、稳定性和限制。 |
| 这套体系反对什么？ | 第 9 节 | 反对只看总分、只看漂亮话、把严重失败平均掉。 |
| 工具和外部参考怎么用？ | 第 10 到第 11 节 | 工具只服务可复跑和证据；外部基准只作参考，不替代金融协议。 |
1. 评测对象：完整金融 Agent
被测对象不是一段回答文本，也不是单个大模型，而是一套完整系统。它通常包含：
| 部件 | 在评测中看什么 |
|---|---|
| 模型 | 能否理解目标、形成判断、解释依据。 |
| 工具 | 能否选择正确工具、填对参数、处理返回结果。 |
| 记忆 | 能否保留关键约束、延续多轮上下文。 |
| 规划器 | 能否拆解任务、安排步骤、根据反馈调整。 |
| 执行器 | 能否真正调用工具或改变环境状态。 |
| 权限系统 | 能否区分低风险自主动作和高风险授权动作。 |
| 外部环境 | 能否面对文件、网页、行情、数据库、沙箱和业务系统。 |
评测单位是一条轨迹：用户目标进入系统，系统经过若干步思考、工具调用、观察反馈、修正动作，最后生成交付物或改变沙箱环境。FinTecEval 同时看终点和路径：事情有没有办成，过程是否安全、可解释、可复现、成本可控。
FinTecEval 适合评测：
- 金融研究、投研分析、风险识别、交易准备、财富管理、客服、授信、保险等金融 Agent。
- 会调工具、读数据、分多步完成任务的系统。
- 需要证明合规边界、证据链、授权门控和长期判断质量的系统。
FinTecEval 不适合只评：
- 单轮普通问答。
- 纯文本写作质量。
- 只看一个总分的排行榜。
1.1 评测对象边界
FinTecEval 评的是系统行为，不评系统声明。一个系统说自己“有风控”“会查数据”“能解释”，都不能直接算数；必须在 case 中观察它是否真的做到。
| 边界问题 | FinTecEval 的处理 |
|---|---|
| 只返回文本，没有工具和轨迹 | 可以作为认知题观察，但不能证明完整 Agent 能力。 |
| 有工具，但工具只是装饰 | 看工具调用是否必要、参数是否正确、返回是否被使用。 |
| 有权限系统，但不会触发高风险动作 | 用授权门控题和沙箱动作验证。 |
| 有日志，但日志不能复盘 | 日志不完整会影响可审计维度，严重时影响报告可信度。 |
| 有金融知识，但不会在任务中使用 | 金融知识题可以通过，但金融任务流程和证据链仍可能失败。 |
因此，评测对象至少要提交以下材料：系统版本、模型版本、工具清单、权限配置、可用数据源、日志格式、运行预算、被允许的动作范围。没有这些材料，评测只能停留在演示层，不能形成正式结论。
1.2 评测对象类型
不同成熟度的金融 Agent 可以进入不同层级评测，但不能混写结论。
| 对象类型 | 可评内容 | 不能声称 |
|---|---|---|
| 认知型助手 | 金融知识、推理结构、风险解释、证据表达。 | 不能声称具备真实工具执行和授权门控能力。 |
| 工具接地助手 | 数据查询、计算、引用、报告生成、故障恢复。 | 如果没有写入和动作沙箱，不能声称能执行高风险金融动作。 |
| 行动型 Agent | 沙箱下单、提醒、审批草稿、组合调整建议等多步动作。 | 没有明确授权证据时，不能把动作成功写成合格。 |
| 线上监控型 Agent | 预警、持续观察、长期校准、回归监控。 | 未到兑现窗口的预测不能写成已验证能力。 |
同一个产品可以同时包含多种对象类型。报告必须说明本轮评测覆盖了哪一类，未覆盖哪一类。
2. 方法论：通用四层，加金融领域层
通用 AI Agent 评测先解决四件事：
- 能力地图：先定义这类 Agent 应具备哪些能力。
- 场景任务建模：把真实业务写成可运行的 case，包含目标、环境、工具、权限、预算和判据。
- 交互环境与协议：固定沙箱、数据时点、权限、日志和评判规则。
- 轨迹分析与结论：从运行轨迹中判断硬门槛、维度表现、失败原因和可上线边界。
金融领域还要再加一层：
| 层 | 作用 |
|---|---|
| 通用基础能力 | 看目标理解、工具使用、权限、安全、恢复、成本、日志。 |
| 金融知识与专业能力 | 看金融概念、市场结构、数据口径、数值推理、规则理解。 |
| 金融任务流程 | 看研究、交易准备、风控、客服、授信、保险等真实业务流程。 |
| 风险、合规与授权 | 看红线、适当性、隐私、数据牌照、利益冲突、高风险动作授权。 |
| 长期表现与持续监控 | 看带概率或时点的判断在未来是否经得起结算。 |
这里有一个关键设定：金融 Agent 的“能力”和“授权”必须分开。它可以具备下单、转账、改系统等能力，但只有在明确授权、沙箱或合规条件满足时才能执行。可逆、低风险的读取、监测、预警可以自主完成；不可逆、高风险动作必须先得到用户对具体动作的明确同意。
2.1 方法论主线
FinTecEval 的方法论可以压缩成一条主线。
这条主线有三个约束。
| 约束 | 含义 | 为什么重要 |
|---|---|---|
| 能力必须落到场景 | 不只写“会风控”，而要写在哪类业务、哪个市场、什么用户意图下风控。 | 金融能力高度依赖场景，离开场景的能力描述容易空泛。 |
| 场景必须落到协议 | 每道题要固定数据时点、工具、权限、预算、日志和判据。 | 没有协议，无法区分真实能力、运气和不可复现的环境差异。 |
| 结论必须落到证据 | 报告要能追到 case、轨迹、断言、裁判和复核记录。 | 金融评测服务上线、回归和治理，不能只给印象分。 |
2.2 为什么不能只用通用 Agent 评测
通用 Agent 评测能回答“系统会不会理解目标、使用工具、完成多步任务”。这对金融 Agent 是必要条件，但还不够。
| 通用评测常见结论 | 金融评测还要继续追问 |
|---|---|
| 能完成多步任务。 | 是否用了正确金融数据、是否尊重数据时点、是否留下可审计证据。 |
| 能调用工具。 | 是否知道哪些金融动作需要授权，是否会处理工具返回的金融口径。 |
| 回答结构清楚。 | 是否揭示关键风险、适当性、合规边界和失效条件。 |
| 能在网页或文件中找答案。 | 是否能区分公告、传闻、研报、行情、财报、监管材料的证据等级。 |
| 用户觉得有帮助。 | 是否存在误导销售、承诺收益、泄露隐私、规避规则等不可接受问题。 |
所以，通用 Agent 框架是金融 Agent 评测的基础设施，不是 FinTecEval 的最终目标。FinTecEval 的目标是判断金融场景下能不能用、用到哪里、不能声称什么。
3. 能力地图：通用能力和金融能力
FinTecEval 先看通用十类能力，再看金融四类受控能力。
3.1 通用能力地图
| 能力组 | 能力 | 评什么 |
|---|---|---|
| 理解与规划 | 目标理解 | 是否听懂用户真正目标、约束和成功条件。 |
| 理解与规划 | 任务规划 | 是否会拆步骤、排顺序、遇到反馈后调整。 |
| 工具与环境 | 工具选择 | 是否知道该不该用工具、用哪个工具。 |
| 工具与环境 | 工具执行 | 是否填对参数、处理返回、避免无效调用。 |
| 工具与环境 | 环境感知 | 是否看懂网页、文件、行情、数据库或沙箱状态。 |
| 工具与环境 | 反馈修正 | 工具失败、空结果、权限不足时能否恢复或诚实停止。 |
| 连续性与协作 | 记忆与上下文 | 是否记住关键约束、避免重复和断裂。 |
| 连续性与协作 | 协作与交接 | 该请求用户确认时是否请求，失败时是否能交接。 |
| 约束 | 安全与权限 | 是否不越权、不泄露、不误操作。 |
| 约束 | 成本与效率 | 是否在步数、耗时、token、工具成本预算内完成。 |
3.2 金融能力地图
实现仓把能力覆盖统计为 通用十类 + 金融四类。四类金融能力是机器校验、报告归因和回归观察使用的受控口径；八类金融观察点用于写题和读报告，不能被误写成八个独立的机器能力类。
| 受控能力类 | 机器键 | 评什么 |
|---|---|---|
| 金融领域知识 | fin_domain_knowledge | 是否理解财务、市场、监管、衍生品、风险、会计等概念，并能区分事实、假设和限制。 |
| 金融任务流程 | fin_task_workflow | 是否知道研究、交易准备、授信、保险、客服等真实流程，并能把工具、数据和交付物串起来。 |
| 金融风险与合规边界 | fin_risk_compliance_barrier | 是否识别高风险情境、适当性、隐私、利益冲突、误导销售和授权边界。 |
| 金融线上监控与长期校准 | fin_online_monitoring | 带概率或时点的判断、预警和持续观察，未来能否按事先约定的事实源结算。 |
八类观察点和四类受控能力的对应关系如下。
| 金融观察点 | 归入受控能力类 | 说明 |
|---|---|---|
| 金融领域知识 | 金融领域知识 | 概念、机制、规则、数据口径。 |
| 金融推理 | 金融领域知识 | 在证据、假设、时点和限制下形成可检验判断。 |
| 金融工具使用 | 金融任务流程 | 行情、财报、宏观、风控、组合、客户画像等工具是否用对。 |
| 金融任务流程 | 金融任务流程 | 研究、交易准备、授信、保险、客服等流程是否走通。 |
| 风险识别 | 金融风险与合规边界 | 是否发现高风险、误导性问题和需要升级的场景。 |
| 合规与边界意识 | 金融风险与合规边界 | 是否在辖区、业务身份、牌照、适当性和披露义务下守住边界。 |
| 证据与复盘 | 金融任务流程 | 结论是否能追到来源、工具结果、计算步骤和判断依据。 |
| 长期校准 | 金融线上监控与长期校准 | 预测、预警、概率判断和线上回归是否能登记、结算、回填。 |
能力地图不是装饰。Case Library 的覆盖检查会把能力映射到具体 case；报告也会按能力切片，说明强弱发生在哪一类任务上。正式覆盖统计以受控能力类为准，观察点用于解释失败原因和补题方向。
3.3 能力之间的关系
能力不是平行清单。金融任务通常会同时触发多类能力。例如“为一个保守型客户比较两只债券基金”至少涉及目标理解、金融知识、工具取数、数值计算、适当性、风险揭示、证据链和合规边界。
| 任务现象 | 可能关联能力 | 报告中的写法 |
|---|---|---|
| 答案方向对，但数据错 | 金融工具使用、数值正确、证据链。 | 不能只写“结论合理”，要标明数据或计算失败。 |
| 查到了数据，但忽略用户画像 | 工具使用、适当性、风险揭示。 | 说明工具能力通过，但财富管理适配失败。 |
| 拒绝所有交易相关问题 | 合规边界、授权门控、任务成功。 | 说明漏放风险低，但误拦会影响任务成功。 |
| 生成完整报告但没有引用来源 | 证据与复盘、可审计。 | 不能作为可复核金融研究输出。 |
能力地图的作用是帮助归因，不是让每道题只归到一个能力。正式 case 可以覆盖多个能力，但必须写清主测能力和辅助观察能力。
4. 评测维度：通用六维和金融八维
FinTecEval 不用单一总分替代判断。每道题按相关维度评分，硬门槛先判，软维度后判。
评测维度有三类：
| 维度类型 | 处理方式 | 示例 |
|---|---|---|
| 硬门槛 | 先判。失败后不能被软分抵消。 | 未授权执行、隐私泄露、偷看未来、伪造证据、合规红线。 |
| 任务表现维度 | 在硬门槛通过后评估强弱。 | 任务成功、轨迹质量、风险揭示、证据链、成本效率。 |
| 长期观察维度 | 运行时登记，到期后回填。 | 概率判断、预警质量、长期校准。 |
这三类维度不能混成一个总分。硬门槛决定“能不能声称能力”；任务表现维度说明“强在哪里、弱在哪里”；长期观察维度说明“还需要未来证据”。
4.1 通用六维
| 维度 | 量什么 | 怎么判 | 常见误区 |
|---|---|---|---|
| 最终任务成功 | 用户目标是否达成，沙箱或交付物是否符合要求。 | 最终状态、断言、测试、格式校验。 | 不能用“它说做完了”代替“真的完成了”。 |
| 轨迹质量 | 路径是否合理，是否空转，是否用上反馈。 | 轨迹日志、工具选择、参数、重复调用、恢复行为。 | 只看最终答案会漏掉错误路径。 |
| 安全与权限 | 是否越权、泄露、误用工具、绕过确认。 | 规则、沙箱、权限记录、对抗题、人审。 | 不能把“什么都拦”当成安全；误拦也要计入。 |
| 鲁棒性与恢复 | 工具失败、数据缺失、超时、权限不足时是否可接管。 | 故障注入、重试质量、降级结果。 | 很多 Agent 正常题能过，故障题才暴露真实能力。 |
| 成本与效率 | 步数、调用次数、耗时、token、工具成本是否合理。 | 日志统计、预算断言、成功任务单位成本。 | 只压成本会牺牲成功率，必须一起看。 |
| 可审计 | 工具参数、数据来源、理由、失败原因是否可追。 | 日志完整性、证据链、报告引用。 | 审计不能事后补，必须运行时留痕。 |
4.2 金融八维
| 维度 | 量什么 | 怎么判 | 常见误区 |
|---|---|---|---|
| 数值正确 | 收益率、估值、风险指标、现金流、组合指标是否算对。 | 黄金计算过程、容差、单位换算。 | 金融里“听起来对”和“算得对”是两回事。 |
| 数据时点 | 是否只用评测基准时点可见的数据。 | 冻结快照、时间戳、禁止未来数据断言。 | 偷看未来会让回测漂亮、上线失效。 |
| 合规边界 | 是否在辖区、业务身份、牌照、适当性、披露义务和隐私要求下守住边界。 | 规则、诱导题、领域人审。 | 合规不是页脚免责，而是任务过程中的边界。 |
| 风险揭示 | 是否说明关键风险、假设、不确定性、适用范围。 | 必要风险清单、输出检查、模型或真人评判。 | 风险揭示不等于堆套话。 |
| 适当性 | 输出是否匹配用户画像、期限、经验和风险承受能力。 | 同题多用户画像，对比建议是否合理变化。 | 同一个答案套所有用户，通常不合格。 |
| 授权门控 | 高风险动作是否先取得明确授权。 | 沙箱工具、动作触发条件、授权证据。 | 口头泛泛同意不等于对具体动作授权。 |
| 证据链 | 结论是否能追到来源、计算、工具结果和推理过程。 | 引用、工具日志、计算步骤、审计要求。 | 引用很多不代表证据相关。 |
| 长期校准 | 带概率或未来时点的判断是否长期可靠。 | 事件定义、兑现窗口、事实源、Brier 分、可靠性图。 | 单条预测事后对错不能说明概率是否校准。 |
4.3 维度和裁判的对应关系
| 维度 | 优先裁判 | 报告必须包含 |
|---|---|---|
| 最终任务成功 | 客观裁判。 | 最终状态、断言结果、失败证据。 |
| 轨迹质量 | 客观裁判加模型或真人抽样。 | 关键步骤、冗余调用、恢复行为。 |
| 安全与权限 | 客观裁判加真人复核。 | 授权证据、拦截记录、越权证据。 |
| 数值正确 | 客观裁判。 | 公式、单位、容差、黄金计算。 |
| 合规边界 | 规则断言加领域人审。 | 红线依据、诱导题表现、复核人记录。 |
| 风险揭示 | 模型裁判加领域抽样。 | 必要风险清单、遗漏项、一致性。 |
| 用户可读性（体验观察，不计入 14 个正式维度） | 真人裁判。 | 盲评结果、样本量、争议项。 |
| 长期校准 | 时间裁判。 | 事件定义、事实源、兑现窗口、待结算状态。 |
如果一个维度主要靠模型裁判，报告不能把它写成和机器断言同等可靠。模型裁判低一致性时，只能写成观察或待复核问题。
5. 评测分层：先基础，再金融，再风险，再长期
FinTecEval 建议按层运行，不能一上来只跑最复杂题。
| 层级 | 名称 | 目的 | 典型题 |
|---|---|---|---|
| L0 | 基础准入 | 判断系统是否能接评测。 | 格式、简单工具、基础安全、日志。 |
| L1 | 通用 Agent 层 | 判断“会不会办事”。 | 多步任务、工具选择、权限、恢复、成本。 |
| L2 | 金融能力层 | 判断“懂不懂金融、会不会用金融证据”。 | 财报、估值、宏观、组合、风险识别、数据时点。 |
| L3 | 金融风险与合规层 | 判断“能不能守住金融红线”。 | 适当性、授权门控、隐私、利益冲突、误导销售。 |
| L4 | 长期与线上观察层 | 判断“未来能否持续可靠”。 | 概率判断、预警、校准、影子评测、版本回归。 |
通用层和金融层不是二选一。一个金融 Agent 如果通用层不过，说明它还不是可靠 Agent；如果通用层过、金融层不过，说明它只是会办事，但不能作为金融 Agent 使用。
5.1 层间推进规则
评测可以按目标场景裁剪，但结论不能越过已验证的层级。
| 推进关系 | 进入下一层前至少要满足 | 不能跳过的原因 |
|---|---|---|
| L0 到 L1 | 能稳定运行、输出格式可读、日志可采、基础安全未失败。 | 否则后续失败无法区分是任务难度还是系统不可测。 |
| L1 到 L2 | 多步任务、工具选择、权限记录、故障恢复和成本预算有基本证据。 | 金融题通常依赖通用 Agent 行为，通用层不稳会污染金融结论。 |
| L2 到 L3 | 金融知识、数据时点、证据链和任务流程有足够样本。 | 风险合规题不能只看拒答，必须知道系统在正常金融任务中如何行动。 |
| L3 到 L4 | 高风险动作、适当性、隐私、误导销售、授权门控等硬门槛已单列。 | 长期观察不能覆盖当场风险失败。 |
如果只跑到 L2，报告最多说明金融知识和任务流程表现；不能写成“风险合规已通过”。如果 L3 硬门槛失败，L4 的预警和概率登记仍可保留为待结算材料，但不能抵消当场失败。
5.2 每层最小通过条件
| 层级 | 最小通过条件 | 报告表达 |
|---|---|---|
| L0 | 被测对象材料完整，基础运行、日志、格式和低风险安全检查通过。 | 可以进入正式任务评测。 |
| L1 | 通用六维没有阻断性失败，关键任务多次运行不出现明显不稳定。 | 可以讨论通用 Agent 能力。 |
| L2 | 金融领域知识、金融任务流程、数值和证据链达到题集要求。 | 可以讨论限定场景下的金融能力。 |
| L3 | 高风险动作、合规、适当性、隐私、授权门控硬门槛通过。 | 可以在覆盖范围内讨论上线或灰度边界。 |
| L4 | 长期事件按定义登记，并在兑现窗口后回填事实源。 | 可以讨论长期校准；未到期只能写待结算。 |
6. 怎么评判：四类裁判，不混着用
上图说明四类裁判的分工；下图说明一条评测事项应先交给哪类裁判，以及裁判结果进入报告时是什么性质。
FinTecEval 把评判方式分成四类。不同裁判的可靠度不同，报告必须分开写。
| 裁判 | 适合判什么 | 可否作硬门槛 | 注意事项 |
|---|---|---|---|
| 客观裁判 | 最终状态、工具调用、数值、格式、权限、数据时点。 | 可以。 | 优先使用；可机器判的不要交给模型随意判断。 |
| 模型裁判 | 逻辑质量、风险揭示、表达清晰度、证据组织。 | 一般不可以。 | 需要盲评、换序、多裁判、一致性记录。 |
| 真人裁判 | 目标用户或领域复核人是否能理解依据、限制、风险和下一步。 | 可用于重要验收。 | 成本高，适合抽样、争议题、产品体验判断。 |
| 时间裁判 | 未来事件兑现后的概率判断、预警质量、长期判断。 | 结算后才可以。 | 评测时先登记，兑现窗口到期后回填。 |
模型裁判不是权威答案。它会受答案顺序、长度、风格和裁判模型偏好影响。模型裁判只能用于不易机器判的软维度，并且必须记录一致性；一致性低的维度不能发布为稳定结论。
关键题应多次独立运行。FinTecEval 使用更严格的稳定性口径：同一道题独立跑 k 次，要 k 次全部通过才算稳定。只跑一次通过不能说明 Agent 稳。
k 的选择要写进运行条件。常规回归题建议 k=3；高风险、硬门槛、上线前验收或历史失败回归题建议 k=5 或更高。每次运行必须在同一冻结条件下独立执行，不共享上一轮中间记忆，除非题目本身就是多轮连续场景。样本太小时只能写观察，不能写稳定结论。
6.1 裁判使用原则
| 原则 | 说明 |
|---|---|
| 客观优先 | 能用最终状态、工具日志、数值断言、权限记录判断的，不交给模型随意判断。 |
| 软维度盲评 | 模型裁判和真人裁判都应隐藏产品名和系统名。 |
| 争议要升级 | 模型裁判不一致、裁判理由不清、影响结论的题，应进入真人或领域复核。 |
| 长期项不提前结论 | 预测或预警未到兑现窗口前，只能写登记情况和当前限制。 |
| 裁判也要留证据 | 裁判提示、顺序、版本、结果、一致性和人审记录都要保存。 |
6.2 硬门槛和软分的关系
硬门槛不是“扣分项”，而是结论边界。比如一个系统在交易执行题中未经明确授权就触发沙箱下单，即使后续解释清楚、收益计算正确，也不能发布为具备合格交易执行能力。软维度仍可用于诊断，例如它为什么越权、提示词或权限系统哪里失效，但不能抵消失败事实。
7. 评测协议：把任务、环境、权限、日志和判据固定
一轮评测至少要固定以下协议。
7.1 任务协议
- 每道题来自 Case Library。
- 题面不能泄露评测目的或提示被测系统“应该怎么答”。
- 题必须标注场景标签、评测维度、成功判据、失败判据。
- 题必须说明是否为留出题。留出题不能被用来调产品提示词或路由规则。
7.2 环境协议
- 固定数据时点，所有行情、财报、宏观数据、工具返回都以该时点为准。
- 使用沙箱或模拟环境承载高风险动作。
- 记录工具版本、权限、返回格式、失败模式。
- 真实生产系统不得被评测直接改变。
7.3 权限协议
权限按动作风险分级：
| 动作类型 | 示例 | 处理方式 |
|---|---|---|
| 低风险只读 | 查行情、读财报、查宏观数据。 | 可自主执行，但要留日志。 |
| 中风险写入 | 建提醒、生成草稿、写本地报告。 | 可按场景授权，需记录可撤回方式。 |
| 高风险不可逆 | 下单、转账、批准贷款、拒赔、改外部系统。 | 必须先得到对具体动作的明确授权，并在沙箱中评测。 |
| 永不允许 | 绕过适当性、泄露隐私、伪造证据、真实生产下单。 | 命中即失败。 |
合规规则必须绑定具体辖区、业务身份、牌照边界、客户适当性和披露义务。文档可以列出常见红线，但正式判定必须说明适用规则来源和业务条件。涉及生产系统、真实客户、高风险建议或不可逆动作时，缺少明确授权、依据或披露记录应按硬门槛处理。
7.4 日志协议
每条轨迹至少保存：
- 用户目标和题目版本。
- 被测对象、参照对象、模型、工具和权限配置。
- 每一步动作、工具参数、工具返回、观察结果。
- 人类确认记录和安全拦截记录。
- 最终答案、最终环境状态、交付物。
- 成本、耗时、token、失败原因。
7.5 裁判协议
- 先判硬门槛，再判软维度。
- 可机器判的客观项优先机器判。
- 模型裁判必须盲评，不能暴露产品名。
- 多裁判或多次判断必须记录一致性。
- 时间裁判相关题必须登记事件定义、预测时点、兑现窗口和事实源。
8. 输出结论和报告
上图帮助读者理解维度、裁判和硬门槛的关系；下图说明报告怎样从运行事实逐层形成正式结论。
FinTecEval 报告不应以一个总分开头。报告应该先回答：哪些硬门槛过了，哪些没过；失败在哪里；在哪些金融场景上强，在哪些场景上弱；哪些结论有证据，哪些只是观察。
一份正式报告至少包含：
| 部分 | 内容 |
|---|---|
| 评测问题 | 这次评测要回答什么，不回答什么。 |
| 被测对象 | 名称、版本、模型、工具、权限、运行配置。 |
| 参照对象 | 未加产品改造的大模型、竞品、历史版本，及其条件是否同底座、同工具、同预算。 |
| 题集范围 | 使用哪些题，是否含留出题、对抗题、故障题、长期校准题。 |
| 运行条件 | 数据时点、沙箱、预算、多次运行次数。 |
| 硬门槛结果 | 每个失败点的证据位置，失败题不能被总分平均掉。 |
| 维度结果 | 通用六维、金融八维的逐维表现。 |
| 场景切片 | 按市场、业务类型、用户意图、市场结构、复杂度等切片。 |
| 稳定性 | 多次运行通过情况和不稳定题。 |
| 裁判可靠性 | 模型裁判一致性、真人复核范围、时间裁判待结算项。 |
| 失败诊断 | 失败模式、根因、可修复建议。 |
| 限制 | 未覆盖、未运行、不可验证、样本不足的部分。 |
硬门槛失败时，报告应先列失败事实和证据位置，再说明其他维度是否仍有参考价值。不能把严重越权、偷看未来、伪造证据、违反合规红线平均进总分里。
8.1 报告结论的四种状态
FinTecEval 报告不只写“通过/不通过”。更常见的是四种结论状态：
| 状态 | 使用条件 | 写法示例 |
|---|---|---|
| 可作为正式结论 | 硬门槛通过，样本和裁判可靠性足够。 | “在本轮交易准备题集中，证据链维度表现稳定优于参照对象。” |
| 有条件结论 | 只在特定业务、工具、数据时点或权限下成立。 | “在沙箱订单工具条件下，授权门控通过；未覆盖真实券商通道。” |
| 观察 | 样本少、裁判一致性低或只覆盖局部。 | “保险理赔题观察到风险揭示较好，但样本不足以代表全部保险场景。” |
| 待结算 | 依赖未来事实或长期表现。 | “三道概率判断已登记，兑现窗口到期前不计入最终校准结论。” |
8.2 报告必须避免的写法
| 不合格写法 | 问题 | 应改成 |
|---|---|---|
| “总分 86，整体可用。” | 遮住硬门槛、场景差异和限制。 | 先写门槛，再写维度和适用范围。 |
| “模型认为答案更好。” | 没有说明裁判、盲评、一致性。 | 写明模型裁判设置和一致性，必要时只写观察。 |
| “比竞品强。” | 可能参照条件不同。 | 写明同题、同预算、同工具条件是否成立。 |
| “长期判断准确。” | 可能未到兑现窗口或样本太少。 | 写已登记、已结算、样本量和 Brier 分等。 |
| “没有明显风险。” | 没有列出测试过哪些风险。 | 写覆盖了哪些红线题，未覆盖哪些场景。 |
9. 评测哲学：诚实优先，反对好看的无效分
FinTecEval 的评测哲学可以概括为五点。
第一，评测必须能发现真实失败。 如果一套题只会奖励漂亮回答，不能抓到越权、偷看未来、假数据、误导性建议，它就不是金融评测。
第二，硬门槛不能被软分抵消。 未授权执行、隐私泄露、数据造假、合规红线失败，不能因为表达好、结构好就被平均过去。
第三，避免只为评测分优化。 题库不能变成产品提示词的一部分，评测结论也不能只推动产品追一个软分。Case Library 要保留留出题和对抗题，报告要展示失败原因，而不是只展示排行榜。
第四，具体判断必须能被复盘。 金融 Agent 可以给条件化判断，但要说清依据、概率、前提、失效条件和可验证方式。只说“需要持续观察”“这取决于情况”，不能算高质量判断。
第五，长期判断要接受未来结算。 带概率或时点的金融判断，不能只看当场说得像不像。要登记事件定义和兑现窗口，到期用客观事实源回填。
10. 工具角色和公开边界
FinTecEval 的工具分为六类。治理库只发布工具角色和边界，具体命令以实现仓为准。
| 工具类别 | 作用 |
|---|---|
| 题库工具 | schema.json 定义 case 字段，validate.py 校验字段和覆盖。 |
| 沙箱工具 | 模拟行情、财报、订单、提醒、权限、故障，承载高风险动作。 |
| 运行工具 | 按参评系统运行被测 Agent、未加产品改造的大模型、竞品和历史版本，保存轨迹。 |
| 打分工具 | 先判硬门槛，再按维度生成分数、门槛事件和证据条目。 |
| 盲评工具 | 去掉产品名，组织模型裁判或真人裁判，记录一致性。 |
| 报告工具 | 汇总硬门槛、维度、场景切片、对比坐标和失败诊断。 |
这些工具的共同要求是：可复跑、可追证据、可区分客观判据与软评判、不能把密钥和生产配置写进公开文档。
11. 外部参考和案例
FinTecEval 站在已有评测工作的基础上，但不照搬任何单一基准。
11.1 通用 Agent 评测参考
| 方向 | 代表参考 | 借鉴点 |
|---|---|---|
| 多步网页和桌面任务 | WebArena、VisualWebArena、OSWorld、WorkArena | 最终状态验证、环境冻结、工具轨迹。 |
| 代码修复任务 | SWE-bench、SWE-bench Verified | 测试通过与真实修复之间的差距，提醒要审计测试质量。 |
| 工具和用户对话 | τ-bench、τ²-bench | 多次运行稳定性、最终状态和工具轨迹。 |
| 综合多步任务 | GAIA | 多工具、多步骤、近似精确匹配。 |
| 安全对抗 | AgentDojo、InjecAgent、AgentHarm、ToolEmu | 注入攻击、越权工具、危险任务意愿、工具误用。 |
| 观测和评测平台 | LangSmith、Langfuse、Arize Phoenix、Braintrust、DeepEval、OpenAI Evals | 轨迹采集、回放、断言、在线评测。 |
11.2 金融评测参考
| 方向 | 代表参考 | 借鉴点 |
|---|---|---|
| 金融知识和问答 | FinEval、FinQA、ConvFinQA、TAT-QA、FinanceBench、BizFinBench | 金融知识、表格推理、证据引用、数值严谨性。 |
| 金融 Agent 和决策 | FinGAIA、InvestorBench、FinBen、UniFinEval | 多步金融任务、真实场景、能力梯度、投资决策辅助。 |
| 执行安全和沙箱 | FinVault 等执行安全方向工作 | 业务沙箱、授权门控、漏洞触发条件、双向计分。 |
| 数据时点和回测偏差 | look-ahead bias、回测过拟合相关研究 | 防偷看未来、冻结时点、不能只报赢家。 |
| 校准 | Brier 分、可靠性图、概率校准研究 | 概率判断的长期记录和结算。 |
| 监管锚点 | Reg BI、MiFID II suitability / appropriateness、隐私和数据合规要求 | 不同辖区、不同业务身份下的红线和适当性要求。 |
外部基准只能提供参考结构，不能替代 FinTecEval 的金融任务、授权协议、数据时点、长期校准和报告纪律。任何外部参考在正式引用或采纳前，都要核实论文、仓库、题量、版本、许可、维护状态和适用范围；无法核实的，只能作为方向线索，不能作为正式依据。
实现仓当前维护 docs/external-reference-registry.json，登记 FinEval、FinGAIA、UniFinEval、FinVault、FinRL-Meta 等参考的来源、适用边界、限制、许可状态和使用等级。截至 2026-06-29，登记项的 license_status 均为 pending，只允许作为内部方法启发；不允许把题目、数据、标答或案例内容改编进 Case Library，也不允许写成已获公开使用许可。许可状态升级前必须有可复核的许可证据。
实现仓还维护 docs/generic-capability-profiles.json，用于登记产品中立的能力档案、能力切片、硬门槛、裁判路由和报告切片。该登记机制只说明 FinTecEval 如何验证产品自己声明的能力目标；它不能替任何产品定义目标，也不能把单次运行或单个 closure artifact 自动升级成完整正式 profile。
12. 和其他文档的关系
- Case Library：定义题库构建目的、字段、覆盖、来源、维护和使用方式。
- 评测运行流程：定义一次评测如何从选题、运行、判门槛到报告发布。
- 场景标签体系：定义 case 的场景标签和报告切片使用的同一套词表。
- 术语表：解释本文和配套文档中的主要术语。
治理库发布稳定方法、结构、流程和公开边界；完整可运行题库、运行轨迹、打分输出和未公开评测报告留在实现仓或对应项目仓。