原文：The Self-Driving Codebase

Background Agent 是一种在云端基础设施上自主运行的 AI 驱动软件代理——由事件、计划任务或系统信号触发，在无需开发者在键盘前的情况下，跨软件开发生命周期（SDLC）执行开发任务。

软件交付的范式转变

软件交付最初是围绕”人类在键盘前”的约束设计的。现在，代理可以在后台跨数千个仓库自主运行。这一趋势已在 Stripe（Minions 平台）和 Ramp 等公司落地。

我们的旧流程已经无法吸收这些变化。现在，每位工程领导者都在问同一个问题：我们如何从今天的交付流程演进为自动驾驶代码库？

从自动补全到后台代理

自动补全 → 编码代理 → 三个并行运行的编码代理 → 工程师开始寻找变通方案：

  • 多个终端窗口
  • Git worktrees
  • 闲置的 Mac Mini

任何能运行更多代理的方法。

但 localhost 不是为这种情况设计的。代理争夺机器状态、密钥暴露、机器休眠时一切停止。这对独立开发者有效，但对专业工程来说是不可持续的。

我们必须将工程师与工作站解耦。代理需要在后台安全、大规模地运行。

虚假顶峰：个人速度 ≠ 组织速度

你推出了编码代理。工程师更快了。PR 如潮水般涌入。

然而，周期时间没有变化。DORA 指标持平。待办事项反而增加了。

因为收益是与个人复合的，而不是与组织。你在编码代理上投入的时间越长，而不解决周围的系统问题，你的根基就越深。

这就是虚假顶峰。

什么是 Background Agent？

特性 Coding Agent Background Agent
运行位置 你的笔记本或本地机器 云基础设施，远程触发
触发方式 你手动调用 事件、计划任务、Slack 消息、API 调用——任何信号
范围 单个仓库的单个任务 跨仓库、团队、整个 SDLC
开发者角色 在循环中——观察、引导、迭代 在循环上——提示、离开、稍后审查

编码代理需要你的机器和你的注意力。后台代理两者都不需要。它在云端的独立开发环境中运行：完整的工具链、测试套件、一切。与你的设备和会话完全解耦。

从笔记本启动一个，用手机查看结果。从 PR、Slack 线程、Linear 工单、webhook 触发，或手动启动。

你不是在操控它。你不是在观察它。这是一个异步任务：委派、离开、稍后审查。它需要运行多久就运行多久。

构建自驱动代码库的三个步骤

步骤 1：建立后台代理原语

自主代理需要笔记本上没有的基础设施：

🖥️ 开发环境

代理需要一台计算机——具有完整工具链、运行测试能力、通过密钥访问系统的环境。环境应该隔离、可重现，与生产系统高度一致。

模式 1：代理拥有开发环境 代理拥有完整的开发环境。运行 dev container 的 VM，包含代码库、测试套件、数据库和内部网络访问。这是最接近人类开发者工作方式的模式。包括 Stripe 和 Ramp 在内的每家分享代理架构的企业都选择了这种模式。

模式 2：Sandbox 作为工具 代理在服务器或本地运行。需要执行代码时，通过 API 调用单独的远程 sandbox。Sandbox 运行代码并返回结果。这保持密钥和执行一定程度的隔离，但代理只能执行代码，无法完全开发。更适合构建代理产品的公司，而非优化自身工程工作流的组织。

🛡️ 治理

代理是系统中的行动者。它们需要与人类贡献者相同的控制：身份、权限、审计跟踪。

区别在于：通过系统提示强制执行的治理（”请不要删除文件”）只是建议。在执行层强制执行的治理——拒绝列表、限定范围的凭证、确定性命令阻止——才是真正的治理。

没有它，安全团队会完全否决自主代理。他们是对的。

🔌 上下文与连接性

无法访问内部系统的 sandbox 只是玩具。代理需要承担 IAM 角色、查询数据库副本、访问内部 API、从私有 registry 拉取——所有这些都在你的网络内部完成。

上下文和连接性将隔离执行转化为真正的工作。

⚡ 触发器

如果每次代理运行都以开发者输入提示开始，你没有自动化工作流——只是自动化了工作。触发器将代理连接到重要事件：计划任务、webhooks、系统信号。

触发模式：

  • ⏱️ 计划代理：定时触发。可预测、有界、高容量——依赖更新、lint 清理、覆盖率执行
  • ⚡ 事件驱动代理：由系统事件触发——PR 打开、CVE 发布、警报触发。反应式、并发、持续监听
  • ⊞ 代理舰队：一个任务跨多个仓库。每个代理独立工作，产生自己的贡献
  • ◉ 代理集群：多个代理，一个结果。每个代理处理不同方面，结果汇聚成单一交付物

🎯 舰队协调

更新一个仓库是编码代理任务。更新 500 个是舰队任务。相同的 sandbox，在需要更改的每个仓库中复制——并行配置、进度跟踪、聚合结果。这就是个人生产力转化为组织吞吐量的地方。

步骤 2：找到系统的瓶颈

原语给你能力。你在哪里应用它们才重要。这意味着要做工作：调查开发者、与团队坐在一起、绘制时间流向。每个组织的瓶颈都不同。值得首先解决的并不总是显而易见的。

常见瓶颈：

  • 堆积如山的代码审查：PR 搁置数小时，你不断切换上下文。大规模时，审查队列积压，交付时间持平，尽管编码更快
    • 解决方案：后台代理在人工审查前审查每个 PR，审查者专注于设计而非格式

步骤 3：扩展你的软件工厂

工程组织是一个工业系统。今天，开发者站在每个站点：编写、审查、测试。后台代理改变了运营模式。工厂运行，但你的工程师在循环上而不是在循环中。

工程师不是在循环中。他们在循环上。

工厂车间正在运行。代码正在被编写、审查、测试、部署——持续地、自主地。你的工程师在观察。设置约束。验证结果。

实际应用案例

🔧 CI 大规模迁移

后台代理如何在数百个仓库中自动化 CI 管道迁移——无需人工参与。

🛡️ CVE 修复

从披露到部署修复只需数小时，而非数周。后台代理在您的整个代码库中修补漏洞。

🔄 COBOL 到 Java 迁移

使用后台代理进行遗留现代化——来自企业迁移的真实模式，自主大规模运行。

关键洞察

  1. 本地开发的终结：localhost 无法支持大规模代理运行。云基础设施是必须的。

  2. 从”在循环中”到”在循环上”：开发者从实时操控转向异步审查和校准。

  3. 组织速度 > 个人速度：优化单个开发者效率不等于优化整个组织的交付速度。

  4. 治理必须内建：安全不能靠提示工程，必须在执行层强制执行。

  5. 触发器实现真正的自动化：没有事件触发，代理只是更快的手动工具。

参考资源

本文整理自 background-agents.com，由 Ona 团队创建。