DoorDash 的 Flux 通过云代理运行 13 万项工程任务

DoorDash 将工程代理工作负载从开发者笔记本迁移到其 Flux 云平台，原因是本地执行存在多重限制。本地执行受限于可用 CPU 和内存，依赖开发者设备保持连接，并且可能让自主代理访问开发者已有的凭据和内部系统。此外，本地执行使得监控代理运行位置、访问的系统以及代表谁操作变得更加困难。

DoorDash 安全架构师 Radoslav Krehlik 在 LinkedIn 上表示，Flux 是在笔记本代理遇到电力、正常运行时间和安全限制后构建的。工程师可以从 Slack、GitHub 或定时任务触发代理，同时 DoorDash 保持完整的企业安全护栏。

Flux 围绕四个平台原语构建：云沙箱、MCP 网关、可复用 playbook 和调用面。Playbook 定义工作内容，沙箱提供隔离执行环境，网关控制对内部系统的访问，调用面允许通过 Slack、GitHub、cron、命令行或对话界面启动工作流。

沙箱使用 Firecracker 微虚拟机隔离代理工作负载。每个环境预置了任务所需的仓库、开发工具、密钥和运行时依赖。DoorDash 报告 95 分位端到端沙箱设置时间少于 5 秒，包括启动微虚拟机、克隆仓库、安装构建工具和配置编码代理框架。

代理通过 Agent Gateway（内部 MCP 网关）访问 DoorDash 内部系统，该网关提供范围化权限并记录代理活动以供审计和策略执行。Playbook 以 YAML 定义，指定任务、所需工具、权限、验证和安全边界，并可将代理驱动步骤与确定性代码结合。

Flux 最初用于自动代码审查，DoorDash 称这是一个频繁且可测量的工作流。随后扩展到 CI 分流、值班任务、维护工作流和工单驱动开发。平台支持超过 300 个 playbook，每周超过 10,000 次调用，工作流可无人值守并行运行。

DoorDash 还将 Slack 集成从私密频道改为公共线程，以便工程师观察代理执行、审查结果，并了解其他团队如何委派工作。这种透明度有助于建立信任和协作。

TOP GROUP Vietnam 联合创始人 Duy Nguyễn 在 LinkedIn 上评论，一旦代理处理后台工作、代码审查、内部工具和并发执行，难题就从模型选择转向控制：身份、权限、沙箱、审计日志、配额和真正的终止开关。

这一观点与 Flux 的设计相呼应：通过 MCP 网关实现范围化权限和审计，通过 Firecracker 沙箱实现隔离，通过 playbook 定义安全边界。控制机制成为大规模代理部署的关键。

Flux 的做法是编码代理向云执行迁移的更广泛运动的一部分。GitHub 支持 Copilot 的本地和云沙箱环境，并提供对文件系统、网络和系统访问的控制。其云沙箱为代理提供隔离环境，执行编码任务而不消耗本地开发者资源。

这表明，随着代理承担更多关键任务，云执行和集中控制可能成为标准实践，而本地执行的安全和资源限制推动这一转变。