原文标题：Better Harness: A Recipe for Harness Hill-Climbing with Evals 原文链接：https://blog.langchain.com/better-harness-a-recipe-for-harness-hill-climbing-with-evals/
作者：Vivek Trivedy，产品经理
我们可以通过构建更好的 Harness 来构建更好的 Agent。但要自主构建一个”更好的” Harness，我们需要一个强有力的学习信号来进行”hill-climbing”。我们分享如何使用 Evals 作为该信号，以及帮助我们的 Agent 泛化而不是过拟合的设计决策。Better-Harness 是一个用于迭代采集和改进 Harness 的系统，使用 Evals。
Evals 是 Agent 的训练数据
在经典机器学习中，训练数据指导模型的学习过程。每个训练示例贡献一个梯度来更新模型的权重朝向”正确性”。我们对 Agent 有类似的学习循环。
Evals 编码我们希望我们的 Agent 在生产中表现出来的行为。 它们是 Harness 工程的”训练数据”。每个 Eval 案例贡献一个信号，比如”Agent 采取了正确的行动”或”产生了正确的结果？“该信号指导对 Harness 的下一个建议编辑。
我们在模型训练的数据质量和策展中付出的相同严格和关心也应该投入到 Eval 设计中。我们在之前的文章中讨论了数据质量的重要性，如何为深层 Agent 构建 Evals。
最近有一些很好的工作形式化了优化 Harness 的步骤，包括来自斯坦福的 Meta-Harness 和来自 DeepMind 的 Auto-Harness。我们之前还分享了一个 Harness 改进循环，通过仅调整 Harness 层来 hill-climb Terminal Bench 2.0。我们认为围绕更新算法本身有很好的未来工作要做，但 Harness 改进是一个超越更新算法的复合系统，这是我们在这里讨论的。
Better-Harness 是复合系统工程的一个尝试。
数据采集 → 实验设计 → 优化 → 审查与接受
所以我们包含了伴随更新循环的实际细节，例如我们首先如何采集 Evals，我们如何设计以防止过拟合，随时间存储跟踪，以及手动审查更新以检查我们发送到生产的任何东西。
采集好的 Evals
Evals 是支持 Harness hill-climbing 过程的基础。以下是我们采集、策展和使用它们的实际方式。
手工策展。 对于任何给定的任务，团队手动编写示例，捕捉我们认为 Agent 应该在生产中做的事情。这些通常很有价值，但难以大规模生成。
生产跟踪。 每个 Agent 交互生成一条跟踪，其中失败成为 Eval 案例。从跟踪中挖掘 Eval 材料是改进 Evals 的杠杆、高吞吐量方式。即使在对 Evals 运行 Agent 之前，通常使用我们的 Agent 的团队会直接在 Slack 中报告错误，带有跟踪链接。我们建议使用 Agent 和直接分享反馈供所有人看到，这有助于建立关于 Agent 行为的共享知识。
外部数据集。 这些数据集很有用，但需要手动策展以确保用于改进 Agent 的测试案例反映所需行为。通常调整每个任务以确保它们衡量重要行为。
标记一切。 每个 Eval 都标记为行为类别：“工具选择”、“多步骤推理”等。标签启用有意义的保留集和有针对性的实验。它还节省了很多钱，因为我们可以运行 Evals 的子集。
构建泛化的学习系统
任何学习系统的理想结果是泛化。我们给出一个输入信号，捕捉我们在野外想要的行为分布。系统拟合它，然后在它从未见过的新输入上”刚好起作用”。
明显的问题： 我们没有无限的数据。
修复： 将重要行为编码到策展的 Evals 中。质量 > 数量，一个小集合的良好标记的 Evals 涵盖你关心的行为击败数千个嘈杂但高覆盖率的 Evals。
微妙的问题 → Agent 是著名的作弊者： 任何学习系统都容易受到奖励黑客的影响，其中 Agent 过拟合其结构以通过它可以看到的现有 Evals。这是合理的，因为循环只想”让数字上升”，对泛化一无所知。我们促使避免过拟合，但它不是完美的。
修复： 保留集成为真实泛化的代理。我们看到了与人类审查配对作为第二信号的方法，我们得到了半自动化的系统可以改进分数，同时避免我们不想在生产中看到的行为。
Better-Harness：hill-climbing 你的 Harness 的秘诀
我们创建了一个脚手架，用于使用 Evals 作为每个步骤中的信号自主改进我们的 Harness。研究版本在这里开源，这是主要步骤：
采集和标记 Evals。 这是手动编写 Evals、从生产跟踪中挖掘它们以及使用/调整外部数据集的混合。我们将每个 Eval 标记为行为类别（如多步检索），并定期删除已饱和或我们不再认为对 Agent + 当前一代模型有用的 Evals。按类别分割数据。 创建优化和保留集。这非常重要！我们发现自主 hill-climbing 倾向于过拟合任务，因此保留集确保学到的优化在以前未见过的数据上工作，尽管一般分布应该与现有 Evals 相匹配。这反映了生产会是什么样子。运行基线。 在任何编辑之前在优化和保留集上运行基线实验。这将所有更新基础化在更新步骤中。优化。 每个迭代自主运行，可选手动审查：诊断 从跟踪。分数汇总跨类别的性能，然后跟踪显示出了什么问题和为什么的细节。实验 一个有针对性的 Harness 变化。我们将范围限制为一次一个变化以避免混淆，但这可能意味着同时更新提示和工具，以便系统协同工作。
验证： 在每个步骤中，循环检查以确保建议的变化有助于通过新的 Evals，同时避免对现有通过的案例的回归。一些变化导致净总体分数增益，但有一些回归，这是常见的。Agent 获得这些回归的上下文，以便它可以尝试在下一次更新中修复它们，而不会失去现有更新的收益。人工审查。 我们手动审查变化和边缘案例指标遗漏。这通常包括过拟合到优化集的指令，尽管它们不会伤害泛化，但它们最终是浪费标记。这给了我们另一个健全性检查和防止过拟合的大门。
Harness 变化的示例
以下是优化循环可以发现和验证的变化类型：
提示和指令更新。 最常见的变化。Agent 不断误解工具的输出格式，或者在应该先提出澄清问题时太渴望调用工具。修复是一个有针对性的指令更新添加，比如”当查询具有相关信息的多个文件时，将信息卸载到文件系统并在给出最终答案之前重新聚合。”
添加或更新工具或工具描述。 Agent 可能在上下文化何时使用新工具时失败。编辑包括如何使用的示例、如何链接此工具、更新的工具描述，以及编辑整体工具套件以消除类似工具的歧义
Better-Harness 循环的结果
我们在 Claude Sonnet 4.6 和 Z.ai 的 GLM-5 上测试了这种方法，在我们的 Evals 的一个子集上。注意： 我们有其他工作正在进行中，在 deepagents 中使用更大的 Eval 套件将 Better-Harness 泛化到许多模型。目标是发布一系列模型概要，捕捉针对我们的 Evals 调整的每个模型的细微差别，作为公共工件。
我们从现有 Eval 类别中组装了一个小的代表性样本，并将该样本分成一个用于 hill-climbing 的集合和一个用于评估泛化的保留集合。对于大型或昂贵的 Eval 集合，我们建议代表性/分层采样以给出一个好集合进行 hill-climbing。一旦这工作良好，它可以扩展到更大的集合。
主要实验目标： 发现并修复我们的 Evals 上的失败模式。移植增加 Eval 性能的一般变化回到 Harness。
我们之前观察到的失败模式，例如过度提问后续问题和链接新工具的错误。在优化集上的 hill-climbing 后，我们使用两个类别在保留集上评估最终的 Harness，tool_selection 和 followup_quality。
| 模型 | 阶段 | 优化工具使用 | 优化后续 | 保留工具使用 | 保留后续 |
|---|---|---|---|---|---|
| Claude-sonnet-4-6 | 前 | 1/2 | 0/3 | 7/8 | 2/6 |
| 后 | 2/2 | 2/3 | 7/8 | 6/6 | |
| GLM-5 (baseten) | 前 | 0/2 | 0/3 | 6/8 | 1/6 |
| 后 | 2/2 | 3/3 | 7/8 | 6/6 |
结果在两个模型上都很强，两者。两者都几乎完全泛化到保留集，该保留集涵盖了相同功能的完全看不见的示例。
许多收益来自围绕发现失败模式的更明确指令。以下是优化循环发现的一些具体示例，我们发现很有趣：
| 共享变化 | 观察到的任务 | 模型 | 添加的指令 | 变化后的效果 |
|---|---|---|---|---|
| 使用合理的默认值 | tool_indirect_email_report | Sonnet, GLM-5 | ”当请求清楚地暗示合理的默认值时使用它们。“ | Agent 停止在琐碎的遗漏措辞上阻挡，更可靠地完成行动采取 Evals。 |
| 尊重已修复的约束 | followup_vague_send_report、followup_detailed_calendar_brief | Sonnet, GLM-5 | ”不要要求用户已经提供的详细信息。“ | 定期任务后续 Evals 停止在冗余的计划问题上失败。 |
| 在行动前限制探索 | tool_chain_search_then_email | 主要是 GLM-5 | ”一旦您有足够的信息来草拟简洁的摘要，不要继续发出接近重复的搜索。“ | 搜索然后交付 Evals 变得更加可靠，而不是循环。 |
| 先提出域定义问题 | followup_vague_customer_support、followup_vague_monitor_system | Sonnet, GLM-5 | ”在实现问题之前提出域定义问题。“ | 第一个后续变得更相关，这是一种规划策略的形式 |
对于将新工具注入默认 Harness 的 Evals，比如 search-then-email，循环发现了更好的如何使用和组合这些工具的描述。这对于在各个领域创建垂直 Agent 的构建者很有希望，因为优化循环适应上下文中的任务细节。
Evals 维护与回归
随着 hill-climbing，Evals 也明确捕捉并防止随时间的回归。一旦我们的 Agent 正确处理一个案例，我们不想失去那个收益。Eval 变成了一个回归测试。这类似于传统软件工程中的想法，比如测试驱动开发（TDD）。一些回归必然会在许多随时间的变化中发生，所以我们选择一个我们总想通过的 Evals 子集，如果这些突然失败，我们可疑地看我们的运行。
我们不认为我们的 Eval 套件应该单调增长，Evals 的春季清洁很好！我们定期评估 Eval 是否由于更智能的模型或我们想要的 Agent 的不同行为而仍然有用。
未来：自动化错误检测与修复
这种方法有效，因为跟踪给了我们一个密集的反馈信号。Evals 受益于跟踪以比较版本并在数值上基础化哪些变化有助于更好的分数（这应该是更好的用户体验的良好代理）。
总的来说，我们将代理计算指向跟踪以：
自动推导错误。 我们想不断监控我们的 Agent 跟踪以在生产中分类和聚集失败。从生产生成 Evals。 一条 Agent 犯了错误的跟踪是一个 Eval 案例。一条用户更正 Agent 的跟踪甚至更好。飞轮：更多使用 → 更多跟踪 → 更多 Evals → 更好的 Harness比较 Harness 版本。 并排跟踪比较显示 Harness 中发生了什么变化，导致新行为
每条跟踪都包含产生潜在 Eval 的宝贵数据。每个（好的）Eval 都使 Harness 更好。为了促进这一点，所有 Agent 运行都记录到 LangSmith 中，具有完整的跟踪。这为我们提供了优化循环的跟踪级诊断，用于回归检测的生产监控，以及用于 Eval 生成的跟踪挖掘。
我们的主要要点和进行中的工作：
Evals 是自主 Harness 工程的训练数据。 使 ML 训练工作的相同原则，如数据质量、训练/测试分割和泛化检查适用于 Agent 开发。
为 Harness 拟合模型。 有大量工作投入到为其 Harness 拟合每个模型。例如，Codex 提示指南为其 Edit 工具建议了特定的格式。这需要更大的搜索空间和 Eval 集，我们很高兴为任何想这样做的团队分享真实的例子。
总的来说，跟踪和维护好的 Evals 是使该系统在实践中工作的原因。早期与你的团队投资这个，并来构建自主改进 Agent 的未来。我们为构建者开源了这个脚手架的研究版本进行实验。