后台编码代理：模型从来不是重点。谁来完成闭环才是。

# 什么是后台编码智能体？AI编码智能体自动创建拉取请求，详解 来源：https://factorykit.ai/blog/background-coding-agent 后台编码智能体是一种无需你在场即可工作的AI编码智能体。你交给它一个任务，它在隔离的云端环境中实现变更，运行你的检查，在真实浏览器中验证结果，然后打开一个拉取请求。你的参与仅限于输入任务和审查输出。 本文基于实际运营经验撰写。在2026年7月的两周内，我们的后台编码智能体平台FactoryKit为三个生产产品（自身、Hashnode和Bug0）交付了180多个功能。在那段时间的中途，我甚至不再打开本地开发环境。本文中的数据来自实际运行，而非基准测试。 如果你正在评估这一品类，很可能带着以下问题而来： - 后台编码智能体与Copilot或Cursor有何不同？ - 我能信任一个无人编写的拉取请求吗？ - 这种智能体每次运行20分钟到底在做什么？ - 我们应该像Ramp和Uber那样自建一个，还是购买现成的？ - 目前存在哪些后台编码智能体？ 下面我将尝试回答这些问题。 ## 后台编码智能体是什么（以及不是什么） **自动补全帮助你打字。IDE智能体帮助你驾驶。后台编码智能体在你做其他事情的同时工作。区别不在于模型，而在于循环在哪里运行，以及谁来关闭它。** AI编码工具已经经历了三代，而且它们经常被混淆。 | 代际 | 运行位置 | 谁关闭循环 | 示例 | |------|----------|------------|------| | 自动补全 | 你的编辑器 | 你，每几秒 | GitHub Copilot (2021) | | IDE与终端智能体 | 你的机器 | 你，每几分钟 | Cursor, Claude Code, Codex CLI | | 后台编码智能体 | 云端沙箱 | 拉取请求审查 | Devin, Codex cloud, Jules, FactoryKit | *三代AI编码工具。每一代都将人类从键盘操作中推得更远。* 这些代际背后的模型通常相同。Claude和GPT为所有三行工具提供动力。变化的是“框架”：在需要人类介入之前，工具拥有多少循环的控制权。作为实践，智能编码就是沿着这张表格向下推进。 IDE智能体是同步的：它工作，你观看，你打断。后台编码智能体是异步的：工作单元是一个任务，输出单元是一个拉取请求。中间没有任何环节需要你。你还会看到它们被称为自主编码智能体或云端编码智能体；这个品类还很新，名称尚未固定。 以下是在FactoryKit中输入侧的样子。你选择仓库（一个任务可以跨越多个仓库）、选择智能体，然后描述变更： *FactoryKit中的一个任务：选择仓库、选择智能体、描述变更。这就是全部输入。* 那个智能体选择器是一个细节，我想尽早强调，因为它常常让人惊讶：编码智能体（Claude Code、Codex或Grok Build）是一个每任务的选择，而不是平台承诺。不同智能体有不同优势（https://factorykit.ai/p/claude-code-vs-codex），工厂并不关心在某个任务上运行的是哪个智能体。 ## 拉取请求是审批关口 **后台智能体不会取代代码审查。它们将所有审查都转移到拉取请求上。这只有在PR附带证据，而不仅仅是差异时才有用。** 市场上每个后台智能体都“提出PR”。这个短语掩盖了一个关键问题：PR附带什么？ 仅凭差异会加重审查者的负担。你现在要冷读机器编写的代码，还得猜它能不能运行。有效的方式是我称之为“有证据支持的PR”：一个带着自身证明的拉取请求：它通过的检查、差异的自审、以及变更在真实浏览器中工作的录屏。 以下是一个真实运行的例子： *PR #58附带的QA录屏。智能体在沙箱中的浏览器里驱动应用；录屏随拉取请求一起发送。* 这是它在仓库中的呈现方式： *每个变更的仓库一个PR。证据在PR正文中，审查者已经在那里了。* 我不会假装证据能弥补所有差距。录屏证明功能可以工作；但它不能证明功能就是你的本意，或者方法适合你的架构。审查仍然能发现意图和设计问题。但证据消除了对智能体PR最廉价、最常见的怀疑：“这真的能运行吗？” ## 后台编码智能体如何工作 **实际上它是一个管道：沙箱、克隆、实现、检查、修复、审查、记录、推送。** 当任务在FactoryKit中启动时，会在云端配置一个全新的隔离沙箱。仓库被克隆进去。智能体读取代码库、实现变更，然后运行每个仓库自己的检查：代码风格、类型、测试，无论仓库定义了什么。如果检查失败，它有一定次数的尝试来修复（我们允许3次）。然后它审查自己的差异，并通过在记录的浏览器中运行应用来对变更进行QA。只有在所有这些之后，平台才会提交工作、推送分支并打开拉取请求。 *运行生命周期。一个结构性细节比其他所有都重要：智能体从不接触git。它编辑一个工作树。平台负责推送。* 智能体不能推送、强制推送、重写历史或打开PR。它生成一个工作树；主机提交并推送它。无论模型某天表现有多糟糕，影响范围仅限于一个目录。 以下是运行过程中的样子： *观察一次运行：智能体在工作时进行叙述。工具调用被有意隐藏。叙述是审查者实际会阅读的日志。* 根据我们在三个产品中的运行： | 任务复杂度 | 典型时长 | |------------|----------| | 简单 | ~5分钟 | | 中等 | 10到15分钟 | | 复杂 | 20到30分钟 | 任务最多可以运行五小时，之后我们才会终止。大多数时候你根本不会观看这些。你会在PR到达时得知。 凭证是此类安全审查中每个团队都会首先遇到的问题，所以这里给出确切机制。沙箱内的智能体持有一个占位凭证。当它向GitHub或模型网关发起请求时，网络防火墙会在传输过程中将占位符替换为真实令牌，并且每个令牌的作用域仅限于它所对应的那个仓库。 *FactoryKit的平台凭证（模型网关密钥、GitHub令牌）在传输过程中注入，从不存在于沙箱内部。你的应用运行所需的环境变量会进入沙箱，因为没有它们你的应用无法启动。* ## 2026年谁在构建后台编码智能体 **这个品类真实存在的最有力证据：在你能够购买之前，Ramp和Uber已经各自内部构建了一个。** Ramp构建了Inspect，一个与他们的Linear工作流相连的后台智能体，每次会话在沙箱化的VM中运行。他们的工程博客报告称，在使用后的几个月内，“约30%合并到前端和后端仓库的拉取请求由Inspect编写”（https://engineering.ramp.com/post/why-we-built-our-background-agent）。Uber在平台规模的单仓库上运行智能体；根据《The Pragmatic Engineer》2026年3月10日的报告（https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development），92%的Uber开发者每月使用智能体，11%的拉取请求由智能体打开。 两家公司都让平台工程师在沙箱化、凭证处理和审查工作流上投入了大量精力，然后才产生了第一个有用的PR。在2026年，你也可以跳过这些，直接购买一个： - **Devin**（https://devin.ai/）（Cognition）：最早广为人知的后台智能体，在其云端VM中运行并行会话。 - **OpenAI Codex**（https://openai.com/codex/）：与ChatGPT订阅绑定的云任务，从Codex界面委派。 - **Google Jules**（https://jules.google/）：将你的GitHub仓库克隆到Google Cloud VM并打开PR，提供免费层。 - **GitHub Copilot编码智能体**（https://github.com/features/copilot）：将GitHub Issue分配给Copilot，它会草拟PR，原生集成于GitHub。 - **Cursor后台智能体**（https://cursor.com/）：从Cursor编辑器启动的异步运行。 - **FactoryKit**（https://factorykit.ai/）：我们构建的。多仓库任务、每任务可自选编码智能体、带有录屏浏览器QA的有证据支持的PR。 | 智能体 | 运行位置 | 启动方式 | 特点 | |--------|----------|----------|------| | Devin | 其自有云端VM | Devin网页应用 | 最早入局者，并行会话 | | OpenAI Codex | OpenAI云端 | ChatGPT / Codex界面 | 与ChatGPT订阅绑定 | | Google Jules | Google Cloud VM | jules.google | 免费层 | | Copilot编码智能体 | GitHub Actions | 分配GitHub Issue | GitHub原生 | | Cursor后台智能体 | Cursor云端 | Cursor编辑器 | 从IDE交接 | | FactoryKit | 每任务独立沙箱 | 网页应用 | 多仓库任务、智能体选择、有证据支持的PR | 这些工具在实际方面各不相同（运行位置、验证内容、成本），严肃的比较值得单独一篇文章。一句话总结：它们都能提出PR；区别在于你有多信任它，而无需重新做一遍工作。 ## 运行两周的实际体验 **在2026年7月的两周内，FactoryKit为三个生产产品交付了180多个功能。我不再打开本地开发环境。** FactoryKit由一个小团队构建，并且它自我构建：大多数对FactoryKit的更改本身就是FactoryKit的任务。我们的git历史就像任务日志，因为它就是。FactoryKit仓库的PR #58的任务是“计费页面标题错误。它两次显示FactoryKit”，合并自分支 `factory/the-billing-page-title-is-wrong-it-says--b06169`。没有人写提交信息。任务就是提交信息。 同一个工厂也运行着Hashnode和Bug0的日常开发，这些都是拥有真实用户的生产应用，而非演示仓库。在这三个产品中，截至2026年7月26日的两周内，交付了180多个功能。 *仪表盘中的近期任务。每一行都以相同方式结束：一个拉取请求。* 我自己的工作流变化并非计划中的；它就这么发生了。任务从我所在的任何地方输入。PR带着证据返回。审查在GitHub中进行，后续反馈作为同一条任务的消息，后续提交堆叠到同一个PR上。在这两周中的某刻，我注意到自己完全没有打开本地开发环境，而且之后就再也没有打开过。 适用的地方和不适用的地方。标准Web应用是理想场景：浏览器QA循环假设变更可以在浏览器中执行。移动应用不受支持。有些任务第一次会出错；修复方法是发一条后续消息，而不是重写，对话会保留在PR上。 ## 后台编码智能体是AI软件工厂的单元 **一个智能体是一个工具。一支带有检查和审批关口的智能体队伍就是一个工厂。** 这篇文章中的工具通常被逐个讨论。能够获得真正吞吐量的团队会并行运行许多个，针对同一个仓库，使用相同的检查，最后只有一个关口。这就是一条生产线，而后台编码智能体是它的基本单元。 *工厂形状：智能体负责生产线，PR关口保持人工。* Ramp和Uber之所以内部构建这个形状，是因为当时没有可购买的产品。这个窗口正在关闭。对于2026年的大多数团队来说，有趣的问题不再是“工厂形状”（https://factorykit.ai/p/ai-software-factory）是否有效。而是自己构建一个是否比直接接入一个更能利用好你的平台工程师。这个问题值得单独一篇文章，并附上详细的计算。 ## 常见问题 **什么是后台编码智能体？** 一种异步工作的AI编码智能体：你分配一个任务，它在隔离的云端沙箱中实现变更，运行仓库的检查，验证结果，然后打开供人类审查的拉取请求。在任务和PR之间你不需要介入。 **后台编码智能体与副驾驶（copilot）有何不同？** 副驾驶在你编写代码时提供帮助：它建议，你接受，每小时几十次。后台编码智能体完全取代了编写过程，将人类参与转移到拉取请求。实际测试：合上你的笔记本电脑。如果工作停止了，那它就不是后台智能体。 **后台编码智能体在生产仓库上运行安全吗？** 使其安全的机制是隔离和作用域，而非模型行为。在FactoryKit中，每个任务运行在一个全新的沙箱中，智能体从未拥有git访问权限，平台凭证在传输中注入而非存储在沙箱内，每个令牌的作用域仅限于单个仓库。没有人工批准PR，什么都不会合并。 **后台编码智能体每个任务需要多长时间？** 根据我们的运行：简单任务约5分钟，中等任务10到15分钟，复杂任务20到30分钟。任务最多可以运行五小时，然后超时。 **2026年存在哪些后台编码智能体？** Devin（https://devin.ai/）（Cognition）、OpenAI Codex（https://openai.com/codex/）云任务、Google Jules（https://jules.google/）、GitHub Copilot编码智能体（https://github.com/features/copilot）、Cursor后台智能体（https://cursor.com/）以及FactoryKit。Ramp的Inspect（https://engineering.ramp.com/post/why-we-built-our-background-agent）和Uber的内部智能体是最知名的内部构建。 --- 理解这类工具最快的方法，就是看着你自己编写的任务变成附有录屏的PR回来。立即完成你的第一个任务（https://factorykit.ai/）。