AI 摘要 · 由英文经 AI 翻译

Self-Improving AI Coding Agents Through Accumulated Behavioral Rules: A Closed-Loop Framework

Aditya Aggarwal, Nahid Farhady Ghalaty

arXiv:2607.13091v1cs.SEcs.AI

TL;DR

静态编码智能体指令 无法通过审查反馈随经验积累而演进。本文将源自人工审查的持久化规则与基于清单的自查相结合。结果显示,观察期内跟踪的错误类别均未复发,审查重心转向设计,规则也实现了跨边界迁移。

  • 问题

    静态编码智能体指令 记录了开发规范,却缺乏根据审查结果改进后续行为的反馈闭环。

    出处:§I · p. 1
  • 方法

    该框架将可泛化的人工审查反馈转化为跨会话加载的持久化行为规则,并将代码生成与基于清单的自查相结合。

    出处:C. The Feedback Loop · p. 2
  • 结果

    对 9 类错误的跟踪涵盖规则生效后累计 74 次会话暴露,观察到 0 次复发;审查重心转向设计,规则也实现了跨边界迁移。

    出处:§X · p. 8
  • 启示与局限

    人工审查知识可跨会话保留,无需微调或模型专用基础设施。

    出处:§X · p. 8

    由于缺乏对照基线或配对消融实验,所报告的错误抑制和审查重心转移仅提供初步实证证据,而非因果证明。

    出处:§VIII · p. 7

Abstract

from arXiv · show

LLM-based coding agents repeat the same classes of mistakes across sessions because they lack a mechanism to retain corrections from human review feedback. We present a closed-loop framework in which every accepted review comment is codified as a persistent behavioral rule, progressively expanding the set of error classes the agent can self-detect. The framework combines an accumulating rule set in a version-controlled instruction file, a self-review checklist executed before code submission, and automated validation that ensures rule set integrity as it grows. In deployment across a 35+ service microservices platform, the rule set grew from 5 to 18 behavioral rules, 15+ language-specific standards, and a 15-item self-review checklist, all derived from real review feedback. We present empirical results from 11 recorded working sessions spanning code generation, PR review, incident investigation, and cross service refactoring. We observe that accumulated rules shift review effort from low-level correctness toward design-level validation, achieve a measured 0% recurrence rate for ruled-against error classes, and transfer across heterogeneous agent interfaces. We compare our approach against related work in experiential LLM learning (Reflexion, ExpeL, Voyager) and automated code review (CodeReviewer, SWE-bench agents), showing that our framework achieves persistent cross-session learning without weight updates, operates on production codebases rather than synthetic benchmarks, and addresses an orthogonal dimension (behavioral consistency over time) that existing benchmarks do not measure. The result is a coding agent that improves with every review cycle, accumulating the engineering wisdom of its human collaborators without changing a single model weight.

I. 引言 · A. 范围与定位

该框架将被采纳的人工审查反馈转化为持久化行为规则,存储在版本控制下的指令文件中,无需更新模型权重。它针对特定代码库中编码智能体的已知失误模式,旨在辅助人工审查,而非保证语义正确性。

I. 引言

  • 编码智能体会在不同会话中重复已被审查指出的错误,而微调、RAG 和静态指令 均缺乏审查驱动的行为反馈闭环。文中指出,微调成本高,且针对特定组织;RAG 提供代码上下文而非行为约束,静态指令 则不会随经验积累而演进。出处:§I · p. 1
  • 被采纳的审查意见转化为持久化自查规则,使框架力求预防的错误类别单调扩展。所提出的行为规则累积方法旨在将可避免的审查意见降至零。出处:§I · p. 1

A. 范围与定位

  • 版本控制下的指令文件提供了不依赖模型和工具的操作记忆,无需更新权重。这一共享载体可供团队成员复用并立即部署;该框架既不涉及重新训练,也不涉及基于人类反馈的强化学习(RLHF)。出处:§I · p. 1, A. Scope and Positioning · p. 2

I. 引言

  • 11 次有记录的工作会话涵盖代码生成、PR 审查、跨服务重构和故障调查,用于考察规则累积、错误类别抑制和知识迁移。论文介绍了系统架构,并报告了生产部署中的定量实证结果。出处:§I · p. 1
  • 通过与 Reflexion 、ExpeL 、Voyager [15]、CodeReviewer 和 SWE-agent [16] 比较,论文将跨会话持久的行为一致性定位为现有基准遗漏的一个维度。比较涵盖基于经验的 LLM 学习和自动化代码审查。出处:§I · p. 1

A. 范围与定位

  • 组织记忆完全源于被采纳的审查结果,将个别纠正转化为特定代码库内面向错误类别的行为约束。与静态指令不同,指令文件直接根据审查结果扩充,每条新规则都可追溯至一条被采纳的具体意见。出处:A. Scope and Positioning · p. 2
  • 该框架通过针对已出现的错误来辅助人工审查,但既不能证明语义正确性,也无法防止所有可能的失误。其预期收益是让审查者腾出精力关注更高层次的问题。出处:A. Scope and Positioning · p. 2

II. 框架架构 · A. 结构化指令文件 · B. 规则表示

该框架将已采纳的审查意见转化为持久化行为规则,保存在受版本控制的指令文件中,并在每次会话时加载。结构化规则表示将审查来源与自查清单条目关联起来,并为未来的验证工具提供支持。

II. 框架架构

  • 每条已采纳的审查意见都会转化为持久化行为规则,持续扩展智能体在后续会话中的自查能力。Figure 1 展示了这一闭环反馈过程。出处:Figure 1 · p. 2

A. 结构化指令文件

  • 智能体在每次会话开始时,都会加载受版本控制的 Markdown 指令文件作为系统上下文。遵循这一约定的文件包括 AGENTS.md、规则文件和指令文件。出处:A. The Structured Instruction File · p. 2
  • 指令文件便于追加内容,且规模单调增长:通过新增规则、偶尔细化规则来积累工程判断,极少删除规则。这种积累性被视为该文件的关键属性。出处:A. The Structured Instruction File · p. 2
  • 实际部署中,指令分为行为规则、代码规范、自查清单、反模式和工作流规则。这些内容涵盖操作安全边界、特定语言的审查经验、代码批准前的检查、禁用模式及替代方案,以及按任务触发工具或子智能体的条件。出处:A. The Structured Instruction File · p. 2

B. 规则表示

  • 人类可读的 Markdown 规则隐式编码了标识符、类别、来源、适用范围、约束、理由、清单映射、添加日期和审查溯源信息。示例规则 R17 涉及新增内部 HttpClient 注册,并映射到自查条目 #9。出处:B. Rule Representation · p. 2
  • 规则模式将规则与其源头审查事件及自查清单条目关联起来,同时支持未来的冲突检测和有效性评分。清单映射在指令文件与提交前检查之间建立了可验证的联系。出处:B. Rule Representation · p. 2

C. 反馈闭环 … F. 以工作区验证保障可靠性

该框架将具有普适性的人类审查反馈转化为持久化行为规则,逐步扩展智能体跨会话的错误自检能力。规则治理与会话启动时的自动验证共同维护不断扩充的指令集。

C. 反馈闭环

  • 经采纳的审查意见若指出具有共性的错误,就会转化为持久化规则,扩展智能体在后续会话中可自行检测的错误类别。这一循环依次包括代码生成、基于检查清单的自查、人工审查、添加规则以及重新加载更新后的指令。指令文件跨会话、模型和工具边界保存组织记忆。出处:C. The Feedback Loop · pp. 2–3

D. 规则生命周期与治理

  • 工程师将可能再次出现的错误提炼为规则,并在保留规则 ID 的前提下,直接修订范围过宽或过窄的规则。由接收反馈的工程师判断,该错误是否可能在其他情境中再次出现。出处:D. Rule Lifecycle and Governance · p. 3
  • 定期审查通过让具体规则涵盖一般规则来消除冗余,团队则通过代码仓库的拉取请求审查流程解决规则冲突。对共享指令文件的修改必须通过拉取请求进行。出处:D. Rule Lifecycle and Governance · p. 3

E. 规则示例

  • 规则禁止调用方释放由工厂创建的 HttpClient 实例,要求使用结构化日志模板,并规定以 !A && !B && !C 表示否定条件的合取。这些规则源于审查中发现的资源生命周期、日志消息插值和布尔守卫子句错误等问题。出处:E. Illustrative Rule Examples · p. 3
  • 其他规则要求使用 ?? throw new ArgumentException(...) 进行显式空值校验,并为每个新增的 HttpClient 注册添加 SSRF 策略条目。审查者发现了使用空值宽容运算符的问题,以及某个内部 HTTP 客户端注册缺少对应 SSRF 允许列表条目的问题。出处:E. Illustrative Rule Examples · p. 3

F. 以工作区验证保障可靠性

  • 会话启动验证检查智能体定义、技能指令、知识时效性、指令文件完整性、自动化脚本和工具服务器配置,防止新增内容不合规范。检查要求前置元数据有效且包含必填字段、技能指令结构正确、具备时效性日期和必需的指令章节、脚本确实存在,以及工具服务器配置格式正确。出处:F. Workspace Validation as Reliability… · p. 3

G. 会话连续性 … C. 知识来源分布

部署中通过会话交接和任务日志保留进行中工作的上下文,不同界面的智能体共用同一份指令文件。在所分析的学习来源中,人类评审反馈占 39%。

G. 会话连续性

  • 会话交接文件在会话之间保留进行中的工作、待处理的评审和建议的后续行动。这使保留的知识从行为规则扩展到进行中工作的上下文。出处:G. Session Continuity · p. 3
  • 任务日志按时间顺序记录已完成的工作,作为会话交接的补充。这两种机制共同支持会话连续性。出处:G. Session Continuity · p. 3

A. 环境

  • 部署环境包含 35+ 个服务和约 50,000+ 行共享基础设施代码,采用托管容器编排和服务网格。多个界面中的智能体读取同一份指令文件。出处:A. Environment · p. 3
  • 智能体支持代码生成、评审、架构分析、事件响应和跨服务重构。这些活动通过部署平台中的多个智能体界面开展。出处:A. Environment · p. 3

B. 规则随时间累积

C. 知识来源分布

D. 观察到的效果 … A. 实验设置

新增规则后的 11 次有记录的会话中,观察窗口内未再出现规则明确禁止的模式。审查者反馈,在机械性问题上花费的时间减少,更多精力转向架构合理性和设计权衡。

D. 观察到的效果

  • 新增规则后的 11 次有记录的工作会话中,观察窗口内未再出现规则明确禁止的模式。这表明相关模式在所观察的部署条件下受到抑制,并不意味着底层模型永久具备这一特性。出处:D. Observed Effects · p. 4
  • 审查者反馈,在机械性问题上花费的时间减少,更多精力转向架构合理性和设计权衡。出处:D. Observed Effects · p. 4
  • 新团队成员立即继承了积累的规则集,无须经历最初形成这些规则时的学习过程。出处:D. Observed Effects · p. 4
  • 随着规则集从宽泛指令演变为精确要求,具体、可执行的规则比一般性指导得到了更可靠的遵循。出处:D. Observed Effects · p. 4

E. 规则冲突:具体示例

  • 对所有 IDisposable 对象统一使用 using 声明的要求,与不释放工厂创建的 HttpClient 实例的要求之间存在一处冲突,最终通过缩小通用规则的适用范围得以解决。代码审查发现了这一矛盾,解决依据是框架的正确行为,而非主观判断。出处:E. Rule Conflicts: A Concrete Example · p. 4

F. 跨界面的行为迁移

  • 积累的规则可在 IDE 集成式智能体与终端式智能体之间即时迁移,因为两种界面都加载同一份指令文件。IDE 智能体擅长代码仓库分析,终端智能体擅长执行任务;两者均同等受益于积累的规则。作者认为,这可为专业化多智能体工作流提供共享记忆, 。出处:F. Multi-Interface Behavioral Transfer · p. 4, D. Observed Effects · p. 4

A. 实验设置

  • 部署平台由 35+ 个服务组成,两种智能体界面读取同一份共享指令文件。平台包含 13 个自定义智能体定义、10 项操作技能和 6 份共享知识文档。数据来源包括 11 条带日期的任务日志、2 个已提交的指令文件修订版本及持续的本地增补、4 份专题记忆文档,以及覆盖 6 个代码仓库的 36 次 PR 审查。出处:A. Experimental Setup · p. 4

B. 规则积累动态 … E. 知识迁移模式

部署期间,规则建立后未记录到错误复发,审查意见则集中于架构、API 设计和性能。规则增长逐渐放缓,多数有记录的知识迁移跨越了仓库或工具边界。

B. 规则积累动态

C. 错误类别复发分析

D. 审查意见类别转变

E. 知识迁移模式

F. 规则具体性的演进 … A. 研究发现总结

在观察期内,部署中跟踪的已纠正错误类别均未复发,同时观察到知识在工具、代码仓库和任务类型之间迁移。规则逐步细化,三层持久记忆占用的上下文不足 128K 窗口的 5%。

F. 规则具体性的演进

G. 多层记忆架构

H. 会话任务多样性

A. 研究发现总结

  • 在不改动模型的情况下,从已采纳的人工审查反馈中提炼出 18 条行为规则、15+ 条语言专用代码规范,以及含 15 项的自审清单。这些内容存储在受版本控制的指令文件中,供多个智能体接口读取使用。出处:A. Summary of Findings · p. 5
  • 在为期四周的部署中,跟踪的 9 类错误在规则引入后累计 74 次会话暴露中,观察到 0 次复发。这一观察结果并非统计保证:部署仅覆盖一个团队和一种主要编程语言,且未设置 A/B 对照。出处:A. Summary of Findings · p. 5
  • 观察到的知识迁移事件中,60%(9/15)跨越了代码仓库、工具或任务类型的边界。通过一个接口添加的规则,会在使用另一接口的会话中立即生效。以纯 Markdown 编写的声明式自然语言约束,使知识能够迁移至将该文件加载为系统上下文的智能体。出处:A. Summary of Findings · p. 5

B. 契合点与贡献 … C. ExpeL:跨任务经验学习

该框架将人类评审中采纳的反馈转化为持久、可审计的规则,并通过标准工程流程管理。这些规则不同于 Reflexion 的情景式自我反思,也不同于 ExpeL 自主提取的经验。

B. 契合点与贡献

  • 该框架将不依赖特定厂商的智能体融入代码评审,通过记录规则的来源、负责人、变更历史及其在提交前检查清单中的位置,使组织知识可审计。每条规则均可追溯到对应的评审事件、采纳该评论的工程师,以及引入该规则的拉取请求。出处:B. Match and Contribution · p. 6
  • 可部署的指令文件依托标准基础设施,整合规则模式、生命周期、验证机制和反馈闭环,无需微调、模型专用工具或专门的记忆后端。部署使用 Git、Markdown、拉取请求评审和纯文本验证脚本,使组织能够利用现有基础设施复现这一模式。出处:B. Match and Contribution · p. 6
  • 实证证据仅来自一个团队、一种语言和四周的观察,且无对照基线;文中还记录了规则冲突与生命周期治理方面的挑战。论文报告了一个具体的规则冲突及其解决方式,并讨论了治理问题和影响实证有效性的因素。出处:B. Match and Contribution · p. 6
  • 在部署期间观察到的 PR 评审评论中,66% 涉及架构、API 设计或性能,14% 涉及机械性正确性。此前已纠正的错误类别在该时段内得到抑制。积累的规则也可作为可迁移的入职资料,让新成员了解组织的评审历史。出处:B. Match and Contribution · p. 6

A. 比较框架

  • Table X 按关键维度组织相关工作的比较。所提供的段落提到了该比较表,但未给出单元格中的具体值或排名。出处:A. Comparison Framework · p. 6

B. Reflexion:会话内的语言强化

  • 据报告,Reflexion 在 HumanEval 上的 pass@1 达到 91%;它将针对任务反馈的语言化反思存入情景记忆。论文将 Reflexion 自行生成、局限于单次任务经历的反馈,与经人类采纳并在后续会话中加载的规则作对比;后续会话还可能使用不同模型或智能体接口。论文认为两种机制互补,同时区分了孤立问题上的通过率与多样化生产任务中对错误类别的抑制。出处:B. Reflexion: Verbal Reinforcement… · p. 6

C. ExpeL:跨任务经验学习

  • 经人类验证的规则具有可追溯的专家评审来源,并能在本质不同的任务类型间迁移,这使其区别于 ExpeL 自主提炼的经验。ExpeL 自主收集经历、提取自然语言经验,并在同类任务内迁移。论文认为,人类验证至关重要,因为将错误规则作为权威上下文加载,可能导致错误在不同会话间被放大。出处:C. ExpeL: Experiential Learning Across… · p. 6

D. Voyager:持久化技能库 … H. 记忆增强的 LLM 系统

该框架将持久化的声明式行为规则与可执行技能库、通过权重训练的审查模型、单一上下文内的自我改进及问题解决基准区分开来。其记忆由纳入版本控制、便于人类阅读的 Markdown 规则构成。

D. Voyager:持久化技能库

  • Voyager [15] 存储可执行的 Minecraft 技能,而该框架存储声明式自然语言约束;两者均利用持久化、纳入版本控制的知识来持续积累能力。Voyager 的技能库由可执行的代码函数构成。出处:D. Voyager: Persistent Skill Libraries · p. 6

E. 预训练代码审查模型

  • 与预训练审查模型, 不同,该框架通过上下文注入规则,实时积累知识,并记录组织特有的规范。对比模型通过微调权重学习,知识在训练时即已固定,侧重跨公共代码仓库的泛化,而非学习公共代码库中不可见的内部规范。出处:E. Pre-trained Code Review Models · p. 6

F. SWE-bench 智能体

  • 最先进的智能体可解决 SWE-bench Lite 中 20–40% 的问题;SWE-bench 及智能体实现 [16],, [20] 评估的是单个 GitHub 问题的解决能力。这是作为背景介绍的基准性能,并非所提框架的实测结果。出处:F. SWE-bench Agents · p. 7
  • 该框架旨在避免已知错误并保持长期行为一致性,作者指出,现有基准并未评估这一维度。相比之下,SWE-bench 关注智能体能否解决某个问题。出处:F. SWE-bench Agents · p. 7

G. Self-Taught Optimizer、Self-Refine 与 Self-Debugging

  • STOP 、Self-Refine 和 Self-Debugging [22] 均在单一执行上下文内运行,而该框架能永久保留改进成果。STOP 递归改进脚手架代码;Self-Refine 利用自身生成的评语迭代改进;Self-Debugging [22] 采用小黄鸭调试式解释。出处:G. Self-Taught Optimizer, Self-Refine,… · p. 7

H. 记忆增强的 LLM 系统

  • 与 MemoryBank 及相关记忆系统相比,该框架采用更简单的存储形式:纳入版本控制、便于人类阅读和审计的 Markdown 规则。规则存储于纯文本文件中。出处:H. Memory-Augmented LLM Systems · p. 7

I. 具有持久记忆的个人 AI 助手 … A. 有效性威胁

该框架将已采纳的代码审查反馈转化为共享行为约束,并遵循六项设计原则。现有证据仍属初步,对照设置、统计功效、部署多样性和长期观察均有限,扩展性与审查质量风险也尚未解决。

I. 具有持久记忆的个人 AI 助手

  • OpenClaw 为单个用户记忆对话事实;与之不同,该框架从已采纳的代码审查反馈中提炼团队级声明式约束,以预防特定类别的错误。OpenClaw 为个人 AI 助手提供持久记忆和技能库。出处:§I · p. 7

VII. 设计原则

  • 具体性比率从 0.60 升至 0.78;六项原则强调单调增长、具体性、来源追踪、工具无关的编码、经验证的增长和共同维护。具体约束优于抽象指导;规则可以细化,但不会删除,且可追溯至审查意见或生产事件。结构化 Markdown 已跨 2 个平台迁移;新增规则须经自动验证,并通过共享代码仓库中的 PR 进行变更。出处:§VII · p. 7

VIII. 局限性与有效性威胁

  • 当前 ∼6,250 个 token 尚未超出上下文限制,但规则无界增长和多团队治理仍是尚未解决的扩展性约束。更大的规则集可能需要分层组织或摘要;多个团队需要分层或按命名空间划分的规则,以及明确的冲突解决策略,以避免碎片化或相互矛盾。曾有一次冲突需要人工识别,这表明有必要引入自动冲突检测。出处:§VIII · p. 7
  • 采用该框架需要已采纳的书面审查反馈、工程师投入时间将其编写为规则,以及能够加载并遵循项目级指令的智能体接口。缺少任何一项前提,都可能使反馈循环失去输入,或导致规则被忽略。作者预计,对每次变更均开展同行审查的中大型工程组织最有可能采用该框架。出处:§VIII · p. 7
  • 规则引入后,9 类错误的 74 次暴露机会、6 个代码仓库中的 36 个 PR 和 11 次会话提供了初步证据,但不足以证明因果关系,也未作出正式的统计显著性声明。观察到的效果包括观察期内未出现错误复发,以及审查意见转向设计层面。研究未设置平行对照组,也未在相同任务序列上,与静态提示工程或无规则基线开展配对消融实验。出处:§VIII · pp. 7–8

A. 有效性威胁

  • 部署仅限于一个采用类型化语言且严格遵循框架约定的组织,限制了结论向其他代码库、语言及框架使用不够一致的场景推广。较弱的编译期约束或不一致的框架使用方式,可能改变审查意见的分布,并降低依靠规则抑制错误的收益。出处:A. Threats to Validity · p. 8
  • 规则质量取决于人工审查者:错误规则会放大错误,而噪声较多的审查文化可能使规则集劣化,速度甚至超过验证机制发现问题的速度。出处:A. Threats to Validity · p. 8
  • 四周和 11 次会话不足以揭示长期增长动态,规则占满可用上下文窗口后的行为也尚未得到观察。出处:A. Threats to Validity · p. 8

IX. 缺失的基准 … 未来研究方向

持久保存、纳入版本控制的规则将人工评审反馈转化为跨会话指导;在部署观察窗口内,所跟踪的错误类别未见复发。本节概述了时序评测基准、企业渐进式采用路径,以及有效性、自动化和治理方面的后续研究。

IX. 缺失的基准

  • 拟议基准检验纠错能否跨会话持续生效,关注行为随时间的一致性,而非仅衡量静态能力。该基准结合了从评审中提炼的精选规则集、触发禁用模式的种子任务,以及检验纠错能否跨会话边界持续生效的任务序列。这一时间维度可补充 SWE-bench、HumanEval 和 CodeReview 基准。出处:§IX · p. 8

X. 结论

  • 持久保存、纳入版本控制的规则将人工评审反馈编为规范,无需更新权重或依赖特定模型的基础设施,即可使可自检的错误类别单调增加。规则集从 5 条扩展至 18 条行为规则,另有 15+ 项代码规范和一份含 15 项的自检清单。无需微调,也无需修改现有 LLM 架构。出处:§X · p. 8
  • 规则生效后,9 类受跟踪错误累计有 74 次会话暴露,观察窗口内未见复发。生产部署覆盖 35+ 个微服务,共记录 11 次会话。这是一项观察性结果,文中明确说明了其局限性。出处:§X · p. 8
  • 66% 的评审意见涉及架构/API/性能,14% 涉及机械性正确性,反映出评审关注点向设计层面转移。在观察到的事件中,60% 出现了规则的跨边界迁移。出处:§X · p. 8

在企业环境中落地该框架

  • 企业可在现有工具链内,通过共享指令、评审驱动的规则提炼、自动化验证和拉取请求治理,渐进式采用该框架。纳入版本控制的指令文件包含行为规则、语言专属规范和自检清单,供所有智能体界面读取使用。将已采纳且可泛化的评审意见在同一 PR 或后续 PR 中提炼为规则,通过 CI 或提交前钩子验证格式和模式,并像评审代码一样评审指令变更。出处:Operationalizing the Framework in an… · p. 8

未来研究方向

  • 未来评估应将加载规则的智能体与无规则基线比较,并在不同组织中开展复现研究,检验有效性及其适用边界。拟议的 A/B 研究采用相同的输入任务流,并预注册评审意见数量、缺陷逃逸率和评审者任务耗时等指标。复现研究应覆盖不同编程语言、代码库规模和评审文化,并结合跨会话行为一致性基准。出处:Future Research Directions · p. 8
  • 未来工具应从相似评审意见中提出候选规则,在合并前检测冲突,并支持多团队规则组合与来源追踪。治理模型应防止隐性矛盾,并在规则从团队范围推广至整个组织时保留其来源记录。出处:Future Research Directions · p. 9
Loading 2607.13091v1…