Harness² 深度解析：让 Agent 的执行方式持续改进

目录

• 1. 开放世界任务为何让 Harness 难以维护
• 2. 从论文原图理解 Harness²：两层递归如何连接
  • Harness² 实际允许修改哪些东西
• 3. Propose–Probe–Compose：行为对比怎样指导一次修改
• 4. 第二层递归：积累可以再次执行的改进经验
• 5. 实验结果支持了什么
• 6. 如何使用 Harness²：从 WorkBuddy 示例到 DeerFlow 接入
  • 用 WorkBuddy-Bench 走一遍官方链路
  • 把这个流程接到 DeerFlow
• 7. 先接 DeerFlow：把一次实验执行做成可比较的协议
• 8. 让改进进入生产：回归、发布与总成本
• 附录：参考资料与校准说明
  • 校准说明
  • 名词与概念
  • 参考资料

双层递归、可执行经验与 DeerFlow 的工程接入

一个 Agent 接到新的资料研究任务，明明能读取文件、搜索和写报告，却反复打开同一份材料，最后交出一篇看似完整、引用却没有核对过的文章。工程师可以补一条提示词，也可以加一个引用检查脚本。但任务每变一次，就得重新发现问题、重新猜测改法。如果这些尝试只留在聊天记录和临时分支里，系统的维护成本会随着任务种类一起增长。

Google Cloud AI Research 的 Harness² 项目研究的正是这件事：模型权重保持固定，让 Agent 在执行新任务时调整模型周围的 Harness，并把这次调整得到的证据用于下一次调整。 论文把这个过程称为 recursive agent harnessing。其目标不只是为当前任务找到一份更合适的执行配置，也包括改进“以后如何修改执行配置”的过程。论文与摘要、官方仓库

这个方向值得关注，也容易被误读。Harness² 的在线反馈是执行行为的对比，不等于任务正确性的证明；它开源的是能运行的研究流程，不是已经具备业务回归、隔离 Worker 和生产发布能力的通用服务。下面先沿论文原图解释方法，再讨论如何把它接到已有 DeerFlow 执行器上。

1. 开放世界任务为何让 Harness 难以维护

这里的 Harness，可以理解为模型执行任务时依赖的提示词、记忆、工具指引、Skills、脚本、委派方式和运行控制。它决定模型看见什么、能做什么、什么时候调用工具，以及结果如何变成交付物。过去讨论 Agent 工程时，我更常把它放在 framework、runtime、harness 的分层中：框架提供编排抽象，运行时负责实际执行，Harness 是围绕模型组织能力与约束的可调整部分。具体项目的边界未必完全一致，本文采用这个操作性定义。相关阅读：DeepAgents 深度解析、论文 §1–2

让 Harness 自行修改，首先碰到两个问题。其一，新任务在设计阶段没有出现过，在线执行时往往没有现成答案或可靠评分器。修改一份 Skill 以后，系统很难立即得到“分数提高了”的监督信号。其二，某个任务中好用的执行配置可能包含大量领域细节；直接带到下一任务，未必能带来同样收益。论文据此把关注点从“保存一份成功配置”，推进到“保存这份配置为什么被提出、怎样被试过、观察到了什么”。论文引言

本文用一个 假设场景 贯穿机制说明：Agent 根据多份材料生成带引用的研究报告。基线执行可能出现重复读取、关键材料漏看、引用核对不足。这里没有真实业务实验，也不会为示例编造提升分数。它只用于说明：没有标准答案时，怎样让一次 Harness 修改仍然有可检查的依据。

2. 从论文原图理解 Harness²：两层递归如何连接

图 1：Harness² 的双层递归流程。图源：Ruiyao Xu 等，《Harness²: Recursive Agent Harnessing for an Open World》，arXiv:2610.14224v1（2026），原论文 Figure 3；论文图注、查看高清原图、项目官网。图片内容未修改；论文页面标注 CC BY 4.0。

这张图最好按箭头读，而不是只看中间的几个角色。蓝色区域处理当前的 Task t，紫色区域处理下一次改进将参考的经验。它们相连，但保存和传递的对象不同。论文 §2 与 Figure 3

第一步，左侧的 Agent Executor 用 Initial Harness 跑当前任务。 它产生轨迹（trajectory）与交付物（output）。轨迹可以展示是否读取了材料、何时调用工具、在哪一步重试；交付物能展示报告、文件或回答本身。基础执行揭示的是当前 Harness 的行为，单看一次运行还不能判定答案正确。

第二步，Harness Editor 给出两个不同范围的候选。 图里的 Invariant 指跨领域可能重现的代理性缺陷，比如规划顺序混乱、无效工具调用、上下文管理不当；Domain 指当前领域的知识、流程与约束。两个候选都是对可执行 Harness 文件的编辑。用假设的研究报告任务看，前者可以规范材料清单与阶段性检查，后者可以加入引用核对 Skill 和确定性脚本。

第三步，Candidate Probes 让两个候选在同一个任务上执行。 运行时尽量匹配模型与环境条件，再比较各自轨迹、交付物和基础执行。假如某个候选减少了重复读取，却让 Agent 跳过最终核对，这就是一个需要带进组合阶段的回归观察。对比为“编辑引起了什么行为变化”提供证据；它没有自动产生正确答案验证器。

第四步，Harness Composer 读取候选、文件差异和执行证据，形成 Final Harness。 它可以合并有依据的修改、改写冲突的部分、仅采纳其中一个，或保持原配置。组合后的 Harness 还会执行一次，并连同决策依据留下记录。图中的 Final Harness 指当前任务被采用的版本；论文用星号表示“被选中”，不表示数学上的最优或已经通过独立业务验收。论文 §2.2

第五步，右侧的 Experience Reflector 回看完整改进过程。 它把可执行配置与有对比证据支持的经验写入 Improvement Harness 的库中。底部箭头 “Move to the next task” 容易产生误解：论文下一任务仍从公共基础执行 Harness $H_0$ 出发，先前任务的执行配置并不自动成为新默认值；更新过的经验库会引导新的提案与组合。论文 §2.3

这就是标题中平方的含义：一层改进当前任务的执行方式，另一层积累“怎样改进执行方式”的经验。两层之间靠执行记录连接。模型参数、各阶段提示指令和决策规则在论文设定中保持固定；持续变化的重点是经验库。

Harness² 实际允许修改哪些东西

论文把执行 Harness 拆为八类可编辑的文件级组件。它们覆盖的不是同一种能力，因此在业务接入时也不应全部塞进一条长系统提示词。论文 §2.1 与 Appendix D.3、官方 README

文件级拆分使编辑、比较和版本管理变得具体。执行器是否真的按指定版本加载这些文件，是后面业务集成的第一道验收题。

3. Propose–Probe–Compose：行为对比怎样指导一次修改

论文把一次任务内改进写成 Propose–Probe–Compose。它的价值在于把“我觉得可以加一句提示词”变成一条有目标、有运行记录、有取舍理由的编辑链。论文 §2.2

Propose：先定位缺陷，再提出两种范围不同的修改。 基础运行、当前任务、已有 Harness 和经验库一起交给编辑器。通用候选处理跨任务可能重复出现的规划、工具使用、上下文或委派问题；领域候选处理当前领域的程序、格式或约束。候选可以复用经验库组件，但任务事实仍要按当前材料核对。对报告案例，通用候选若提出“先建立材料清单再写作”，领域候选若提出“引用必须能回溯到原文件页码”，两者要各自落实到真实可加载的组件文件。

Probe：让修改后的 Harness 真正执行同一任务。 只阅读 diff 无法知道 Agent 是否照做。Probe 记录候选运行中的动作与观察，再与基础执行作对照：重复读取是否减少，引用核对是否发生，脚本是否成功完成，是否出现新的提前结束或额外调用。这里的匹配条件包括同一任务、模型和环境配置；即便如此，模型采样仍可能造成波动。一次有利轨迹只能支持一个有限判断，不能直接证明效果会稳定迁移。论文 §2.2.1 与 Appendix F

Compose：把证据转为具体文件决策。 组合器不必在两个候选之间二选一。例如，通用候选提高了材料覆盖率，而其中某条护栏令输出中断；领域候选改善了引用核对，但增加了无意义的全量复读。组合器可以保留前者的材料清单与后者的核对脚本，删去引起回归的规则，并记录这些选择对应的观察。新的组合配置还要再次执行，形成下一条可检查的轨迹。

可用的判断链是：观察到的缺陷 → 编辑的组件与意图 → 同任务运行中的变化 → 保留或舍弃的理由。其中最后一环很关键。如果日志只写“新版本更好”，既无法复盘，也很难让后续任务知道适用条件。把行为对比写成任务正确性结论，则越过了证据本身的范围。

论文给出了一个真实的 JobBench 案例（Figure 9），恰好把这条链串起来。基线轨迹显示，Agent 没有对多份源文件中的数字做核对，也没有在写完后重新打开交付物检查。通用候选增加了盘点输入、追踪数字来源和回读文件的流程约束；领域候选增加了处理日程、场地、人工与预算文件的专项 Skill，以及数字格式的工具指引。Composer 根据候选执行证据保留了两边的四处修改，组合后重跑补齐了备忘录缺失的章节。论文的 事后基准评测 给出 43.1→77.8 分。这个分数帮助读者理解案例效果，却没有在当时作为在线编辑器可见的反馈。这里的关键变化，是把“写完文件”推进为“文件中的数字可追溯、文件本身可复查”。

任务级递归还可以扩大预算。Parallel 模式在同一轮收集更多通用和领域候选，分别组合多个后继配置，扩大探索宽度；Sequential 模式连续运行多个改进步骤，让下一步继承前一步配置和累积执行证据，增加精炼深度。论文中的 $k$ 控制预算；$k=1$ 时两种方式退化为同一个基础步骤。$k>1$ 时，最终选择器从既有交付物里选一个，不重新综合新内容。更多探索通常意味着更多模型调用、运行时间和费用；论文只研究了有限预算范围。论文 §2.2.2、Appendix F

4. 第二层递归：积累可以再次执行的改进经验

如果每个任务都只留下最终交付物，下一个任务仍要从头推测改法。Harness² 保存的是一次改进的完整记录：基础执行、候选修改、探测结果、组合决定和最终采用的配置。任务结束后，Experience Reflector 从中挑出有行为证据支持的教训。论文 §2.3

经验库条目包括可执行 Harness 组件，以及记录适用场景、教训与支持证据的 EXPERIENCE.md。索引帮助后续改进会话按需查看相关条目。证据不足时，反思阶段可以不新增经验；“本次选中了某个输出”本身不足以证明这个修改可以迁移。这个设计让经验既有文本解释，也有能被再次装载、编辑和探测的文件。论文 §2.3

论文对复用的测量也提示了一个细节：经验库里的文件更多被 改编，而不是被整份复制。补充实验中，按基准不同，约 22%–47% 的已修改文件能找到可追溯的库内内容；真正保留库条目一半以上行数的文件只有 2%–10%。这与“任务仍从公共配置起步”的机制一致：库提供可检查的起点和适用经验，新任务仍需要针对自己的材料重新编辑、探测。论文 Appendix E.2

由此要分清四种常被混在一起的资产：

论文讨论的是第三项；第四项属于本文后面提出的生产工程层。任务内采用的配置可以进经验库，但不应因此自动覆盖线上默认版本。也正因为下一任务从 $H_0$ 开始，经验库中旧组件的复用需要先判断新任务是否相似、约束是否仍成立，再由提案阶段选择性引入。论文 §2.3

5. 实验结果支持了什么

论文在三个专业基准上评估：WorkBuddy-Bench 覆盖 Code、Web、Office 交付物，JobBench 覆盖较长流程的职业任务，LAB 是法律工作基准，表中的 Partial 表示按评估条件统计的部分通过率。主结果是三次不同任务顺序运行的均值；执行模型为 Gemini 3.5 Flash 和 GLM-5，初始执行 Harness 为 OpenCode 或 Codex，默认编辑器为 Claude Opus 4.8。下表选取同一轮 $k=1$ 的几个配置，避免把不同指标拼成一个“总提升”。论文 §3、表 1–2

这些数字说明：在论文的任务流与执行环境里，一轮基于对比证据的 Harness 修改，能给不同模型和基准带来增益。它们没有给 DeerFlow 或任何特定业务任务提供收益预测。论文还报告，WorkBuddy-Bench 上 Gemini 3.5 Flash / OpenCode 的平均分在并行 $k=5$ 时由 $k=1$ 的 77.5 增至 80.8；增加预算有效，但要算上编辑器和候选执行的成本。论文 §3–4

另外两组结果有助于理解“双层递归”是否有价值。去掉经验库后，WorkBuddy-Bench 的对应分数从 77.5 降至 74.4，JobBench 从 36.0 降至 34.2；说明在该实验设置中，跨任务经验确实影响后续修改。把 JobBench 积累的库用于 WorkBuddy-Bench 的一次修改，在 Code、Web、Office 三个子集分别带来 0.6、0.5、2.9 分增益。论文明确指出后一项是回顾性迁移测试，不能写成真实在线部署后的持续学习成绩。论文 §4 与表 3

还有一条容易被放大的结论：论文展示过相对弱一些的执行模型，在改进后的 Harness 下超过更强模型的基础配置。这证明 Harness 影响很大；它没有证明“改 Harness 总能替代换模型”。在 JobBench 上，Gemini 与 GLM-5 的增益排序就不同。论文自身也指出，执行对比受随机性和共同模型偏差影响，不保证结果正确或能迁移到新任务。论文 §3–4、Appendix F

“工具调用更可靠”也不等于“调用次数总会更少”。在 Gemini 3.5 Flash / OpenCode、$k=1$ 的实验里，论文记录三个基准的工具错误率都下降；但 JobBench 的平均调用数从 27.4 增到 32.8，LAB 从 20.8 增到 25.2。多出的步骤可能用于核查，不能只按调用次数判断好坏。补充失败分析还列出九个相对基线退化的案例：选择器有时选中较弱交付物，候选也可能共享同一个错误前提；输出波动和评测缺失进一步增加归因难度。这些反例说明，Probe 的执行对比需要连同不确定性一起保存。论文 Appendix E.4、E.6

6. 如何使用 Harness²：从 WorkBuddy 示例到 DeerFlow 接入

官方仓库已经交付可运行代码，支持并行与顺序递归、OpenCode 和 Codex 执行器，以及 JobBench、LAB、WorkBuddy-Bench 三个适配器。仓库提供不需模型凭证的本地 demo：它使用确定性编辑器和真实 Python 执行，适合看懂流程；模型驱动的基准运行仍需相应环境与模型配置。仓库也提供运行记录、结果和恢复机制。它可以作为方法核心复用，但并未把业务 API、分布式实验 Worker 或生产发布流程一并交付。官方 README：安装、实验与结果

用 WorkBuddy-Bench 走一遍官方链路

若要从“看懂机制”走到“运行真实任务”，WorkBuddy-Bench 是仓库里比较直观的入口：它分为 Office、Web、Code 三个子集，官方示例按子集分别安装和运行。以 Office 为例，先按 安装说明准备 Linux、Python 3.12、uv、Node.js 20+、Google Cloud CLI 和 Docker，再在 .env 中设置 Vertex 项目及模型。官方 WorkBuddy 配置要求 HARNESS2_SOLVER_MODEL 使用 google-vertex/gemini... 形式、HARNESS2_JUDGE_MODEL 使用不带提供商前缀的 gemini... 模型名，并设置 GOOGLE_CLOUD_PROJECT；改进模型可单独配置，缺省时沿用执行模型。只想观察递归流程时，可先运行不需模型凭证的 harness2-demo --output runs/demo --k 2；下面的 WorkBuddy 命令会调用模型并产生费用。WorkBuddy 指南

git clone https://github.com/google-research/harness2.git
cd harness2
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
cp .env.example .env
# 在 .env 中填写 GOOGLE_CLOUD_PROJECT、HARNESS2_SOLVER_MODEL、HARNESS2_JUDGE_MODEL
# HARNESS2_IMPROVER_MODEL 可选；缺省时沿用执行模型
gcloud auth application-default login
docker info
harness2-setup wb --subset office
harness2-check --bench wb --subset office
harness2 --bench wb --subset office --k 1 --mode parallel --dry-run
harness2 --bench wb --subset office --k 1 --mode parallel --max-tasks 1
harness2-judge --bench wb --subset office --k 1 --mode parallel
harness2-report --bench wb --subset office --k 1 --mode parallel
# 可选：给同一次运行中的基础 Harness 单独评分
harness2-judge --bench wb --subset office --k 1 --mode parallel --bases

这里的 wb 是 WorkBuddy 适配器，office 是本次选定的子集；换成 web 或 code 时，安装后的检查、运行、评测和报告都要使用同一个 --subset。--dry-run 先预览任务选择，不调用模型。--max-tasks 1 是 每个领域最多一题，并不保证整次运行只有一题；若只想试一个领域，应先从预览结果里选出领域，再给运行命令加 --only-domains <领域名>。评测与报告必须沿用相同的基准、执行器、子集、k、模式和种子。官方 WorkBuddy 数据有单独的许可条件，实际下载前应阅读其 上游许可。README 的命令约定、实验指南

这组命令背后做了什么，比命令本身更值得借鉴：harness2-setup 安装固定版本的 WorkBuddy 运行环境、适配补丁和所选子集的数据；适配器从任务文件发现输入，并按任务元数据组织经验库。每次候选执行使用新的基准容器；运行与交付物保存在 runs/wb/office/。harness2-judge 在候选选择完成后读取验证结果，harness2-report 汇总改进后的离线分数；验证器的 score.json 不会交给在线编辑器。如需和基础 Harness 的评分比较，可另用同一组参数运行 harness2-judge --bases，它将基线结果写入 base_judged.json；常规评测写入 judged.json。这就是“在线靠行为对比决定怎样改，离线再用基准评分检验结果”的实际边界。WorkBuddy 指南：安装、任务、容器与评分、实验指南：结果与基线

把这个流程接到 DeerFlow

适配其他 Harness，要完成两件事。业务任务适配 负责列出任务、提供真实输入与材料、抽取交付物、导出可读轨迹、声明领域与任务约束。执行框架适配 负责定义可编辑组件的文件结构，把候选文件准确装入目标执行器并校验。源码中的 BenchmarkAdapter 与 SubstrateLike.surface() 给出了这两个方向的接口；execute(task_id, harness_dir, run_id, timeout) 返回运行目录，评测 score() 的接口说明则把打分放在最终选择提交之后。因此，离线评测分数不能被写成 Harness² 在线 Compose 的反馈。适配协议源码

WorkBuddy 展示了“任务适配、隔离执行、收集证据、事后评分”的完整闭环，但它的任务文件、容器和评分器不能直接替代 DeerFlow 的业务任务。第一阶段可让 Harness² 保持为独立的旁路进化服务：DeerFlow 继续负责生产执行，实验 Worker 则按候选版本加载 DeerFlow 配置，对同一任务快照反复运行，并把轨迹与交付物转换成 Harness² 可读取的记录。下图是 本文的工程方案，不是论文或官方仓库的现成部署图。

这张表只是职责映射，不表示 DeerFlow 已有同名接口，也不表示 WorkBuddy 的评分器可用于业务验收。WorkBuddy 适配说明、Harness² 适配协议

图 2：本文建议的职责边界。紫色对应 Harness² 方法核心，蓝色对应现有执行器，绿色对应需要补充的发布门禁；虚线表示证据回流与受控发布。该图是本文工程方案，不是官方交付架构。 查看高清架构图，可放大阅读。

“独立”不一定意味着第一天就拆成多个微服务。先在一个进化服务里封装提交、查询、取消、预算与幂等；执行 Worker 可单独扩容。Harness² 核心目前以候选 Harness 目录和运行结果目录为主要接口，远程 Worker 因此需要一个桥接层：上传任务快照与候选包，执行后把结构化轨迹、交付物和必要文件落回可追溯的运行目录。这个目录契约跑通后，再考虑分布式存储和服务拆分。适配协议源码、仓库运行说明

7. 先接 DeerFlow：把一次实验执行做成可比较的协议

DeerFlow 已有可嵌入的 DeerFlowClient 入口、配置、技能选择与流式事件；这些能力适合承接一次实验执行。接入时最重要的不是让编辑器先自动写提示词，而是证明“指定候选文件在一次独立执行中真实生效，并且它与基础执行的条件可比较”。当前公开源码中的客户端会缓存构造后的 Agent 与部分配置，配置对象也可能存在进程级状态；仅换一个 thread ID，不能作为配置和记忆完全隔离的证据。DeerFlowClient 源码、配置说明

我会把第一版可编辑范围收敛到 提示词补充、Skills、检查脚本。这几类组件较容易版本化、装载与验收。中间件、子智能体和更深的工具循环改动先留在候选范围之外，等执行协议、依赖与回归稳定后再开放。收敛编辑面是工程取舍，不是 Harness² 方法本身的限制。

快照要包含任务输入、附件、可读的初始记忆、工具版本、模型参数和执行器版本。Worker 至少隔离文件目录、checkpoint、配置实例、缓存与记忆写入。若工具连接数据库、邮件或外部业务 API，容器只能隔离本地进程，不能撤销已经发生的外部副作用；这些工具需要测试租户、模拟接口或可恢复的测试数据。相同快照控制的是初始条件，不保证随机模型产生逐字相同的轨迹。

每次运行最好再留一份简短的 run manifest：任务快照哈希、候选 Harness 哈希、实际加载哈希、模型与执行器版本、工具环境版本、run_id、轨迹位置、交付物位置、结束原因和用量。这里特别要同时记录“请求加载什么”和“真正加载了什么”；否则缓存造成的配置串用，会被误判为某个候选无效。这个 manifest 是本文建议新增的证据协议，不是 Harness² 仓库已经定义的通用服务格式。

在自动改进前，先由工程师手写两份候选配置，让 DeerFlow Worker 按同一任务快照分别执行，检查实际加载哈希、轨迹和产物。若这一步无法复现候选差异，接上自动提案只会放大不可解释的噪声。完成协议验证后，再把 Harness² 的提案、探测、组合接到同一入口。这样，业务生产路由可以继续工作，进化任务在旁路积累证据。

8. 让改进进入生产：回归、发布与总成本

Harness² 的 Probe 回答的是“某次编辑对当前任务的执行产生了什么影响”。业务生产还需要另外回答：“没有参与这次编辑的任务是否退化？关键规则是否被违反？费用和延迟是否可接受？”因此，我建议把 候选采纳、经验保留、生产发布 作为三个独立决策。前两个可以主要依据论文的行为证据；生产发布要引入独立任务集、业务验收与版本审批。论文 Appendix F、相关阅读：验证与测量

回归可以分四层看：组件能否加载与校验；轨迹是否出现无效调用、遗漏步骤或副作用；任务交付物是否满足约束；端到端业务是否减少人工返工、提高合格交付率。没有 ground-truth 的生产任务，仍可用可检查的硬约束、抽样人工评审和业务后验指标补证。不要把一段自我评价文本当成独立验收。

发布流程可以很朴素：固定一个不可变配置版本，运行中的任务一直使用启动时的版本；新候选先过回归，再由业务范围或灰度策略选择后续任务使用；发现退化时把版本指针切回旧配置。每份版本都保存来源 task、采用理由、覆盖组件、回归结果与适用范围。以上是本文建议新增的工程层，不是开源仓库自带的生产发布模块。

费用也要分开算。一次优化包括基础执行、两个候选执行、组合后执行、编辑器调用和经验整理；扩大到 $k>1$ 后还会增加探索运行。回归验证也是成本。真正的经济性取决于后续多少相似任务从更好的组件和经验中获益，以及无效调用、重试和人工返工减少多少。可以用一个简单口径跟踪：

总成本 = 优化与回归费用 + 后续任务执行费用 + 人工返工费用；同时观察单位合格交付成本、关键约束违反率和 P95 延迟。

适合先试点的任务，通常有一定重复性、能够保存执行轨迹、允许重跑，且外部写操作有测试路径。若任务一次性且实验代价很高，或关键副作用无法隔离，优先建立可观测性和执行协议，比立即开大递归预算更有价值。论文的实验显示 Harness 的改进空间真实存在；业务系统要把它变成持续能力，还需证明这种改进能跨任务复用，并在独立回归与总成本约束下成立。

附录：参考资料与校准说明

校准说明

• 文中的实验分数来自论文基准，不用于估算 DeerFlow 的业务收益；JobBench 个案的 43.1→77.8 是事后评测结果，不是在线编辑阶段的正确性反馈。
• 图 1 使用论文 Figure 3 原图。图 2、run manifest、独立服务、Worker 隔离、独立回归和版本发布是本文工程方案，尚未完成业务实测。
• 官方仓库的代码接口会继续演进；在实际接入前，应固定 Harness² 与 DeerFlow 的代码版本并再次核对。

名词与概念

• Execution harness（执行 Harness）：当前任务运行时加载的提示词、Skills、脚本、工具指引等组件。
• Improvement harness（改进 Harness）：引导后续如何修改执行 Harness 的机制及其持久经验库。
• Probe（探测）：让候选配置执行相同任务，观察文件编辑带来的行为差异；它本身不证明交付物正确。
• BenchmarkAdapter（任务适配器）：Harness² 源码中把任务、执行、轨迹和交付物接入方法核心的接口。

参考资料

• Xu, Ruiyao, et al. “Harness²: Recursive Agent Harnessing for an Open World.” arXiv:2610.14224v1, 2026；论文 Figure 3 原图。
• Harness² 项目官网；Google Research 官方仓库与 README；核心适配接口。
• DeerFlow 官方仓库；DeerFlowClient 源码；配置说明。