用十几个Agent搭建黑灯工厂：Lauren Tan的信任阶梯与米其林厨房

从「人肉代理」到「黑灯工厂」的跃迁

如果你还在逐个 micromanage 你的 AI 编码 Agent，那你可能错过了更大的图景。Lauren Tan——前 Meta React 团队成员、现 Cursor（已更名 SpaceX AI）工程师——最近分享了她用十几个协调 Agent 每月向生产环境合并超过 2,500 个 PR 的实践。这个数字背后不是疯狂堆砌 Agent，而是一套关于「信任阶梯」与「厨房环境」的工程哲学。

她在访谈中坦言，最初自己也陷入过每个 Agent 都要亲力亲为的泥潭：「我花了太多时间只是 micromanage 一个 Agent。」转折点在于她意识到，真正的瓶颈不是模型能力，而是人类作为「肉代理」（meat proxy）在 Agent 与工具之间传递上下文。要打破这个瓶颈，她必须重新设计 Agent 所处的环境，而不是试图直接改造 Agent 本身。

信任阶梯：从单兵作战到并行管理

Lauren 将 Agent 的采用过程描述为攀登「信任阶梯」。在低阶梯阶段，人类需要不断干预、验证每一步输出，信任度极低；随着环境与验证工具完善，Agent 可以承担更大责任，人类则逐步后退。

她强调，这个阶梯无法跳级。没有可靠的验证手段，就不可能有真正的信任，最终只能回到「锁死并 micromanage」的模式。因此，她花了大量时间构建一套名为 PStack 的开源技能体系，其中最关键的一环就是验证（verification）技能。

「即使你不使用 PStack 或我的技能，我认为你工具箱里最重要的技能应该是验证。」

验证技能的本质是给 Agent「手和眼睛」，让它能像真实用户一样运行代码、交互、抓取追踪信息并自行调试。没有这层能力，Agent 无法真正闭环迭代，人类就必须永远充当中间人。

厨房中的技术负责人角色

环境即一切：为什么米其林厨房比软件工厂更贴切

Lauren 并不喜欢「软件工厂」这个词，因为它容易让人联想到低质量与机械复制。她更倾向用「米其林厨房」来比喻理想的 Agent 工作环境——同样追求效率，但更强调工艺与品质。

在这个比喻里，人类工程师是主厨，Agent 是副厨。主厨不再亲自切每一颗蒜，但必须负责厨房的布局、食材的采购与储存、以及最终出品的把关。对应到工程实践：

技能（Skills） 是菜谱与操作流程
CLI 与确定性脚本 是厨房里的专用工具，比如压蒜器
Lint 规则与类型系统 是厨房的物理约束，让错误操作难以发生
验证循环 是试吃与品控环节

她特别指出，很多团队误以为 Agent 能力完全由模型供应商决定，人类无法干预。但实际上，代码库结构、约束规则、验证工具这些环境要素完全在工程师掌控之中，且对 Agent 表现影响巨大。

慢速切蒜的隐喻

验证：最重要的一项技能

在 Lauren 的实践中，验证是让信任阶梯真正运转的关键。她为 Cursor 的 Agent 窗口做性能优化时，第一个真正有效的技能就是让 Agent 能够自行运行性能分析、抓取堆栈快照并判断改进是否有效。

她借助「爬山」（hill climbing）的思路：给定一个评分标准或评估规则，Agent 可以在循环中不断尝试改进，因为验证环节让它能自主判断每次改动是否朝着正确方向前进。这使她从性能调优的微观管理中解放出来。

为了方便验证，她还将确定性部分抽离成自定义 CLI。例如，与 Playwright 和 Chrome DevTools 协议交互的「胶水代码」被封装成脚本，Agent 不需要每次重新发明轮子。她观察到，在缺乏 CLI 时，每个 Agent 都会重新构建一套自己的验证脚本，造成大量重复与速度损耗。

「我尝试把确定性的部分抽出来变成代码，只把真正需要判断力的部分留给 Agent。」

这一原则同样适用于代码迁移场景——通过 AST 爬取与 code mod 脚本实现机械转换，而不是让 Agent 每次凭「感觉」重写。

爬山（hill climbing） 是优化算法中的一种局部搜索策略：从一个初始解出发，迭代地尝试邻近解，若目标函数值改善则接受新解，否则保持原解，直到无法找到更优解为止。在 AI Agent 的上下文中，爬山比喻 Agent 在验证循环中不断尝试改进，每次根据评分标准（如性能指标、测试通过率）判断改动是否有效，从而自主朝着目标方向前进。Lauren Tan 借助这一思路，让 Agent 在性能优化等任务中自主迭代，而人类只需定义清晰的评估规则。这要求验证环节能提供即时、可靠的反馈信号，否则爬山过程可能迷失方向或陷入局部最优。

连接内外循环：让Agent自己找活干

每月 2,500 个 PR 并非来自 2,500 次手动对话。Lauren 将工作拆分为两个循环：

内循环：工程师与 Agent 在代码库中协作，围绕明确意图推进任务
外循环：Slack、X、邮件、Linear 等外部系统中的 Bug 报告、功能请求与讨论

过去，她是两个循环之间的「人肉摆渡车」，不断把外部上下文搬运给 Agent。现在，她使用 GrokBot 这类工具订阅 Slack 频道、X 提及或 Linear 问题，并通过 MCP 或自建连接器将信息直接送入 Cursor 的项目（Projects）协调 Agent。

Agent持续监控外部渠道

Cursor 的 Projects 功能提供了「协调 Agent」（coordinator agent），它不亲自干活，而是像行政总厨或幕僚长一样分配任务、监督子 Agent。当突然涌入大量 Bug 报告时，协调 Agent 能判断最佳拓扑结构，将任务高效分发给子 Agent 团队。Lauren 目前拥有超过 10 个这样的「幕僚长」，各自负责不同领域——性能、用户 Bug 修复、甚至探索用不同语言重写应用。

自动化评审与「黑灯」边界

面对「你怎么评审 2,500 个 PR」的质疑，Lauren 的回答是：采样，而非全量阻塞。

她会在每天固定时间抽查已合并的 PR，严格审视代码质量，寻找 Agent 重复犯的错误模式。如果某个问题只出现一次，可以放过；但如果多个 Agent 反复走同样的捷径或传播同样的临时方案，那就说明环境需要修正——应该调整 lint 规则、类型约束或技能，而不是去责怪单个 Agent。

她的 Agent 被设置为全自动驾驶模式：每个 PR 会触发严格的验证循环，生成多个验证 Agent 进行模糊测试（fuzzing）——实际运行应用、模拟人类点击、寻找回归与 Bug，然后自行修复并重复，直到 PR 达到可合并状态。这个过程 token 消耗很大，但可以调节验证 Agent 数量。

「我早上醒来后查看提交历史来评审。如果发现问题，我就去纠正、回滚、添加新的 lint 规则。」

她坦言，第一天开启这种「黑灯」模式时非常害怕，担心造成线上事故。但环境与验证的双重保障最终让她能安心入睡。

验证与环境的组合是关键

不是所有领域都能黑灯

Lauren 审慎地指出，这套方法高度依赖于工作的可验证性。软件工程中的许多任务可以程序化验证，因此单向门（one-way door）可以变成双向门（two-way door）——合并后可回滚。但对于医疗、法律、金融等验证困难的领域，全自动驾驶的 PR 合并并不现实。

她将希望寄托于更面向 Agent 的编程语言，例如将编程与数学证明结合的 Bend。如果证明能表明代码在所有情况下正确，那么合并就不再需要人类逐行审查。但这一天尚未全面到来。

单向门与双向门（one-way door / two-way door） 是产品与工程决策中的经典隐喻，由 Amazon 等公司推广。单向门决策不可逆或逆转成本极高（如数据模型重构、公开 API 变更），需要谨慎缓慢；双向门决策则可快速回滚（如功能开关、UI 调整），适合快速试错。在 AI Agent 自动合并 PR 的场景中，Lauren Tan 指出，由于软件工程的可验证性，许多原本的单向门操作（如合并代码）通过完善的验证循环和回滚机制变成了双向门——合并后若发现问题可立即回退。这种转变是「黑灯工厂」模式的前提，也是其局限于高可验证性领域的根本原因。

技能即语言：每个人都该有自己的刀

访谈最后，Lauren 与主持人 Gary 达成共识：技能本质上就是流程的语言化，是 Markdown 文件，没有任何魔法。真正的价值在于把抽象流程提炼成清晰文字时所付出的思考。

她鼓励开发者不要只照搬他人的技能库，而要回看自己的历史对话记录，找出自己反复纠正 Agent 的地方，将其转化为可复用的技能或 lint 规则。她自己在 PStack 中的 recall 技能就源于此：每次开启新对话时，她希望把上一个对话中的宝贵上下文压缩并带入新会话，于是把这一工作流固化成了技能。

「每个厨师去新餐厅工作时都会带上自己的刀。工具跟着人走。信任本质上是对你自己工具的信任。」

随着模型能力提升，技能文件可以变得更小、更聚焦于工作流本身，而把实现细节交给模型自行判断。Lauren 预测未来的技能会越来越紧凑，而 PStack 与其它技能库完全可以混搭组合——关键在于你是否愿意花时间磨快自己的刀。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出的开放协议，旨在标准化 AI 助手与外部数据源、工具之间的连接方式。它定义了一套客户端-服务器架构：MCP 服务器暴露资源（如文件、数据库）、工具（可执行函数）和提示模板，AI 应用（客户端）则通过统一接口调用这些能力。在本文语境中，MCP 充当了连接外部系统（Slack、Linear 等）与 Cursor 协调 Agent 的桥梁，使 Agent 能直接订阅事件、获取上下文并触发动作，而无需工程师手动搬运信息。这大大简化了集成工作，让 Agent 能自主感知外部循环的变化，是实现「Agent 自己找活干」的关键基础设施。