让 Builder 学会设计执行环境：元技能让固定权重智能体宏平均分提升 8.95 个百分点

论文把“支持设计”本身变成学习对象：Builder 从自己构建的 harness 在开发任务上的执行记录与分数中提炼可复用的元技能，每条元技能包含 when（何时需要支持）、provide（提供什么能力或资源）、use（Target 如何使用并保留哪些判断责任）三个字段。 此前相关工作或学习求解者自身的任务技能（如 Evo-Harness 把执行经验编译为求解者技能），或搜索 harness 实现（如 Meta-Harness），或演化上下文与代码的工程策略（如 Meta Context Engineering）；本文聚焦于 Builder 层面的可复用支持原则，并把它与冻结技能库后在留出任务上重新构建 harness 的部署协议结合起来。 技能学习从空技能库开始，经过两轮开发集遍历，每个开发任务最多产生一次有证据支撑的 keep/revise/add 更新，每条技能限 192 token；开发集约占各基准 10%（Harness-Bench 11 个开发任务、95 个测试任务；NewtonBench 32 个开发任务、292 个测试任务），技能库在测试前冻结。

把同一份完整元技能库交给 Builder 去实现，比直接交给 Target 更有效：在全部六个模型–基准组合上均优于直接交付，平均提升 12.02 个百分点，最大单点差距达 25.43 个百分点。 这一对比在保持语义知识内容不变的前提下，只改变“是否由 Builder 先把知识转化为可执行支持”，从而把收益归因于把声明式原则落地为持久状态、可执行工具、验证逻辑或控制决策，而非仅仅让 Target 看到更好的建议。 六个原始设置全部胜出，例如 Harness-Bench 上 Gemini 为 67.81 对 42.38；对照条件共享组件接口、设计指引、构建权限与最多两次接口修复机会，Target 执行预算固定。

在构建能力固定的条件下，经验本身带来增益：全库 Builder 在全部六个设置上优于空技能库 Builder，平均提升 8.95 个百分点，全库宏平均分为 65.31%。 空技能 Builder 保留了同样的七类组件族、构建指令与 16K 输出 token 预算，因此差距反映的是“该建什么支持、如何与 Target 行为整合”的经验，而非单纯的脚手架构建能力。 增益随 Target 与基准变化：NewtonBench 上三个 Target 均为正、平均 10.96 个百分点，Harness-Bench 平均 6.95 个百分点；作者据此提出经验在失败模式跨任务稳定复现时最有用。

同一模型同时充当 Builder 与 Target 时，元技能仍带来提升：三个同模型设置中平均比无技能构建高 18.71 个百分点，比直接交付给 Target 高 14.14 个百分点，且权重不变。 这提示了一条不依赖更强外部教师、也不更新权重的系统级自我改进路径：模型通过学会为自己构建更好的支持来改善自身执行。 使用 Gemini-3.6-Flash 与 Gemini-3.1-Pro 的三个设置，构建、反思与执行由同一模型完成；作者同时说明证据覆盖一个主 Builder、两个基准、每个任务与条件一次采纳执行。

该结果面向测试时 AI4AI 场景：Builder 与 Target 权重固定，学习与构建发生在 Target 执行预算之外，Target 执行预算固定（Harness-Bench 30 轮、30 次工具调用、96K token；NewtonBench 12 轮、10 次工具调用、192K token）。适用对象是需要在已知工作流类别与物理机制内完成新实例的智能体系统，收益以宏平均分衡量。对实践者而言，这提示可以把经验沉淀为可复用的支持原则库，再由 Builder 逐任务编译为指令、记忆、上下文、工具、执行控制、验证与恢复、工作区准备等七类组件；对研究者而言，它给出了一个可继续扩展的参考点，用于比较不同的支持表示与构建策略。

跨 Builder 转移的效果方向不一致：NewtonBench 上 Sol-to-Qwen 技能库由 Sol 使用得 +13.36 分，转移到 Gemini-Pro 则为 −4.45 分，而 Harness-Bench 上同一转移为 +2.72 分，且所有置信区间均包含零。技能精炼并非单调：Harness-Bench 上 Gemini 逐轮提升，Qwen 却从第一轮峰值下降 4.06 分。组件消融中只有 Gemini 去掉控制器的置信区间排除零，记忆加上下文的三个置信区间均含零。作者也指出证据覆盖一个主 Builder、两个基准、每个任务与条件一次采纳执行，跨数据集复用、更长学习历史、以及相对构建成本的表现评估留待后续工作。