Harness² 把 Agent 的配置改动放回任务里检验：从执行记录定位失败，分别提出候选改法，在相同任务上试跑，再根据行为与产物的变化决定采用什么。已有 trace 和 eval 的团队，可以借此把漏读文件、跳过验证等失败，转成一次可审查、可回退的改进实验。

Harness² 到底在改什么？

Harness 可以理解成模型周围的工作系统：指令、工具、记忆、skills，以及任务怎么拆、结果怎么检查。模型权重保持不变，调整这些部分，也可能改变 Agent 完成任务的方式。

Harness² 把改进分成两层。

第一层处理当前任务：先运行原配置，观察问题；分别提出通用流程和领域流程的改法；运行候选配置；根据实际行为差异合成下一版，再执行一次。

第二层处理后续任务：保存采用的配置，以及什么情况下、什么改动起了作用。新任务从共同的基础配置开始，由改进过程选择性借用旧经验，而非一路继承上一份任务的全部配置。这个区别很重要：客户 A 的字段映射，不该自动变成客户 B 的规则。方法说明

先判断：你需要的是哪一种改进？

看到 Agent 出错，重试、换模型、加规则，都可能有效。选择取决于错误发生在哪里。

你观察到的问题建议先试什么取舍
给足材料、拆清步骤后，仍然理解不了关键关系比较更合适的模型，或补上缺失信息流程优化很难补齐缺失的能力或事实
每次都漏同一个明确步骤人工修正 skill 或脚本原因清楚时，直接修通常更省事
不同任务在不同环节失败，事先很难写全流程尝试 Harness² 式的候选改动与对照运行能按任务适配，但要承担额外执行和维护成本

比如，让 Agent 每周从同一种 CSV 算固定指标，优先写好解析和计算代码就够了。

如果任务是“读这批各不相同的资料，做出可交付的分析”，每次输入结构和要求都在变，事先穷举工作流会更困难。这才是我愿意尝试动态改进的场景。

还有一个很实际的前提：任务得能重跑。草稿、分析副本、隔离环境里的代码比较合适；会重复发邮件、扣款、改生产数据的步骤，要先从试验执行中拿掉。

同样一句要求，放在哪里差别很大

“检查一下结果”可以写进 prompt，也可以做成 skill、脚本或工具调用后的检查。每种方式的成本和约束力都不一样。

Harness² 开放了八类可编辑组件，包括系统提示、guardrails、记忆、工具指导、subagents、skills、脚本和 plugins。官方仓库

实际落地时，我会用下面这张表决定改动的位置。

需求更合适的位置一个具体例子
几乎每个任务都需要的短规则常驻指令或工具指导明确区分已完成的操作和准备执行的操作
某类任务才需要的专业流程按需加载的 skill做竞品比较时，先统一套餐、计价周期和使用量口径
有明确输入输出的重复计算或检查脚本检查必填列、重复 ID，以及分项之和是否等于总计
读取量大，但只需要返回少量结果的独立工作Subagent读一组文档，返回条款差异和原文位置
每次工具调用后都必须执行的机械动作Runtime hook / plugin文件写入后触发格式校验，失败时阻止进入交付步骤
后续任务确实需要的稳定事实带范围和来源的记忆某个项目已确认的术语定义，而非上一次任务的临时猜测

这张表的用法很简单：先问错误需要“判断”还是“执行”。需要根据上下文判断的流程，适合 skill；已经能够明确写出检查条件的部分，尽量交给代码。

如果一个数字检查每次都能由程序完成，就没有必要每次请模型重新理解一遍。相反，讨论市场进入策略时，硬编码一个固定检查清单也无法替代判断。

工具层的机制同样要看运行时是否真的支持，不能把一段写着“必须检查”的文本当成已经执行的检查。

用一个例子，把“自我改进”拆成可做的步骤

假设你有一个 Agent，每周读取销售、退款和广告支出，生成经营简报。下面是示例设计，不是我的实测记录。

某次报告收入偏高。看执行记录后，发现它读了销售表和广告表，没有读退款表。报告很流畅，但少了一份输入。

这时可以提出两个候选修复。

候选 A：修通用流程。 开始分析前列出输入文件及用途，交付前核对哪些文件实际参与了分析。希望解决的是“看到什么先做什么，做着做着漏了输入”。

候选 B：修领域流程。 增加经营简报 skill：计算净收入前核对退款口径，注明期间、币种和税费处理；关键数字保留到来源的对应关系。希望解决的是“即使读了文件，也不知道业务上该怎样合并”。

两个候选都在同一份输入的副本上运行，模型、工具权限和预算保持一致。比较时别只看哪篇报告读起来更专业，先看具体行为：

  • 退款表有没有被读取？
  • 净收入的计算口径有没有说明？
  • 数字能不能追回来源？
  • 原来正确的广告支出有没有被改坏？
  • 多花的时间和费用，换来了什么？

假如 A 补齐了输入，却仍然把退款算错；B 算对了退款，却漏了另一份附件，就有理由组合两者。但组合后仍要重跑，因为两段单独有效的流程放在一起，可能增加重复工作，甚至互相冲突。

也可能最好的决定是只留下 B，或者两者都不留。一次试验的价值包括排除没用的改动。

什么证据，足够让改动留下？

我会把采用分成两步，避免一次看起来不错就全局生效。

先判断它是否值得继续试。 改动需要对应一处可定位的失败，运行后出现预期的行为变化，产物也通过针对这处问题的检查。上面的例子里，“读了退款表”只是过程证据；净收入算对了，才是结果证据。

再判断它是否值得复用。 用没参与设计的新案例检查，尤其要包含原本能做对的案例。若结果波动明显，原配置和候选配置都多跑几次，看看差异是否持续。只在一个案例上见效，就先保留为该场景的候选经验。

这套采用门槛是我的工程建议。匹配输入和运行条件能减少干扰，但一次前后对比仍然可能碰上随机波动。把“行为改变了”“这次结果更好”“值得跨任务复用”分别记录，后续才知道哪一层证据还缺着。

保存什么，决定下一次能否少走弯路

最后保存“已解决收入计算问题”，几乎帮不了下一次。

更有用的记录可以很短：

  • 适用情况：多份文件共同支撑一份经营报告
  • 观察到的问题：销售汇总存在，但退款来源未参与计算
  • 采用改动：输入清单检查，加净收入核对流程
  • 支持证据：原运行遗漏退款表；修改后读取并解释了计算口径
  • 仍需核实：新任务的币种、期间、退款确认方式
  • 可复用文件：对应 skill 和检查脚本

这样留下的经验有适用范围。下一个任务可以复用检查方法，同时重新确认业务事实。

多跑几次值不值，要把账算完整

作者在 WorkBuddy-Bench、JobBench 和法律任务基准 LAB 上评估了这套方法。以 Gemini 3.5 Flash 配合 OpenCode 的 WorkBuddy-Bench 为例，平均分从基础配置的 72.4 提高到单步改进的 77.5；并行预算增加到 k=5 时为 80.8。这些是论文报告的三次运行均值，不能直接对应到某个产品的收益。官方结果

这里最容易误解的是“单步”。官方流程里，k=1 已经包含一次参考执行、两次候选探测和一次最终执行，另外还有生成改动、合成和经验整理的工作。流程说明

所以我会同时记三笔账：

  1. 质量收益： 漏项少了多少，人工返工是否减少，原来正确的案例有没有退步
  2. 完整成本： 所有候选执行、编辑和检查的费用，加上人工审查时间
  3. 等待时间： 用户从提交请求到拿到可用结果，实际等了多久

一个需要交给客户的复杂报告，多花几分钟换来更少返工，可能划算。每天调用十万次的简单请求，每次都跑整套改进流程，账可能完全不同。

我的起步选择会是：先离线找改法，把验证过的稳定部分放回日常流程。等到任务差异确实大到固定流程难以覆盖，再考虑让部分高价值任务在执行时自行适配。

如果需要扩大探索：有几个互相竞争的原因，适合并行试；上一轮改动已经奏效、下一处问题才显露出来，适合顺序试。两种方式都要先设预算，不能因为系统还能继续改，就一直让它改。

已经有 eval 的团队，怎样接上这一步？

上一篇 LLM eval 工具比较 解决的是：改了 prompt 后，怎样知道质量有没有变化。这里往前多走一步：看到了失败，怎样提出更有针对性的修复。

现有的 trace 和评测集都用得上。

Trace 提供诊断材料：Agent 读了什么，在哪里调用失败，哪一步开始偏离任务。评测集负责检查修复之后的结果，尤其是没参与改动设计的新案例。

论文说改进阶段不需要标准答案，含义是提出和筛选配置时可以利用执行差异。论文里的最终结果仍由基准评测衡量；它也明确承认，执行差异和模型判断不能保证正确性。实验设置与限制

落到自己的系统，能写确定性校验的地方就保留校验；涉及业务判断的地方，用清楚的评价标准和人工抽查。已经有更可靠的反馈，就继续用，不必为了复刻“无标准答案”的设定把它关掉。

第一次实验，做到多小才合适？

我会把第一次实验限制在一类任务和一个反复出现的问题上。

第一步：选 8–12 个已有案例。 拿一部分诊断和试改动，另一部分先留着。里面既要有失败案例，也要有原本能做对的案例。这个规模适合发现明显问题，还不足以证明普遍有效。

第二步：固定比较条件。 记录模型、原始配置、工具和预算，保留输入副本、输出与执行记录。否则模型升级和数据变化都可能被误认成配置收益。

第三步：只提出两个有明确假设的改法。 一个针对通用流程，一个针对任务本身。每个改法都写清：它要改变哪一步，预期看到什么现象，可能伤害什么已有能力。

第四步：运行并决定是否保留。 检查具体错误有没有减少，再拿预留案例验证。结果不稳定的地方重复运行；没有改善证据的改动先不加入正式配置。

第五步：留下最小可用版本。 保留原版本、改动差异、适用范围、测试结果和回退方法。先让人审核，再考虑自动采用。

这五步可以先手工做。对短任务，一个下午足够启动第一轮；长任务的执行时间和评估时间另算。初次目标是判断这种改进方式对你的问题有没有用。

如果你已经保存了失败执行，可以把下面这段交给负责诊断的 Agent：

根据任务要求、当前配置、执行记录和产物，找出一个可以定位到具体步骤的失败。分别提出一个通用流程改动和一个领域流程改动。每个改动说明：证据在哪里、改哪个组件、预期改变什么行为、可能引入什么退步，以及怎样比较。没有足够证据时明确说不知道。先给出可审查的最小 diff，不修改权限、凭据或对外操作规则。

参考资料