Dropbox发布了Nova，这是一款内部平台，目标是在公司的工程工作流中编排和运维 AI 编程智能体。与将 AI 助手视为独立的编码工具不同，Nova 提供了一个集中的执行层，使智能体能够在 Dropbox 的 monorepo、CI 系统、可观测性工具和基础设施工作流内运行，从而使 AI 系统能够参与从修复不稳定测试到依赖迁移和生产事故调查的各种工作。

据 Dropbox 介绍，该平台是为了应对现成编码智能体能力与企业级软件工程现实之间日益增长的不匹配而创建的。虽然许多 AI 编码工具擅长在本地生成代码片段，但 Dropbox 的工程师需要能够在围绕Bazel、monorepo验证流水线和内部运维工具构建的高度定制化环境中安全运行的系统。通过在与 Dropbox 工程基础设施直接连接的隔离云会话中运行编程智能体，Nova 解决了这一问题，使提议的更改可以在被接受之前针对真实的构建、测试和运维系统进行验证。

Dropbox 将 Nova 描述为一个可复用的 AI 辅助工作流平台，而非单一的 AI 助手。每个 Nova 会话都在与特定代码提交关联的隔离环境中运行，能够执行验证命令、对失败进行迭代，并在测试或构建失败时自动继续改进解决方案。这创造了 Dropbox 所称的“提出—验证—迭代”工作流，其目的是让智能体基于工程师已经依赖的、具有相同确定性的系统开展工作。

该平台同时支持交互式开发者会话和异步运维工作流。工程师可以通过 Web 界面、CLI 或 API 启动会话，而内部服务则可以在更大的自动化流水线中以编程方式调用智能体。Dropbox 表示，这种共享执行模型使公司能够在不为每个使用场景单独构建定制基础设施的情况下试验 AI 辅助的工程工作流。

尽管代码生成仍是核心能力，Dropbox 强调 Nova 的许多成功部署更多集中在运维与维护任务而不是功能开发。一个显著示例是 Deflaker，这是一个基于 Nova 的内部工作流，用于自动调查和修复不稳定的测试。该系统能够分析通过与失败的测试日志，通过 Nova 提出候选修复，借助重复的 CI 运行验证更改，并迭代重试，直到识别出稳定的修复或达到重试上限。

Nova 也可以用于大规模迁移和依赖升级，包括框架转换和自动修复因依赖更新引入的中断。Dropbox 表示，早期的迁移工具缺乏交互性，导致团队在自动化失败后难以恢复。通过将这些工作流整合到 Nova 中，工程师现在可以在保持人工审查、共享护栏和可复用运维工具的同时启动大批量的 AI 辅助迁移。

Nova 的一个主要设计目标是确保 AI 智能体在 Dropbox 现有的工程生态系统内运行，而不是创建平行的工作流。该平台能够与可观测性系统、内部插件、Slack 讨论和基于 MCP 的工具集成，为智能体提供超越源代码的上下文感知能力。Dropbox 还有意将代码发布与智能体执行分离，保持分支与合并操作的确定性和外部可控性，以降低运维复杂性并保持清晰可审计性。

公司表示，其最大教训之一是周边平台基础设施与底层语言模型本身同等重要。验证循环、隔离执行环境、上下文知识源、密封测试和确定性工作流对在大规模环境上实现可信赖的 AI 辅助工程至关重要。

Dropbox 的 Nova 平台反映了行业趋势，即构建内部的“智能体平台”而非仅依赖独立的 AI 编程助手。软件行业的多家公司正越来越多地试验能够自主调查故障、修复基础设施问题、审查代码和执行运维任务的 AI 系统。比如，GitHub、Anthropic与OpenAI等平台都扩展了围绕编码智能体、工作流编排与 MCP 集成的工具，以便组织尝试将 AI 在生产工程环境中投入运行。

同时，研究与行业经验越来越表明，仅靠模型质量不足以满足企业 AI 采用的需求。最近一项关于内部编码智能体的学术研究 发现，工作流集成、安全护栏、确定性工具链与人工监督往往比提示词工程对可靠性与信任的影响更大。Dropbox 的 Nova 架构强烈反映了这一理念，优先考虑编排、验证与运维集成，而非单纯的代码生成能力。

最后，Nova 代表了 Dropbox 对 AI 智能体作为工程生命周期中长期参与者的愿景，而非仅为单个开发者提供孤立的辅助。公司已经试验多智能体从不同视角审查拉取请求、调查生产崩溃、分析运维工作量并协调大规模基础设施迁移的工作流。

随着软件组织持续将 AI 深度整合到工程运维中，像 Nova 这样的平台表明行业正朝着一个未来的方向发展，那就是 AI 智能体将成为嵌入式基础设施组件，它们不仅能写代码，还能直接参与复杂软件系统的持续运行、维护与治理。

查看英文原文：Dropbox Introduces Nova, an Internal Platform for Running AI Coding Agents at Scale