多年来，工程生产力的核心始终是减少软件开发生命周期中的各种摩擦，而 AI 编程工具则被寄予厚望，用来加速实现阶段的工作、提升开发者产出。然而，当这些工具在 Dropbox 工程团队中被广泛采用后，我们逐渐意识到：加速代码生成只是把瓶颈推向了后续环节。
AI 极大提升了代码编写速度，但代码流动得越快，代码评审队列、CI 系统、验证流程、发布协调以及生产运维所承受的压力也就越大。挑战已经不再只是帮助工程师更快写出代码，而是如何让整个软件开发生命周期能够吸收、验证并安全地交付大幅增加的工作量。正是这种认知，推动 Dropbox 从单纯采用 AI 工具，迈向对工程系统与工作流程更全面的演进。
在这篇文章中，我们将分享 Dropbox 如何从辅助工程师工作的 AI 工具，逐步转向能够执行特定任务的 agentic 系统；我们如何构建支撑这些工作流的平台；以及工程师如何调整自己的工作方式，与这些系统协同合作。
从 Copilot 到 Agent
第一代 AI 编程工具主要是在现有开发流程中帮助工程师完成工作，例如解释代码、生成代码片段以及回答问题。这类工具非常有效，但它们本质上仍然是工程师身边的 Copilot。
Agent 的出现改变了这种交互模式。一个 agent 可以接收一个边界明确的任务，检查代码库、修改文件、运行测试、针对失败结果不断迭代，并最终返回一个供人工审核的成果物。工程师依然对需求意图、系统架构、代码质量以及发布决策负责，但具体的实现流程已经发生了显著变化。借助 agentic 开发模式，工程师能够并行推进更多工作、探索更多方案，并把过去大量消耗时间和注意力的重复执行工作交给系统完成。
然而，随着 agent 持续提升代码产出速度，负责审查、验证和交付这些代码的周边系统也开始承受越来越大的压力。代码评审系统、测试基础设施、验证流程、发布机制以及生产运维体系，都必须适应规模远超以往的 AI 辅助产出。
这种变化也迫使我们重新审视围绕这些工具构建的整体工程环境。更多代码和更多 Pull Request 并不一定意味着更高的客户价值。与此同时，由于 agentic 工程改变了工程师规划、审查、验证和负责工作的方式，因此赋能和培训的重要性已经与工具本身同等重要。
Nova：我们的 Agent 平台
Nova 是这种转变最具代表性的例子之一。Nova 是 Dropbox 内部的编程 agent 平台，我们构建它的目标，是让工程师能够使用自然语言描述任务，并在一个受控环境中运行 AI 编程 agent，同时为其提供访问代码库所需的上下文。Nova 的价值并不主要来自底层模型本身，而是来自围绕模型建立的一整套系统能力，包括代码库上下文、内部工程实践、安全执行机制、工作流集成以及人工审查流程。
如今，Nova 已经产生了实质性的成果。在 Dropbox 当前的 Pull Request 中，大约每 12 个就有 1 个来自 Nova，而且使用率仍在持续增长。但更重要的变化在于，它正在改变整个工程组织的运行模式。过去需要经过一连串人工操作才能完成的工作，现在可以被组织成一个结构化且可审查的工作流：定义任务、让 agent 在既定护栏内执行、验证结果，然后由人工在代码进入生产环境之前做出最终判断。
Nova 的应用范围也早已超越功能开发。它越来越多地被用于迁移项目、不稳定测试修复、缺陷调查、依赖更新，以及其他高劳动密集度的工程任务。这些工作对于维持系统健康至关重要，但往往很难获得足够优先级。我们也在持续开发新的系统，以支持更多 agentic 工作流。
衡量产品交付速度，而不只是代码产出
随着 AI 辅助产出不断增长，我们也开始重新思考如何衡量工程生产力。
当代码编写速度是主要瓶颈时，Pull Request 吞吐量是一个非常有价值的生产力指标。但随着 AI 改变了工作的规模和形态，我们逐渐发现，单纯关注吞吐量已经不够了。
随着 PR 数量持续增长，挑战不再只是衡量产出，而是判断整个系统是否能够高效消化这些增长。代码评审负担、CI 成本、返工情况以及软件质量，都成为与最终客户价值同样重要的观察指标。因此，我们逐渐建立起一种更完整的衡量框架，把工程生产力看作从 AI 使用、工作流采用、生产环境产出，再到最终客户影响的连续演进过程。
这一衡量模型包含四个阶段：
- Fuel（燃料）：衡量 AI 工具是否被实际使用；
- Adoption（采用）：跟踪团队工作流发生了怎样的变化；
- Output（产出）：衡量 AI 是否真正参与了生产工作；
- Impact（影响）：关注最重要的结果——提升产品交付速度，缩短从创意产生到客户价值实现的时间。
质量与信任的重要性丝毫不亚于速度。我们会跟踪代码评审响应时间、首次测试通过率、缺陷比例以及返工率等指标，以判断产出增长是否能够在真实环境下维持质量。更快的代码生成绝不能以牺牲可靠性和客户信任为代价。
这正是衡量体系发生的核心转变：从局部活动指标转向对整个系统结果的关注。
工程工作流也必须随之演进
更重要的是，agentic 工程不仅仅是工具层面的变化，它正在改变软件开发本身的运行模式。
随着越来越多的实现工作被 agent 接管，工程师的角色也逐渐转向定义目标意图、分析问题、审查生成结果，以及做出更高层次的架构和质量决策。工程师仍然需要对最终结果负责，但日常工作的具体形态已经开始变得截然不同。
这种转变不会自动发生。成功采用 agentic 工作流，不仅需要工具，也需要相应的赋能体系。在 Dropbox，我们投入了大量资源开展实践培训、黑客松、工作流分享、训练营以及工程师主导的经验传播，帮助团队向已经采用这种工作方式的同事学习。
不同团队接受这些工作流的速度也各不相同。有些工程师希望尽快获得更多自动化和灵活性，而另一些人则需要更明确的护栏机制、可信度信号以及与自身工作直接相关的实践案例。对于运行高风险系统的团队来说，其采用路径通常也会比负责低风险或相对隔离模块的团队更加谨慎。
我们的目标并不是强迫所有工作流都通过 agent 完成，而是在真正能够产生显著杠杆效应的场景中，让 agentic 开发变得有用、安全、可衡量且可复制。
我们学到的经验
在这场转变中，我们学到的最大教训是：AI 并不会消除软件开发中的瓶颈，它只是改变了瓶颈所在的位置。
随着代码生成速度不断提升，约束条件开始向下游转移，进入代码评审、验证、测试、发布协调以及生产运维等环节。继续优化过去的瓶颈，已经无法带来同样级别的收益。
这也改变了组织应该重点投入资源的方向。仅有生成能力远远不够。随着 agentic 系统不断扩展规模，验证、编排、工作流集成、治理以及度量体系都会变得越来越重要。真正的竞争优势不会来自所有人都能使用的基础模型，而会来自围绕这些模型构建的系统能力：上下文、内部工具、质量控制，以及将它们连接起来的工作流。
与此同时，agentic 工程也把更多压力向产品和设计环节前移。随着实现速度提升、并行开发能力增强，产品判断的质量、设计定义的清晰度以及规格说明的结构化程度都会变得更加重要。因此，更精准的问题定义、更完善的规格设计、更快速的设计验证，以及更紧密的产品与工程协作，都会成为 agentic 工程不可或缺的一部分。
我们还发现，传统生产力指标已经无法完整反映真实情况。Pull Request 吞吐量依然重要，但更关键的问题是：AI 是否帮助团队在不损害可靠性、质量和信任的前提下，更快地把想法转化为客户价值。
agentic 工程的核心，在于让工程师能够把更多注意力和判断力投入到真正重要的地方：定义目标意图、设计可持续演进的系统、验证质量，并更快地为客户创造价值。
未来的工程生产力竞争，不会仅仅取决于谁拥有最好的模型，而会取决于谁能够围绕这些模型构建最优秀的系统。
真正的挑战已经不再是生成更多代码，而是构建能够可靠地把 AI 辅助产出转化为客户价值体验的工程体系。