2504.15228_SICA: A Self-Improving Coding Agent

总结

Figure 1: Meta Agent Loop: the agents starts with the minimal code required to support initial self-improvement, and then follows a sequence of benchmarking and meta-improvement.

关键概念

  • ADAS(Automated Design of Agentic Systems)使用元代理优化目标代理,但其本身不具备自我改进能力(即元代理和目标代理是分离的);

  • 自指式元代理编程(fully self-referential meta-agent programming)是一种更优的替代方案,在每次改进过程中可以利用之前提升的编码能力,形成能力增强的正反馈循环。

  • 自我改进的编码代理(Self-Improving Coding Agent, SICA)消除了元代理与目标代理之间的界限,能够自主编辑自身代码库,以优化成本、速度和基准性能。

  • 元智能体 (Meta-Agent): 这是理解本文的关键。它不是用来解决外部问题的,而是专门用来改进“目标智能体”的。但在SICA中,元智能体和目标智能体是同一个系统,只是在不同时刻扮演不同角色。这就像一位程序员(元智能体)在改进自己(目标智能体)编写的代码,实现了真正的“自我指涉”。

  • 异步监督器 (Asynchronous Overseer): 这是一个独特的安全与效率组件。它就像一个独立的、时刻保持警惕的“监工”,基于对整个系统运行轨迹的观察,实时判断主智能体的行为是否健康,并可以动态地发送指导信息或终止任务,防止智能体浪费资源或陷入死循环。

相关工作

  • 传统方法(需要大量人工投入,可能错过自动化搜索能发现的优化模式)

    • 思维链 (Chain-of-Thought, CoT)

    • Self-refinement(自我优化)

    • Self-reflection(自我反思)

  • 技能学习与自我改进

    • 方向:让智能体学习可重用的技能并持续改进

    • MaestroMotif:利用大语言模型反馈学习技能奖励,通过代码生成组合技能

  • 通过自然语言优化

    • OPRO和Promptbreeder通过语言优化提示词,但不修改对应的代码库

  • 自动化设计与优化(更依赖结构化的进化搜索)

    • AgentSquare:模块化设计空间,自动化搜索模块组合

    • AlphaEvolve:使用编码智能体进行科学发现和优化

  • 最接近的前期工作

    • ADAS使用一个元智能体改进目标智能体,但元智能体本身不改进

  • 同类工作

    • Gödel Agent 和 Zelikman 声称实现自我改进,但主要集中在语言理解、数学或算法任务上,而非广义的软件工程任务

核心方法:自我改进循环

评估 (Evaluate): 对当前的智能体(A_i)在多个基准测试(如SWE-Bench, LiveCodeBench)上运行,评估其性能。性能的度量是一个综合效用函数 U,它不仅考虑得分,还考虑了时间和经济成本,鼓励智能体变得更高效、更便宜。

生成 (Generate): 系统从历史档案中选出表现最好的智能体(A_i^)作为“元智能体”。这个“元智能体”被赋予一个任务:分析历史档案中的成功与失败案例,识别出当前智能体系统的弱点,并提出并实现改进方案。 这个改进方案直接体现为对SICA自身代码库的修改(例如,添加一个新的文件编辑工具、优化一个子智能体的提示词、或重构一个函数)。

迭代 (Iterate): 生成的新智能体(A_{i+1})被保存,并进入下一轮评估。这个过程循环往复,实现自我驱动式的进化。

多智能体(Multi-Agent)系统的 Prompt 设计规范

  • 三层 Agent 架构:

             ┌──────────────┐
             │  Main Agent  │  ← 总调度(类似 orchestrator)
             └──────┬───────┘
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
  Sub-Agent    Sub-Agent    Sub-Agent
 (执行者)     (执行者)     (执行者)

                    │
                    ▼
             Overseer Agent
             (监督/裁判)

👉 核心思想:

  • Main Agent(调度者):负责“拆任务 + 调度”

  • Sub-Agent(执行者):负责“干活”

  • Overseer(监督者):负责“监控 + 纠偏”

其他 代理使用 Sonnet 3.5 (v2),15次迭代的API成本约为7000美元

结论

  • 代码编辑与导航任务显著提升:

    • 在一个包含50个SWE-Bench Verified问题的随机子集上,SICA的性能从最初的17%提升到了53%。这表明SICA在长周期、复杂的软件工程任务上取得了巨大进步。

    • 在自建的代码导航和文件编辑任务上,性能也有明显提升(如文件编辑准确率从0.82提升至0.96)。

    • 通过分析改进过程,可以发现SICA自主创造了更高效的编辑工具(如“智能编辑”、“差异编辑”)和代码导航工具(如“AST符号定位器”),这些新工具直接带来了性能提升。

  • 推理任务提升有限:

    • 在AIME和GPQA等需要深度推理的任务上,SICA的提升微乎其微。

    • 原因分析: 当基础模型(如o3-mini)本身已经非常强大时,外部的智能体框架(scaffolding)反而可能成为干扰。例如,主智能体可能只是简单地将问题转交给强大的推理子智能体,而没有利用智能体系统的复杂功能,甚至一些粗糙的组件会打断模型自带的“思维链”,导致性能下降。这揭示了模型能力与系统架构之间的复杂互动关系。

  • 结论:本研究成功构建了SICA,一个能够通过自主修改代码来实现自我改进的智能体系统。实验证明,在需要复杂任务分解和工具调用的“智能体型”任务上,这种自我改进机制非常有效。同时,研究也指出了当前方法的局限性,尤其是在面对已经高度优化的推理模型时,外部框架的提升空间有限。

优缺点

  • 优点:

    • 创新性强: 首次在通用代码智能体上实现了真正意义上的自我指涉改进,打破了传统的“元智能体-目标智能体”分离模式。

    • 可复现性强: 开源了代码,为后续研究提供了坚实的平台和参考。

  • 缺点

    • 探索与创新的“品味”问题: 智能体提出的改进想法容易受初始特征的影响,陷入局部最优或重复迭代相似的主题,缺乏真正“颠覆性”的创新。这反映了当前LLM在开放式创新上的瓶颈。

    • 成本高昂: 一次15次迭代的运行成本高达约7000美元,这极大地限制了该方法的普及和广泛应用。

    • 基准依赖与路径依赖: 智能体的改进方向高度依赖于其评估的基准。如果基准有偏差,改进方向也会随之偏离。同时,早期的不良改进可能会“污染”历史档案,影响后续的迭代方向。

相关prompt

Main Agent Prompt

你的任务是协调多个子代理,共同解决问题。以下是需要解决的问题:

问题陈述 ==============================================================
{problem_statement}
问题陈述结束 ==========================================================

现在,你需要将这个问题委派给一个、两个或任意数量的代理,以确保问题得到彻底解决。

在委派时请注意以下几点:

1. **关于问题陈述的传递**   - 子代理本身也能访问问题陈述,因此通常不需要完整复述
   - 只需给出清晰的方向指示即可
   - 如果问题陈述很长,**明确禁止**完整复述,相信子代理可以自行查阅

2. **你的工具权限**   - 你拥有文件/目录查看工具,这有助于你了解上下文环境
   - 这些工具仅用于帮助你把握全局,以便更有效地协调子代理
   - **没有**任何可以直接进行实质性工作的工具,因为你的角色是路由者、委派者和协调者

3. **关于子代理**   - 你需要仔细了解每个子代理可用的工具清单
   - 基于子代理的能力来决定下一步调用哪个代理
   - 子代理负责执行具体工作、做出必要的状态变更,推动任务进展

Base Sub-Agent Prompts

作为一名专业且有经验的程序员,你的工作方法是:

1. **放慢节奏,不要一次性写完整个文件**

2. **首先彻底理解上下文**:
   2.1 浏览项目,找出所有可能有用的文档文件(README.md 文件、常见的 MD 文档文件等)
   2.2 查看每个文件,做笔记或摘要,关闭不相关或过长的文件
   2.3 根据指令探索代码库:找出所有相关文件,识别现有的设计模式和惯例

3. **(可选)开始编码前进行原型设计和规划**:
   3.1 在测试目录中创建一些简单的示例
   3.2 通过执行反馈来评估或比较不同方法
   3.3 将信息和经验综合起来,形成最终的设计或解决方案

4. **进行代码修改**:
   4.1 找出最简洁有效的方式来完成所需的修改
   4.2 遵循现有的代码风格规范

5. **进行端到端测试**:
   5.1 优先使用测试脚本进行端到端测试,避免使用测试框架
   5.2 如果上述方式不可行,或者项目已使用测试框架,则沿用现有框架
   5.3 确保代码有效、没有引入回归问题、且能按预期工作

6. **做好收尾工作**:
   6.1 检查所有文档在修改后是否仍然保持更新
   6.2 清理所有临时文件或临时修改

**注意事项**- 不要创建虚拟环境
- 尽量避免使用 pytest 和模拟对象(mocks),优先使用端到端测试脚本
- 如果请求明显是探索性质的,可以跳过上述严格的流程,采用适当的方式处理
- 如果在复杂的算法或数学问题上遇到困难,可以调用你的推理代理来帮助获得思路和推进工作
这是你需要解决的问题:

你的问题 ================
{self.problem_statement}
==================================

工作方法:
1. 先梳理清楚问题本身的要求和意图
2. 规划最小可行解决方案,验证方法的可行性
3. 快速执行,根据反馈灵活调整
4. 对照原始需求进行验证

核心原则:
- 选择最简单的可行方案
- 尽早验证、持续验证
- 遇到阻碍时快速调整适应
以下是初始请求,仅供参考背景,这是我们最终要解决的问题:

初始请求:
{self._context.initial_request}
初始请求结束。

以下是分配给你解决的问题:

问题陈述:
{self.problem_to_solve}
问题陈述结束。

Overseer Prompt

你是一个负责实时监控代理执行的专家系统监管员。你将看到正在进行的执行轨迹,并需要判断是否需要干预。你以循环方式运行。

你的任务是:
1. 分析当前的执行状态
2. 判断是否拥有足够的信息做出可靠评估
3. 评估代理是否健康推进,还是需要干预
4. 如果需要干预,向正在运行的代理提供有建设性的引导提示
5. 在极端情况下,取消代理的执行并通知其父代理取消原因
6. 如有需要,为后续的评估迭代留下备注

请按以下结构化格式提供你的分析:

### 监管员分析示例
当前执行轨迹:

graph_repr

之前的监管员备注(如有):
self._previous_notes if self._previous_notes else '无备注。'

关键考虑因素:
- 已返回的代理无法接收通知
- 查看时间戳和事件数量,了解执行进度
- 某些代理可能需要较长时间才能完成,这是正常的
- 既要考虑单个代理的健康状况,也要考虑全局执行进度
- 如果代理似乎卡住无法终止,提醒它可以通过生成 <COMPLETE>{COMPLETE_STOP_TOKEN} 来退出
- 当代理被分配在元改进阶段处理自身代码时,如果它试图直接测试工具或其他功能(使用自己正在运行的代码),立即干预,告诉它要么进行端到端的新代理测试(python -m workdir.agent -p "<some prompt>"...),要么创建测试脚本来直接测试工具
- 当代理不再推进、浪费资源、明显偏离正确方向或违反指令时,可以取消其执行。在发出取消命令前,必须至少尝试一次通知代理其错误行为
- 取消代理时,必须同时通知其父调用代理取消的原因
- 如果任务变得不可行,经过多次失败尝试后,代理开始重复自身行为,指示主代理使用其 early_exit 工具提前退出
- 谨慎使用取消操作,因为取消会造成中断,且通常比引导代理成功完成代价更高——任何新的子代理往往需要从头开始任务

上次检查时间:{self._last_check_time.strftime("%H:%M:%S") if self._last_check_time else "无"}
当前时间戳:{datetime.now().strftime("%H:%M:%S")}

你的分析:

From Moonlight

三句摘要

  1. 🤖 本文介绍了一种名为SICA(自改进编程智能体)的系统,它能够通过自主编辑自身代码库来提升其在基准任务上的性能。

  2. 📈 实验证明,SICA在SWE-Bench Verified上的性能提高了17%至53%,并在LiveCodeBench和合成基准测试中也取得了额外的性能提升。

  3. 💡 SICA通过LLM反思和代码更新实现自引用改进,消除了元代理与目标代理的区别,展示了一种数据高效、非基于梯度的学习机制。

关键词

  • Self-Improving Coding Agent (SICA): 一种由本文提出的能够自主编辑自身代码库以提高性能的编码代理,它消除了元代理和目标代理之间的区别,实现了完全的自我改进,并在基准测试中展现了显著的性能提升。

  • Meta-Improvement Loop: SICA运行的核心循环,它从过往代理的存档中选择表现最佳的代理作为元代理,该元代理被指示分析存档、识别改进点并实施代码更新以生成新的代理版本,然后对新版本进行基准测试并将其结果存入存档,形成持续自我迭代和改进的机制。

  • 子代理 (Sub-agents): 由主代理调用的小型、专业化的代理,它们接受输入参数并返回字符串值,用于任务分解、委托以及管理长运行代理的上下文长度,从而提高效率和可扩展性。

  • 监督者 (Overseer): SICA中一个异步运行的基于LLM的组件,它周期性地监控代理的执行状态,判断是否存在异常行为(如循环、偏离任务),并通过发送通知或在严重情况下取消代理执行来干预,以确保代理保持在正确的轨道上。

  • LLM上下文窗口 (LLM Context Window): 指的是提供给大型语言模型(LLM)的输入结构化信息,包括系统提示、核心提示(如问题陈述、文件内容、目录树)以及助理消息(如思维链推理、工具调用及结果、子代理调用及结果等),这些内容共同构成了LLM进行决策和生成的基础。

  • 效用函数 (Utility Function): 一种用于量化代理表现的评分机制,它综合考虑了标准化基准测试性能分数、运行成本和执行时间,并设定了相应的权重和惩罚机制(如超时惩罚),用于选择下一轮迭代中表现最佳的代理。

  • SWE-Bench Verified: 一个用于评估编码代理在软件工程任务上表现的基准测试集,它要求代理进行问题分解、代码导航以及快速高效的文件编辑,SICA使用其随机子集进行性能评估。

  • LiveCodeBench: 一个包含类似竞技编程任务的基准测试集,这些任务通常需要更强的理论推理能力,SICA也使用其随机问题进行性能评估。

  • 代理系统自动化设计 (ADAS): 一项先前的工作,其中一个元代理(meta-agent)负责改进另一个目标代理(target-agent),与SICA直接由代理改进自身(无元/目标代理区分)形成对比,突出了SICA在自我改进方面的独特之处。

  • 可观察性 (Observability): SICA中的一个关键安全机制,通过提供丰富的洞察力(如思维链、行动、子代理调用)以及交互式网络界面,允许人类全面监控和理解代理的内部运作,尤其是在自我改进过程中,以确保安全受控。

  • 存档 (Archive): 存储系统所有先前代理版本及其相应基准测试结果的数据库,这个存档是元改进循环的关键组成部分,为元代理提供了分析和学习历史性能数据以指导未来改进的基础。

摘要

这篇论文介绍了自我改进编码智能体 (SICA),一种能够自主编辑其自身代码库以提高性能的智能体系统。该研究展示了LLM智能体在真实世界任务中部署的潜力,特别强调了通过LLM反思和代码更新驱动的、数据高效且非梯度学习的自我改进机制。

摘要与引言

当前,大型语言模型 (LLMs) 在多个领域取得了显著进展,但要将其应用于实际,通常需要将其封装在能够编排LLM调用并提供工具的智能体系统中。这些系统通常是手动设计和优化的,耗费大量人力且可能无法探索到最优解空间。

本文提出的SICA旨在解决这一局限性,它能自主修改和改进自己的代码,例如发现新的提示方案或工具。作者认为这种完全自指的元智能体编程是可行的。与现有工作(如ADAS)不同,SICA消除了元智能体与目标智能体之间的区别,实现了真正意义上的自我改进。

核心贡献包括:

  • SICA的提出:一个能够编辑自身代码库以改进其性能、成本和速度的自我改进编码智能体。

  • 实证证据:在SWE-Bench Verified的随机子集上,性能提升了17%到53%,并在LiveCodeBench和合成智能体基准测试中也取得了额外性能提升。

  • 开源实现:SICA使用标准Python实现,为构建新的SICA系统和训练LLMs提供了参考框架。

相关工作

传统智能体系统的开发和优化主要依赖手动设计智能体架构和提示技术,如思维链 (Chain-of-Thought, CoT) 和自我反思。近期工作开始探索自动化方法,如MaestroMotif通过LLM反馈学习技能奖励,以及OPRO和Promptbreeder通过语言优化提示。

本文区分了SICA与现有方法的不同:

  • **ADAS **:ADAS使用一个元智能体改进目标智能体,但元智能体本身不改进。它仅编辑用特定领域语言 (DSL) 编写的单个前向函数。SICA则完全自我改进,在整个Python代码库上操作,且没有元智能体和目标智能体的区别。

  • Gödel Agent 和 Zelikman et al. :这些工作声称实现自我改进,但并非通用编码智能体,其评估主要集中在语言理解、数学或算法任务上,而非广义的软件工程任务。SICA是首个真正意义上的自我改进编码智能体

方法

SICA的核心运行循环类似于ADAS 的循环,但进行了关键修改以实现自我改进。

1. 元智能体循环 (Meta Agent Loop)

SICA的运行流程如算法1所示:

  1. 初始化初始智能体 \(A_0\)

  2. 在每次迭代 \(i\) 中,评估当前最佳智能体 \(A_i\) 在基准测试 \(B\) 上的性能,并将其存储在 \(p_i\) 中。

  3. 选择截至当前迭代的最佳性能智能体 \(A_{\hat{i}}\) (其中 \(\hat{i} = \arg \max_{j \in \{0,...,i\}} p_j\)) 作为元智能体,由它来分析历史档案 (\(A_{\le i}\)\(p_{\le i}\)),识别改进点,并生成下一个智能体 \(A_{i+1}\)

  4. 重复此过程直到达到预设的迭代次数 \(n\)

这与ADAS的关键区别在于:ADAS有一个固定的元智能体,并且只存档目标智能体;而SICA将所有智能体都存档,并选择性能最佳的智能体作为元智能体来进行自我改进。

2. 效用函数 (Utility Function)

为定义“最佳”智能体,SICA使用一个效用函数 \(U\) 来衡量综合性能,考虑了标准化基准性能得分 \(p_{score}\)、实际运行时间 \(p_{time}\) 和成本 \(p_{cost}\)

效用函数的计算公式为: \(U = w_{score} p_{score} + w_{cost}(1 - \min(1, p_{cost}/\$10)) + w_{time}(1 - \min(1, p_{time}/300 \text{ s}))\)

其中,权重系数设置为:\(w_{score} = 0.5\), \(w_{cost} = 0.25\), \(w_{time} = 0.25\)。成本上限为每问题$10,时间上限为300秒。如果智能体超时,最终效用函数会乘以一个超时惩罚 \(\tau = 0.5\)\(U_{final} = \begin{cases} U (1 - \tau), & \text{if timed out} \\ U, & \text{otherwise} \end{cases}\)

该分数仅用于选择下一个元智能体和下一个迭代的基础智能体,不涉及权重更新。

3. 初始智能体 (Initial Agent) 描述
  • 工具:初始智能体配备了一系列基本工具,包括打开/关闭文件、覆盖文件、执行shell命令、计算器、提交最终答案、从子智能体调用返回结果,以及提前退出子智能体调用。此外,还有一个“档案分析”工具用于提取迭代统计信息。工具调用机制采用XML格式化结构化生成,使用停止令牌来解析工具名和参数。例如:

    <TOOL_CALL>
    <TOOL_NAME>tool_name</TOOL_NAME>
    <TOOL_ARGS>
    <arg1>value1</arg1>
    <arg2>value2</arg2>
    </TOOL_ARGS>
    </TOOL_CALL>
    

    其中 </TOOL_CALL> 注册为停止令牌。

  • 子智能体 (Sub-agents):初始智能体包含编码智能体、问题解决智能体和推理智能体。子智能体通过接受输入参数并返回字符串值的方式被调用。这种抽象设计有两个目的:确保基准任务完全自主运行,以及管理长时间运行的上下文长度。子任务完成后,其上下文可以被自然地丢弃,只保留返回结果作为摘要。

  • 异步监督器 (Asynchronous Overseer):这是一个并发运行的LLM,定期评估智能体的行为是否存在病态或偏离任务的情况。它可以通过向运行中的智能体发送消息进行干预,或在严重情况下取消智能体执行。监督器通过提供系统状态的全面文本表示(包括调用图、事件流、LLM消息、工具调用响应等)来检测模式并避免重复工作。监督器每30秒或在关键事件时被调用。

  • LLM上下文窗口结构 (LLM Context Window Structure)

    • 系统提示 (System Prompt):首先呈现,包含智能体定义、目标、工具文档、子智能体文档和系统指令。

    • 核心提示 (Core Prompt):作为聊天模板中的第一个用户消息,包含调用者指定的问题陈述、已打开文件的视图以及当前工作目录的表示。

    • 助理消息 (Assistant Messages):LLM智能体上下文的其余部分,包含思维链推理、工具调用及其响应、子智能体调用及其响应,以及来自异步监督器的通知或评论。

    • 这种结构允许新内容追加,从而保留KV缓存,以降低延迟和成本。

实验与结果

1. 基准测试

SICA在以下基准测试中进行了评估:

  • **SWE-Bench Verified **:50个随机问题,测试问题分解、代码导航和高效编辑。

  • **LiveCodeBench **:50个随机问题,类似竞技编程,涉及更多理论推理。

  • 合成基准测试

    • 文件编辑基准测试:通过克隆SWE-Bench中使用的代码库,识别连续提交中有趣的文件编辑,然后提示智能体将文件编辑成与目标内容匹配。

    • 代码库导航问题:克隆Python代码库,识别“有趣”的符号,并要求智能体找到符号的定义位置(路径/行号/列号)。

实验中,多数智能体使用Sonnet 3.5 (v2) ,推理智能体使用o3 mini 。15次迭代的API成本约为$7,000。

2. 性能进展

图3和表1展示了SICA在15次迭代中的性能进展:

  • 文件编辑基准测试:智能体初始效率低下(准确率0.82),但通过引入基于diff和范围的“智能编辑”工具,性能显著提升至0.91-0.96。

  • 符号导航基准测试:性能从0.35提升至0.40-0.43。智能体在迭代9中实现了基于抽象语法树 (AST) 的符号定位器。

  • SWE-Bench Verified:性能从0.17显著提升至0.51-0.53。这主要归因于智能体框架的不断改进。

  • LiveCodeBench:性能有细微提升,从0.65提升至0.70-0.71。

迭代期间的关键改进如下:

  1. Smart Editor(智能编辑器):实现了一个新工具,根据编辑特性智能选择并执行最优的文件编辑策略。

  2. Quick Overwrite Tool(快速覆盖工具):解决文件编辑操作的性能问题,减少令牌使用。

  3. Diff-Enhanced Smart Editor(Diff增强型智能编辑器):增加了智能的基于diff的策略选择和改进的基于模式的编辑。

  4. Simplified DiffVerifier Tests(简化Diff验证器测试):改进开发体验以提高可维护性。

  5. Code Context Summarizer(代码上下文摘要器):添加新工具,使用ripgrep高效提取和总结代码上下文,提高代码库探索效率。

  6. SmartEditor Input Normalizer(智能编辑器输入归一化器):增加了InputNormalizer组件,提高编辑操作效率和可靠性。

  7. Enhanced File Edit Verification(增强文件编辑验证):实现全面的文件状态跟踪系统,提高编辑操作效率。

  8. Minimal Diff Output Optimization(最小化Diff输出优化):优化文件编辑操作中的令牌使用,最小化diff上下文输出。

  9. AST Symbol Locator(AST符号定位器):集成了基于AST的符号定位工具,用于精确的代码导航。

  10. Optimized File Edit Routing(优化文件编辑路由):在MainAgent中实现显式任务类型检测和路由优化,改进文件编辑任务的处理。

  11. Enhanced File Size Optimization(增强文件大小优化):添加100KB的文件大小阈值,优化大文件处理并减少处理开销。

  12. Hybrid Symbol Locator(混合符号定位器):实现混合符号定位方法,结合ripgrep进行候选识别和AST验证。

  13. Context-Sensitive Diff Minimization(上下文敏感Diff最小化):将上下文敏感的diff最小化功能集成到SmartEditor工具中。使用AST解析Python代码更改,并对其他文件类型进行模式分析,旨在通过最小化更改上下文来减少令牌使用。

  14. Optimized AST Parsing in Hybrid Symbol Locator(混合符号定位器中优化的AST解析):在hybrid_symbol_locator.py中实现有针对性的AST解析,仅处理相关代码区域而非整个文件。

3. 推理任务性能

图4展示了SICA在推理密集型任务(AIME 2024和GPQA Diamond )上的表现。结果显示改进较少。初始智能体(使用Sonnet 3.5和o3 mini推理子智能体)在此类任务上表现已良好(o3 mini在AIME上达到87%,GPQA Diamond上达到79%)。论文指出,主智能体常常只是将问题委派给o3 mini推理智能体。为诱导推理行为而引入的粗糙组件,可能反而中断了在智能体系统外部训练的推理模型的思维链,导致性能下降。这暗示了未来需要将LLM模型与智能体系统设计联合训练。

结论

SICA展示了通过编辑自身代码库实现自我改进的可能性,尤其是在需要更长周期操作的“智能体式”任务中。性能在SWE-Bench Verified上提升了17%到53%,同时平均每问题时间略有减少。该框架为自动化智能体系统设计提供了实用方法,也为未来联合训练基础模型和智能体系统奠定了基础。

局限性

  • 创新想法生成困难:LLM智能体难以自主提出真正新颖、可行且有趣的修改想法。不佳的想法会导致冗长且昂贵的代码编辑和基准测试运行。

  • 路径依赖:初始特征想法会强烈影响后续的想法,导致结果具有更高方差。

  • 基准分数受限:短时间(5分钟)和每问题成本限制可能导致初始基准分数低于底层语言模型的预期,尤其对于长周期任务。初始改进大部分来源于加速文件编辑和降低成本。

未来工作

  • 联合更新基础模型权重:目前SICA采用非权重学习机制,未来可探索将基础模型的权重与智能体系统联合更新。

  • 自动化基准设计与策展:SICA的灵活性使其能够为自己创建新的基准测试和评估,如本文中的合成基准测试。

安全考虑

  • 可观测性 (Observability):SICA设计了复杂的、用户友好的可观测性机制,提供详细的思维链、操作和子智能体调用信息。这包括一个交互式网页界面和异步LLM监督器,后者可以检测病态行为并取消智能体。由于SICA不涉及模型权重更新,这一机制能提供强大的安全保障。

  • 迭代、基于评估的更新程序:在基准测试中纳入安全相关评估,确保每个智能体在进入下一迭代前都通过安全验证。

作者认为本工作对社会没有直接的重大负面影响,因为其目标主要集中在提高代码编辑机制或多步骤推理的有效性。

Abstract

本论文研究了大型语言模型(LLMs)代理系统的自主改进能力。作者展示了一个具备基础编程工具的LLM代理系统,能够自动修改自身的代码,从而在多个基准任务中提升性能。

核心内容总结:

  • 背景与动机:随着LLM的发展,越来越多的LLM被部署在“代理系统”中,这类系统通过代码调用LLM并为其提供工具来完成任务。

  • 主要发现:作者设计的代理系统能够通过自我编辑代码的方式,实现性能提升。

  • 实验结果

    • SWE Bench Verified的一个随机子集上,性能提升了17% 到 53%

    • LiveCodeBench和一些合成生成的代理基准任务中也观察到了性能提升。

  • 意义与贡献

    • 推动了代理系统自动化、开放式设计的发展。

    • 提出了一种数据高效、非基于梯度的学习机制,该机制依赖于LLM的反思(reflection)和代码更新。

重点内容强调:

  • 自我改进机制:这是本文的核心创新点,即代理系统能够通过LLM的反思生成代码更新,从而提升性能。

  • 非梯度学习方法:不同于传统深度学习的训练方式,本文方法不依赖大量数据和反向传播,而是通过少量任务反馈进行代码优化。

精简说明:

  • 没有涉及复杂的数学公式或算法步骤,主要为方法论和实验结果的概述。

  • 表格数据未在摘要中出现,但提到了多个基准测试中的显著性能提升。


如需继续总结后续章节内容,请提供下一节文本。

1 Introduction

本节介绍了大语言模型(LLMs)在多个领域和任务中取得的显著进展,并指出为了在实际应用中使用这些模型,需要将LLMs封装在代码中,构建能够调用工具并执行操作的系统,这类系统被称为代理系统(agent system)。

1.1 代理系统的优势

代理系统通过组合不同的提示策略(prompting strategies)和输出整合方法,显著提升了模型在基准测试中的表现。例如:

  • 早期方法包括 best-of-NN 采样 和 链式思维(Chain of Thought, CoT);

  • 更复杂的方法如 STaR 、思维树(Tree of Thoughts, ToT)、思维图(Graph of Thoughts, GoT)、LLM 辩论(LLM Debate)、迭代自优化(Iterative Self-Refinement)、专家提示(Expert Prompting) 等。

Schulhoff 等人的综述 汇总了大量手动设计的代理策略,说明该领域已有广泛探索。

1.2 自我改进的代理系统

随着编码代理(coding agents)的发展,提出一个关键问题:代理是否可以自主修改和优化自身代码,自动发现新的提示策略或工具?

作者提出:

  • 与传统手动设计的代理相比,自指式元代理编程(fully self-referential meta-agent programming)是一种更优的替代方案;

  • 传统方法如 ADAS(Automated Design of Agentic Systems) 使用元代理优化目标代理,但其本身不具备自我改进能力(即元代理和目标代理是分离的);

  • 自我改进系统的优势在于:在每次改进过程中可以利用之前提升的编码能力,形成能力增强的正反馈循环

1.3 本文贡献

本文提出了一种自我改进的编码代理(Self-Improving Coding Agent, SICA),其主要贡献包括:

  1. SICA 架构
    消除了元代理与目标代理之间的界限,能够自主编辑自身代码库,以优化成本、速度和基准性能。

  2. 实证验证
    在 SWE-Bench Verified 的随机子集上,SICA 的性能从 17% 提升至 53%,即使考虑了安全约束和资源效率。

  3. 开源实现
    提供了一个基于标准 Python 实现的 SICA 系统,不依赖领域特定语言(DSL),为后续研究和模型微调提供了参考框架。

项目地址:https://github.com/MaximeRobeyns/self_improving_coding_agent


总结
本节从代理系统的发展出发,提出自我改进代理的必要性与可行性,并介绍了 SICA 的核心思想与初步实验结果,强调其在自动化优化和持续提升方面的潜力。

3 Methods

概述

SICA(Self-Improving Coding Agent)的核心运行机制类似于ADAS循环,其流程如图1所示。与ADAS不同的是,SICA会从历史存档中选择表现最好的代理作为元代理(meta-agent),而ADAS的元代理是固定的。两者都会将新代理在基准测试中评估,并将结果存入存档。


3.1 初始代理(Initial agent)

SICA的初始代理是一个功能完善的编码代理,具备多种工具、子代理和监督机制,这些组件都具备自我改进的潜力。

工具(Tools)

  • 文件操作:打开、关闭、覆盖文件。

  • 执行命令:运行shell命令、计算器工具。

  • 任务控制:提交最终答案、返回子代理结果、提前退出子代理。

  • 存档分析:提取代理迭代的统计信息。

子代理(Sub-agents)

  • 功能:类似工具调用,接受输入并返回字符串结果。

  • 作用

    1. 实现任务的完全自主运行,无需人工干预。

    2. 管理上下文长度,避免长时间运行导致的上下文膨胀。

  • 初始子代理

    • 编码代理

    • 问题求解代理

    • 推理代理

异步监督器(Asynchronous Overseer)

  • 功能:定期运行,检测异常行为或任务偏离,必要时通知或终止代理。

  • 调用频率:默认每30秒调用一次,或在关键事件触发时调用。

  • 输入信息:包括代理调用图、LLM消息、工具调用与响应、子代理调用与响应。

  • 作用:识别重复工作、行为模式,防止代理陷入死循环或偏离任务。

上下文结构(LLM Context Window)

如图2所示,上下文结构包括:

  1. 系统提示(System Prompt)

    • 代理定义与目标

    • 工具与子代理文档

    • 系统指令

  2. 核心提示(Core Prompt)

    • 问题描述

    • 打开的文件内容

    • 当前目录树

  3. 助理消息(Assistant Messages)

    • 思维链(CoT)推理

    • 工具调用与结果

    • 子代理调用与结果

    • 监督器通知

上下文管理策略

  • 新内容以追加方式添加,保留KV缓存以降低延迟和成本。

  • 文件编辑以diff形式追加,定期合并到文件视图中。


自我改进流程(Self-Referential Agent Improvement)

算法1:自我改进代理流程

输入:

  • 基准测试集 \( B = \{b_j : j = 1, \ldots, m\} \)

  • 迭代次数 \( n \in \mathbb{N} \)

输出:

  • 改进后的代理系统 \( A_n \)

步骤:

  1. 初始化代理 \( A_0 \)

  2. \( i = 0, 1, \ldots, n-1 \) 进行迭代:

    • 评估 \( A_i \) 在基准测试上的表现 \( p_i \)

    • 从存档中选择表现最好的代理 \( A_{\hat{i}} \)(即 \( \hat{i} = \arg\max_{j \in \{0,\ldots,i\}} p_j \)

    • 使用 \( A_{\hat{i}} \) 生成下一个代理 \( A_{i+1} \)

  3. 返回最终代理 \( A_n \)


性能评估函数(Utility Function)

基础效用函数(Base Utility):

\[ U = w_{\text{score}} p_{\text{score}} + w_{\text{cost}} (1 - \min(1, p_{\text{cost}} / \$10)) + w_{\text{time}} (1 - \min(1, p_{\text{time}} / 300\text{ s})) \]

其中:

  • \( p_{\text{score}} \in [0,1] \):标准化基准得分

  • \( p_{\text{cost}} \):成本(美元)

  • \( p_{\text{time}} \):运行时间(秒)

  • 权重设置:\( w_{\text{score}} = 0.5, w_{\text{cost}} = 0.25, w_{\text{time}} = 0.25 \)

  • 成本上限:$10/问题

  • 时间上限:300秒,超时则取消

超时惩罚(Timeout Penalty):

\[\begin{split} U_{\text{final}} = \begin{cases} U(1 - \tau), & \text{if timed out} \\ U, & \text{otherwise} \end{cases} \end{split}\]

其中 \( \tau = 0.5 \)

该效用函数仅用于选择下一个元代理和基础代理,不用于模型参数更新。


小结

  • SICA 的核心机制:基于ADAS循环,但引入了动态选择元代理的机制。

  • 初始代理结构:包含工具、子代理、监督器,支持自主运行与上下文管理。

  • 上下文结构:分为系统提示、核心提示、助理消息,便于扩展与KV缓存优化。

  • 性能评估:通过效用函数综合考虑得分、成本、时间,超时引入惩罚。

  • 自我改进流程:通过迭代评估与生成新代理,实现代理系统的持续优化。

4 Experiments and Results

本章主要展示了代理系统在多个编码任务上的性能表现,以及随着迭代改进的提升趋势。

标题不变:4 Experiments and Results

主要内容总结:

实验设置:

  • 使用了多个基准测试任务,包括:

    • SWE Bench Verified:测试问题分解、代码导航和高效文件编辑能力,从中选取50个随机问题。

    • LiveCodeBench:50个随机问题,偏向竞争性编程,需要更多理论推理。

    • 两个合成基准任务

      1. 文件编辑基准:通过Git提交差异构造,代理需将文件编辑成目标状态,评分基于文件内容相似度,并考虑时间、成本和token消耗。

      2. 代码导航基准:代理需定位Python项目中符号的定义位置,返回格式为path/to/file.py:line_num:column_num

模型配置:

  • 大部分代理使用 Sonnet 3.5 (v2),一个“推理代理”使用 o3 mini

  • 由于是长期任务,使用了性能更强的模型,15次迭代的API成本约为7000美元。

图表与数据:

  • 图3:展示了代理系统在15次迭代中性能的变化趋势,标注了关键改进点(如“Smart Edit”工具、AST符号定位器、混合符号定位器等)。

  • 表1:详细列出了每次迭代在不同基准任务上的准确率及平均成本指标(成本、时间、token消耗、缓存命中率)。

关键数据趋势:

  • 文件编辑基准:准确率从0.82提升到0.96,说明“智能编辑”工具显著提升了效率。

  • 符号定位基准:从0.35提升到0.43,第9次迭代引入AST符号定位器后有明显提升。

  • SWE-Bench Verified:准确率从0.17提升到0.51,显示代理框架在复杂任务上的持续改进。

  • LiveCodeBench:准确率从0.65提升到0.71,提升幅度较小,但整体趋势向好。

成本与效率:

  • 平均成本从1.91美元降到1.70美元,时间从130秒降到114秒,token消耗略有上升。

  • 缓存命中率从32.5%提升到36.3%,说明代理系统在复用已有信息方面有所改进。

重点内容强调:

  • “Smart Edit”工具:代理在早期只能通过覆盖文件进行编辑,效率低,后来实现了基于diff和范围的“智能编辑”,显著提升了文件编辑性能。

  • AST Symbol Locator:第9次迭代引入的AST符号定位器,在Python项目中表现良好,提升了代码导航和相关任务的准确率。

  • Hybrid Symbol Locator:后续迭代中进一步优化,结合多种定位策略,提升了整体性能。

  • Agent Iteration Utility:代理系统在每次迭代中根据性能提升获得“效用”反馈,从而驱动自我改进。

不重要内容精简:

  • 对于符号定位任务得分较低的原因,作者归因于数据质量问题(如目标符号指向未安装的外部库),这部分属于次要说明,未对整体结论产生重大影响。


4.1 Performance on Reasoning Tasks(未完整展示)

简要说明:

  • 作者还测试了代理系统在需要更多推理能力的任务上的表现,如AIME问题解答任务。

  • 虽然未展示完整数据,但指出这是为了评估代理在“推理密集型”任务中的自我改进能力。


总结:

本章通过多个基准任务和15次迭代实验,展示了代理系统在代码编辑、导航、问题解决等方面的持续改进。关键工具(如智能编辑、AST定位器)的引入显著提升了性能,同时成本和效率也得到了优化。图表数据清晰展示了性能提升趋势,验证了代理系统的自我改进能力。

4.1 性能在推理任务上的表现(续)

—— AIME 与 GPQA Diamond 的改进有限

重点内容总结:

  • 实验背景与结果概述:
    本节讨论了系统在 AIME(美国数学邀请赛)和 GPQA Diamond(一个高难度常识推理数据集)上的表现。结果显示,尽管引入了多代理系统(agent system)和多种推理组件(如数学验证器、符号计算器、几何专家等),但整体准确率提升有限。

    • o3-mini 模型在“高推理努力”设置下,单独在 AIME 和 GPQA Diamond 上分别达到了 87% 和 79% 的准确率。

    • 而整个代理系统(agent system)在这些任务上的平均准确率仅为 76%,甚至低于单独模型的表现。

  • 系统结构与迭代分析:

    • 初始代理系统(iteration 0)使用的是 Sonnet 3.5 作为主代理,o3-mini 作为推理子代理。

    • 随着系统迭代(如第 4 和第 6 次迭代),引入了一些“粗糙的”推理组件(如数学交叉验证器、几何专家等),但这些组件并未显著提升性能,反而可能干扰了原本训练良好的推理模型的思维链(chain of thought),导致性能下降。

  • 关键观察与分析:

    • 多数情况下,主代理只是将问题直接委托给 o3-mini 子代理,未充分利用整个系统的能力。

    • 对于已经具备强推理能力的模型(如 o1、o3-mini、DeepSeek R1),人为加入的推理诱导组件可能反而破坏其内部推理流程,导致性能下降。

  • 未来方向:

    • 作者指出,未来的研究方向应是联合训练“代理型”大语言模型(agent LLMs)与代理系统架构,以更好地融合模型与系统组件的优势。


总结:
本节通过实验表明,在已有强推理能力的模型基础上构建代理系统,并不能自动带来性能提升。相反,若系统设计不当,反而可能干扰模型的推理过程。这提示我们,在构建复杂代理系统时,需要更精细地设计与训练策略,以充分发挥模型与系统架构的协同作用。

5 Conclusion

本节总结了SICA(Self-Improving Coding Agent)的研究成果与意义。

核心内容:

  • SICA 是一个具备自我改进能力的编程代理系统,其核心在于通过代理系统编辑自身代码库,实现自我提升。

  • 实验结果表明,这种自我改进机制在长期任务中尤其有效,尤其是在基础大语言模型(LLM)需要结构化引导的任务中。例如,在SWE-Bench Verified的一个随机子集上,问题解决率从17% 提升至53%,同时平均每个问题的解决时间略有下降。

  • 该框架不仅提供了一种实用的自动化代理系统设计方法,也为未来联合训练基础模型与其代理系统的工作奠定了基础。


5.1 局限性(Limitations)

本节分析了SICA在当前阶段存在的主要限制。

重点内容:

  • 缺乏创新性改进思路:LLM代理在每次自我改进中难以自主提出真正新颖、可行且有价值的修改建议,这在开放式学习领域已有相关研究指出。

  • 错误修改代价高昂:如果代理采纳了一个低质量的修改建议,将导致长时间的代码编辑和昂贵的基准测试运行。虽然失败的尝试会被记录在案,但早期的修改建议往往会影响后续思路,形成路径依赖,导致代理运行结果的方差较大。

  • 初始建议质量影响后续表现:例如,如果代理一开始过于关注某些低效功能(如缓存打开的文件),会降低后续建议的质量。

其他限制:

  • 时间与成本限制影响基准表现:由于设置了较短的5分钟超时限制,以及单个问题的成本控制,导致基础模型(如Sonnet 3.5 v2)在SWE-Bench等长期任务中的初始得分可能低于其真实水平。

  • 改进方向偏向效率而非任务本身:很多提升来自于文件编辑速度和成本控制的优化,这些因素在SWE-Bench评分中体现不明显。


5.2 未来工作(Future Work)

本节展望了SICA未来可能的发展方向。

重点内容:

  • 非参数学习机制的潜力与局限:SICA通过优化提示词和代码逻辑来改变系统行为,而不是更新模型参数。这种方式在样本效率上较高,但未来可以探索联合更新基础模型参数与代理系统的方法,如AlphaEvolve所展示的那样。

  • 模型微调与工具适配:可以更明确地对基础模型进行微调,使其更好地适应新创建的工具和系统结构。

其他方向:

  • 基准测试的动态生成:当前系统尚未达到基准测试的上限,但未来可能会面临静态测试集的局限。一种解决方案是自动设计和维护测试集,如相关研究中通过代码生成RL环境的做法。

  • SICA 的灵活性验证:作者通过让代理自主设计两个合成基准测试(文件编辑与符号导航),展示了SICA能够支持自我生成新的评估任务的能力。


总结:

本章从成果、局限与未来方向三方面全面总结了SICA系统。其核心贡献在于验证了自我改进代理系统的可行性,并提出了未来在模型联合训练与自动基准生成方面的研究方向。

6 Safety Considerations

本节重点讨论了自改进系统可能带来的安全问题,并提出了两种主要的风险缓解机制。

1. 可观测性(Observability)

作者强调,对于潜在的自改进系统,人类必须能够全面监督其运行过程。为此,SICA 系统设计了多种用户友好的可观测机制,包括:

  • 交互式网页界面:用于实时监控代理系统中的所有事件;

  • 异步 LLM 监督器:可基于特定行为判断是否终止代理运行,并可使用不同于主代理的 LLM 模型进行判断。

附录 A.2 提供了监督器提示语的示例及其控制权限说明(见原文链接)。由于当前系统不更新模型权重,模型难以通过思维链隐藏信息(如隐写术),因此可观测性机制在当前系统中具有较强的安全部署效果。

但作者也指出,如果未来系统引入模型权重更新机制,仅靠可观测性将不足以应对所有风险,还需进一步研究其他安全机制。

2. 基于评估的迭代更新机制

作者提出,可以在迭代更新过程中引入安全性评估指标。虽然当前的基准测试集主要关注能力提升,但未来完全可以在每次迭代前加入安全性验证,确保代理在进入下一阶段前满足安全标准。

结论

作者认为,本研究不会带来显著的负面社会影响,其目标主要集中在提升代码编辑机制和多步推理能力等方面。

Appendix A Agent Prompts

本节介绍了主代理(Main Agent)及其如何协调子代理(Sub-Agents)来解决问题。

主代理提示(Main Agent Prompt)

主代理的职责是协调子代理,将请求路由到合适的代理,并将各子代理的结果综合成最终答案。
主代理不会直接执行任务,而是作为一个调度器和协调者

任务流程如下:

  1. 接收问题:主代理接收用户提供的完整问题陈述(Problem Statement)。

  2. 分发任务:根据问题内容,主代理将任务分配给一个或多个子代理。

  3. 传递问题陈述:确保子代理准确理解问题。如果问题陈述较长,不应重复全文,而是给出清晰指示,让子代理自行参考原始问题。

  4. 使用工具辅助:主代理可以访问文件和目录查看工具,帮助理解上下文,但不直接执行实质性操作

  5. 依赖子代理工具:主代理需根据子代理所拥有的工具列表,判断下一步应调用哪个代理。

重点说明:主代理不负责具体执行,而是通过调度子代理完成任务。子代理各自拥有特定工具,负责执行具体操作并推动任务进展。


A.1 基础子代理提示(Base Sub-Agent Prompts)

该部分描述了子代理的基本行为准则:

子代理应具备专业程序员的思维方式,遵循以下原则:

  1. 逐步推进:不要一次性写出完整的文件或解决方案,而是分步骤进行。

  2. 深入理解上下文:在开始执行前,必须彻底理解当前任务和环境背景

重点内容:强调子代理在执行任务前应先理解问题全貌,避免盲目操作。同时,强调逐步执行的重要性,以提高代码质量和可维护性。


总结:

  • 本节主要介绍主代理与子代理之间的协作机制。

  • 主代理负责任务调度和结果整合,不执行具体操作。

  • 子代理负责执行具体任务,需遵循“逐步执行”和“深入理解上下文”的原则。

  • 强调了问题陈述的传递方式、工具使用限制以及子代理的职责划分。

Appendix B Example Traces

概述

本节提供了多个示例轨迹,用于展示主智能体(Main Agent)在处理多步推理任务时的完整思考和行动过程。这些示例轨迹展示了智能体如何逐步推理、调用工具、验证结果,并最终得出答案。每个示例都包括了智能体的思考过程(Thought)、采取的行动(Action)、行动的结果(Observation)以及最终答案(Answer)。


示例 1:数学问题求解

问题:求解方程 \( x^2 - 5x + 6 = 0 \)

智能体思考过程

  • 识别这是一个一元二次方程。

  • 使用求根公式:\( x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a} \)

  • 代入 \( a = 1, b = -5, c = 6 \)

行动

solve_quadratic(1, -5, 6)

结果: 返回两个解:\( x = 2 \)\( x = 3 \)

结论: 方程的解为 \( x = 2 \)\( x = 3 \)


示例 2:逻辑推理题

问题:如果 A 比 B 高,B 比 C 高,那么谁最高?

智能体思考过程

  • 分析句子结构,提取逻辑关系。

  • 推理出 A > B > C,因此 A 最高。

行动: 无工具调用,直接逻辑推理。

结论: A 最高。


示例 3:数据查询任务

问题:2023 年中国的 GDP 是多少?

智能体思考过程

  • 需要查询外部数据源。

  • 调用 API 获取最新 GDP 数据。

行动

query_gdp(year=2023, country="China")

结果: 返回数据:12,666 亿美元(名义 GDP)

结论: 2023 年中国 GDP 为约 12,666 亿美元。


示例 4:多步推理任务

问题:某商品原价 100 元,先涨价 10%,再降价 10%,最终价格是多少?

智能体思考过程

  • 第一步:计算涨价后的价格:100 × 1.10 = 110 元

  • 第二步:计算降价后的价格:110 × 0.90 = 99 元

行动

final_price = calculate_price(initial=100, increase=10, decrease=10)

结果: 返回最终价格:99 元

结论: 最终价格为 99 元,低于原价。


总结

本附录通过多个示例展示了主智能体在面对不同类型问题时的完整推理过程。这些示例涵盖了数学计算、逻辑推理、数据查询和多步推理等任务,体现了智能体在实际应用中的灵活性与准确性。特别是对数学公式的正确应用和对多步操作的清晰分解,展示了智能体处理复杂问题的能力。

Appendix C Function Calling Interface

本节介绍了大语言模型(LLM)的函数调用接口,其核心功能是让LLM在运行时动态调用工具或子代理(sub-agents),而无需预先定义控制流程。

实现方式概述

  • 实现该功能有多种方法,包括:

    • 受限生成(constrained generation)

    • 在不中断生成流的情况下解析代理输出

    • 依赖LLM服务提供商或推理框架的原生函数调用功能

采用方案:无约束结构化生成

为了最大化的灵活性,作者采用了无约束结构化生成方法,具体如下:

  • LLM输出为XML格式的文本

  • 将特定的XML闭合标签(如</TOOL_CALL>)注册为停止标记(stop token)

  • 通过检查生成停止的原因,可以判断是否发生了工具调用或代理调用

  • 随后解析内容并执行相应的工具或代理

示例:工具调用语法

<TOOL_CALL>
<TOOL_NAME>tool_name</TOOL_NAME>
<TOOL_ARGS>
<arg1>value1</arg1>
<arg2>value2</arg2>
</TOOL_ARGS>
</TOOL_CALL>
  • </TOOL_CALL> 是停止标记

  • 首先解析 TOOL_NAME,用于查找可用工具

  • 然后将 TOOL_ARGS 中的参数解析为字典格式

  • 最后实例化并调用对应的工具类

格式选择:XML vs JSON

  • 选择XML而非JSON的原因:

    • XML格式不需要对字符串字面量进行转义

    • 特别适用于需要直接包含文件内容作为参数的场景,避免了JSON中繁琐的转义操作


重点总结

  • 本节核心在于实现LLM在运行时灵活调用外部工具的机制

  • 采用XML格式的结构化生成方式,通过注册停止标记来触发工具调用

  • XML格式的选择提升了处理复杂参数内容的便利性,是设计中的关键决策点

Appendix D Additional Result Details

附录 D:更多结果细节总结

本附录提供了智能代理在实验过程中逐步改进的更新记录,对应图3中的性能变化趋势。以下是按更新顺序的详细说明:


1. 智能编辑器(Smart Editor)

  • 内容:新增 SmartEditor 工具,能根据编辑特征智能选择最优文件编辑策略。

  • 重点:这是核心功能之一,为后续优化打下基础。


2. 快速覆盖工具(Quick Overwrite Tool)

  • 内容:优化文件编辑操作,提升全文件覆盖性能,减少 token 使用。

  • 重点:提升效率,减少资源消耗。


3. 差分增强型智能编辑器(Diff-Enhanced Smart Editor)

  • 内容:引入基于差分的智能策略选择和模式编辑优化。

  • 重点:显著提升编辑策略的智能性和准确性。


4. 简化 DiffVerifier 测试

  • 内容:优化开发者体验,提高测试的可维护性。

  • 非重点:属于维护性改进,非核心功能。


5. 代码上下文摘要器(Code Context Summarizer)

  • 内容:新增 CodeContextSummarizer 工具,使用 ripgrep 高效提取和总结代码上下文。

  • 重点:提升代码库探索效率,对上下文理解有帮助。


6. SmartEditor 输入归一化器(Input Normalizer)

  • 内容:新增 InputNormalizer 组件,提升编辑操作的效率和可靠性。

  • 重点:增强编辑流程的稳定性。


7. 增强型文件编辑验证

  • 内容:实现全面的文件状态跟踪系统,提升编辑效率。

  • 重点:提升系统对编辑状态的控制能力。


8. 最小差分输出优化(Minimal Diff Output Optimization)

  • 内容:通过最小化差分上下文输出,减少 token 使用。

  • 重点:优化资源使用,尤其在大文件编辑中效果显著。


9. AST 符号定位器(AST Symbol Locator)

  • 内容:集成基于 AST 的符号定位工具,实现精准代码导航。

  • 重点:提升代码理解与跳转的准确性。


10. 优化文件编辑路由(Optimized File Edit Routing)

  • 内容:在 MainAgent 中实现任务类型检测与路由优化。

  • 重点:提升系统对不同类型编辑任务的处理效率。


11. 增强文件大小优化

  • 内容:设置 100KB 文件大小阈值,优化大文件处理。

  • 重点:减少大文件处理的资源开销。


12. 混合符号定位器(Hybrid Symbol Locator)

  • 内容:结合 ripgrep 候选识别与 AST 验证的混合定位方法。

  • 重点:兼顾效率与准确性,提升代码导航性能。


13. 上下文敏感的差分最小化

  • 内容:在 SmartEditor 中集成上下文敏感的差分最小化,使用 AST 解析 Python 代码变化,其他类型文件使用模式分析。

  • 重点:显著减少 token 使用,提升编辑效率。


14. 混合符号定位器中的 AST 解析优化

  • 内容:在 hybrid_symbol_locator.py 中实现目标 AST 解析,仅处理相关代码区域。

  • 重点:提升解析效率,避免全文件解析带来的性能损耗。


总结

本附录详细记录了代理系统在文件编辑、代码导航、资源优化等方面的逐步改进过程。其中,SmartEditor、CodeContextSummarizer、Hybrid Symbol Locator、上下文敏感差分最小化等模块是提升系统性能和智能性的关键。同时,多个优化措施(如输入归一化、文件大小阈值、AST优化)显著提升了系统的效率和稳定性。