小改动才进得去：彭博用智能体每天提一条质量请求

本文是论文 Pomona: Continuous Code Quality Improvement via Small, Agentic Pull Requests at Bloomberg（arXiv:2606.06752）正文第 I 节至第 VI 节及数据可用性声明的中文译文，由智测团队翻译。作者是伦敦大学学院的 David Williams、彭博的 Angelos Evripiotis、Serkan Kirbas、Sergey Magidovich、Harry Morgan、Peter Wainwright，以及伦敦大学学院的 Federica Sarro。参考文献未逐条展开。这是工业经验论文，不是公开基准。代码、数据和所用模型因保密协议不能公开。问卷补充材料见 https://figshare.com/s/09a23c22550f3e3967b2 。

摘要

这篇工业经验论文介绍 Pomona，一个用智能体技能做持续代码质量改进的轻量工具。它受 Kaizen 持续改进思路启发，把发现和增量修复做成一个循环：扫描技能找出任务并排进待办，修复技能生成小而容易评审的拉取请求。这样可以频繁做低风险改进，同时保住工程师的信任，并压低技术债。作者在彭博做了三个月的团队部署，并向资深工程师发了问卷。结果是：39 个拉取请求里合并了 32 个（82.1%），关闭时间的中位数刚过两小时。受访的 12 人里有 10 人表示想采用 Pomona，称赞的是差异小、以及它盯着代码质量。评估之后，另一个团队也采用了。文末给出在工业里部署智能体的可操作经验。

关键词：软件质量；技术债；面向软件工程的人工智能；智能体。

I 引言

大语言模型集成和智能体方案在软件工程里成熟之后，组织越来越想找可靠办法，改善员工的开发过程。有的研究说，基于大模型的软件工程工具显著加快了开发速度。也有研究观察到，用了大模型的开发者做日常任务反而更慢，却以为自己更快。He 等人发现，开源仓库采用智能体后，开发速度只是暂时上升，代价是更长期的代码复杂度和质量问题上升。

图 1 是 Pomona 的总览。职责分成两个智能体技能，都和一个结构化任务待办交互。左边的扫描技能发现任务并填入待办；修复技能挑选最高优先级任务，生成一条小而容易评审的拉取请求。

为调和短期速度和长期可维护性之间的张力，作者提出一个受 Kaizen 启发的智能体方案，名叫 Pomona。Kaizen 是日语，也是一套商业方法：用增量、持续的改动促进持续改进。智能体技能是用户定义的指令，让自主智能体能处理专门、可重复的工作流。Pomona 有两个这样的技能：一个识别代码质量改进任务，一个处理这些任务。它建立并维护一份结构化、排好优先级的待办。任务来自采用者定义的多个来源，例如静态分析器、行内技术债标记、测试覆盖缺口，以及偏离项目编码规范的地方。每次从待办里挑最高优先级的一项，Pomona 生成很小的拉取请求，目标大约是 10 行差异，然后更新待办，再重复。它用三点应对高效采用人工智能时的需求和困难。第一，摩擦低：发现任务和生成补丁是后台自主工作流，工程师不必改自己的开发活动。第二，赌注低：人在回路里评审，没有工程师批准，Pomona 的贡献进不了代码库；拉取请求很小，批准过程对工程师也更简单。第三，盯着代码质量：Pomona 引入的改动，更可能有利于代码库的长期可维护性。

Pomona 已经在彭博使用，早期印象正面。为评估实际价值，作者做了混合方法研究。先人工审计第一个采用团队在三个月部署里由 Pomona 生成的 39 个拉取请求。接受率和效率都高：39 个里成功合并 32 个（82.1%）。被接受的那些里，有 25 个除了强制评审之外不需要其他人的交互。关闭时间中位数是 2 小时 14 分钟。作者再用问卷补充：问卷发给 12 名尚未使用 Pomona 的资深工程师。12 人里有 10 人表示想试这个工具，尤其看重差异小（10/12）和聚焦代码质量（10/12）。写作时，第二个工程团队已经采用，并计划在彭博内更广地分发。后文详述实现，并给出在大规模工业环境里部署智能体式软件工程人工智能的实践策略。

II Pomona 概览

图 1 把 Pomona 画成两个智能体技能。扫描技能（第 II-B 节）在目标仓库里识别代码质量改进任务，编成结构化、排好优先级的待办。修复技能（第 II-C 节）从待办里选最高优先级任务，生成一条新的拉取请求供人评审。用智能体技能这种载体，实现很简单：修复技能、扫描技能和结构化待办，各自是一份 Markdown 文件，可以接到当前任何智能体产品上。这种格式也使 Pomona 与编程语言无关。作者评估的具体实现（第 III-A 节）针对的是 Python。

下面各节说明每个组件，以及它们如何循环组合成持续的代码质量改进环。

II-A 排好优先级的任务待办

结构化的代码质量改进待办，处在扫描技能和修复技能中间。扫描技能往里填排好优先级的改进任务；修复技能消费这些任务，生成供人评审的改进拉取请求。图 2 是待办摘录。

待办任务按优先级组 P1 到 P4 分类。分组定义在表 I 的「收益 × 易评审程度」矩阵里。采用 Pomona 的工程师可以改扫描技能的规定，定义在自己的开发情境里什么算高收益。一条经验是：能抓住缺陷的改进，应优先于化妆式改动。例如，禁止可变默认参数的规则，比调整导入顺序更有价值。作者在第 III-A 节评估的那次实现里，扫描技能规定写的是：高收益改动会抓住真实缺陷或防止未来缺陷（可变默认值、循环变量捕获、缺失的异常链）；减轻维护负担（删掉死代码、修正误导性注释）；或改善开发者体验（更好的错误信息、更清楚的代码）。

采用工程师也可以用类似过程定义什么算容易评审。这次实现的扫描技能里写的是：如果改动是完全自动的（自动修复、格式化），是机械且重复的（评审者可以快速扫过），范围小（单个文件或单条规则），或者不引入行为变化，就算容易评审。

最初设计把待办存在仓库根目录的一份 Markdown 文件里。好处是待办集中，并和代码库一起做版本管理。作者也指出，待办也可以通过模型上下文协议接到 Jira 这类项目管理软件上。

表 I：任务管理的优先级矩阵

II-B 扫描：识别修复任务

扫描技能自动发现并排列新的代码质量改进任务。它作为修复技能（第 II-C 节）的一部分执行，具体是在待办里高优先级任务变少的时候，也就是 P1 和 P2 两类都空了。为补待办，扫描技能并行启动多个子智能体，各自探索不同的发现区域。子智能体的数量和用途应由采用者按需要定义。全部子智能体搜完后，输出合并成排好优先级的待办任务。

在作者这次实现里，定义了三个不同的子智能体。子智能体 1 做 ruff 规则扩展，以及 mypy 的严格类型检查扩展。ruff 是 Python 的代码检查器和格式化器，mypy 是 Python 的静态类型检查器。子智能体 2 在代码库里搜索写成 TODO、FIXME、HACK、XXX 的待办，并按下列指南分类：代码其实已经做完、注释只是自我说明的，标为 P1；解法明显的清楚修复，标为 P1 或 P2；还需要领域调查的修复，标为 P3；愿望式注释标为 P4。子智能体 2 还搜索与周围代码矛盾的注释，并用这些办法找死代码：未使用的导入、被注释掉的代码块（连续注释行远多于 3 行），以及提前返回之后到不了的代码。子智能体 3 比较源模块和单元测试模块，找出没有测试的模块，从而识别覆盖缺口。它优先纯逻辑、没有数据依赖的模块，因为这些最容易测；也优先分支逻辑复杂的模块，因为这些价值最高。此外，子智能体 3 检查是否遵守仓库定义的编码规范（通常在智能体配置文件里），并寻找可以拆小的长函数，也就是超过 50 行的函数。

全部智能体搜完后，扫描技能分两步汇总。第一步列出并拼接发现，去掉重复。第二步按表 I 的优先级矩阵和第 II-A 节的规则，给每条独特发现分优先级。

分完优先级后，任务转换成图 2 的待办条目格式，加进对应优先级类别。这时就可以交给下一节的修复技能。

II-C 修复：处理扫描找出的任务

修复技能是 Pomona 的入口。它是一个智能体技能，可以由用户执行，也可以配置成周期性触发，例如每天一次。

第一步让智能体读取目标仓库根目录的任务待办。如果待办文件不存在，或者高优先级（P1 和 P2）类别是空的，就先执行扫描技能（第 II-B 节），然后回到修复技能的剩余步骤。

待办里有任务时，下一步是从最高优先级类别里选第一条。如果一条下面还有子项（如图 2），指令规定选第一条子项。

下一步是实现修复，有几条规则。第一，任何改动都要用项目的测试和代码检查命令验证，命令由采用团队指定。第二，改动必须小：目标是很小、容易评审的拉取请求，智能体应瞄准大约 10 行差异。超过了，就按采用团队提供的策略拆开。这次实现里的一个策略是：一次只为一个目录启用检查规则或补测试，再把其他目录的后续项加回待办。

代码改完并验证后，智能体更新待办：删掉已完成的任务，如有后续任务就加上。待办存在仓库里，不必另维护一份完成日志，项目的 git 历史会记下待办随时间的变化。

代码和待办都改完后，智能体提交。提交说明里要写清这次改动的动机，并链到相关资料，方便以后的人在翻项目历史时理解这些自动改动。

修复技能的最后一步问用户要不要生成拉取请求。要的话，智能体就按仓库的标准模板创建一条。作者的实现用的是彭博内部的模型上下文协议集成。这一步是否询问，取决于控制方式：如果技能是周期性自主触发（例如每天一次），而不是工程师发起，就跳过这个选择，前面的步骤一完成就创建拉取请求。标题是一句话，概括改进了什么、为什么重要，并加特定表情前缀，标明这是人工智能生成的。描述要求先写对工程师的具体结果。只有在能超出标题提供额外价值时，才加其他小节。例如，只有标题本身说不清改动时才写「改进」；只有做了超出项目标准测试命令的特殊测试时，才写「测试与检查」。

III 早期观察与评估

评估是混合方法：分析一个团队在三个月采用期里由 Pomona 生成的拉取请求，并向尚未使用的人发问卷，看他们对这个概念有没有兴趣。

III-A 分析 Pomona 的拉取请求

作者用第一个采用团队在三个月里由 Pomona 生成的拉取请求，评估早期影响。期间 Pomona 生成了 39 个拉取请求，团队全部关闭了，要么合并，要么拒绝。作者对每个请求手工抽取标准化元数据，包括所解决问题的优先级（P1 到 P4）和性质（也就是来源）。为衡量复杂度，记录差异大小（文件数和代码行数），以及改动是否导致待办里增加了子任务。最后观察每个请求的结果和评审动态：是否合并，从创建到关闭的时间，评审次数和非评审评论数，合并前是否需要后续提交。被拒绝的，记下团队给出的明确理由。

III-A1 结果

评估期大约三个月，从 2026 年 3 月中到 6 月中。团队希望完全控制仓库里人工智能生成拉取请求的数量，所以每条新请求都由一名团队成员手工执行修复技能，由扫描技能决定处理哪类任务、按什么顺序。团队的目标是「每天一条 Pomona 拉取请求」。扣除公共假期和团队假期后有 55 个工作日，他们大体做到了，产出 39 条。总接受率是 82.1%（32/39）。

优先级方面，Pomona 生成的请求里 31 条是 P1，其余 8 条是 P2。其他优先级组里也有任务，但三个月里 P1 和 P2 一直够用，没有轮到它们。多数（26/39）处理的是 ruff 规则违反。其余包括补单元测试（5 条）、删除死代码（3 条），以及其他仓库特定任务（5 条）。值得注意的是，有 6 条是团队成员直接要求的：他们在别的拉取请求里手工加了对应的待办条目。这说明，把待办放在仓库根目录、让人能够改，提供了灵活性。

七条被拒绝的请求里，四条是因为「竞态」：人还没评审，Pomona 又执行了一次，产生重复请求。重复的被拒绝，原来的被接受。针对这个疏漏，作者改了 Pomona，让它跳过已经被当前未合并请求处理的任务。剩下三条拒绝里，两条是因为格式不理想，最后一条团队没有评论就关了。

32 条被接受的请求里，28 条按原样接受，人类评审者不需要再补提交；25 条除了合并前的强制人工评审之外，没有评论或其他交互。这个大体正面的结果说明，Pomona 处理的任务范围通常小到只需要简短评审。与这种低复杂度相符，关闭时间（合并或拒绝）的中位数只有 2 小时 14 分钟。周转一直很快：39 条里有 25 条（64.1%）在 4 小时内解决，29 条（74.4%）在当天解决，33 条（84.6%）在下一个工作日解决。两端都有离群值：重复请求被关掉时最短 1 分钟；团队评审能力特别低的时候，最长四个工作日。关闭时间的总体分布支持作者的说法：Pomona 摩擦低，能嵌进既有工作流，没有显著的认知负担。

Pomona 请求的大小跨度很大。所有大小指标（改动的文件数和行数）都不计待办本身的改动，只看对代码库的影响。改动文件数的中位数是 4，平均数是 6.5，最少 1 个，最多 35 个。更让人担心的是改动行数，按增加行与删除行之和计算。中位数是 37，平均数是 57.7，范围从 5 到 168。修复技能的原始实现明确写了 10 行差异，但在处理重复性重构时，智能体有时守不住这个上限。尽管偏离了，超过 100 行的九条请求里，超过一半在同一个工作日内被合并。这说明，当目标改进很直观时，更大的请求也可以处理。这里更大的请求通常是把同一条 ruff 规则一次用到整个文件或子目录。基于这些经验，采用团队后来把 Pomona 的大小上限提高到 100 行，并用确定性检查强制执行：超过上限就自动拒绝。作者也指出，大小作为指标有局限，需要更好的代理来估计评审工作量，这是重要的未来方向。

最后，被接受的请求里有六条往待办加了新任务。其中一条触发了扫描技能，新增 8 个任务。另外五条加的是与手头任务直接相关的子任务，以免改动范围大到不好评审。

III-B 非用户问卷

为了解人们对这个概念有没有兴趣，作者做了一份问卷发给工程师。具体对象是彭博开发者体验（DevX）团队里的工程师，因为他们对组织的开发工具理解更深。问卷有 12 个问题。前五个覆盖人口统计：职位、从业年限、对面向软件工程的人工智能工具的熟悉程度。然后给参与者看图 1，并配一段 Pomona 的高层描述，接着是七个问题：工具看起来是否有用（若无用，为什么）；如果采用，每周愿意评审多少条拉取请求；哪些功能看起来最有价值；希望 Pomona 处理哪类任务；最后可以补充意见以打磨概念。问卷放在补充材料里。

III-B1 结果

共 12 人完成问卷。其中两名团队负责人，九名资深软件工程师，一名软件工程师。七人从业超过 10 年，四人 4 到 10 年，一人 1 到 4 年。人工智能辅助开发（也就是集成开发环境里的工具）方面，九人说每天用，一人每周，一人每月，一人从不用。智能体工具（例如自动生成和评审拉取请求）方面，六人每天用，两人每周，三人每月，一人从不用。

看到 Pomona 的概念后，多数人（9/12）觉得有用，更多人（10/12）说以后想试。如果采用，多数人（8/12）愿意每周评审 2 到 3 条，只比第 III-A 节那个采用团队观察到的每周 3 到 4 条略少。其余回答是分开的：一人愿意每周多于 5 条，一人愿意 4 到 5 条，其余两人偏好每周 1 条或更少。在概念里描述的功能中，差异小和聚焦代码质量改进都被 10/12 的人称赞；7/12 的人重视自动识别并完成任务。这些回答说明，多数人欣赏 Pomona 的形式，但对自动选任务和排优先级，需要很高的信心和控制。

参与者希望 Pomona 处理的任务里，六人提到待办和过时注释，六人提到静态分析或代码检查问题，三人提到简单修缺陷，另有三人提到依赖管理，似乎是因为他们信任智能体能自主处理这个范围的问题。还有人提到文档、测试（会是「拉取请求大小上限的唯一例外」）、性能修复，以及删除死代码。

也有几人指出缺点和以后可以改进的地方。他们担心评审过载，怕 Pomona 只是「制造更多要真人处理的未合并请求」，或产生「无偿搅动」：任务技术上成立，但「没重要到值得在意」。另一人指出，「有时代码坏味道需要大规模重构，这看起来超出 Pomona 的范围」。尽管如此，仍有 10/12 的人想试这个工具。作者据此认为，这些范围更小的代码质量任务之所以主要被忽略，是因为工程带宽不够，而不是因为人们觉得没价值。其他回答里，信任和能动性是关键话题。几人不愿「信任人工智能的判断去发现该修的正确问题」，更偏好用户控制的方式，也就是第 III-A 节那种完全由用户触发的修复技能，而不是自主触发；这也包括想要「控制先排什么」。最后，有一位受访者希望 Pomona 能根据评审反馈迭代自己的拉取请求。作者把智能体式的拉取请求打磨看成有希望的未来工作。

IV 讨论

基于在彭博部署和评估 Pomona 的经验，作者讨论工业采用智能体式人工智能的可操作判断，并给研究者和实践者列出未来工作。

小改动有利于采用。Pomona 的早期成功，不在于解决最「难」的编码问题，而在于以高准确率、低摩擦处理高优先级、低复杂度的任务。第一次工业部署里很高的合并率说明，当前智能体可以有把握地处理仓库里的「低垂果实」，例如代码检查违反和死代码。小而直观的改动，既降低评审者的怀疑，也降低认知负荷。事实上，尽管 Pomona 表现强，采用团队仍故意把产出限制在每天最多 1 条。这说明，在人工智能驱动的开发里，人的评审带宽远比代码生成速度更是瓶颈。问卷里 10/12 的人把小差异列为最吸引人的功能，说明可评审性对接受人工智能贡献很重要。

用人工智能管理技术债。发现表明，工程师希望人工智能处理那些「被忽略」的任务：待办、过时注释、死代码和代码检查。这些任务重要，但工程师很难抽出时间手工做。Pomona 表明，智能体可以很容易地配置成对准待办、过时注释和依赖更新。这些正是本研究里工程师强烈希望自动化的地方。若干 Pomona 请求还会生成额外任务，说明人工智能可以成为持续技术债管理的催化剂，而不只是一次性工具。

排优先级和发现一样重要。静态分析工具能找出许多潜在任务，但选对要应用的改进至关重要。表 I 和第 II-A 节的「收益 × 易评审程度」策略，让智能体聚焦高收益、低摩擦的改动，使自动改动交付可感知的价值。既然人的代码评审带宽是瓶颈，未来研究的一条路可以是自动的任务相关性过滤：发展能把「相关」或「重要」的代码改动，和仅仅「成立」的改动区分开的技术。

智能体式任务分解。另一条促进工业采用的未来方向，是研究智能体如何在没有人介入的情况下，可靠地识别大任务，并拆成小而容易评审的任务。

专家的怀疑，以及人在回路里。通过基于拉取请求的形式，工程师完全控制改动是否进入代码库。这些请求用一致的模板清楚传达每次修改的目的和影响，把清楚和对工程师的好处放在前面。这种透明对建立对自动改动的信任至关重要。问卷显示，经验丰富的工程师（从业 10 年以上）仍然警惕用「智能体判断」来排任务优先级。因此，智能体方案应继续推动以用户为中心的范式，就像 Pomona 这样：工作流由用户发起，待办可以访问，影响取决于评审。

量化认知负荷。目前很难找出智能体拉取请求从有用建议变成「无偿搅动」的阈值。未来研究应从二元的「合并或拒绝」率，转向多维指标（纳入工程师的主观感受），抓住人与人工智能协作的认知负荷。这需要设计代理，来测量评审人工智能代码和人类代码时的上下文切换成本，以及核验自动改动所花的心智努力。

V 相关工作

不同领域里关于智能体技能的初步研究，已经探讨技能对任务表现的提升，包括软件工程任务；也探讨如何组织、保护，以及大规模演化技能。结果大体是：经过挑选的技能能提升表现，尤其在特定场景里；但软件工程任务上的增益仍依赖情境，总体影响仍不清楚。这些结果说明，为软件工程任务设计有效、可复用的过程性知识是困难的；在实践中部署这类技能时，需要治理和验证机制。

与先前工作不同，先前工作主要评估、生成或保护智能体技能，本文研究的是如何按用户需要，在真实工业环境里设计和接入智能体技能。所呈现的工具用技能实现低摩擦、持续、增量的代码质量改进，并通过早期采用研究说明它对用户的价值。作者还报告了部署中的实践教训。

VI 结论

这项工作介绍 Pomona。它利用智能体技能，通过自动、容易评审的改动，持续改进代码质量。早期评估包括三个月的团队部署，以及发给资深实践者的问卷。评估表明，Pomona 有潜力在对开发速度影响很小的前提下帮助管理技术债，并作为一种低赌注、高收益的方式，在软件工程里采用智能体式人工智能。

数据可用性

Pomona 在彭博内部系统和仓库里开发与评估，因保密协议不能发布数据和源代码。作者也不能透露使用了哪些人工智能服务或模型。不过，实现由三份 Markdown 文件组成：修复技能、扫描技能和待办，可以和任何语言模型组合。本文已经详述如何在实践中实现这样的工具，使学术界和实践者以后都能采用。用于用户评估的问卷已公开。