Stripe实践：自动改进的软件

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

Stripe Engineering在2026年初悄悄公布了这一数字：他们的内部代理，称为Minions，现在每周生成超过1,300个Pull Request。

每一个PR在合并前都经过人工审查，其中没有包含一行人类编写的代码。

那些Minions维护的代码库支持的年度支付量超过1万亿美元。

Stripe是乐观的情况。悲观的情况出现在GitClear对2020年至2024年间2.11亿行变更代码的分析中，该分析发现重构代码下降了60%，复制粘贴代码上升了48%，代码流失率翻了一倍——新代码在两周内被回退。

DORA报告将AI采用与更高的吞吐量和更低的交付稳定性联系起来。Stack Overflow 2025年调查显示，经验丰富的开发者报告使用AI工具时生产力下降了19%，尽管他们认为自己更快了。

这篇文章是关于这两种情况之间的差距——是什么让编码代理真正维护软件，以及是什么让同一个循环堆积成一堵墙。

2、"自动改进的软件"到底意味着什么

这个术语被过度使用了，有三件不同的事情正在发生，规划这项工作的开发者应该知道他们想要哪一个。

从Issue到PR的自动化：代理摄取Slack对话、错误报告或功能请求，并生成一个可审查的Pull Request。

Stripe Minions就是这样做的。GitHub Copilot的云代理、OpenAI Codex和Cognition的Devin也是。

使用这些工具的生产部署中，传入Bug工单的解决时间下降了30-50%。

持续维护循环：代理处理那些没人能顾上的长尾工作：依赖升级、框架迁移、文档-代码偏差、测试覆盖率缺口。

Cursor Background Agents、Claude Code的/loop（2026年3月9日）和Replit Agent 4（2026年3月11日，具有并行分叉功能，约90%的时间自动解决合并冲突）都提供了这个功能。

代码库级别的转换：在测试下进行的大规模迁移。

Amazon Q Developer现在可以在几分钟内运行.NET → Linux和Java 8 → Java 17的转换。

Augment Code的200K token上下文引擎和Sourcegraph Amp的跨仓库图谱处理以前需要花几个季度才能完成的迁移。

这三个不同的工具做三个不同的工作，它们有一个值得注意的共同点：没有一个是为了从头开始编写软件。

它们是为了维护已经存在的软件，这是一个有着不同经济学的问题。

3、实际在发布什么

经过验证的生产现实：

• Stripe Minions： 基于Block的Goose的一个分支构建。每周1,300+个PR，管理超过1万亿美元支付量的代码没有人类作者。任务源自Slack对话、Bug报告和功能请求。
• Spotify Honk： 基于Claude Code和Claude Agent SDK构建。截至2026年QCon London，每十天合并1,000+个PR。代码检查、编译和测试是代理自我纠正的三个信号。
• Anthropic的claude-c-compiler： Claude本身是最高贡献者，最后统计有3,957次提交。80%的开发者现在在工作流中使用AI编码代理。78%的代理编码会话涉及多文件编辑——代理不是在写孤立的函数，它们在修改系统。

Block的一位开发者这样总结这种转变：*"你不再是编码了。你是在监督。"*收益是更少的打字、更少的上下文切换、更少的那些总是感觉像负担的手动工作。

陷阱是假设监督比自己动手更容易——在足够长的时间线上，这并不总是正确的。

4、代理现在处理的长尾工作

对于大多数开发者来说，实际问题是一个编码代理具体能从他们的盘子中拿走什么。

当前的答案：

• 依赖升级： 过时的包、安全公告、在现有测试下的版本升级
• 框架迁移： Amazon Q在几分钟内完成.NET → Linux和Java 8 → Java 17，而不是几个季度
• 文档偏差： 代码-文档偏差被自动检测和修复。Eugene Petrenko 2026年1月的案例研究使用16个代理在四小时内重构了一个文档集；三个独立的验证代理，在没有先验上下文的情况下，给出的评分为8.5、9.0和9.0（满分10）
• 测试覆盖率缺口： 代理识别未测试的代码路径并生成单元测试、集成测试和边缘情况测试
• 安全漏洞修复： 输入清理、添加认证检查、在正确的边界加密
• 客户Bug报告 → PR： Codex、Claude Code和Devin现在自主处理Jira、GitHub和Linear工单，生产数据显示解决时间下降了30-50%

这里有趣的转变不是代理可以编写软件；一年前它们就能了。而是那些清理工作的长尾——团队一直默认永远做不到的东西——现在在经济上值得去做了。

5、是什么让循环真正起作用

每个有效的实现中都出现了三个结构模式。

同位数据： 代理代码、追踪、日志、评估套件和实时软件在一个地方。

mabl团队在75个仓库中运行编码代理，通过添加每个仓库的操作手册，将上下文漂移失败从40%降到5%以下。

大多数大规模的代理失败来自于代理无法找到的缺失上下文，而修复方法就是确保上下文在代理会读取的某个地方。

有界迭代： 每个发布的循环都自我限制：

• Spotify Honk：每会话10轮，3次会话重试
• Claude Code /loop：最大3天
• 大多数评估驱动的循环：5轮

2025年3月进入失控对账循环并在11天后才被任何人注意到的金融科技AI代理，就是当代理没有这些限制时发生的情况。

这不是一个异常事件；这是一个无界代理在有足够时间和奖励信号去追逐时会做的事。

持续垃圾回收： 来自Propel Code的分析：

漂移不是bug的同义词。它是形状的丧失。一个漂移的代码库仍然可以编译、发布，甚至通过测试。

模式：定期清理代理、机械不变量、小型重构PR——而不是每季度的清理项目。

这里复利价值是微妙的。

它不是来自代理比人类写出更多的代码，而是来自代理捕捉到没有人类会优先考虑的小问题。

文档注释中的一个拼写错误。一个落后一个版本的依赖。一个代码覆盖了但测试没有覆盖的边缘情况的测试用例。

这些都不是紧急的。但它们都在积累。托管循环的平台最终成为循环维护的第一个东西，这就是为什么从一开始就以这种方式构建是值得的。

6、哪里仍然会出问题：新的债务

Addy Osmani在2026年1月命名了这种失败模式：80%问题。 Andrej Karpathy报告转向了*"80%的代理编码和20%的编辑+润色。"* Osmani的洞察：剩下的20%不是清理。

它是决定代码能否在生产中存活的工作：速率限制、可观测性钩子、带退避的重试逻辑、熔断器、审计日志、PII处理、输入清理。

代理系统性地交付不足的非功能需求。

数字支持这种说法：

• GitClear（2.11亿行，2020-2024）：重构代码下降60%，复制粘贴上升48%，代码流失率翻倍
• DORA报告：AI采用与更高的吞吐量和更低的交付稳定性相关
• Stack Overflow：经验丰富的开发者报告使用AI工具时生产力下降了19%（与本系列之前研究中METR的随机对照试验一致）
• 使用AI的PR率增加20%；每个PR的事件增加23.5%
• 不受管理的AI代码到第二年将维护成本推至传统水平的4倍
• Forrester：75%的技术决策者到2026年将面临中度到严重的技术债务

该领域中正在形成的模式现在有了一个名字：连贯的混乱。每个单独的变更都是合理的，但它们共同构成了一个不太协调的代码库——编译通过、测试通过、PR差异看起来很干净，但仍然变得越来越难以被任何一个人完全掌握。

这堵墙在大约第16到18个月左右出现。代码库不断增长，速度不断下降，团队逐渐意识到他们不再完全理解自己的系统。

CodeRabbit用一句话捕捉到了这种转变："2025年是AI速度之年。2026年将是AI质量之年。"

7、如何正确采用它：四阶段计划

上述模式不是偶然组合的，它们需要大致按照下面描述的顺序建立。

我看到实现Stripe规模自主性的团队是那些首先构建了约束框架然后逐步添加规模的团队。

试图一次完成所有事情的团队往往比什么都不做的团队更早撞墙，因为这个循环的半成品版本创造了新的失败类别，而没有消除旧的。

第一阶段：建立约束框架

在任何代理自主运行之前，边界需要存在。

• 为一个仓库编写AGENTS.md和CLAUDE.md： 保持每个文件不超过50条指令。HumanLayer的分析发现Claude Code自己的系统提示大约有50条指令，而前沿模型在质量退化之前能可靠地遵循150-200条指令。项目命令（lint、test、build），三四个明确的"不要做"规则，以及代理无法仅从代码推断的约定。
• 添加每个仓库的操作手册： 这就是将mabl的上下文漂移失败从40%降到5%以下的原因。部署步骤、测试模式、内部缩写、只对这个仓库真实而对其他地方不成立的奇怪东西。
• 连接PreToolUse钩子以阻止对约束的更改： 代理绝不能编辑lint配置、hooks目录、CI工作流或AGENTS.md本身。如果它可以编辑约束，它最终一定会编辑。
• 停止测试： 在监督模式下对一个小任务运行编码代理。如果它待在约束内并产生符合你约定的输出，继续前进。如果它试图削弱规则来通过检查，在继续之前先修复钩子。

第二阶段：在一个仓库上运行有界循环

单一仓库，单一任务类型，每个Pull Request人工审查。

• 选择一种任务类型团队已经在手动做：依赖升级、文档-代码偏差修复、测试覆盖率缺口或客户Bug分类。开始只选一种，这个阶段的目标是了解代理会弄错什么，而不是最大化吞吐量。
• 限制循环： Spotify Honk的每会话10轮和3次会话重试是一个很好的起点。Claude Code /loop在无人值守运行时限制为3天。选择限制并将它们写入代理的指令中。
• 让人工审查每个PR： 这是发现代理在你的代码库上具体会出什么错的阶段。不要为了速度跳过它；跳过的代价是那个11天的金融科技失控事件。
• 停止测试： 在合并10-20个PR后，问团队审查代理的输出是否比手动完成任务明显更轻松。如果是，继续前进。如果不是，在扩展之前需要收紧约束框架。

第三阶段：添加评估和可观测性

只有当你能判断循环是在变好还是变坏时，循环才能复利。

• 从这个阶段的第一天起连接可观测性： Langfuse（自托管，免费）、Braintrust（免费层覆盖100万个span和1万个评估分数）或LangSmith，选一个。捕获每个工具调用、模型调用和内存操作作为结构化span。
• 为代理已经产生的已知失败模式编写10-15个单元评估用例。 失败成为评估用例。套件从真实的生产行为增长，而不是从想象中。
• 设置每周定时任务，针对新的生产追踪重新运行回归套件。同样的检查在本地、CI和实时流量上运行。
• 添加持续的清理PR。 小型定期重构运行，而不是每季度的债务冲刺。跟踪重复分支率、后续修复率、未解决的警告数量。
• 停止测试： 团队能通过阅读追踪来回答*"为什么代理在第6步失败了"*吗？如果可以，可观测性层是真实的。如果不可以，在扩展之前加强 instrumentation。

第四阶段：谨慎扩展

现在约束框架可以承载额外的仓库和任务类型了。

• 一次添加一个仓库。 每个仓库需要自己的AGENTS.md和操作手册。第一个仓库的手册不是模板，每个代码库都有自己的怪癖。
• 一次添加一种任务类型。 按顺序从依赖升级到文档偏差到Bug分类，而不是并行。
• 注意代码库漂移。 跟踪GitClear风格的指标：重构率、复制粘贴密度、两周内的代码流失率。如果流失率翻倍或重构率下降，放慢速度并审计正在积累什么。
• 每月重新运行早期阶段的停止测试。 在三个仓库上有效的约束框架不自动在十个仓库上有效。16-18个月的墙是真实的，它首先表现为早期停止测试中的小退化。

从这件事中获得最多收益的团队不是生成最多代码的团队。

它们是那些保持纪律去审查、重构和围绕代理的输出来塑造架构，而不是简单地合并它产生的任何东西的团队。

AI似乎放大了已经存在的任何东西——一个干净的代码库变得更干净、更快，而一个混乱的代码库以代理产生代码的速度积累债务。

8、重新审视

编码代理现在确实在改善软件。

Stripe Minions、Spotify Honk、Anthropic自己的内部编译器——自主PR是真实的，解决时间的收益也是真实的。工作已经从编写代码转变为监督代码。

但这个收益取决于约束框架。没有有界循环、每个仓库的手册、持续清理和对代理可以修改什么的约束，每周发布1,300个PR的同一个编码代理就会变成在第二年将你的代码流失率翻倍、维护成本翻四倍的同一个编码代理。

关于这个主题的写作中反复出现一句话：*托管循环的平台是循环维护的第一个东西。*这是对的，也是一个有用的框架。

它倾向于低估的是，在循环可以安全无人值守运行之前，约束框架的其余部分需要已经存在多少。

如果你从这篇文章中带走一件事：构建循环，但在让它无人值守运行之前，先构建围绕它的边界和约束。

及早发现这种动态的团队最终拥有了真正每周都在变好的代码库。

跳过约束框架工作的团队倾向于以艰难的方式发现16到18个月的墙。

原文链接：Auto-Improving Software: What Coding Agents Now Maintain Without Us

汇智网翻译整理，转载请标明出处