KAPSO：基于知识引导的自主程序合成与优化框架 KAPSO: A Knowledge-grounded framework for Autonomous Program Synthesis and Optimization
基于知识和经验记忆的迭代程序优化框架，在MLE/ALE基准上取得SOTA
前置知识
编码智能体（Coding Agent）
基于大语言模型（LLM）的自动化代码生成系统，能够根据自然语言描述或任务规范生成、修改和调试代码。当前主流编码智能体（如AIDE、R&D-Agent）在短任务上表现尚可，但在需要多轮迭代、长时间运行的复杂工程任务中，容易出现状态丢失、重复犯同样错误、无法复用已有工程知识等典型失败模式。KAPSO正是针对这些长时程失败场景设计的改进框架。
理解编码智能体的现有局限性是理解本文动机的基础，KAPSO的核心贡献就是解决这些系统性失败模式
评估器边界（Evaluator Boundary）
KAPSO框架的核心设计概念，指的是将程序的执行、测量和比较逻辑封装为一个显式的评估器契约。评估器定义了代码制品 $c$ 如何被执行、输出如何被度量、以及何时停止优化循环。评估器可以是全自动的（基于指标、测试套件），也可以是随机的（多次rollout取均值），还可以集成LLM作为评判者或人类反馈。形式化地，一次评估执行返回测量记录 $R(c) = (\text{status}, M(c), F(c), A(c))$，其中 $M(c)$ 为定量测量，$F(c)$ 为定性反馈，$A(c)$ 为辅助制品。
这是KAPSO区别于其他框架的关键抽象，通过统一评估器接口实现跨领域泛化
情景记忆（Episodic Memory）
受认知科学启发的记忆机制，用于存储从实验轨迹中提取的可复用经验教训。每条记忆条目包含触发条件的紧凑描述、泛化的经验教训、推荐的操作，以及指向原始实验分支及其制品（如日志、diff、评估反馈）的溯源信息。情景记忆的核心价值在于：当系统遇到类似的失败模式时，可以直接调用历史经验来避免重复犯错，从而加速优化收敛过程。
情景记忆是KAPSO减少重复错误、加速收敛的核心机制，理解它才能理解框架的认知能力
知识图谱与检索（Knowledge Graph & Retrieval）
KAPSO的知识系统将异构来源（代码仓库、文档、论文、内部手册）转化为结构化的知识表示。知识以四类页面类型组织：Principle（原则）、Implementation（实现）、Environment（环境）、Heuristic（启发式），页面之间通过类型化边连接（如IMPLEMENTED_BY、USES_HEURISTIC、REQUIRES_ENV）。机器检索层面使用Neo4j图索引和Weaviate向量索引的混合检索方案，支持基于种子仓库的条件检索和失败条件增强检索（ERA）。
知识检索系统是KAPSO获取领域专业知识的关键基础设施，直接影响优化质量
Git原生实验引擎（Git-native Experimentation Engine）
KAPSO将每次实验尝试表示为一个独立的git分支，通过ExperimentSession管理实验的完整生命周期。每个分支记录相对于父分支的代码变更、评估器配置、运行日志和评估输出制品。这种设计保证了每次实验的可重现性和可审计性，同时支持树状搜索策略中将成功的实验作为后续实验的父节点进行复用。实验完成后通过git push将分支发布回本地工作区仓库。
实验引擎提供了可靠的实验管理和溯源能力，是框架可重现性和可调试性的基础
研究动机
基于LLM的编码智能体虽然降低了代码编写的成本，但在长时程执行循环中仍然不可靠。论文系统地总结了三类核心失败模式：第一，跨迭代状态丢失——系统无法记住之前的实验结果、已尝试的方案和失败原因，导致重复探索已经走过的死路；第二，脆弱的调试能力——面对集成错误、环境配置问题或格式违规时，智能体往往无法有效地诊断和修复问题，反复触发相同的错误；第三，领域知识复用失败——即使相关知识存在于代码仓库、文档、内部手册或之前的尝试中，智能体也难以有效检索和应用这些专业知识。在MLE-Bench等真实ML竞赛场景中，这些问题尤为突出，因为成功往往依赖于环境设置、数据契约、评估工具链、调试流程和性能调优等专家级工程知识的持续应用。
本文的目标是本文旨在构建一个端到端的评估器驱动程序优化框架KAPSO，给定自然语言目标和评估方法，系统能够通过迭代的构思、代码合成/编辑、执行、评估和学习过程，持续改进可运行的程序制品。核心目标不是简单的代码生成，而是将程序合成为一个长时程优化过程中的算子，通过评估器的反馈驱动进步。框架需要支持可插拔的评估器和知识后端，使同一优化循环能够应用于代码准确性、鲁棒性、效率或偏好质量等不同目标的场景。
与已有工作不同的是，KAPSO的独特切入角度在于三个紧密耦合的设计创新。首先，它将知识平面与执行平面显式分离——知识平面负责聚合和索引异构知识来源，执行平面以评估器边界为锚点进行实验驱动的优化，两者通过检索API连接。其次，它引入了认知记忆层，不仅从外部知识库检索信息，还从自身实验轨迹中提取可复用的经验教训，形成级联检索机制（WSR加PFR回退，加上ERA失败增强）。第三，它采用git原生的实验管理方式，将每次尝试编码为可重现、可审计的分支制品，这在现有编码智能体框架中是独一无二的。与R&D-Agent、AIDE等开源框架相比，KAPSO在复杂任务上的优势尤为显著，Medium难度任务上领先23.69个百分点，Hard难度任务上领先17.78个百分点。
核心方法
KAPSO的整体设计思路可以概括为「评估器驱动的迭代优化闭环」。直觉上，这就像一个高级工程师的工作方式：面对一个编程任务，不是一次性写出完美代码，而是先构思方案、实现代码、运行测试、观察结果、总结经验教训，然后基于反馈改进代码。KAPSO将这个流程形式化和自动化了。技术路线上，框架通过Kapso API暴露四个核心操作：evolve（评估器驱动的优化循环）、deploy（将选定方案部署为统一运行时接口）、learn（从异构来源摄取知识）和research（发现领域相关的外部材料）。evolve操作由OrchestratorAgent实现，它组合四个可插拔子系统——SearchStrategy（搜索策略）、ContextManager（上下文管理器）、KnowledgeSearch（知识检索）和CodingAgent（编码智能体）——驱动一个交替构建上下文和执行实验的迭代循环。
KAPSO与已有方法的本质区别在于三个核心创新。第一，评估器边界的概念：程序合成不是终点，而是长时程优化过程中的一个算子。给定代码制品 $c$，评估器返回测量记录 $R(c) = (\text{status}, M(c), F(c), A(c))$，优化目标是期望效用 $J^{\star}(c) := \mathbb{E}[U(R(c))]$。当执行具有随机性时，系统通过 $K$ 次rollout的聚合估计器来近似真实效用。第二，知识平面与执行平面的分离：知识系统在MediaWiki中托管供人类审查和策展，同时通过图索引和向量索引支持机器检索；执行平面围绕评估器边界进行实验。第三，认知记忆的级联检索机制：基础检索获取领域知识，失败后通过ERA增强附加故障条件启发式和替代实现。
方法步骤详情
KAPSO的优化流程可以分解为以下步骤。步骤1：种子仓库检索——给定目标 $g$，通过RepoRetrieve函数在仓库语料库中搜索候选种子仓库 $\hat{r}$，返回置信度 $\rho \in [0,1]$，若 $\rho \geq \tau$ 则从 $\hat{r}$ 初始化，否则从空脚手架初始化。步骤2：知识检索——通过RetrieveKnowledge获取相关的原则、实现、启发式和环境约束，组装为知识包。步骤3：上下文构建——ContextManager渲染任务描述、约束、检索到的知识、情景洞察和先前实验摘要的统一上下文 $x_i$。步骤4：搜索策略执行——SearchStrategy根据上下文提出候选方案规格 $u_i$ 并选择要评估的候选项，支持线性搜索和LLM引导的树搜索。步骤5：实现与调试——在隔离的git分支上执行implement-and-debug循环，CodingAgent应用代码变更，调试预算 $D$ 限制修复尝试次数。步骤6：评估——通过评估器执行代码制品，返回测量记录，支持标量效用映射 $U$ 或偏好关系 $\succ$。步骤7：情景记忆更新——从实验轨迹中提取可复用教训，存入向量数据库。步骤8：控制器决策——根据当前状态决定Retry（重试当前工作流）、Pivot（切换到替代知识/仓库）或Complete（完成优化）。
技术新颖性
KAPSO的技术新颖性体现在多个层面。首先是形式化贡献：论文提供了严格的数学记法，将编码智能体的迭代优化过程与黑箱优化和程序综合文献对齐。实验历史被明确定义为 $H_i = \{e_1, \ldots, e_{i-1}\}$，每个实验记录了分支标识、方案规格、预算进度、代码制品、rollout数和聚合结果。其次是架构创新：Git原生实验引擎将每次尝试编码为可重现的分支制品，这在现有框架中是首创，解决了跨迭代状态丢失和实验不可审计的问题。第三是知识获取管道：从2000多个广泛使用的数据和ML仓库中提取结构化知识，通过确定性文件挖掘发现README中未强调的有用文件（如脚本、配置、评估工具、部署清单），并将它们转化为类型化的知识页面。第四是认知记忆的级联检索设计，结合了WSR（带源检索）、PFR（带先前反馈的检索）回退和ERA（错误恢复增强）三种机制，形成了一个完整的知识检索-失败学习-方案改进闭环。
实验结果
KAPSO在两个互补基准上展示了端到端性能。在MLE-Bench（Kaggle风格的ML竞赛）上，Leeroo（KAPSO的实例化系统）在所有难度级别上均优于顶级开源智能体框架，总体奖牌率达到50.67%±1.33%，比最强开源基线R&D-Agent的35.11%±0.44%高出15.56个百分点。尤其值得注意的是，随着任务难度增加，优势更加明显：Low难度两者持平（均为68.18%），Medium难度Leeroo达到44.74%±1.52%而R&D-Agent仅为21.05%±1.52%（领先23.69个百分点），Hard难度Leeroo达到40.00%±0.00%而R&D-Agent为22.22%±2.22%（领先17.78个百分点）。在ALE-Bench（AtCoder启发式竞赛）上，Leeroo取得了最高的最终性能1909.4，排名百分位6.1%，超越原始ALE-Agent的1879.3（6.8%），同时将总成本控制在914.8美元，低于ALE-Agent的1003.3美元，显示出更高的成本效率。在竞赛级别对比中，Leeroo在大多数AHC竞赛中超越ALE，部分竞赛差距巨大，如ahc016（2022 vs 1457）和ahc026（2040 vs 1965）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| MLE-Bench Low难度 | 奖牌率 (%) | 68.18 ± 2.62 | R&D-Agent: 68.18 ± 2.62 | 持平（+0.00） |
| MLE-Bench Medium难度 | 奖牌率 (%) | 44.74 ± 1.52 | R&D-Agent: 21.05 ± 1.52 | +23.69 |
| MLE-Bench Hard难度 | 奖牌率 (%) | 40.00 ± 0.00 | R&D-Agent: 22.22 ± 2.22 | +17.78 |
| MLE-Bench All难度 | 奖牌率 (%) | 50.67 ± 1.33 | R&D-Agent: 35.11 ± 0.44 | +15.56 |
| ALE-Bench 聚合 | 最终性能/排名百分位 | 1909.4 / 6.1% | ALE-Agent: 1879.3 / 6.8% | +30.1 / -0.7% |
| ALE-Bench 总成本 | 累计LLM成本 ($) | 914.8 | ALE-Agent: 1003.3 | -88.5 (节省8.8%) |
局限与改进
论文明确指出了ALE-Bench结果的一个重要局限：ALE-Bench中竞赛数量相对较少，这可能引入噪声，因为LLM和智能体的性能在不同任务间可能存在较大变化。例如在ahc039竞赛中，ALE-Agent取得了异常高的2880分，但这种表现在其他类似短竞赛中并不一致，而Leeroo在同一竞赛中仅得2310分。此外，从更广泛的视角分析，论文未充分探讨以下问题：第一，知识系统的冷启动问题——当面对全新领域（不在已索引的2000个仓库中）时，框架的性能退化程度未被量化；第二，评估器设计的敏感性——不同评估器配置（如rollout数、LLM评判者的提示设计）对最终结果的影响未被系统研究；第三，计算成本分析不够细致——虽然报告了LLM成本，但未详细分解知识索引构建、情景记忆维护、git分支管理等基础设施的计算开销；第四，框架的模块化设计虽然允许替换子系统，但各子系统之间的交互效应和最优配置组合未被深入探索。
独立分析的弱点
尽管KAPSO在基准测试上表现优异，但仍存在几个值得改进的弱点。第一，知识系统的静态性：当前知识库是一次性从2000个仓库中构建的，缺乏在线更新机制。当遇到新的技术栈或快速演进的领域时，过时的知识可能误导优化过程，建议引入增量知识更新和时效性权重机制。第二，情景记忆的泛化能力有限：当前的经验教训提取依赖于LLM对实验轨迹的理解，可能存在过度泛化（将特定场景的教训错误地推广）或泛化不足（未能提取有价值的经验）的问题，可以考虑引入结构化的因果推理来提高提取质量。第三，搜索策略的探索效率：虽然支持线性搜索和树搜索，但缺乏自适应的探索-利用平衡机制，建议引入基于贝叶斯优化的采集函数或蒙特卡洛树搜索（MCTS）的UCB策略来更高效地分配计算预算。第四，部署接口的局限：当前deploy操作返回Python Software对象，对于需要GPU训练或大规模分布式执行的场景，远程执行后端的实际性能和可靠性需要更多验证。
未来方向
论文和其成果指向多个有前景的研究方向。首先，扩展评估器的多样性——当前评估主要基于确定性指标和竞赛评分，未来可以探索更复杂的评估器，如基于人类偏好的RLHF风格评估、多目标优化评估（同时优化准确性和推理效率）、以及对抗性鲁棒性评估。其次，跨领域知识迁移——当前知识库主要面向数据科学和ML竞赛，可以将框架应用于软件工程（如单元测试生成、代码审查）、科学计算（如物理模拟优化）和系统编程（如性能调优）等领域，研究知识在不同领域间的迁移效果。第三，多智能体协作——当前OrchestratorAgent是单体架构，可以探索将知识检索、代码合成、调试等子任务分配给专门化的子智能体，通过协作提高效率。第四，人机协作优化——MediaWiki知识系统已经支持人类审查和策展，未来可以进一步研究人类反馈如何更有效地融入优化循环，特别是对于需要领域专家判断的任务。第五，从Leeroo在ALE-Bench上的成本效率优势（914.8美元vs1003.3美元）出发，可以深入研究如何在保持性能的同时进一步降低LLM调用成本，如通过更智能的上下文压缩和选择性知识检索。
复现评估
论文在可重现性方面做了相当出色的工作。作者公开了完整的知识包，包括MediaWiki dump、Neo4j和Weaviate快照、以及基于Docker的部署脚本，可以在可重现配置中启动MediaWiki实例和所有索引。知识库的仓库语料清单（包括URL、commit标识和选择标准）也被公开，支持时间点重建。框架的模块化设计允许独立替换评估器、知识后端和编码智能体，降低了复现的技术门槛。然而，完全复现仍面临一些挑战：第一，MLE-Bench和ALE-Bench的执行环境需要特定的基准测试设置，论文提供了明确的执行协议但未提供一键式复现脚本；第二，Gemini-2.5-pro作为底层LLM的使用引入了API依赖和成本（每次MLE-Bench运行预算上限200美元，ALE-Bench总计约914.8美元）；第三，Git原生实验引擎在大量迭代后可能产生较大的存储开销，论文未讨论长期运行的存储管理策略。总体而言，对于一个涉及复杂多组件系统的框架来说，KAPSO的可重现性支持在同类工作中属于上乘水平。
论文图表