一个月向生产环境交付 2500 个 PR,怎么做到的?——Grok Bot 团队 Lauren(@poteto)的答法不是"更多人盯",而是把工程团队的经验、约束与验证能力沉淀成运行环境,让智能体在较少人工盯防下持续交付。
PR 数量只是这套环境长期运行的结果,主线始终是"如何建立信任"。她把这种环境比作"米其林厨房":人仍然对产品结果负责,智能体则在被设计过的工具、流程与约束里完成大量具体工作。
她从一个真实的性能治理场景讲起:Cursor 的 Agent 窗口迭代太快,PR 进入的速度超过人工逐条审查性能回归的能力——她过去手工用 Chrome DevTools、性能 trace、heap snapshot 排查,后来把"运行应用、采集证据、定位热点、持续改善性能"整套动作编码给智能体。
她对变化的概括一针见血:工程师本人曾经就是吞吐瓶颈,团队需要把工程判断转化为可复用的环境能力。由此得到的规模化规律也很清楚:少量智能体可以靠人工持续校正,更大规模的并行需要可靠的行为边界——"高并发本身没有产生信任,可重复的证据链和更难犯错的系统结构才产生信任。"
她给出的四层能力是全文骨架:①直接验证(Control Glass)——智能体经 CLI 与 Chrome DevTools Protocol 运行应用、采集 trace 与 heap snapshot,用运行时证据确认功能与性能,不许只凭"能编译"或智能体自述下结论;②任务记忆(Feature map)——把功能入口、键盘操作、DOM 交互与功能含义存进代码库,让智能体能理解一张模糊的缺陷截图并复现具体场景;③工程 skills(pstack)——把调试、开发、原型、性能的经验写成 playbook 与 skills,"资深工程师的工作方式"变成团队可复用的执行步骤(其公开文档的原则是"直接检查真实产物":功能走完整链路、委派的工作查实际 diff 或运行行为);④架构约束(Dune)——用目录约定、导入依赖图与线程边界限制可选路径,让"简单路径"同时成为正确路径,在代码层面阻断已知反模式。
三大组织启示同样值得逐条抄:其一,代码库正在成为智能体的"物化记忆"——智能体会延续它读到的模式,好结构会被复制,临时 workaround 也会被复制;她用"花园"作比:及时清除会扩散的坏模式、维护一条清晰的 paved path——重心从"写下更多规范"转向"让规范体现为可执行结构"。
其二,纠错要按强弱顺序沉淀到约束系统:代码库与架构 → 静态分析 → 规则与 BugBot → 技能 → 人工风格审查——每当你需要重复纠正某类行为,就把经验固化成数据结构、依赖边界、lint、测试或自动化检查,下一次 agent 干活时直接继承改进后的环境。
其三,自动化要形成闭环——外环由 Grok Bot 连接 Slack、Datadog、Sentry、PlanetScale 等信息源、按事件触发任务;内环由 Cursor 自动化与 SDK 承担具体工程工作,目标链路是:缺陷报告进入 → 智能体自动复现 → 创建 PR。
我的看法:这篇是今晚所有工程线的总装配。四层里,直接验证=评测与证据链的执行版(57422 的评级、57585 的"能打开看才算数");任务记忆=知识线"存"的代码库形态(57513、57547 的目录与图谱,长进了仓库本身);skills=说明书族(57668 的 SKILL.md 纪律);架构约束=Mcode 事务哲学在目录层的镜像(57565:"简单路径=正确路径")——而"高并发不产生信任,证据链才产生信任"正是信任图谱那篇的中心句,这里给了它生产现场的答案。
三大启示里最妙的是"物化记忆":当代码库成为智能体读得进去的长期记忆,文档纪律与花园观其实是同一件事——你在给未来的 agent 写记忆(57459 的渐进披露,本质也是这件事)。
对读者最可操作的一条我放最后:先别急着买更多算力,先把你的纠错一层层沉到架构里——环境先行,交付量只是迟到的读数。
经验、工具名与数字均按发帖整理转述(源自 Lauren 的公开分享),以原分享与相关项目文档为准。