跳转至

运行框架优化

概述

运行框架优化（Harness optimization）是指通过自动化方式搜索 LLM 智能体运行框架（harness）的代码，在无需人工设计的情况下发现高性能配置。智能体运行框架通常由人工手动设计，但经验证据表明：框架的选择对任务性能的影响，与模型选型相比不相上下，甚至更为显著。自动化框架搜索将运行框架视为可学习的制品，通过迭代优化持续改进。

Meta-Harness 论文（Lee et al., arXiv:2603.28052, March 2026）对此给出了具体验证：一个智能体外层循环系统对运行框架代码展开搜索——这些代码决定了向模型存储、检索和呈现哪些信息——并持续发现优于人工设计基线的框架。

运行框架优化问题

运行框架不只是一个系统提示词，而是围绕模型的完整程序化封装：检索逻辑、上下文构建、记忆管理、工具定义、完成条件检测以及状态追踪。这段代码中的每一个设计决策——抓取哪些文本块、如何排序和去重、何时丢弃或压缩上下文、如何格式化示例——都会影响任务性能。

现有优化方法（DSPy、TextGrad、OPRO、ProTeGi）在运行框架优化中适配性较差，原因有两点：

  1. 文本 vs. 代码：它们优化的是文本指令（提示词、少样本示例），而非实现检索、分支和状态管理的任意代码。
  2. 反馈压缩：它们将评测反馈压缩为简短摘要或标量分数，丢失了执行链路中的详细信息（工具调用、模型输出、中间状态），而这些信息恰恰是诊断候选方案为何失败的关键依据。

运行框架优化需要一个能够基于原始执行链路进行推理的代码编辑智能体，而不是依赖压缩摘要的文本改写器。

Meta-Harness 系统架构

Meta-Harness 是一个外层循环系统，由三个组件构成：

智能体提议器

提议器是一个代码编辑智能体（论文中使用 Claude Code with Opus 4.6），负责读取文件系统中已有的框架候选方案，并提出改进后的运行框架实现。与此前接收压缩梯度或摘要的优化方法不同，提议器可访问：

  • 所有历史候选框架的源代码
  • 各候选方案的评测分数
  • 原始执行链路：发送的提示词、执行的工具调用、模型输出及状态更新

提议器每次搜索迭代的中位读取文件数为 82 个，每轮迭代引用超过 20 个历史候选方案——这种非马尔可夫访问模式充分利用了完整的搜索历史，而非仅依赖上一个候选方案。

基于文件系统的搜索历史

每个经过评测的框架都在文件系统中对应一个目录，结构如下：

candidates/
  run_001/
    harness.py        # source code
    score.json        # evaluation metrics
    traces/           # per-task execution logs
      task_001.json
      task_002.json
      ...

这种结构每轮迭代最多可为提议器提供 1000 万 Token 的诊断上下文，远超任何文本优化器摘要所能承载的信息量。提议器可跨历史候选方案执行 grep 搜索、并排比较实现，并从原始链路中精准定位具体的失败模式。

搜索循环

外层循环的执行流程如下：

  1. 初始化：以基线框架（人工设计或空脚手架）为起点
  2. 评测：在训练任务集上评测当前框架，将源码、分数和执行链路记录到文件系统
  3. 提议：生成新框架——代码编辑智能体读取文件系统、诊断问题并修改代码
  4. 迭代：典型运行在 20 轮迭代中共评测约 60 个框架

提议器可引入全新逻辑——自定义路由谓词、新颖的重排序启发式方法、自适应上下文预算——而不仅仅是调整现有参数。

实验结果

Meta-Harness 在三个领域进行了评测：

在线文本分类

与最先进的上下文管理系统对比： - 分类任务准确率提升 7.7 个百分点 - 上下文 Token 消耗减少 4 倍 - 结果：发现的框架在性能和效率上均优于人工设计的基线

检索增强数学推理（200 道 IMO 级别题目）

与无检索、BM25 及密集检索对比： - 在五个搜索过程中未见过的模型上，平均准确率提升 4.7 个百分点 - 发现的框架：一个紧凑的 4 路由 BM25 程序，自动识别出组合数学、几何、数论的路由谓词及默认路由——这种策略结构是通过搜索涌现出来的，而非人工预先指定 - 所有设计决策（路由谓词、重排序词项、去重阈值、各路由示例数量）均由外层循环在 40 轮迭代中自动确定 - 对未见任务和模型变体具有良好的泛化能力

智能体编程（TerminalBench-2）

与人工设计基线（Terminus 2、Terminus-KIRA）对比： - 发现的框架超越所有人工设计基线的任务通过率 - TerminalBench-2 涵盖 89 个 Dockerized 任务：代码翻译、分布式机器学习配置、系统编程、生物信息学、密码分析 - Meta-Harness 对完整编程框架进行演化：系统提示词、工具定义、完成条件检测逻辑及上下文管理协同优化

启示

框架选择是独立于模型的性能调节手段

在某一模型上通过搜索发现的框架，可迁移至未见过的其他模型。这意味着运行框架优化能够产生可移植的性能提升，不依赖于搜索时所用的特定模型——对于频繁升级模型的团队而言，这是一大实际优势。

执行链路是核心要素

Meta-Harness 的关键架构决策在于：给予提议器原始执行链路的访问权，而非仅提供分数。压缩后的每候选方案摘要会丢失诊断细微框架失效所需的细节（错误的检索路由、上下文在错误位置被截断、去重阈值过于激进）。原始链路才能支持精准定向的代码修改。

自动化框架优化与人工框架工程相辅相成

Meta-Harness 并不取代人工框架工程——仍然需要初始脚手架，且提议器能从基线框架中编码的领域知识中获益。但它解决了探索问题：可能的框架实现空间过于庞大，无法通过人工穷举，而对工作机制的直觉往往在特定领域（如 IMO 级别数学路由）中失效。

与已有优化工作的对比

系统 优化对象 反馈信号 提议器类型
OPRO 提示词（文本） 标量分数 LLM（文本编辑）
ProTeGi 提示词（文本） 文本梯度 LLM（文本编辑）
TextGrad 提示词 + 参数 文本梯度 LLM（文本编辑）
DSPy 提示词 + 少样本示例 模块分数 LLM（文本编辑）
GEPA 提示词（文本） 完整执行链路（反思式，Pareto 前沿候选筛选） LLM（文本编辑）
Meta-Harness 运行框架代码 通过文件系统获取的原始执行链路 代码编辑智能体

Meta-Harness 的核心差异化在于：优化代码（而非文本），并通过结构化文件系统为提议器提供未经压缩的诊断访问权，而非将反馈压缩为梯度或摘要。GEPA 是精神上最接近的前驱工作——它同样拒绝标量奖励压缩、转而采用完整执行链路——但 GEPA 停留在文本空间（通过反思式变异和 Pareto 前沿候选筛选来演化提示词），而非编辑任意运行框架代码。详见 GEPA。

产品化：Databricks Omnigent

Databricks Omnigent（2026 年发布，基于 Apache 2.0 开源）是一款商业元运行框架产品，定位于现有智能体运行框架之上——包括 Claude Code、Codex、Pi 及各类自研内部智能体——而非取代它们。其能力组织为三大方向：Composition（将多个底层智能体/运行框架组合为统一工作流）、Control（跨运行框架的治理、路由与策略执行）和 Collaboration（在不同底层运行框架下运行的智能体之间实现共享状态与任务交接）。

命名说明：尽管都使用"元运行框架"这一术语，Databricks Omnigent 与上文介绍的学术论文 Meta-Harness（Lee et al., arXiv:2603.28052）是两个独立项目。学术论文关注的是对运行框架代码进行自动搜索以发现更高性能的框架配置；Omnigent 是一款产品，用于并排组合和治理多个已构建好的运行框架。团队理论上可以用 Omnigent 来编排多个运行框架，其中某个运行框架本身正是通过 Meta-Harness 搜索产生的——两者互为补充，并非竞争关系，尽管名称上存在重叠。

最佳实践

挑战 / 领域 描述 解决方案 / 建议
链路数据冗长 原始执行链路数据量大 将链路按任务结构化为独立文件；让提议器通过 grep/cat 选择性读取，而非将所有链路注入每个对话轮次
提议器上下文预算 1000 万 Token 的历史数据超出单个上下文窗口 使用具备文件系统工具的代码编辑智能体；智能体选择性读取相关历史候选方案，而非一次性消耗全部上下文
泛化风险 框架对训练任务分布过拟合 搜索过程中在保留任务子集和保留模型上进行评测；验证集差距扩大时提前停止
初始化质量 基线框架较差会导致收敛缓慢 以可用的人工设计基线作为起点；在框架目录中附上简短说明文档，解释任务领域背景
日志质量 链路数据噪声大或不完整会妨碍诊断 确保所有工具调用、模型输出和状态转换均被记录；对提议器交互的清晰日志记录是硬性要求
搜索预算 20 轮迭代中评测 60 个框架成本较高 前 10 轮迭代使用更轻量的评测（更少任务、更小模型）；对排名靠前的候选方案再切换到完整评测

参见

参考资料