企业官网建设流程全解析

note

• Harness的8个组件：System Prompt（定义 Agent 总体角色与行为原则）、Guardrails（规定必须遵守的约束与检查规则）、Memory（保存可跨步骤/任务复用的信息）、Skills（提供解决特定任务的 SOP/经验）、Tool Guidance（告诉 Agent 各工具何时以及如何使用）、Scripts（提供可直接执行的确定性程序）、Subagents（通过子 Agent 实现任务分工与上下文隔离）、Plugins（在 Agent/Tool Loop 特定节点自动介入的中间件逻辑）
• HARNESS² 思想：Agent 不应该只生成结果，还应该保留它如何诊断失败、如何修改执行系统、以及哪些修改在什么条件下有效的过程。
• 研究动机： 现有 Agent 自进化方法依赖任务评测与经验反思，但开放式任务往往缺少标准答案（GT），且单任务优化经验难以迁移到新任务。
• 核心方法： 提出双层递归 Harness 优化框架，不更新 LLM 权重：
  • 任务级优化（Propose–Probe–Compose）： 自动提出 Harness 修改方案（Prompt、Tools、Skills、执行策略等），通过实际 Rollout 比较不同方案的执行轨迹与产物，筛选并组合有效改动，迭代优化当前 Harness。
  • 跨任务优化： 对历史优化过程进行归因与经验提炼，沉淀为持久化的 Improvement Harness，指导后续任务的 Harness 修改，实现经验复用。
• 实验结果： 在 WorkBuddy-Bench、JobBench、LAB 等任务上，相较原始 Harness，部分配置最高分别提升 11.5、4.5、11.8 个百分点。
• JobBench揭示了 harness 改进的本质：模型可能已经具备足够的知识，但执行系统没有要求它查找、核对、验证并保存证据。有效改进不是告诉模型“你更聪明一点”，而是改变工作流，让错误更不容易通过。
• 如果这一范式能够继续解决可靠性、成本和安全问题，那么未来 agent 框架的竞争重点可能不只是“谁的模型更强”，还包括：谁的 harness 更容易修改；谁的执行轨迹更可分析；谁的规则更容易验证；谁的改进经验更可迁移；谁能够安全地控制递归边界。
• HARNESS² 的递归对象：
  • 任务级递归优化的是“当前任务怎么执行”；
  • harnessing 级递归优化的是“下一个任务怎么改”。
  • 前者产出更好的 harness，后者把这个过程沉淀成更好的改进策略。两层递归形成闭环：当前任务产生具体 harness 和执行证据 → 经验库保存被验证的模块及适用条件 → 新任务据此提出更合理的候选 → 新候选又产生更多对比证据。

摘要

论文：HARNESS²: Recursive Agent Harnessing for an Open World
作者：Ruiyao Xu、Yanfei Chen、Zhongying CuiZhu 等（Google Cloud AI Research / Northwestern University）
论文编号：arXiv:2610.14224
项目主页：harness2.github.io
链接：https://github.com/google-research/harness2

HARNESS² 的核心命题不是“让模型写一段更好的提示词”，而是把 Agent 的运行时系统拆成两个层次：

• 执行 harness：真正负责完成当前任务的系统提示、规则、记忆、技能、工具、脚本、子智能体和中间件；
• 改进 harness：负责诊断失败、提出 harness 修改、验证效果并保留经验。

前者随每个任务变化，后者跨任务持续积累。

• 任务级递归通过Propose—Probe—Compose（提出—探测—组合）使用候选 harness 之间的“行为对比”指导修改
• harnessing 级递归则把被采纳的 harness 和对应的改进经验写入持续改进库。实验覆盖 WorkBuddy-Bench、JobBench 和 Harvey’s Legal Agent Benchmark，基础模型包含 GLM-5 与 Gemini 3.5 Flash，初始执行环境包括 OpenCode 和 Codex。

结果表明，单次对比改进即可带来提升，更大的并行或串行预算能够继续提高收益，此前积累的经验也能改善后续任务，甚至可以在不同基准之间迁移。

本文的目标不是复述论文摘要，而是回答四个问题：

1. 为什么 agent harness 值得作为独立的递归改进对象？
2. HARNESS² 在“没有标准答案”的开放世界中如何判断一次修改是否有效？
3. 两级递归分别解决什么，为什么它们必须耦合？
4. 实验增益背后有哪些可迁移的工程启示，以及哪些结论尚不能推出？

1. Agent 的瓶颈可能不在模型，而在 harness

1.1 Agent 不是一个裸模型

论文把 Agent 定义成：

Agent = 模型 + harness

模型负责推理、规划和生成；harness 则决定模型“在什么上下文中、能调用什么工具、按什么流程、受到什么约束”来执行任务。

HARNESS² 将 harness 拆成八个可编辑文件：

这种分解比“system prompt”更符合真实 coding agent 的运行方式。OpenCode 中的 harness 由组件树表示，Codex 中则对应AGENTS.md、技能、脚本、子智能体等运行时组件。它们不是提示词中的几个段落，而是真正挂载到运行环境中的文件。

1.2 为什么“换 harness”会比“继续换模型”更有性价比

同一模型在不同 harness 下可能出现明显不同的行为：

• 有没有明确的规划步骤；
• 是否强制交叉验证输出；
• 能否发现并复用既有技能；
• 是否会无限制调用工具；
• 是否允许模型绕过关键校验；
• 是否将重复流程固化为脚本。

论文的基本判断是：在基础模型已经较强的情况下，继续优化提示、记忆、技能和工具控制，可能比重新训练模型更直接。这里的“改进”也不意味着改变模型权重，而是改变模型所处的执行环境。

因此，harness 成为一个具有吸引力的递归对象：它可解释、可文件化、可执行、可回滚，而且修改代价通常低于重新训练。

1.3 现有 harness 优化方法的三个盲点

第一类是离线 harness 搜索。

代表方法先在固定的训练或开发任务上评价候选 harness，再选择一个配置并部署。它假设部署时的任务分布能够被搜索阶段覆盖，但开放世界的任务通常事先未知。静态 harness 可以迁移，却很难覆盖新领域、新工具和新流程。

第二类是单任务在线改进。

系统对当前任务提出若干修改，从中选出表现更好的候选，然后开始执行。问题是：一个在当前任务上有效的配置，可能高度依赖当前任务。直接将整套执行 harness 继承给下一任务，容易产生噪声、过拟合和漂移。

第三类是“改进器本身不学习”。

即使 agent 修改了当前任务的 harness，它下一轮仍然可能重复犯同样的诊断错误。它会遗忘哪些修改曾经有效，也不清楚不同修改分别在什么条件下适用。换言之，过去的研究通常优化“执行产物”，而没有充分优化“产生产物的过程”。

这构成了论文要解决的双重挑战：

① 没有标准答案时，如何可靠地指导在线 harness 修改？
② 如何让“harness 的改进能力”本身随经验而提升？

2. 两级递归：执行 harness 和改进 harness 解耦

HARNESS² 把递归对象拆成两层。

任务级递归回答：“这个任务应该怎样改？”

harnessing 级递归回答：“以后再遇到任务时，应该怎样提出、验证和组合修改？”

2.1 为什么必须分开

如果只更新执行 harness，系统积累的是“已经形成的答案”；如果只更新改进 harness，则当前任务缺少快速适配能力。两者单独存在都不完整：

• 只有执行 harness：每个任务仍从较原始的状态开始，无法复用既有模块和经验；
• 只有改进 harness：无法在当前任务内部快速迭代，且经验缺少真实采用结果作为锚点；
• 两层耦合：当前任务产生具体 harness 和执行证据，跨任务经验反过来改善未来任务的提议与选择。

HARNESS² 让执行 harness 在任务内部变化，让改进 harness 在任务边界之后变化。模型权重、环境接口和改进算法本身仍然固定，递归发生在外层运行系统。

3. 任务级递归：用行为对比代替缺失的标准答案

3.1 为什么不能用“模型自评对不对”

开放世界设置刻意不使用即时 ground truth、正确标签或显式正确性反馈。常见替代信号各有局限：

• 模型直接判断最终答案，容易受语气、格式和模型偏差影响；
• 单元测试只能覆盖可程序化验证的问题；
• 两两比较可能稳定选出风格偏好，但不能证明答案正确；
• 单次执行轨迹包含随机性，一次成功或失败不足以确认修改有效。

HARNESS² 采用的信号是：在相同模型和相近环境下，候选 harness 相对于参考 harness 的行为变化。

参考执行不会直接判定结果是否正确，而是暴露出当前 harness 在规划、工具使用、信息整合、验证和交付过程中的实际表现。随后，系统观察候选修改是否改变了目标行为，以及是否引入副作用。

3.2 Propose：同时提出“通用改进”和“领域改进”

对于任务q t q_tqt​、当前 harnessH \mathcal HH和历史记录E \mathcal EE，改进器会生成两个候选：

1. 不变式候选
   面向跨任务通用的 agentic 缺陷，例如：

   • 先计划后执行；
   • 减少上下文漂移；
   • 合理拆分复杂任务；
   • 控制工具调用次数；
   • 对关键结果执行交叉验证；
   • 明确何时委派给子智能体。

2. 领域式候选
   面向当前任务的专门知识、流程和约束，例如：

   • 电子表格中的时间、金额和预算口径；
   • 网页元素定位与下载流程；
   • 法律文档层级和引用规范；
   • 行业交付模板；
   • 当前工作区的工具与文件结构。

这里的“不变式”并不意味着永远有效，而是指它试图解决的缺陷更可能跨任务重复出现。

一个重要约束是：领域事实必须基于当前任务证据，不能从经验库中原样照搬。

经验库中的技能、脚本或规则可以被复用、改写或适配，但针对当前任务的具体事实必须重新核验。否则，跨任务复用就会从“借鉴经验”退化成“记忆污染”。

3.3 Probe：让候选 harness 在受控条件下执行

每个候选 harness 都会被放回当前任务中运行，并和参考执行进行匹配。需要比较的不仅是最终交付物，还包括：

• 执行轨迹；
• 工具调用序列；
• 错误发生位置；
• 中间推理与检查行为；
• 上下文使用方式；
• 子智能体的委派；
• 输出结构；
• 是否引入新的失败模式。

一条候选修改可能得到三种典型结果：

这种比较不能消除随机性。论文也承认，并行候选可能共享基础模型的相同偏差。因此，“行为对比”是改善修改方向的证据，不是绝对真理。

3.4 Compose：把多个候选的局部收益合并起来

组合器不是简单选择“分数较高”的候选，而是根据行为证据决定：

• 哪些改动获得了明确的行为支持；
• 哪些改动相互冲突；
• 是否应将不同候选中的有效部分合并；
• 是否需要对修改增加条件、参数或限制；
• 是否保留原始 harness 的部分组件；
• 是否直接拒绝全部候选。

这一步使 HARNESS² 区别于 Best-of-k。Best-of-k 只在多个输出之间进行选择；HARNESS² 则会保留候选 harness、探针结果和组合决定，将其用于跨任务学习。

4. 并行、串行与经验库：把任务内的探索转化为跨任务能力

4.1 并行递归：宽度来自多个候选与组合

并行递归同时生成并验证多个候选，再从不同执行证据中组合继任 harness。它适合：

• 快速探索不同故障假设；
• 覆盖“流程问题”“工具问题”“领域知识问题”等多种修改方向；
• 在同一计算预算下获得更多行为对比；
• 组合多个候选的局部收益。

论文中的k不是单纯的“重试次数”。在并行设置中，它代表候选、探针和组合所构成的探索宽度。实验显示，从 (k=1) 增加到 (k=5)，三个基准上的结果仍有上升趋势。

4.2 串行递归：深度来自累积证据

串行递归在完成一轮改进后，将继任 harness 及其执行证据传递给下一轮。它能让改进器看到：

• 第一轮修改解决了什么；
• 哪些行为仍未变化；
• 新的失败模式是什么；
• 后续修改是否与先前修改冲突。

串行递归的优势是聚焦，风险是过拟合当前任务和累计计算开销。HARNESS² 的框架并不要求二选一：实际系统可以混合使用并行候选探索与串行证据积累。

4.3 Harnessing 级递归：经验库保存的不只是旧 prompt

任务完成后，系统不是只保留最终 harness，而是更新一个持续改进 harness。典型库条目包含：

adopted_harness/ ├── systemprompt.md ├── guardrails.md ├── LongTermMEMORY.md ├── tool_guidance.md ├── skills/ ├── scripts/ ├── sub_agents/ ├── plugin/ └── EXPERIENCE.md

EXPERIENCE.md会记录：

• 任务表现出的问题；
• 采用了哪些 harness 修改；
• 这些修改在什么条件下有效；
• 哪些候选没有通过验证；
• 组合阶段发生了什么取舍；
• 哪些经验可跨任务复用，哪些只适用于特定场景。

论文特别强调：可执行组件被原样保留，而不只是压缩成自然语言摘要。原因很直接——脚本和技能一旦被转写成摘要，接口、路径和调用条件等关键信息容易失真。

5. 实验设计：如何公平比较“有经验”和“没经验”

5.1 三个基准的侧重点不同

WorkBuddy-Bench

覆盖代码、网页和办公三类任务，是复合型的工具使用基准。评分器将隐藏测试、文件与结构检查、LLM 或 VLM 判断结合。论文采用各域测试分割，例如代码 40 题、网页 35 题、办公 25 题。

JobBench

包含 65 个职业任务，论文使用冻结后的 34 个测试任务。每个任务包含输入文档和若干交付物，采用基于加权评分表的模型判断。

LAB（Harvey’s Legal Agent Benchmark）

包含 1,251 个法律任务、24 个法律实践领域和四种工作类型：分析、起草、审阅、研究。论文报告的是 100 个冻结测试任务的逐标准通过率，即 Partial pass rate。

5.2 基准评分器不可见

论文刻意避免评分信号泄漏：

• WorkBuddy-Bench 验证器不向任何模型暴露预期答案；
• JobBench 的评分表不向执行器、编辑器和选择器展示；
• LAB 使用模型评分器，但改进过程不使用即时正确性标签。

因此，开放世界任务级改进阶段不能直接查询基准评分器来挑选 harness。

5.3 主要比较对象

论文设置了几类对照：

• Base harness：从初始 harness 开始，不修改；
• Best-of-k：基础 harness 多次执行后选择交付物，但不修改 harness；
• ReasoningBank：不改 harness，只检索并补充历史记忆；
• Harness Scaling：在当前任务内反复修改，但不积累跨任务经验；
• Meta-Harness：离线搜索 harness，再原样部署；
• HARNESS²：任务级递归与 harnessing 级递归结合。

这里存在一个需要仔细理解的公平性条件：Meta-Harness 可以使用对应基准的训练或开发集合，而 HARNESS² 不使用这些集合。HARNESS² 面对测试任务流时从空库开始。如果仅看 Meta-Harness 的离线搜索结果，不能简单得出“它一定弱于 HARNESS²”；但论文关注的是不同更新阶段和反馈条件下的适应方式。

5.4 评测口径

• 每个结果通常是多条独立任务流的平均值；
• 使用相同冻结执行器、初始 harness、任务流和评分器；
• 编辑器与选择器在部分主实验中采用 Claude Opus 4.8；
• 单次执行设置 200 个模型轮次和 3,600 秒上限；
• 实验主要测量最终任务质量，也补充了每任务总计算量。

6. 实验结果：从单步改进到跨任务迁移

6.1 一次对比改进已经能普遍提高结果

在论文报告的四种模型—harness配置中，仅执行一个 Propose—Probe—Compose 步骤，HARNESS² 均优于对应基础 harness。代表性最大提升包括：

• WorkBuddy-Bench：提高11.5 分；
• JobBench：提高4.5 分；
• LAB Partial：提高11.8 个百分点。

这里的分数口径不同，不能横向相加或计算统一平均增益。WorkBuddy-Bench 采用任务内多项检查通过率，JobBench 采用加权评分表得分，LAB 报告的是逐标准 Partial 通过率。比较的重点应是各自相对于基线或对照的提升。

6.2 增加预算通常带来额外收益

在 Gemini 3.5 Flash 与 OpenCode 配置下，并行递归把默认单步改进继续提高：

• WorkBuddy-Bench：2.9～3.9 分；
• JobBench：3.0～4.2 分；
• LAB Partial：2.6～6.7 个百分点。

预算研究还显示，随着 (k) 增加，并行与串行递归总体呈上升趋势。这并不说明计算量越大越好，而是说明在实验预算范围内，扩展探索比简单停止在首轮更有价值。

6.3 并行递归不是重复抽奖

如果并行递归只是重复采样，它不应稳定优于 Best-of-k。实验结果表明 HARNESS² 的优势不仅来自多执行一次，还来自：

1. 显式诊断执行轨迹中的问题；
2. 针对问题生成定向候选修改；
3. 使用行为对比评估候选；
4. 将不同候选中被支持的部分组合起来；
5. 把候选、证据和结果写回经验库。

因此，它更接近“定向搜索与合成”，而不是“重新生成多个答案再投票”。

6.4 经验库可以影响后续 harness 的质量

删除经验库后，WorkBuddy-Bench 平均下降3.1 分，JobBench 下降1.8 分。这说明采用过的 harness 和过程经验并非冗余装饰。

进一步的迁移实验更有代表性：

• 使用更高并行预算生成的经验库，可以改善后续任务，即使不再增加探测；
• 从 JobBench 迁移到 WorkBuddy-Bench 仍有收益；
• 迁移在 WorkBuddy-Bench 的 Code、Web、Office 上分别带来约+0.6、+0.5、+2.9 分。

这些结果意味着，系统积累的不只是“某个任务应该用哪段提示词”，还包括可供新任务复用的模块和适用条件。

6.5 同模型也可以改进同模型

论文还测试了执行器和编辑器使用同一模型的设置，包括 GLM-5、Gemini 与 Claude 系列模型。例如 Claude Opus 5 在三项基准上分别提高3.3、5.5、3.0 分，GLM-5 在 LAB 上提高13.7 分。

这并不意味着模型完全没有依赖外部更强模型的帮助，但它反驳了一个简单假设：“只有上级模型才能改进下级模型。”

7. 一个具体案例：失败原因不是模型不会，而是流程没有验证

论文给出的 JobBench 案例比较典型。

任务需要综合多个输入文件并生成若干交付物。基础 harness 版本得到43.1 分，改进版本得到77.8 分。被加入或加强的模块包括：

1. 强制穷举输入文件
   避免模型在缺少某份文件时凭默认假设作答。

2. 对关键数据强制溯源
   使交付物中的预算、日期、人员、面积等数据能够回溯到输入文件。

3. 用脚本重新打开并检查生成文件
   不仅“声称文件已生成”，还验证格式和内容可解析。

4. 建立多文件对账技能
   对预算、时间表、人员、场地等不同文件进行交叉核对。

5. 把验证步骤放进流程与中间件约束
   降低模型跳过检查的概率。

这个案例揭示了 harness 改进的本质：模型可能已经具备足够的知识，但执行系统没有要求它查找、核对、验证并保存证据。有效改进不是告诉模型“你更聪明一点”，而是改变工作流，让错误更不容易通过。

8. 工程启示：Agent harness 应该怎么设计

8.1 把 harness 当作一个可版本化的运行时项目

HARNESS² 最有迁移价值的想法，是把提示词、技能、脚本、规则和插件组织成文件树，而不是把全部逻辑塞进一个长 system prompt。

推荐的工程结构可以是：

harness/ ├── systemprompt.md ├── guardrails.md ├── memory/ │ └── long_term.md ├── tools/ │ ├── descriptions.md │ └── guidance.md ├── skills/ │ └── spreadsheet_reconciliation/ │ ├── SKILL.md │ └── scripts/ ├── scripts/ │ └── validate_outputs.py ├── subagents/ │ └── document_reviewer/ ├── plugins/ │ └── require_verification.ts └── changelog/ └── change_2026_10_24.md

每个变更最好附带：

• 触发的问题；
• 修改的组件；
• 运行证据；
• 已知副作用；
• 适用条件和不适用条件。

8.2 尽量把确定性问题交给代码

论文组件消融显示，技能与脚本往往比单纯修改提示更有效：

• 移除技能，Code 与 Web 分别下降3.6 和 6.9 分；
• 移除脚本，Office 下降7.4 分；
• 三类平均下，技能、脚本和提示组分别下降5.3、3.7、1.5 分。

这并不是说提示没有价值，而是说明：如果任务可以被程序化检查，就不应反复要求模型靠注意力记住规则。

可固化的能力包括：

• 文件格式校验；
• 表格字段与单位核对；
• 数据溯源；
• 重复流程执行；
• 输出 schema 验证；
• 工具调用次数与超时控制；
• 中间产物保存；
• 失败重试策略。

8.3 自检机制应该成为 harness 的一等组件

可以设置不同层次的验证：

验证机制既可以写成技能，也可以由中间件在工具环中强制触发。

8.4 经验库应保存“可复用模块 + 适用条件”

只保存“某个任务成功使用了某段提示”价值有限。更有价值的经验至少应包括：

• 失败症状；
• 诊断依据；
• 修改方案；
• 行为前后对比；
• 有效场景；
• 已知失效场景；
• 可执行组件；
• 使用次数与结果。

经验库既要防止重复劳动，也要避免无差别照搬。一个任务中的预算核对技能可以迁移，但其具体金额、时间、公司名称不应该被当成跨任务事实。

9. 局限性与风险：这篇论文证明了什么，没有证明什么

9.1 行为改进不等于客观正确

行为对比能减少随机猜测，却无法保证最终答案绝对正确。候选可能共同受到基础模型偏差影响；执行轨迹中的行为变化，也可能与最终交付质量只存在相关性。论文没有证明对比组合能够在所有任务上发现真值。

9.2 开放世界标签缺失不等于实验环境完全无监督

基准评分器仍然提供了最终评测结果，只是它们没有进入任务级在线修改过程。这里证明的是“在线阶段不需要即时正确标签”，而不是“整个研究过程完全不需要任何评价”。

9.3 评测与生成可能存在模型同源性

部分配置下，执行器、编辑器、选择器或评分器可能来自相近模型家族。模型偏好、语言风格和评价偏差可能相互放大。因此，性能提高是否完全来自通用推理能力，仍需要更多异源模型评测。

9.4 递归不等于无限安全扩张

论文中的模型权重、环境接口和改进算法没有持续通过梯度更新。所谓“递归”主要体现在 harness、改进库和改进策略的积累。它不会自动解决：

• 权限越权；
• 不可逆操作；
• 有害内容生成；
• 隐私泄漏；
• 错误规则被不断放大；
• 自我修改失控；
• 跨任务错误记忆；
• 对基准或评分器的隐式过拟合。

任何真实部署都需要增加权限边界、沙箱、审计、人工批准和回滚机制。

9.5 成本和延迟无法忽略

HARNESS² 需要：

• 执行参考 harness；
• 运行多个候选；
• 编辑和组合 harness；
• 执行最终任务；
• 维护经验库；
• 在复杂任务上保留多条执行轨迹。

因此它不适合所有低延迟、低成本场景。更合理的定位是高价值、容错探索、可重复执行的任务，例如专业文档生成、代码工程、数据分析、研究和办公自动化。

10. 递归的终点：Agent 开始积累“如何改进自己”的经验

10.1 传统 RSI 在优化什么

递归自我改进可以作用于不同对象：

• 模型权重；
• 改进程序；
• Agent 代码；
• 提示词；
• Agent 的运行时系统。

HARNESS² 选择的是最后一类。它不训练模型，而是通过模型持续修改模型所依赖的执行系统。

10.2 HARNESS² 的递归对象是什么

任务级递归优化的是“当前任务怎么执行”；harnessing 级递归优化的是“下一个任务怎么改”。前者产出更好的 harness，后者把这个过程沉淀成更好的改进策略。

两层递归形成闭环：

当前任务产生具体 harness 和执行证据 → 经验库保存被验证的模块及适用条件 → 新任务据此提出更合理的候选 → 新候选又产生更多对比证据。

10.3 为什么这个方向值得关注

它把 agent 工程从“一次性设计提示词”推进到“持续改进执行系统”。真正的价值不只是单次提高几分，而是证明以下能力具有可行性：

• harness 可以像代码一样被版本化；
• 失败轨迹可以被转化为修改证据；
• 有效模块可以被复用和改写；
• 改进经验可以跨任务积累；
• 不同基准之间可能存在可迁移的改进能力。

HARNESS² 目前仍是一个有边界的框架：模型判断可能出错，行为对比可能失真，递归成本仍然较高，权限和安全控制也必须由外部机制补充。但它在“不改变模型权重”的前提下证明了一件事：Agent 的运行时系统能够被持续修改、验证、版本化和复用。相比一次性设计一套固定提示词，这更接近一个可以长期演化的工程对象。

11. 源码分析

代码仓库中中prompt.py中的propose函数：LLM 根据什么轨迹证据提出 Harness 修改，具体怎么思考反思轨迹可以参考下面代码的how字符串列表。

关键设计：
INV（Invariant）： 优化通用执行能力，例如工具使用、错误恢复、结果验证。
DOM（Domain-specific）： 优化领域知识与专业流程，例如财务对账、法律文档检查。
Evidence-grounded Attribution： 要求修改依据来自轨迹中的行为差异、重复错误或可观察风险，避免无依据地修改 Harness。

defpropose(bp:BenchPrompts,dim:str,surface:SurfaceSpec|str,*,k:int=1,index:int=1,round_t:int|None=None,)->str:"""The job for one INV or DOM candidate. `round_t` set => sequential mode, pass t."""ifdimnotin("INV","DOM"):raiseValueError(f"unknown proposal dimension{dim!r}; expected 'INV' or 'DOM'")st=_st(surface)ifbp.prompt_pack=="tts"andround_tisNone:return_tts_propose(bp,dim,st,k=k,index=index)block=(st.invifdim=="INV"elsest.dom).format(deliverable=bp.deliverable_word,domain=bp.domain_word,levers=(bp.inv_leversifdim=="INV"elsebp.dom_levers).strip(),)where=(f"You are candidate{index}of{k}on this dimension, drawn independently from the "f"same evidence."ifk>1else"")ifround_t:where+=(f"\n\nThis is round{round_t}. You are editing the checkpoint the previous "f"round produced, not the original harness, and the evidence includes every "f"earlier round. In this stage `KEEP_BASE` means leave that CURRENT checkpoint "f"unchanged; it never resets to the original harness.")how=["# HOW TO DECIDE WHAT TO CHANGE\n","Every edit must trace to a moment in a trajectory. For each one ask: which run did ""what, and would this text have changed it? If you cannot name the moment, the edit ""is speculation and costs context for nothing. Prefer, in order:"," 1. a DIVERGENCE -- the runs disagreed, so the agent can already do it and just ""needs telling. This is the cheapest win."," 2. a repeated concrete failure -- the same error or omission in every run."," 3. a risk visible in a trajectory but not yet realised.","Do not fix what the runs already got right, and do not restate what the harness ""already says clearly; duplicated instruction dilutes the rest.",]ifwhere.strip():how+=["",where.strip()]how+=["","Do not hedge toward an average or try to cover every base -- commit to the ""single most defensible version of your dimension. A later stage compares and ""merges.",]parts=["You are adapting an autonomous agent's harness.",_work(bp),_lens(bp),block,GENERALIZE.format(domain_word=bp.domain_word,DOMAIN_WORD_UPPER=bp.domain_word.upper()),"\n".join(how),]ifbp.yardstick.strip():parts.append(f"# WHAT GOOD PROCESS LOOKS LIKE HERE\n\n{bp.yardstick.strip()}")parts+=[ANSWER_FREE,EVIDENCE_BOUNDARY,st.surface_md]return_tidy("\n\n".join(parts))