一、引言：一觉醒来，20个PR自己合进了主干
2026年8月，SpaceXAI的Grok Bot工程师Lauren Tan（@poteto）在团队工作坊分享了一张GitHub贡献曲线——五个月，超过3000个PR。她同时运行20多个AI智能体，个人月交付量突破1000个PR，团队月交付量直逼2000+。
“一觉醒来，20个PR已经躺在主干分支上了。而且翻了一遍，写得还不错。”
她自己也承认，这话听着像批量制造垃圾代码。但她紧接着补了一句：“我保证我不是。”
这位Lauren Tan不是普通人。她是前Cursor工程师，曾在Meta和Netflix任职，在Netflix担任过两年工程经理，现在负责SpaceXAI的Grok Bot工程团队。她的核心实践——pstack——已经开源在Cursor官方插件仓库中（GitHub: cursor/plugins/pstack），成为多智能体工程领域最受关注的工程实践之一。
来源：36氪《一觉醒来20个PR自己合进了主干》（2026-08-31）；Lauren Tan Maven工作坊分享
二、信任曲线：从\”盯着一个智能体\”到\”撒手20个智能体\”
Lauren分享了一张她称之为\”信任曲线\”的图表。纵轴是信任度，横轴是同时运行的智能体数量，从1到成千上万。
信任度
^
| ____________________
| / \\ ← 当前阶段 (10-20 agents)
| / \\
|/ \\
| \\
| \\
| \\___________
+——————————————-> 同时运行的智能体数量
1 5 10 20 50 100
↑ ↑
五个月前 Star Trek 级
(盯着1个agent不敢眨眼) (尚未到达)
一年前，几乎没人用智能体写代码。模式是：你盯着屏幕，每一行输出都要看，一句一句地提示。无法并行，因为你不信任它。
信任崩塌的典型时刻：有一次她报了个bug，问智能体某个功能为什么不工作。智能体一口咬定是某个地方的问题。她翻开工具调用记录一看——它压根没读那段本该相关的代码。
“智能体在猜，而且它不知道自己在猜。”
Lauren在Netflix当过两年工程经理，她发现——管人的技巧和管智能体的技巧，重合度高得惊人。
三、核心实践一：给智能体造一双眼睛（Control Glass + Feature Map）
Lauren认为，最重要的技能不是提示词，而是验证。
她对验证的定义是：让智能体真的能把代码跑起来——能抓CPU耗时记录，能抓内存快照，能自己打开iOS模拟器点一遍。用户在你的应用上怎么用，它就怎么走一遍，然后自己测，自己验。
没有这一层，瓶颈就是你自己。
传统的开发循环是：你让它改个东西→它写完→你打开本地构建发现不对→截图→复制控制台报错→粘回去→它慢慢理解→再改一版。你在这个循环里当\”人肉传送带\”。
所以Lauren进Cursor后写的第一批技能之一，叫control glass。这个技能教智能体自己去调Chrome DevTools协议，自己跑起应用，自己截图、点击、读控制台。
但光有control glass还不够——智能体能跑起来应用了，但它不知道这个应用是什么。于是配套的feature map出现了。
┌──────────────────────────────────────────────────┐
│ Feature Map 结构 │
├──────────────────────────────────────────────────┤
│ Feature: 左侧栏卡顿 │
│ ├── 入口: 主窗口左侧导航面板 │
│ ├── 快捷键: Cmd+1 │
│ ├── DOM 选择器: #sidebar-panel │
│ ├── 预期交互: 点击菜单项 → 加载内容 → 渲染 │
│ ├── 验证方式: │
│ │ ├── 截图对比 (pixel diff) │
│ │ ├── 控制台日志检查 (error/warn filter) │
│ │ └── 性能指标 (FPS < 55 即视为异常) │
│ └── 关联文件: │
│ ├── src/sidebar/SidebarPanel.tsx │
│ ├── src/sidebar/hooks/useSidebar.ts │
│ └── src/sidebar/styles/sidebar.css │
└──────────────────────────────────────────────────┘
Feature map把每个功能从用户视角怎么进入、快捷键是什么、甚至选元素该用哪个属性都列好。效果立竿见影——Cursor内部有个Slack频道收用户反馈，质量普遍很差，很多人就丢一张截图配三个问号。有了feature map，智能体也能顺着查下去。
Benny：值夜班的自动化Bug修复智能体
Benny是Lauren开发的自动化智能体，也是Grok Bot的前身。它在Slack里专门接bug报告，跑到云端开一台自己的电脑，在里面运行Cursor，用同一套control glass技能操作应用，试着把问题复现出来。
有一次，它这样回话：在修复前的提交上复现出来了，修复后消失。附上一条云端运行记录的链接，你想翻就能翻。
它给的不是一句\”应该已经修好了\”，而是一组能对照的证据。
关键设计：Lauren用了一套\”盲测\”机制来验证技能本身——她派出一堆子智能体跑评测，给它们的目录起一些看不出来的名字，不让它们知道自己正在被评估。再叫一个不同模型家族的智能体当裁判，交叉复核，防止自评偏袒。分数不满意就用/loop接着刷，一直刷到10分。
四、核心实践二：Dune架构——把每句代码评审都变成红灯
Lauren敢撒手，靠的不是模型变强，是让护栏变硬。
Grok Bot的架构有个内部代号叫Dune。她的形容是——可以理解成给Electron应用的Next.js，专门为智能体书写而设计。
4.1 禁用useEffect
写过React的都知道useEffect是最大的坑之一。在Dune里，useEffect被禁用了——用了CI直接报红。
4.2 禁用代码注释
智能体写的注释99%都在描述一些跟代码无关的历史片段。它会写下\”Lauren说永远不要这么干\”——可她当时的意思只是这个PR很烂，你改一下那部分，根本不是什么全局规则。
所以，凡是智能体干不好的事，一律封杀。
4.3 进程隔离
Electron有渲染线程和主线程。agents window在这块分得不清楚，经常有代码被误拉进渲染线程。要跑60帧，每帧只有16毫秒预算，一旦混进重计算或者大量IO，画面立刻开始卡。
Dune的做法是直接分出electron main和electron renderer两个目录，CI去检查依赖图，跨目录乱引用直接失败。
4.4 分层护城河模型
┌──────────────────────────────────────────────────────────────┐
│ 分层护城河模型 │
├──────────────────────────────────────────────────────────────┤
│ 第1层（最硬）: 代码库架构本身 │
│ ├── 目录结构强制分离 (electron main vs renderer) │
│ ├── 唯一正确的写法 = 唯一可能的写法 │
│ └── 智能体天然爱抄现成模式，把正确写法做成唯一写法 │
├──────────────────────────────────────────────────────────────┤
│ 第2层（硬约束）: CI / Lint / 编译器诊断 │
│ ├── useEffect → CI报红 │
│ ├── 代码注释 → CI报红 │
│ ├── 跨目录引用 → 依赖图检查失败 │
│ └── 构建变红 = 不可合并 │
├──────────────────────────────────────────────────────────────┤
│ 第3层（软约束）: Rules / Skills / 代码审查Bot │
│ ├── 智能体会忘，会漏，不会稳定执行 │
│ ├── 需要配合审计和定期检查 │
│ └── 仅靠这一层，代码库变垃圾只是时间问题 │
└──────────────────────────────────────────────────────────────┘
Lauren的原话：
“如果你只有规则、机器人、技能和一份代码风格指南，你的代码库变成一堆垃圾只是时间问题。”
核心哲学：最短的路，就是最好的路。智能体解决问题时永远挑最省事的方式，那就把最省事的方式做成最正确的方式。
把Grok Bot重构到这套架构，用掉了600多个PR——还债的成分居多。
五、pstack插件系统：多智能体调度的工程化实现
pstack是Lauren开源的多智能体编排系统，发布在Cursor官方插件仓库中。它不仅仅是一个prompt集合，而是一个完整的工程化套件。
5.1 pstack架构概览
┌─────────────────────┐
│ /poteto-mode │ ← 入口路由
│ (主调度器) │
└──────────┬──────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 21条工程原则 │ │ 22个任务Playbook│ │ 23个工作流技能│
│ │ │ │ │ │
│• Laziness │ │• Bug fix │ │• /how 系统追踪│
│• Prove It │ │• Feature │ │• /why 历史分析│
│ Works │ │• Refactoring │ │• /architect 设计│
│• Boundary │ │• Perf issue │ │• /arena 竞争设计│
│ Discipline │ │• Orchestrate │ │• /swarm 并行覆盖│
│• Guard Context│ │• Autopilot │ │• /interrogate 审查│
│ Window │ │• Babysit │ │• /recall 上下文恢复│
└──────────────┘ └──────────────┘ └──────────────┘
│
▼
┌─────────────────────┐
│ 多模型分发引擎 │
│ │
│ Sol → 精确代码实现 │
│ Grok → 快速机械工作 │
│ Fable → 判断与文案 │
│ Opus → 审查面板 │
└─────────────────────┘
5.2 核心代码：多智能体调度器
以下是一个基于pstack思想的简化多智能体调度器，用Go语言实现：
package main
import (
\”context\”
\”fmt\”
\”log\”
\”sync\”
\”time\”
)
// Agent 代表一个智能体实例
type Agent struct {
ID string
Role string
Model string
Playbook string
Status string // idle, running, blocked, done, failed
Goal string
Result *AgentResult
}
// AgentResult 智能体执行结果
type AgentResult struct {
PRs []string
Decisions []Decision
Evidence []Evidence
Error error
}
// Decision 决策记录
type Decision struct {
Time time.Time
Phase string
Action string
Reason string
Evidence string
Outcome string
}
// Evidence 验证证据
type Evidence struct {
Type string // screenshot, trace, log, snapshot
Content string
Passed bool
}
// Orchestrator 多智能体编排器
type Orchestrator struct {
agents map[string]*Agent
playbooks map[string]*Playbook
mu sync.RWMutex
decisionLog []Decision
}
// Playbook 任务剧本
type Playbook struct {
Name string
Steps []Step
Parallel bool
}
// Step 任务步骤
type Step struct {
Order int
Description string
AgentRole string
VerifyFunc func(*Agent) bool
}
// NewOrchestrator 创建编排器
func NewOrchestrator() *Orchestrator {
return &Orchestrator{
agents: make(map[string]*Agent),
playbooks: make(map[string]*Playbook),
}
}
// RegisterAgent 注册智能体
func (o *Orchestrator) RegisterAgent(a *Agent) {
o.mu.Lock
