一个 24/7 代理团队如何成形：SpaceXAI 工程师 Lauren Tan 把工程判断写进系统

一夜自动合并 20 个 PR，前面是 600 多个重构 PR

Lauren 的主体分享从视频约第六分钟开始。她接手的是一套真实运行、又带着绿地项目典型风险的 GrokBot 代码库：原型生成得很快，代码却没有稳定护栏。

Lauren 说，她已经很少亲自看代码。某天早上醒来，大约 20 个 PR 已由代理自动合并；上一个月她提交了约 1000 个 PR，当月才到第 12 天，又接近 800 个。

这些数字都来自她的现场自述，公开视频没有附上可独立审计的仓库和 PR 清单。它们可以说明交付规模，却不能直接证明代码价值、缺陷率或普遍生产率。

她还解释了为什么主动让代理拆分任务：单个 PR 可能只有几十行，也可能达到数百乃至上千行，并没有固定上限。她看重的是让每次提交尽量原子化地说明一小块改动，使 Git 历史继续成为理解上下文、回滚改动和定位缺陷的工具，而非做高 PR 数量。一个四万行的大 PR 即使合并成功，也很难回答问题究竟从哪里开始。

真正值得先看的，是这四个数字之间的关系。

20 个自动合并 PR 是输出端，600 多个重构 PR 是基础设施端。中间是一套重新设计过的代码库，单靠更聪明的提示词填不上这段距离。

GrokBot 最初是一个快速生成的绿地应用。速度很快，架构却会自然长成“代理当时最方便怎么做，就怎么做”的样子。每个任务都能局部完成，长期叠加后，目录、依赖、进程和状态管理开始互相缠绕。代理也许还能继续改，人类却越来越难理解和信任它。

Lauren 的选择是为代理重建工作环境。她把这套 Electron 架构叫作 Dune。目标是减少代理每次做决定的数量，让结构替它承担抽象原则。

让正确路径成为最短路径：Dune 如何约束代理

Dune 有一个很强的设计判断：代理喜欢走捷径，那就把最短路径设计成正确路径。

这句话比“给 AI 写一份更完整的编码规范”更具体。编码规范要求代理每次都记住、理解并主动服从；架构约束则直接改变它能看到的选项。

缩小错误空间把“请记住规范”改造成代理无法轻易绕过的路径

1. 功能共置一个功能的状态、组件与逻辑尽量放在一起
2. 进程边界主进程与渲染进程职责明确，避免重任务挤占界面
3. 依赖图检查跨层、跨进程导入由 CI 机械阻止
4. 危险模式禁用针对代理反复滥用的模式设置 lint 或编译门

第一层是功能共置。一个功能的大部分代码放在同一目录，代理不必跨多个共享目录寻找状态、组件和业务逻辑。它只需要识别“我正在改新手引导”，就能把主要工作限制在对应功能目录内。

第二层是进程边界。Electron 的主进程和渲染进程承担不同工作。计算或 I/O 一旦误入渲染侧，就会和界面绘制抢时间。60 FPS 意味着每帧只有约 16 毫秒，重任务越界很容易造成卡顿。Dune 用明确目录和导入图检查阻止这种依赖穿越。

第三层是把已知危险模式直接禁掉。Lauren 举了两个激进例子：禁止直接使用 useEffect，也禁止普通代码注释。这两样东西不一定永远错误；她针对的是代理反复滥用它们。尤其是注释，模型很容易把一次 PR 讨论中的临时意见写成永久规则，留下与当前代码无关的历史说明。

这些规则未必适合所有团队，但背后的方法可以迁移：找到代理最常走的坏捷径，先问能否通过 API、目录、类型或依赖关系让它根本走不进去。

把人工提醒改造成 CI：人的判断如何提前进入系统

代码审查里反复出现的同一句话，是一条尚未被编译进系统的规则。

如果工程师每周都要评论“这个依赖不能从渲染进程引入”“这里不能直接读共享状态”“这个功能必须放进自己的目录”，团队其实是在用最昂贵、最慢的方式执行约束：等错误发生，再让人发现。

Lauren 给出的迁移顺序很清楚：

最后一行很重要。Rules、Skills 和 BugBot 都有价值，但它们是较软的约束。代理可能漏读、误解或在长任务中忘掉。架构、类型系统、编译器和 CI 会给出机械结果，不能靠一句“我已经遵守”绕过去。

她用 Rust 举了一个具体例子：严格的编译器和借用检查器会在代码审查前淘汰一大类错误。这个例子不要求所有团队改用 Rust，它说明技术栈本身决定了多少工程判断能在人工介入前被机械执行。

于是，人类并没有退出工程判断。人的工作位置发生了变化：从逐个 PR 重复提醒，移到提前设计接口、错误空间和通过条件。

这种前置设计会消耗重构时间和 token，但回报不只属于最强模型。边界足够明确后，能力较弱的代理、新加入的工程师，甚至不熟悉完整代码库的产品和设计人员，也更容易在同一套护栏内安全贡献。

验证能力决定并行上限：代理必须能自己运行产品

架构可以让代码更像样，CI 可以挡住已知坏模式，但两者仍不能证明用户看到的功能真的可用。

Lauren 把验证称为代理工具箱里最重要的能力。这里的“验证”远不止跑单元测试。代理要能启动应用，进入用户报告的界面，执行操作，复现问题，采集 CPU trace 或 heap snapshot，完成修改，再用同一条路径检查问题是否消失。

如果这条回路缺一段，人类就会成为转接员：代理写代码，人打开开发版本；人发现按钮没反应，再复制控制台错误；代理修改后，人重新点一遍。一个代理还能勉强配合，十个代理就会把同一个人堵死。

功能地图解决的是“代理不知道产品在哪里”的问题。用户会说“左侧边栏很卡”或只发一张截图和三个问号，代码库里却没有一个文件叫“用户看到的左侧边栏”。功能地图从用户视角记录入口、子功能、快捷键、DOM 选择器和代码位置，让模糊报告能落到可操作路径。

这套思路后来进入 PStack。Cursor 官方仓库公开的 create-verification-skill 仍保留同一原则：从代码库识别用户实际接触的界面，为主要功能建立地图，实际启动产品，驱动至少一个功能，保存证据，清理环境后确认取证结果仍存在。没有亲自跑过的验证 Skill，只能算草稿。

Skills 也要被测试：PStack 如何从代理失败中长出来

Lauren 说，PStack 并不是先设计出一套宏大方法论，再把它分装成 Skills。它从观察失败开始。

代理没有读相关代码就自信判断根因，于是产生一条要求先检索证据的 Skill；代理不会操作真实应用，于是产生 Control Glass 和验证 Skill；代理找不到用户口中的功能，于是补出功能地图。

能力回归测试Skill 从失败样本中生长，也必须回到失败样本中接受测试

观察具体失败→写成可执行 Skill→定义评分标准→多模型隔离执行→比较回归结果通过：首次接触代码库的代理也能完成任务并留下证据

Skill 写出来仍未结束。她把评测理解成“代理的单元测试”：先为任务制定评分标准，在隔离目录或 worktree 中启动多个子代理，让不同模型执行同一任务，再由协调代理或另一个裁判模型评分。修改 Skill 后重新运行，观察它是否更稳定地导向目标结果。

她甚至会给评测目录起不显眼的名字，避免代理意识到自己正在参加测试后改变行为。如果一条 Skill 只有在代理知道自己被评测时才有效，结果就不可靠。评分还可以由另一种模型交叉检查，再让循环持续修改 Skill、重跑任务，直到失败模式真正收敛。

这给团队一个很实用的判断标准。Skill 的质量不能由文档篇幅证明，要看第一次接触代码库的代理是否能按它完成任务，是否留下可检查证据，换一个模型后是否仍能工作，失败时能否定位到 Skill、环境或任务本身。

这套循环还会改变团队知识的形态。传统经验常散落在资深工程师的审查评论、口头提醒和事故记忆里。代理团队需要把它们变成可以分发、执行、评分和回归的工程资产。

从本地观察到自动合并：信任必须逐级购买

Lauren 没有建议团队第一天就启动几百个云端代理。她的顺序恰好相反：从本地开始，打开工具调用，观察代理读了什么、没读什么、怎样失败，再补架构、验证和 Skills。

当本地验证稳定后，任务才迁到云端。她举了一个叫 Benny 的代理：错误报告到来后，Benny 启动云端桌面，运行 Cursor，使用同一套操控 Skill 尝试复现，再判断主分支是否已经修复。现场案例里，它确认问题已在主分支修复，剩下的动作只是发布一个新构建。它交回复现结果、环境状态和下一步动作，而非一句“可能是这里”。

信任逐级购买模型能力只是一部分，权限取决于证据与可逆性

1. 本地观察看清代理读什么、怎样失败
2. 受控改动限制目录、权限和任务边界
3. 独立验证能运行真实产品并留下证据
4. 云端执行隔离环境、独立分支、可审计
5. 错误分诊复现、判断状态并交回下一步
6. 自动合并机械门禁、短回滚与上线监控齐备

公开版 Cursor Cloud Agents 的实现已经更产品化。官方文档说明，每个代理运行在独立 VM，克隆授权仓库，在独立分支工作，并以草稿 PR 交接；网络出口、密钥、审计和仓库权限仍需要团队配置。Cursor 的安全说明也明确把人工复核写进默认交接流程。

自动合并比云端运行多跨了一道门。前者只是代理在哪里执行，后者决定代理能否改变主分支。要开放这项权限，团队至少要证明：任务边界清楚；架构能机械阻止高风险错误；代理会运行真实产品；失败证据可追踪；回滚路径足够短；监控能发现上线后的异常。

产品经理和设计师能直接贡献代码，也来自同一个条件。系统先把可接受的改动范围收得足够清楚，让不熟悉整个代码库的人和代理都不容易越界，参与门槛才会真正下降。

PR 数量不是生产率：这套方法能学什么，不能照抄什么

这场分享很容易被误读成一套高产秘诀：多花 token、重写代码库、让代理自动合并，然后用 PR 数量证明效率。

PR 数量只记录改动被切成了多少份。一个大任务可以拆成十个 PR，同样十个 PR 也可能只是小修复。它没有自动包含缺陷率、返工、回滚、用户价值、交付时间和维护成本。

METR 在 2026 年更新开发者生产率实验时给出了一个很能说明问题的边界：晚 2025 工具的原始数据出现了加速迹象，但参与者选择偏差、较低报酬和多人同时运行代理造成的计时困难，让研究团队认为这些数据只能提供很弱的幅度证据。研究更新甚至专门指出，并行代理让“一个任务花了多少人类时间”更难测量。

单个高产工程师的 PR 数字更不能替代生产率研究。更合理的团队指标应同时看：从需求到可验证结果的时间、人工介入次数、缺陷与回滚、验证证据完整度、改动可逆性，以及最终业务结果。

绿地和棕地也不能采用同一条改造路线。全新应用最容易快速生成，也最容易在没有护栏时失控，所以适合从第一天设计代理友好边界。成熟代码库如果已有严格类型、测试、权限和大规模工程规范，可能已经比新项目更适合代理。全面重写只有在现有结构无法提供机械边界、迁移能够分阶段验证时才值得考虑。

Lauren 还指出，大型科技公司为数量庞大、能力和经验不同的人类工程师建立的框架、约定、权限限制和防误操作设施，恰好也能约束代理。代理工程并非凭空出现的一门新学科；很多有效基础设施，只是把原来为人类组织设计的护栏重新用于模型。

模型调用和过夜运行的成本也必须单独核算。视频里的 token 投入没有给出可复用的成本表，末尾对具体模型、价格和能力的现场讨论也会随产品更新而失效，因此不能拿来承诺另一支团队的预算或产出。

因此，真正可复制的成果不是“每月 1000 个 PR”。它是一套逐步降低人类同步成本的方法：先收窄代理的错误空间，再让代理独立验证结果，把重复失败写成经过评测的能力，最后根据证据开放更多权限。

一支 24/7 工作的代理团队，并没有消灭人的判断。它把人的判断从深夜逐行看代码，提前搬到了白天设计系统、定义完成条件和检查证据的地方。