本文作者： @SantoshPraneeth 和 @jeffizhungry
Flux 是 DoorDash 面向工程师的云端 Agent 平台。在 2026 年的一个月里，我们使用 Flux 自动化了 130,000 项工程任务。自 2026 年第一季度上线后，Flux 迅速扩展，目前已经支撑起 DoorDash 内部的大规模后台工作流，包括每周超过 25,000 次自动化代码审查，以及每周使用的 300 多个独立 playbook 和 10,000 多次调用。这些工作流可以在无人值守的情况下并行运行，全天候不间断。
我们将逐一探讨那些推动我们超越本地笔记本电脑上 Agent 工作负载的限制、为什么我们选择自研 Flux 而不是只依赖托管的编码 Agent，以及让 Agent 委派变得可重复且安全的平台原语，例如 Agent 沙箱、MCP 网关、playbook 和调用入口。
Flux 后台工作流用例
Flux 在 DoorDash 内部单月使用情况概览，涵盖自动化代码审查、playbook 运行和后台任务完成情况
我们的起点
在过去一年中，用户在笔记本电脑上运行 Agent 工作负载时很快就遇到了各种限制：
- 资源与可用性。笔记本电脑的 CPU 核心数固定、内存和电池有限，而且所有这些资源都要与设备上的每个应用共享。Agent 工作流通常需要并行运行构建、测试和大规模搜索等计算密集型任务，很快就会让笔记本电脑不堪重负。此外，这些工作流还依赖设备保持开机、联网和可用状态；一旦工程师合上笔记本电脑、断开网络连接或暂时走开，工作就会暂停。
- 安全控制。笔记本电脑通常可以广泛访问敏感凭据和系统，包括 SSH 密钥、VPN 会话和已认证的工具。如果让自主 Agent 拥有同等级别的访问权限，会带来不必要的风险和巨大的潜在爆炸半径。本地环境也更难严格限定 Agent 可以访问什么、访问多久。
- 可见性与可审计性。当工作负载分散在各自的笔记本电脑上运行时，执行过程是碎片化的，难以监控。我们更难了解正在运行什么、在哪里运行、以谁的名义运行，以及它访问过哪些系统或文件。
我们解决这些问题的思路很简单：
将任务委派给安全、自主的编码 Agent，让工程师能够把更多精力投入到创新、深度思考和解决复杂问题上。
为什么我们自研 Flux
托管的编码 Agent 很有用，但它们迫使你做出艰难的取舍：要么将敏感代码和执行上下文发送给第三方，要么为第三方开辟一条通往内部系统的路径。对 DoorDash 来说，更困难的问题并不仅仅是让 Agent 编写代码——这个问题基本已经解决了。真正困难的是为 Agent 提供合适的环境、工具、权限、集成和约束。
我们的策略是掌控 Agent 周边的原语，包括编排、沙箱、工作流、权限、集成，以及 Agent 高效工作所需的 DoorDash 特定上下文。我们还把这些原语设计为模块化，这样我们就可以灵活地为每项任务选择最佳的第三方工具，或者在需要对安全、集成、性能或用户体验有更深入掌控时选择自研。
这些原语让工作流的创建更加民主化，也让系统更能适应未来的用例。由于它们可以以不同方式组合，团队可以构建新的 Agent 工作流，而无需重构底层基础设施，也无需规定每位工程师应该如何组织自己的工作流。例如，我们的代码审查及其评估都运行在 Flux 基础设施上。
原语，而非工作流
构成 Flux 的四个平台原语——沙箱、MCP 网关、playbook 和调用入口——以及它们如何相互连接，将任务转化为 Agent 可以安全执行的工作
如上图所示，Flux 围绕四个平台原语构建：沙箱、模型上下文协议（MCP）网关、playbook 和调用入口。它们共同让 Agent 委派变得可重复。playbook 定义工作内容，云沙箱为 Agent 提供真正的工作场所，Agent 网关控制 Agent 可以访问哪些系统，调用入口则让工程师能够从他们一直在使用的平台发起和接收工作。
沙箱提供执行环境
本地 Agent 在交互式开发中表现良好，但不太适合无人值守的工作流。它们依赖工程师各自的笔记本电脑，争夺本地资源，难以审计，也无法在并行任务中高效扩展。
Flux 将执行迁移到由 Firecracker 微虚拟机（microVM）支撑的隔离云沙箱中，实现硬件级隔离。每个沙箱都会预置任务所需的代码仓库、开发者工具、机密信息和运行时依赖，为 Agent 提供完整的工程工作空间，同时也为 DoorDash 提供一致的执行、安全和可观测性模型。
掌控这一层让我们能够支持真实的工程工作流，包括在单次会话中跨多个代码仓库进行修改并创建多个拉取请求。对于完整的端到端环境搭建——从启动 microVM 到克隆所需的代码仓库、安装构建工具、配置受支持的编码 Agent 框架——Flux 的 95 百分位服务水平目标（SLO）为五秒以内。
MCP 网关提供受管控的访问
Agent 需要访问工程师日常使用的各类系统，包括持续集成（CI）、可观测性平台、问题跟踪器、部署工具、代码搜索、文档和服务元数据。但默认情况下，不应授予宽泛且不受限制的访问权限。
Flux 通过一个名为 Agent Gateway 的自研 MCP 网关将 Agent 连接到内部系统。每个 playbook 声明其所需的工具，Flux 只授予该任务所需的范围化权限。每次操作都会被记录，形成清晰的审计轨迹。
这种网关架构为我们提供了一个集中控制点，用于身份验证、授权、可观测性、使用跟踪和策略执行，所有这些都让 Agent 的访问更安全，也更容易大规模运维。
Playbook 定义工作内容
Playbook 是 Agent 工作的可复用单元——相当于 Flux 平台上技能和 Agent 驱动任务的 Docker 容器。它定义在单个标记式 YAML 文件中，打包了任务、输入、上下文、技能、工具、权限、验证、预期输出和安全边界，以确保工作执行的一致性。
Playbook 可以将提供灵活性和判断力的 Agent 步骤，与提供可预测性、更低成本和更易验证的确定性步骤相结合。这让团队可以在需求演进时，将逻辑在 Agent 驱动执行和传统代码之间迁移，而无需重新设计工作流。
调用入口：贴合开发者的使用场景
同一个 playbook 可以从 Slack、GitHub、cron、CLI 或对话技能触发。这意味着团队只需定义一次工作流，就可以从最契合当下场景的入口调用它：
- Slack：用于协作委派
- GitHub：用于 PR 和 CI 自动化
- Cron：用于定期维护
- CLI：用于开发者直接控制，或通过技能调用
这正是 Flux 易于采用的原因。
经验教训
构建 Flux 让我们在产品采用和基础设施两方面都收获良多，包括：
- 从小处着手，赢得信任。我们从自动化代码审查开始，而不是试图自动化整个软件开发生命周期。代码审查发生频率高、可衡量，而且工程师很容易评估其质量。它为我们提供了一个生产工作流，让我们可以在扩展到 CI 故障分流、值班任务、维护 playbook 和工单驱动开发之前，先调整质量、延迟、成本和表现。
- 让工作可见。我们的第一个 Slack 集成为每次 Agent 运行创建了私密频道。这虽然让 Flux 对个人很有用，但并没有形成团队习惯。将工作转移到公共线程后，采用模式发生了改变。工程师可以看到其他人委派了什么，观察 Flux 的进展，审查输出结果，并共同建立信任。
- Playbook 需要赋能。可复用的工作流不会仅仅因为平台存在就自动出现。工作坊和黑客松帮助团队将重复的运维工作转化为 playbook。原语让自动化成为可能，赋能则帮助团队识别哪些工作流值得固化成 playbook。
下一步
我们将深入探讨支撑 Flux 运转的平台原语，以及构建新工作流的开发者体验。我们还会讨论在 Flux 之上构建的应用，包括我们的内部 Slack Agent——Flux Responder。
致谢
感谢 Adam Rogal、Adam Yarger、Andy Fang、Ashwin Kachhara、Fan Xia、Ivan Rudovol、Jason Prasad、Jialu Deng、Justin Block、Justin Deocampo、Justin Fan、Keith Lyall、Praneet Singh、Sean Chen、Tyler Berrett 和 Volanda Zhu 对平台和本文的贡献。
