把智能体赶出笔记本：DoorDash 一个月让云端代理干完 13 万个工程任务

想象这样一个场景：一位工程师在 Slack 里丢下一句话，几分钟后，一个隔离环境自动拉起，代码克隆完成、依赖装好，智能体开始读仓库、跑测试、提 PR。整个过程不需要他的笔记本一直开着，也不占用本地那颗已经发烫的 CPU。这不是演示视频，而是 DoorDash 过去一年真实跑起来的日常。

一分钟速览

• DoorDash 把工程智能体从开发者笔记本迁到自研云平台 Flux，2026 年单月自动化完成 13 万个工程任务。
• 平台每周支撑超过 2.5 万次自动化代码审查、300 多个 Playbook、1 万多次触发调用。
• Flux 由四个原语搭起来：云端沙箱、MCP 网关、可复用 Playbook、多入口触发。
• 沙箱用 Firecracker 微虚拟机隔离，端到端搭建的第 95 百分位目标压在 5 秒以内。

为什么非要把智能体搬上云

把编码智能体放在开发者笔记本上，最初看起来是最省事的选择：环境现成、凭据现成、代码就在本地。但一旦智能体从「帮我看一眼」变成「替我干一整晚」，本地执行的三个天花板就同时压了下来。

第一是算力。笔记本的 CPU 和内存要同时服务人和其他进程，智能体并行跑几个任务就开始互相抢资源。第二是在线时间。人下班合盖，智能体也跟着停摆，长任务根本跑不完。第三是安全与可观测性。自治智能体继承了开发者本人的凭据和内部系统权限，一旦它访问了不该访问的东西，事后很难还原「它是代表谁、在什么时候、动了什么」。

DoorDash 的解法是把执行环境整体外移。Flux 不再依赖任何一台具体的开发机，任务从 Slack、GitHub、定时任务、命令行或会话接口发起，执行发生在云端，人不在场也能跑完。

四个原语，把「能跑」变成「可控」

Flux 的架构并不复杂，难的是把边界划清楚。它由四个部分构成。

云端沙箱负责隔离。每个任务跑在独立的 Firecracker 微虚拟机里，环境预先配置好仓库、开发工具、密钥和运行时依赖。官方给出的目标是端到端搭建的第 95 百分位在 5 秒以内——包括启动微虚拟机、克隆仓库、安装构建工具、配置编码智能体的 harness。这个数字很关键：如果拉起环境要等两分钟，工程师就不会把高频小任务交给它。

MCP 网关负责权限。智能体不直接连内部系统，而是走统一的 Agent Gateway，权限按任务收窄，每一次调用都留痕，供审计与策略执行使用。这一层决定了智能体能「看见」什么，也决定了出事时能不能查。

Playbook负责标准化。用 YAML 定义任务、所需工具、权限、校验方式和安全边界，把智能体步骤和确定性代码混排：需要可预测结果的地方用脚本，需要判断的地方交给模型。300 多个 Playbook 意味着跨团队复用，而不是每个组从零写提示词。

触发面负责入口。Slack、GitHub、Cron、CLI、会话接口都能发起同一套工作流，工作流之间可以无人值守并行。

从代码审查长出来的平台

有意思的是，Flux 并不是按「平台」设计的。它最初只做一件事：自动代码审查。这是典型的高频、边界清晰、效果可衡量的场景，每周 2.5 万次的量级足以把流程磨顺。跑通之后，DoorDash 才把范围扩到 CI 分流、值班任务、日常维护和工单驱动的开发。

另一个细节值得注意：DoorDash 把 Slack 集成从私密频道改成了公开讨论串。表面上是工具调整，实质是把智能体的执行过程暴露给同组工程师看——谁能看到它怎么想、怎么错、怎么被纠正，谁就能判断该不该把更多任务交给它。这种「可见性」往往比准确率更能决定一个智能体平台能不能活下来。

趋势洞察：竞争点从模型转向控制面

当智能体开始承担后台工作、代码审查和并发执行，难点就不再是选哪个模型，而是身份、权限、沙箱、审计日志、配额和一个真正管用的终止开关。GitHub 给 Copilot 同时提供本地与云端沙箱，也是同一个方向：把执行从「人的机器」搬到「受控的环境」。

对国内团队来说，这件事的启示不在于照抄 Flux，而在于先回答三个问题：智能体用的是谁的凭据，出了问题能不能追到具体的一次调用，以及一个任务的成本上限由谁设定。这三个问题答不上来，智能体规模越大，风险越不可控。DoorDash 的 13 万个月度任务，本质上是用工程手段把这三个问题变成了可配置项。