LLM 能自己改进自己的 Harness 吗？来自 ARC-AGI-3 的对照实验启示

LLM 能自己改进自己的 Harness 吗？来自 ARC-AGI-3 的对照实验启示

一个悬而未决的问题

现代 LLM 并不单独工作。它们运行在一个叫做 Harness（控制框架） 的符号程序里——这个外围软件负责模型调用、提示词管理、记忆保持、错误恢复和工具调用。前沿模型是否有能力自己编写、并根据运行经验自主修改这套 Harness 软件？这个问题此前从未被严格验证过。

在 Agentic AI 系统与工作流自动优化（Meta-Harness、Agentic Harness Engineering）备受追捧的当下，这项研究用受控实验严谨地分析了两个现象之间的鸿沟：模型在开发环境里的性能提升，与在真实未知测试环境里的泛化表现（Adaptation Gap，适应间隙）。

三个核心概念

Harness：控制模型调用、提示词管理、记忆、错误恢复、工具调用的外围脚手架程序。

Harness 适应间隙：开发阶段评估反馈任务上的性能提升幅度，与从未见过的保留测试任务上的提升幅度之差。这代表自主修改未能真正泛化的局限。

固定谱系协议：基于固定的最小仓库（Bootstrap），模型先构建初始 Harness（H₀），用 5 个开发游戏的结果（E_dev）做依据，经过 2 次自主修改（H₁、H₂），最后用 20 个保留游戏评估。

一个贴切的比喻：就像自动驾驶汽车试图修改自己的控制源码来提升性能——在测试跑道（开发游戏）上成绩变好了，可一旦开到真实公路上（保留游戏），反而可能出现稳定性下降或过拟合。

实验设计与结果

实验在 ARC-AGI-3 基准上进行：9 个模型-努力条件、27 条独立 Harness 谱系、81 个冻结快照、总计 2,025 次游戏评估。

研究的量化指标分布与谱系方差经过统计测量。结论可以概括为三点：

1. 泛化不足（对开发任务过拟合）：基于开发游戏反馈修改 Harness 后，这些经验并不能稳定泛化到未见的保留游戏，性能甚至可能停滞或倒退

2. 成本与性能的冲突：在 Harness 修改过程中，优化推理与执行成本的尝试（C_outer、C_run），可能以实际任务完成能力（RHAE）的下降为代价

3. 自主修改的可靠性边界：前沿模型编写和修改代码的能力很强，但保持既有可用行为、避免基于弱证据过度修改的能力仍然薄弱

对企业架构师的启示

成本控制：别让自优化循环烧穿预算

生产环境中让 LLM 驱动的 Agent 或 Harness 自主修改代码、优化工作流时，无节制的循环执行会导致云端推理成本（Token / 计算成本）暴涨。必须在基础设施层面严格控制增量更新次数，并设置验证护栏。

治理与安全：动态代码生成要有闸门

引入「Agentic Harness Engineering」这类架构（LLM 自己生成代码、修改系统 Harness 的工具、记忆、控制循环）时，必须确保未经验证的代码不会直接进入生产运行时：强静态分析、沙箱测试、独立的保留验证管道（LLMOps）缺一不可。

落地检查清单

• [ ] 限制自主修改范围：防止 Agent 直接修改核心控制循环或安全认证模块，仅在允许的工具接口内做优化，沙箱权限分离
• [ ] 验证数据集隔离：优化 Agent 提示词或 Harness 时使用的开发日志（Development Traces），必须与生产运营验证数据集彻底分离，防止过拟合
• [ ] 成本-性能帕累托监控：建立仪表盘，定量跟踪 Harness 变更带来的 Token 消耗增量，对比实际任务成功率的改善效果

与我的实践对照

这套结论和我构建 Agent 平台时的踩坑高度一致。当初给 HarnessAgent 引入 Builder 模式与 Memory 时，我们也在「让 Agent 自己优化自己的执行策略」上做过探索，最后收敛为几条务实规则：

• 开发反馈与线上评估分开：调优用的样本集和验收用的数据集严格隔离，避免把验证集调出幻觉指标
• 修改必须是增量 + 可回滚：任何自主修改都基于快照，出问题一键回退到上一版冻结状态
• 成本护栏前置：把 Token 预算写进运行框架，而不是事后看账单
• 保守优于激进：模型倾向于在弱证据下过度修改，生产环境要主动压制这种冲动

结论

LLM 有能力修改自己的 Harness，但「能改」和「改得好、改得稳」之间隔着一条明显的适应间隙。对工程团队而言，正确的姿态不是追逐「全自动自我优化」的叙事，而是把自主修改放进受限范围、验证隔离、成本监控的三重护栏里。自主优化是手段，稳定的业务交付才是目的。