云代理正在重塑软件构建方式
第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。
AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。
这一转变对你设计系统、管理上下文以及思考开发者角色都具有实际意义。以下是这种转变在实践中实际的样子。
三个时代，三种不同抽象
将 AI 编程工具的发展视为三个阶段，每个阶段代表不同的工作单元，这会有所帮助：
时代 1：Tab 补全 — 工作单元是一行或一个代码块。开发者主导；AI 提供建议。延迟非常重要。大量采用这种方式的开发者在个人编程练习中实现了 30-55% 的任务完成速度提升，尽管不同经验水平的提升效果不一。
时代 2：本地代理 — 工作单元是一个任务，通常在 2-5 分钟内解决。开发者描述意图；代理进行迭代。上下文窗口限制对单个会话能处理的内容设置了严格的上限。这就是“与你的代码库聊天”产品所处的阶段，也是与真实代码库的首次摩擦开始显现的地方。
时代 3：云代理 — 工作单元是一个功能或工单，解决时间从几分钟到几小时不等。代理在一个完整的虚拟机中运行，执行自己的测试，生成带有简短视频演示的 PR，并将其发布到 Slack。开发者审查输出，而不是主导执行。在完全采用这种模式的团队中，代理现在占已合并生产拉取请求的 35%。
每个时代都要求人与机器之间建立不同的关系。云代理需要最大的调整：你不再是驱动者，而是评审者和战略家。
云代理的实际运行基础
基础设施的差异比最初看起来的更重要。
早期的代理实验使用“空白虚拟机”设置：最小化的容器可以运行代码，但缺乏开发者会使用的完整环境。这限制了代理的能力——没有图形用户界面，没有秘密管理，无法直观预览运行中的应用程序。
云代理现在提供预装了开发工具的完整桌面虚拟机。代 理可以 VNC 访问真实的桌面，运行浏览器，执行终端命令，上传文件，并与服务交互。当出现问题时，开发者可以直接进入同一个虚拟机，检查状态，发出更正，并交还控制权。这种紧密的反馈循环——更像是与异步伙伴进行结对编程，而不是委派一个工单——正是实现以小时而非分钟计任务的关键。
另一个关键的架构变化是模型选择的工作方式。当前的系统不是将每个请求都路由到一个单一模型，而是在多个模型之间并行运行“N 中选优”的执行，并选择最佳结果。长期运行的任务会生成子代理：更快、更便宜的模型用于探索和文件搜索；更强的模型用于实现决策。这种方式在代理边界管理上下文窗口限制，而不是试图将所有内容压缩到一个会话中。
并行化转变
云代理带来的最被低估的改变不是纯粹的速度——而是并行性。
当获得一个更快的助手时，本能是期望每个任务都能更快完成。但真正的优势在于同时运行多个任务。拥有云代理的开发者不会为单个功能等待更长时间；他们管理一个并发工作队列，每 90-120 秒检查一次每个线程，而不是在每个任务上依次花费数小时。
这将瓶颈从执行转移到了审查。随着代理生成代码的速度加快，代码审查成为了限制因素。一个内部数据点显示：代理生成的文档 PR 获得了 82% 的接受率；新功能 PR 的接受率为 66%——这仍然远高于大多数开发者的预期，但较低，反映了新开发工作中涉及的额外判断。
适应这一点的团队已将审查从逐行差异检查转变为多层策略：观看 30 秒的功能运行视频演示，然后在代码层面审查关键路径，最后运行安全和性能检查作为最终关卡。仅视频层就消除了在行为问题上令人惊讶的来回沟通。
Slack 成为协调层。对话不再是“你在做这个吗？”，而是转变为“代理正在做这个——我们喜欢这个方向吗？”。团队协作地将提示词作为共享的工件进行完善。围绕代码所有权的社会动态变化是真实存在的，值得我们深思熟虑。
仍存在的难题
云代理虽然强大，但其故障模式是特定的，在你遇到它们之前值得了解。
上下文窗口耗尽是头号故障模式。 对长期编程任务的研究显示，超过 50% 的故障率可归因于上下文限制、工具预算耗尽，或在上下文超过 10 万个令牌后代理陷入重复循环。代理会开始重复之前的动作，而不是合成新的计划。SWE-Bench PRO——一个为长期任务设计的基准测试——显示，即使是当前顶级的模型，通过率也低于 23%，而对较短上下文任务的得分则高得多。
这不是一个随着更大上下文窗口就能自动解决的模型问题。这是一个架构问题。表现最佳的代理使用结构化的上下文管理：在生成新的子代理之前总结已完成的工作，保持活跃上下文专注于当前子任务，并明确检查点状态。
代码库入职慢且脆弱。 代理需要知道如何启动你的后端、运行你的测试、检查服务健康状况、以及在你庞大的单体仓库中导航。这些知识通常是部落化的——存在于开发人员的头脑中或散落在 README 文件里。当前的入职方法可以处理初始设置，但当依赖项改变、凭证过期 或部署目标转移时就会失效。构建一个能够持续维护的 AGENTS.md 或同等文件，是大多数团队尚未完成的运营工作。
特定代码库的约定无法持续。 一个今天在你的代码库上工作的代理，没有它上周学到的约定记忆。它不知道你总是使用特定的错误处理模式，或者 make dev 不起作用，你需要运行三个独立的服务。除非你以代理可读的形式系统地记录这些知识，否则这些知识会一再重复传达。
令牌经济学与未来展望
成本曲线在这里至关重要。面向开发者的 AI 工具成本一直在下降，但云代理执行数小时的任务和 N 中选优的模型路由，消耗的令牌数量远超自动补全。随着代理杠杆作用的扩大，每个开发者的令牌支出可能从每月几十美元飙升到几百或几千美元。
这里存在一个杰文斯悖论的动态：随着代理变得更便宜、能力更强，团队会更多地使用它们，而不是更少。每行代码的成本降低并不意味着总成本降低——它意味着编写了更多的代码行。规划基础设施开支的团队应该明确地模拟这条曲线，而不是假设 AI 工具成本保持不变。
展望未来，发展轨迹是朝着更高的自主性与更紧密的验证循环方向发展。当前的模式——人类编写规范，代理实现，人类审查——可能会转向由代理处理规范细化、跨假设的并行实现以及针对验收标准的自动化验证。人类的角色将越来越像产品和架构职能：提供品味、设定约束、做出需要理解用户上下文的判断。
那些在这方面做得好的团队 ，正在将其视为基础设施工作，而不仅仅是工具采纳。投入于代理可读的文档。构建能够处理并行化 PR 生成而不中断的 CI/CD。建立一个能随吞吐量扩展的审查流程。并且接受与云代理高效协作所需的技能——提示清晰度、系统分解、验证设计——与让你通过 Tab 补全提高生产力的技能有所不同。
AI 作为打字加速器的时代正在结束。AI 作为并行协作者的时代已经开启。
