怎样建立贯穿研发与验收的 Agent 评测集
开发一个基金助手，团队可能已经有单元测试、接口检查，也能完成几次顺利的演示。接下来仍然需要回答，用户交来的真实任务，究竟在什么条件下算做成？
读取了三个年份的文档，能否解释其中一次修订的准确范围？接口成功返回，是否真的交付了可以回读的报告？题内计算全对，能否据此相信真实资料研究也足够可靠？这些问题分别需要不同证据。
如果直到功能写完才临时找几道题，开发时理解的“完成”、验收时检查的“完成”和用户期待的“完成”，很容易各有一套。一个总分也很难把这些差异重新解释清楚。
评测集的作用，从需求阶段就开始了。它把用户任务、成功条件与后续验证连接起来，让研发流程各阶段能够围绕同一个问题积累证据。
ETF Agent 当前有一份 83 道问句的共享目录，也有机制检查与评审控制材料。理解它们的地位，需要先看完整的研发与验收链，再回到核心题、专项题、标签和评分的组织方式。
一、评测集怎样进入整条研发与验收链
一项能力准备开发时，首先要把承诺落到任务上。以现有 RQ-08 为例，用户希望对照三个年份的官方文档，解释一次 ETF 申购赎回清单修订具体改了什么。下面沿这道现有题目说明研发环节，属于教学拆解。
需求阶段需要说清，相关条款能否被定位，较新文件与原条款是什么关系，材料缺口出现时哪些内容还能解释。题目和评价依据越早形成，越容易暴露“支持文档研究”这类需求里尚未讨论的分歧。
进入开发后，要验证的重点转到实现。材料有没有正确传递，只读限制是否保持，修改是否破坏已有行为，都适合用受控输入做快速回归。涉及真实装配或持久化时，再按改动影响选择相应验证。需要判断模型行为时，开发阶段也可以运行少量真实任务。受控回归适合反复定位，真实研究用于观察前者无法回答的问题，两者按改动需要组合。
到了任务验收，需要把选定的任务交给当前系统，核对实际模型输入、工具行为、交付结果与答案质量。题目、来源和预期应在看结果前确定，后续比较才有稳定依据。某一题的工程接缝通过，还需要与它的实际任务表现分别记录。
交付时，结论要对应当次承诺。只承诺修复材料传递，就按相关工程行为验收。若承诺研究能力，则要取得该能力所需的真实任务与质量证据。正式关闭、部署完成和用户使用效果，也各自需要对应事实。
运行以后，新反馈会暴露题集里没有出现的表达、资料和任务组合。审阅这些记录，再把有价值且获准使用的案例补回题集，才会让下一轮验证覆盖到真实问题。
图 1 同一任务贯穿研发，验证选集与验收范围随本次承诺确定。运行后的新案例经过审阅再回到题集。
LangSmith 的官方文档也把固定样本上的评价与生产交互上的评价连接成持续改进流程。前者适合开发比较与回归，后者从真实使用中发现遗漏。它所说的“离线评价”仍然可以调用真实模型，“离线”描述的是预先准备的评价样本，是否调用外部模型需要另行说明。LangSmith 的评价生命周期
这条链里，题集可以跨阶段复用，证据的含义却会变化。同一道 RQ-08，可以帮助讨论需求、检查文档接线，也可以进入真实研究评价。报告需要标明这次实际完成了哪一层。
二、从真实分歧里写出成功条件
建题集时，很容易先列“准确性、完整性、专业性”，再让模型生成一百道题。困难在于，这几个词还没有说明用户在哪一步得不到想要的帮助。
Hamel Husain 与 Shreya Shankar 提出了一种更贴近产品的起点。阅读实际交互记录，先写具体观察，再把相似问题归成失败类型。他们特别建议关注最早可见的失败，因为后续错误可能由它引起。这样得到的分类，才有理由成为后续评价的对象。错误分析方法
把这个方法用于基金助手，同一句“答案不可靠”就会展开成不同问题。
用户需要的资料根本没读到，应该调查检索与读取。资料已经读到，却把旧数据写成今天的事实，要检查时点理解。计算过程看起来完整，分母用错了，要检查数值依据。回答内容正确，却忽略“不要查看我的账户”，则涉及任务范围。
这些问题需要不同的题，也需要不同的修复位置。给每份回答一个笼统的“专业程度”分数，很难决定下一步改哪里。
我们当前题目里有几个适合说明这种区别的例子。
- C01 解释场内交易与场外申购。 用户要求按买入方式、费用、成交价格解释，并明确先不查资料。成功条件包含解释清楚，也包含遵守这次使用限制。
- C04 解释净值从 1 元跌到 0.8 元，再回到 1 元。 跌幅是 20%，回升幅度是 25%。评价要关注两次变化各自的基数，以及答案能否把原因讲明白。
- C24 在今天数据未更新时询问精确加仓金额。 需要区分可用的历史解释、当前金额所缺的依据，以及可以继续获取或澄清的信息。
C24 尤其能说明成功条件为什么要提前写。给出一个精确数字可能显得“有帮助”，整段拒绝又可能丢掉用户仍然需要的数据过期解释。有效评价需要同时看见这两边，才不会把“越敢回答”或“越保守”误当成统一目标。
一旦成功条件具体了，题集就开始表达产品判断。我们希望助手怎样帮助用户，哪些前提改变后应当换一种回答方式，都可以通过题目讨论清楚。
需求与领域判断提供成功条件，开发者负责让输入与运行记录对应，评审再核对参考和答案。这些工作可以由小团队完成，重要的是让参考依据能够独立检查，避免实际实现反过来决定什么答案才算正确。
三、为什么需要核心题，也需要研究专项
日常检查需要观察常见任务是否继续可用，研究专项则需要更复杂的材料来暴露能力边界。每轮都跑全部复杂任务，费用和阅读结果的成本会增加。只留几道常见问题，又很难看见文档理解、证据综合和复杂研究的缺口。这两种需求决定了题集需要有不同用途。
Anthropic 把能力评价与回归评价分开。前者寻找系统目前做不好的任务，后者保护已经能够完成的任务。一个原先困难的任务变得稳定以后，也可以进入回归集合。这种划分让“继续突破”和“守住已有表现”获得各自的观察范围。Anthropic 的 Agent 评测实践
我们的现行目录按核心 14 道、扩展 69 道组织，共 83 道唯一问句。核心覆盖常见且需要持续观察的场景，扩展用于更具体的业务问题与研究能力。题目内容又分布在五个任务家族里。
| 当前任务家族 | 数量 | 希望暴露的问题 |
|---|---|---|
| 通用基金与对话，C 系列 | 31 | 概念、费用、计算、比较、个人只读、建议边界与多轮承接 |
| 应用问答，L 与 Q 系列 | 25 | 组合、现金、每日复盘、市场证据、澄清和复合请求 |
| 金融知识，RQ 系列 | 12 | 原文与摘要、费率与条款时点、文档修订范围、PDF 定位和证据综合 |
| 可复算合成研究，MAE 系列 | 5 | 给定材料中的计算、反证、判断条件和多方法综合 |
| 合成账户研究，RPS 系列 | 10 | 模拟账户结合获准公开 Web、PDF 的实际研究与协作行为 |
数量对应 2026 年 11 月 9 日核对的源码。核心与扩展是这 83 题的选择范围，五个任务家族描述内容，两种划分可以同时成立。
图 2 任务家族说明题目内容，核心与扩展说明选择范围，标签提供交叉视角。按不同条件选题仍沿用同一题目身份。
这里借鉴的是不同集合服务不同决策的思路。核心题是否已经足够稳定，还要看各题的实际运行与评价记录。扩展题也可能包含重要回归场景，不能仅凭“扩展”二字降低其重要性。
这些题目目前仍有实际消费者。CLI、QA 与金融知识入口从共享目录读取问句，近期真实研究记录也复用了 MAE-05 原题。我们能确认题库与这些入口仍然连接，另一次具体复用发生在 11 月 9 日。全量 83 题的固定执行频率，需要相应运行记录才能确认。
这种组织的代价，是维护者需要为每轮评测解释选题。它适合任务逐渐增多、不同研究需要不同资料的产品。对于仍然只有一种固定输入的小工具，一份短清单通常更容易维护。
四、同一道题怎样进入不同的评测范围
有了几个任务家族，为什么还要标签？因为“费用”“计算”“时效”与这些家族并不一一对应。
时效问题会同时出现在一般净值解释、账户查询和文档研究中。想专门观察这项能力，就需要跨任务家族选题。反过来，一道题也可能同时涉及计算、合成数据和用户限制，只按一个主题归档会丢掉其他有用信息。
以 C04 为例。它属于核心范围，关注计算，材料是假设例子，可以由通用执行入口运行。这几个维度共同说明，为什么它适合检查计算解释，又为什么它无需真实账户与当前行情。
当前目录保留了几类彼此独立的信息。
| 维度 | 当前例子 | 对选题的作用 |
|---|---|---|
| 选择范围 | core、extended | 决定默认检查哪些题，以及本次是否扩展 |
| 业务与行为 | fees、calculation、freshness、multi-turn | 跨任务家族选出共同关注点 |
| 资料条件 | public-data、hypothetical、private-input、approved-corpus | 识别公开、合成、私人或指定语料条件 |
| 执行入口 | runner-classic、runner-qa、runner-knowledge | 找到能够消费这些任务的执行器 |
评价目标另有字段记录，后文再谈。这样分开以后，“涉及什么资料”与“准备评价什么”就能分别讨论。
实际选择也会变得具体。按当前选择器核对，核心计算题并排除私人输入，会得到 C04 与 C23。选择时效标签并排除私人输入，会得到 C05 与 C07。选择金融知识入口的题目，则会得到 RQ 十二题。
有一个容易忽略的行为需要讲清。主动指定标签、题目或全量范围时，选择器会在整个目录中匹配。若目标仍是核心题，就需要把 core 同时写进条件。单独排除某标签时，当前选择器仍从默认核心范围缩减。选集应先列出来核对，维护者才知道这次实际比较了什么。
多轮任务还有另一种依赖。C25 比较沪深 300 ETF 与中证 500 ETF，C26 继续问“后者波动大的原因”，并缩小回答范围。单独拿出后一句，指代依据就消失了。当前选择 C26 时会带入前置 C25，分别标明本次题目与必要前置。
标签的作用到这里为止。实际来源权限和预算仍沿原有运行入口执行，执行器还要核对案例支持与必要前置。一个标签能帮助找到题目，获得哪些资料则需要对应授权。
五、材料一变，测的能力也会变
“分析这个策略值不值得研究”，既可以把全部数字放在题里，也可以要求助手去网上找资料。表面上是同一个问题，暴露的能力却有明显差异。
MAE 五题采用题内合成材料，主要好处是可以复算。MAE-05 给出终值情景 50、100、140，主观概率分别为 0.20、0.50、0.30。按题内条件，期望终值是 102，买价从 100 改成 90 后，期望回报率也要随基数变化。评价者可以独立核对数字，再看助手怎样讨论概率、反证与流动性限制。
这类题减少了外部资料变化，适合定位计算或研究判断的差异。它同时把找资料这一步预先完成了，因此还需要其他任务观察真实检索与阅读。
RQ 十二题使用指定金融材料，难点更多落在“这份来源究竟支持什么”。例如 RQ-08 要对照三个年份的官方文档，解释 ETF 申购赎回清单，也就是 PCF 的公告究竟修改了哪些字段。读到一份较新的招募说明书，还需要辨别它与具体修订条款的关系。来源日期、文档范围和结论范围都进入了成功条件。
RQ 中八题要求在指定支持条件下完成正向回答，四题允许针对已知资料缺口给出有范围的交付。允许缺口有明确前提，执行和评价仍需检查该找的材料、实际可见的依据，以及答案怎样说明限制。若只要说一句“资料不足”就算通过，测到的能力会发生偏移。
RPS 十题则结合合成账户与获准公开 Web、PDF，观察助手怎样把产品信息、账户条件和外部证据串起来。模拟账户让题目可以讨论组合问题，同时保留真实用户资料的边界。公开资料会更新，读取也可能失败，这些都要进入本次运行条件。
因此，设计一次评测时需要明确想观察的能力。题内给足材料，可以细看推理与计算。指定文档可以检查证据辨别。经过真实检索，则把发现来源、读取资料和处理缺口也放进任务。三者获得的结果，需要带着相应条件解释。
固定材料需要维护，真实资料引入波动。把这些条件记录在题目与运行结果中，才能判断一次失败发生在获取资料、理解证据还是形成结论的环节。需要比较不同系统时，也能据此核对它们是否面对了相同的信息条件。
六、验收时怎样把证据变成结论
Agent 会找资料、调用工具，也可能保存报告。一份读起来顺畅的正文，能说明表达结果，却还需要其他记录解释任务实际做到了哪里。
Sierra 的 τ-bench 把模拟用户、工具、业务规则与初始环境放进任务，通过任务结束后的数据库状态检查目标是否完成。这样可以容纳不同的有效对话路径，也可以把“声称办好了”与实际效果分别观察。τ-bench 的任务与结果设计
基金研究可以借鉴这种区分，但研究结论还有开放判断。报告确实保存了，仍然需要评价它的计算、证据和解释。我们当前把相应工作分成三个层次。
机制检查关注受控条件下的传递与执行。 例如，过期状态有没有进入后续上下文，只读限制有没有沿既有执行机制保持。现有 55 份编号机制夹具仍由离线测试读取，适合定位这类具体行为。
实际行为关注当前模型怎样完成任务。 它看实际请求、工具调用、资料读取、可取得交付与终态。当前统一运行入口经原 Agent API 做行为观察，真实运行需要相应环境、授权和预算。
研究质量关注结论是否成立。 它需要本次实际可见资料、独立可核对的参考，以及适合任务的人工或模型评审。这里既有算术，也有证据范围、时点、反证和需求覆盖。
这三层帮助定位修复位置。以 C24 为例，若过期状态在传递中丢失，应调查资料与上下文环节。模型看见了状态却给出缺乏依据的当前金额，要调查研究判断。它解释了历史资料、保留了可用内容，则还要对照任务准则评价这份回答。
当前覆盖也有具体范围。83 题都声明实际行为目标，73 题还声明研究质量目标，RPS 十题目前只声明行为层。九份细化准则绑定 C04、C24、C23、C09 与 MAE 五题。目标声明、细化准则和某次已经完成的评分，报告里需要分别呈现。
质量评价暂时缺少材料时，已有答案仍可以保留，评价轴记录未评与原因。这样既能继续查看产品交付，也能清楚知道这次判断还缺什么。
图 3 围绕 RQ-08 的教学示意，图中展示证据类型与结论范围。具体选用哪些验证，由本次变更影响和事前验收承诺决定。
这里最容易混淆的是“测试已经通过”和“工作已经验收”。我们当前的工程关闭按事先声明的无外部模型或真实模型路线执行。前者可以支持相应实现与回归范围的关闭，研究质量仍按实际取得的证据记录。声明真实模型验收的工作，则要回到它自己的题单、运行与评审要求。
持续集成的配置也体现了这种分工。本次核对的自测工作流将静态检查与确定性模拟测试设为阻塞项，真实模型快速自测处于暂停状态，相关步骤本身也是信息性检查。看到一轮持续集成成功，能够据此回查的首先是它实际执行的工程检查。
因此，交付结论需要写到具体范围。材料传递已经通过受控回归、真实任务完成了一次可回读交付、答案中的修订范围已经独立评审，是三个不同的观察。它们在报告中保持独立，才看得出本次承诺还有哪一项没取得证据。
验收前还有两件事值得固定。第一，题目、资料、参考与运行条件在看答案前确定，修改后保留新身份，避免结果好坏反过来改变题单。第二，开发中反复使用的题要保留暴露记录。挑战题一旦进入调试，后续复测可以支持回归，其独立挑战身份也应随之更新。
验收强度与承诺范围应当相称。局部接线修复用相关工程验证建立依据，真实研究能力需要观察相应任务，重要结论再增加独立复核。这样既保留必要正确性，也避免每次小改动都承担全量真实研究的费用。
七、给回答打分之前，先检查裁判
评测集最容易带来一种错觉。有题目、有分数，似乎就能放心比较版本。实际上，裁判可能奖励了错误目标，也可能把合理回答判差。
对 C04，关键词“20%”“25%”都出现，还要看它们分别对应哪段变化。对 C24，只检查是否拒绝精确金额，会漏掉“是否仍然解释了数据过期影响”。对 RQ-08，只检查有没有引用新文档，会漏掉修订范围是否被扩大。
这些都要求裁判看懂成功条件。OpenAI 的评价指南建议用人工反馈校准自动评分，提供具体评分标准，也提醒成对比较可能受答案顺序与篇幅影响。因此，比较“哪个更好”时，还要明确好在哪里，并核对裁判是否稳定认出了这种差异。OpenAI 的评价实践
我们当前有固定的金融答案与引用控制例，用来检查错分母、缺依据、错误引用与合理回答等情况。这些材料评价的是评审逻辑，使用时应保留它们与用户任务题目的用途区别。
一个可操作的检查方法，是让同一条准则面对几种答案。下面是教学构造。
- 一份表达简短、计算正确且解释了基数的答案。
- 一份更长、更像研究报告，却把回升幅度写成 20% 的答案。
- 一份知道当前资料不足，同时保留历史解释并说明所缺依据的答案。
- 一份把全部问题都拒绝掉，连可独立回答的内容也省略的答案。
如果裁判持续偏爱第二份的篇幅，或者无法区分后两份的帮助程度，就要先调整评价。继续沿着这个分数调整系统，可能会不断奖励错误偏好。
还要留意题目被反复开发使用后的信息泄漏。当前九份细化准则标为开发用途，适合支持调试与分析任务表现。要估计对未见任务的适用性，需要另留独立题目或真实新反馈，并在看到结果之前确定评价条件。把同一模板换几个数字，仍然可能保留原来的解题线索。
这也影响如何扩充题集。遇到新反馈，先决定它揭示了哪种未覆盖的条件，再补题或表达变体。按错误筛选的样本适合查缺口，产品整体失败比例还需要与实际使用分布相称的抽样。
八、怎样读结果，决定下一道题补在哪里
题目跑完以后，一份报告应当让读者看清这次覆盖了什么，以及结论在哪些条件下成立。
首先保留任务的分布。 核心与扩展、计算与文档、单轮与多轮分别跑了哪些题，需要能够回查。假设一批结果主要来自 C04、C23 这样的题内计算，即使计算全部正确，文档修订与公开资料研究仍需要各自的任务证据。这里是对结果范围的教学说明，具体表现要看实际运行。
再把材料与结果放在一起。 RQ 题的指定文档是否可见，公开页面有没有读取成功，多轮题的前置是否完整，都影响结果解释。C24 涉及私人输入条件，执行时使用的获准资料或合成变体也需要明确。模型已经读到证据却理解错误，与执行环境未提供材料，应当分别记录。
随后区分执行、质量与评价缺失。 报告已经保存、计算已经复核、开放判断尚未评审，可以同时出现在一轮结果里。当前九份细化准则的覆盖情况也应随题目呈现，才看得出哪些结论有独立依据，哪些仍需人工阅读或补充参考。
重复次数同样影响解读。把核心 14 题各跑五次，会产生 70 次尝试，任务覆盖仍然是 14 道题。重复适合观察同一条件下的波动，增加不同任务则扩展覆盖。若一题时好时坏，值得调查稳定性。若整类任务根本没有出现，则需要补相应任务。
用量也要按这些范围理解。合成计算与公开 PDF 研究需要的时间、请求和工具往往不同，分组记录才便于知道成本花在哪里。费用不完整时保留未知部分，已知小计继续标明其范围。
结果暴露的缺口，可以推动不同的补充。
- 真实反馈出现一种尚未覆盖的需求，补充相应任务与成功条件。
- 已有任务换个表达就失手，补充措辞、指代或上下文变体。
- 来源传递或执行出现具体问题，补充对应的受控机制检查。
- 人工阅读与自动评分分歧明显，补充评审控制例并校准准则。
这种区分也让现有几套材料的关系更清楚。83 道问句提供用户任务，核心与专项选集提供不同观察范围，机制夹具帮助定位受控行为，评审控制例帮助检查评分。扩充哪一部分，取决于结果究竟留下了什么疑问。
回到整条研发链，一份有用的交付结论应当能沿任务追溯。需求阶段承诺了什么，开发阶段验证了哪些实现，验收取得了哪些真实执行与质量证据，运行中又发现了什么新条件。当前题集、运行入口和评审材料提供了这些工作的基础，已确认的覆盖与尚缺的证据仍需逐项记录。
当这条关系清楚以后，团队就能区分该修实现、补资料、调整准则，还是增加一种新任务。题集的维护也就有了具体去处，始终围绕产品准备解决的问题积累证据。
继续阅读
- 完整的执行、观测与评分链路见《Agent 测评全景》。
欢迎在 GitHub Star，持续交流 Agent 评测与产品迭代的实践。