你写了一个资料整理 Agent：输入主题，它搜索资料、读取网页，最后生成一篇带引用的文章。第一次测试，它漏掉了来源；你补了一段提示词，再跑同一道题，结果好多了。

这证明了你修复了这个例子，却还不能说明 Agent 对其他主题也更可靠。如果接下来的每次改动都围绕同一批题目展开，分数越来越高，可能只是系统越来越适应这批题。

要区分“修好了见过的问题”和“提升了处理新任务的能力”，需要给评估数据分配不同职责。本文围绕一个资料整理 Agent，解释 dev、validation 和 held-out test，并给出可以从小规模开始的评估流程。内容与具体框架、模型版本无关，不涉及模型训练代码。

先统一术语：本文的 dev 指什么

本文约定：dev 用来调试和改进，validation 用来比较与选择版本，held-out test 用来检验最终版本在未参与开发的任务上的表现。

这个命名并不是统一标准。在一些机器学习和 NLP 文献中，development set（dev set）就是 validation set 的别名，常见划分是 train / dev / test。阅读其他项目时，要先看数据实际用于什么决策，不能只凭目录名判断。

这里单独设置 dev，是为了描述 Agent 工程中常见的开发活动：读失败日志、改提示词、调整工具、编写 Skill。即使没有更新模型权重，系统也已经根据这些题目的反馈发生了变化。

传统机器学习中，validation 参与模型选择，test 留到最终评估；本文把这一隔离原则应用到整个 Agent 系统。相关基础可以参见 scikit-learn 的交叉验证说明。下文的具体权限和迭代流程是面向入门项目的建议约定，并非某个框架强制要求。

Agent evaluation 到底评什么

一次 Agent evaluation，需要把任务输入交给 Agent，记录它的执行过程和结果，再用预先定义的规则判断是否完成目标。

几个常见术语可以这样理解：task 是一道任务；trial 是对这道任务的一次尝试；trace 是可记录的输出、工具调用和中间结果；grader 是评分器；outcome 是任务结束后的实际结果。Agent 说“已经保存文章”，与目标文件确实存在，是两种不同的证据。Anthropic 的 Agent 评估指南 对这些概念作了系统介绍。

对于资料整理 Agent，可以先写出这样的任务约定：

根据给定的三份参考资料，面向初学者解释容器与虚拟机的区别，生成一篇中文文章。关键事实应有来源，资料不足时应说明不确定性。

然后在运行前约定如何验收：

维度 检查什么 可用证据
任务完成 是否生成文章，是否覆盖指定比较项 产物文件、内容检查
事实依据 关键结论是否被引用资料支持 结论与来源的逐项核对
表达质量 初学者能否理解，是否有未解释的术语 明确的评分量表、人工复核
行为边界 是否访问了任务禁止访问的资源 工具调用记录
资源消耗 完成任务花了多少时间和 token 运行日志

写作任务没有唯一标准答案。可以接受不同的结构、措辞和合理的工具路径；必要的行为边界仍应检查。例如，任务要求只使用给定资料，就不能通过额外搜索获得答案。自动检查、模型评分与人工复核可以组合使用，模型评分应先与人工判断校准。Anthropic：评分器设计

三份数据都应遵循同一套验收定义。它们的主要区别是：评估反馈允许怎样影响后续开发。

三份数据，各自回答一个问题

数据集 回答的问题 允许怎样使用反馈 不能据此声称什么
dev，开发集 为什么失败，怎么修？ 查看任务、答案和 trace，反复调试，修改提示词、工具、Skill dev 高分不能证明新任务表现
validation，验证集 候选版本中，哪个更值得保留？ 在固定条件下比较候选版本，按事先约定的指标选择 被反复用于选择的成绩，不是独立的最终测试成绩
held-out test，独立保留测试集 定版后，在未参与开发和选择的任务上表现如何？ 版本冻结后，按预先约定的协议评估和报告 一个有限测试集不能保证所有真实场景都可靠

dev：把失败转化为改动

在 dev 上，你应该主动查看失败原因。例如，Agent 引用的网页与结论无关，可能来自不同问题：搜索词过宽、没有读取正文，或者把推测写成了事实。

一个合理的开发过程是：先读 trace 确认原因，再提出改动假设，比如“在写作前建立结论与来源的对应关系，可以减少无依据结论”，最后在 dev 上检查修复和回归。

dev 可以加入新发现的失败案例，也可以反复执行。它承担的是开发职责，分数变化必须结合题目版本理解：如果今天比昨天多了十道难题，两个总分不能直接当作同条件比较。

validation：比较已经形成的候选方案

当 dev 上出现改善，就把候选版本拿到 validation 上比较。例如，比较原版 A 与增加来源核对步骤的 B，看 B 是否在更多主题上改善，同时检查耗时和其他能力有没有退步。

建议在一个比较周期内冻结题目、评分规则和运行条件。先确定比较哪些候选、依据什么选，再运行，避免看到结果后不断改指标。

validation 本来就会通过版本选择影响开发，因此不必把它描述为“完全没有参与优化”。需要控制的是反馈的使用方式：优先用整体和分类结果选版本，把逐题反复修补留在 dev。

如果你把某道 validation 的答案或失败 trace 直接用于改写提示词，这道题实际上已经承担开发职责。记录这次用途变化，将其纳入 dev，并在下一版验证集中补充未用于针对性开发的题目。即使只看总分，长期反复挑选也可能逐渐适应这份验证集。

held-out test：冻结以后再检验

held-out 的重点是“保留在开发与选择过程之外”。最终测试前，应冻结 Agent、提示词、工具、Skill、模型配置、评分器和预算。

执行测试时，Agent 当然需要看到当前任务输入；需要隔离的是参考答案、隐藏检查，以及其他测试任务的结果。开发者和负责自动改进 Agent 的程序，也不能提前利用测试题来定制系统。

如果最终结果不理想，可以继续修复产品。只是当这些失败已经用于开发后，原测试集就不能再为修复后的版本提供同样独立的证据。保留原报告，把已暴露的任务转作开发或回归用途，再准备新的独立测试任务。

held-out test 不要求每道题只执行一次。可以事先约定重复试验来测稳定性；关键是测试期间保持版本和协议不变，完整报告结果，不根据中途成绩修改系统或只挑最好的一次。

数据泄漏：分了文件夹，也可能没分开信息

数据泄漏会让评估得到过于乐观的结果。经典例子是把测试数据用于模型构建或预处理；Agent 系统还需要检查提示词、知识库、缓存、记忆与 Skill 中是否混入了测试信息。scikit-learn：数据泄漏

下面是针对资料整理 Agent 的几个具体检查场景：

  • 同一篇资料衍生出三道相似题，分别放进三个集合。措辞不同，但 Agent 已在 dev 上学过对应内容和解法。
  • 把 held-out 的参考文章放进检索知识库，测试时直接检索到了答案。
  • 一次测试后，自动记忆保存了“此题最好这样回答”，后续 trial 读取了这条经验。
  • 开发者看到测试失败，把解决步骤写进 SKILL.md，然后仍把重测称为独立测试。

处理相似题时，先确定希望检验的泛化范围，再按来源分组。例如，同一原始文档的改写题放在同一组；若目标是验证跨项目能力，就按项目隔离。按组划分能减少相关样本跨集合出现的问题。scikit-learn：分组划分

对资料整理任务，还要分清“允许使用的资料”和“隐藏答案”。给 Agent 提供任务所需的原始文档是正常输入；给它提供为这道题制作的参考成稿或评分答案，会改变测试含义。

只读也不等于隔离：如果 Agent 能读取隐藏答案，即使不能修改文件，评估仍然受到了污染。

三组数据的数据量如何分配

没有固定比例。对于本文这种通过提示词、工具和 Skill 改进 Agent 的方式，可以先按 dev / validation / held-out test = 50% / 25% / 25% 规划，再根据任务覆盖和评估精度调整。这是本文给出的起步建议，不是行业标准，也不是官方规定。

这里的 dev 并不用于训练基础模型，因此不必机械套用训练集占 80% 的划分方式。

独立任务总数 dev validation held-out test 用途与限制
60 30 15 15 跑通流程、发现明显问题，分类结论很有限
200 100 50 50 初步比较候选版本，仍需关注随机波动
1,000 500 250 250 为整体与分类比较提供更多样本，不自动保证精度

表中的数量是预算示例，不是实测结果或统计充分性的保证。Anthropic 提到，20–50 个来自真实失败的简单任务就可以启动评估；这指的是起步规模，并非每份集合的标准数量。Anthropic：从零建立评估

先看覆盖、精度和成本，再决定比例

任务覆盖决定每份集合需要包含什么。 如果有 10 类任务，测试集只有 15 题，每类可能只有一两题，很难据此解释分类表现。先覆盖主要场景、边界情况和重要失败模式，再调整数量。按来源去重、分组后再划分，避免用大量近似题制造样本充足的错觉。稀有但重要的风险场景可以单独报告；若刻意提高其占比，应说明总体分数不直接代表真实流量中的成功率。

希望识别的改善幅度决定需要多少证据。 若每题只运行一次并按通过与否计分，15 道测试题多通过一道，总分就增加约 6.7 个百分点，无法据此稳妥判断“提升了 2 个百分点”。即使测试集有 50 道题，多通过一道恰好对应 2 个百分点，也不意味着这个差异足够可靠：还要考虑任务差异和运行波动。希望识别的改善越小，通常需要越多独立任务；候选成绩接近时，应结合不确定性分析，不能只凭总分排名下结论。

运行成本决定执行频率，不要求三份数据同样频繁地跑。 dev 可以频繁执行相关子集，并定期检查完整开发集的回归；validation 在候选版本形成后执行；held-out test 留到定版后按预定协议执行。数据充足时，可以先根据覆盖与精度需要确定 validation 和 held-out 的绝对数量，剩余数据用于开发，不必始终维持 50% / 25% / 25%。

独立任务数量不等于运行次数

同一道题运行三次，仍然只是一道任务。重复运行主要帮助观察稳定性，增加不同任务主要帮助扩大覆盖，两者不能替代。例如，50 道题每题运行三次，应报告“50 道任务、150 次尝试”，不能把它当成 150 道独立任务。

如果只是学习评估流程，可以使用表中的 30 / 15 / 15。如果准备开展实际版本比较，可以先以 100 / 50 / 50 为预算起点，检查场景覆盖后再调整。这些都不是最低门槛；数据不足时应缩小结论范围，结果接近时也不要为凑出胜者而反复查看 held-out、修改系统再重测。

一个从零开始的评估流程

下面用 60 道资料整理任务演示流程，按 dev 30、validation 15、held-out test 15 分配。这些数字仅用于演示，不是实际实验结果，也不足以支撑广泛的能力结论。 真实规模应结合上一节的覆盖、精度和成本要求确定。

第一步：先定义任务，再划分数据

收集不同主题和约束的任务，既包含资料充分的情况，也包含资料矛盾、资料不足的情况。明确哪些结果算通过，哪些只能给部分分，哪些属于必须单独报告的违规行为。

先按原始资料或任务来源去重、分组，再划分三个集合。检查各集合是否覆盖预期的主要任务类型。保存任务 ID、分组关系和数据版本，避免每次运行重新随机划分。

第二步：在 dev 上开发候选版本

保存基线 A 的失败证据，做出一个能解释的改动得到 B。先确认评分器没有误判，再判断 Agent 是否需要修复。

如果这次研究的是 Skill 的作用，就只改变 Skill：例如从 skill_version=none 到 skill_version=s0，或从 s0 到基于 dev 失败改进的 s1。模型、基础提示词、工具、预算和加载方式保持相同，才能更清楚地判断改善来自哪里。

在本文建议的流程里，Skill 的自动生成和改写只消费 dev 反馈；validation 与 held-out 的运行不会把新经验写回可复用的 Skill 或长期记忆。单次任务内的正常推理、计划调整仍然可以进行，每次 trial 都从约定的初始状态开始。

第三步：用 validation 选择版本

事先写下选择规则。例如，本项目可以约定：先检查是否出现禁止访问资源的行为，再比较有依据的任务完成率，同时报告耗时。具体门槛由应用需要决定，不能测试后为了某个候选改规则。

对同一批任务，以相同预算运行 A 和 B。若 B 只有 dev 提升，validation 没有改善，应调查过拟合、任务差异或随机波动，不急于下结论。

第四步：冻结并执行 held-out test

选择候选后，把它与完整配置一起冻结，再执行预定的测试协议。记录至少包括：Agent 版本、Skill 版本、模型标识与采样配置、数据版本、评分器版本、工具和环境版本、时间与调用预算、重复次数、执行时间，以及每次结果和 trace 的位置。

在这个教学例子中，可以预先约定每题运行三次，用来观察同一道题是否忽好忽坏。但三次并不能充分估计稳定性，15 道测试题也不足以支撑广泛结论。

报告应同时给出题目数和尝试数。例如“15 道任务，每题三次，共 45 次尝试”，不能写成“45 道独立任务”。除整体通过情况外，还应报告分类表现、成本、违规情况、基础设施错误和未完成尝试；重试规则也应提前确定。

第五步：区分成功机会与稳定性

pass@1 关注单次尝试成功的概率；pass@k 关注 k 次尝试中至少一次成功的概率；pass^k 关注 k 次尝试全部成功的概率。三者回答的问题不同。Anthropic：非确定性与评估指标

如果一次任务三次尝试中只有一次通过，它对这组三次尝试的“至少成功一次”统计有贡献，但不能说明每次都可靠。对于用户通常只提交一次的写作请求，不能用多次尝试后的最好成绩代替单次成功率。即使产品允许重试，也要考虑系统能否识别正确结果，以及额外耗时和成本。

几个容易误解的问题

held-out 是不是必须比 dev 更难？

不必须。如果目标是估计同类新任务的表现，应让测试集代表目标任务分布，同时避免重复和泄漏。若要检验跨领域或更高难度能力，可以另设测试组，但要单独说明范围，不能把不同分布的分数差简单归因于过拟合。

held-out 没用于本地开发，就能保证模型没见过吗？

不能。你能控制的是自己项目的开发数据和信息流；对于基础模型的预训练内容，往往无法完全确认。公开题目尤其要保留这一限制，不应把“本项目未使用”写成“模型从未见过”。

题目很少，必须机械分成三份吗？

不必为了目录完整把每份切得毫无代表性。可以先建立小型 dev 集明确任务与评分，再逐步积累独立验证和测试任务。暂时只有 dev 证据时，就报告开发集结果，保留尚未验证泛化能力的说明。

测试分数很好，就可以保证上线表现吗？

不能。评估结果受到任务覆盖、样本量、评分质量和环境的限制。小样本中没有出现失败，也不等于失败概率为零。上线后的输入分布和工具状态可能变化，还需要持续观察实际表现。

开始第一个评估项目时，可以先写下三句话：“哪些反馈允许我改系统”“哪些结果允许我选版本”“哪些任务会留到最后”。再据此管理数据、日志、Skill 和记忆，三个集合才会承担各自的职责。

参考资料

本文资料于 2026-09-11 查阅。流程与任务数量为教学设计，未执行真实 Agent 实验，不代表任何模型或 Skill 的实测效果。

本文由 AI 辅助生成，如有错误或建议，欢迎指出。