很多人想一口气开 100 个 Agent。在这场约一小时的 Maven 工作坊里，Cursor 的 Lauren Tan 讲了个更朴素的道理：一个 Agent 的产出你都信不过，开再多也只是给自己添更多要检查的活。她的顺序是：先能验证，再在代码库里加护栏，最后才是放量。下面是我整理的长版笔记。
先看视频
视频来源：YouTube · X 转发 @0xlangeai · 工作坊页面 Maven。
本文基于自动转写整理，人名、产品名和数字可能有误听，引用前请对照视频。
Lauren Tan 是谁
Lauren Tan（网名 Potato）做这场分享时在 Cursor 工作了大约五个月。之前她在 Meta 的 React 团队做 React 编译器，更早在 Netflix 当过约两年的技术负责人兼工程经理。这段带团队的经历，决定了她看 Agent 的角度。
真正的瓶颈是信任
她把管 Agent 比作管人。不信任团队，你就会事事盯着、处处检查，怕他们出 bug。Agent 也一样：它第一百次信誓旦旦说”找到问题了”结果又错了，信任就掉下来，你只能盯着它的每一步。
她也强调，AI 更像结对编程的搭档，不是替你思考的人。它写代码省下的时间，可能在审查时又赔回去。她推荐的一个习惯：先让 Agent 写方案（spec），你审过方案，再让它动手。
从事事盯着到放手
Lauren 用一条”信任曲线”描述自己的变化。一年前，她只用一两个 Agent，不停提示、逐条检查，谈不上并行。到 Cursor 这几个月，情况变了：现在有些 Agent 会自己合并 PR。她说有天早上醒来，已经有大约 20 个 PR 合进去了，她是事后在 main 上审的。
她在 Cursor 的第一个月很慢，还在熟悉代码库。信任上来之后，产出跟着上来：她提到某个月合了约 1000 个 PR，下个月到 12 号已接近 800 个。她也承认 PR 数量本身说明不了质量；她的意思是，检查没有消失，而是搬进了系统里。
验证是最关键的能力
她最看重的是验证：Agent 要能像用户一样使用应用——真的跑起来，抓 CPU trace 或堆快照，打开 iOS 模拟器，把关键流程走一遍。这不保证代码好看，但能把 Agent 推向写出对的代码。
没有这一步，你自己就成了验证员，也成了瓶颈：你提需求，它写代码，你去跑，出错了，你把截图和报错贴回去，再来一轮。所有事都在等你，根本没法并行。
她举的例子是 Cursor 的 Agent 窗口。她刚加入时，那是一个几乎没有配套工具的 React 应用，上线期限又很紧。她用 Chrome DevTools 抓 trace 交给 Agent，换来的常常是自信但错误的猜测。
她为此做了两样东西：
- Control Glass：一个教 Agent 操控应用的技能（web 和 Electron 用 Chrome DevTools Protocol，iOS 模拟器用苹果的工具，再配些脚本）。代码不复杂，关键是这套流程能反复用。
- 功能地图（feature map）：一个文件，从用户视角写清每个功能在哪、有哪些子功能、快捷键和 DOM 选择器。有了它，哪怕是”左侧栏卡”或者一张带三个问号的截图这种模糊报告，Agent 也能对到具体位置去查。
P-Stack：把失败变成技能
这些东西后来整理成 P-Stack，一个 Cursor 插件（P 是 potato，调侃 Garry Tan 的 GStack）。它带的技能能为你的代码库生成验证技能和功能地图，并在应用变化时保持更新。
她是看着 Agent 犯错一点点攒出来的。有一次 Agent 信誓旦旦地指认某个组件有问题，其实根本没读过相关代码——她是翻开工具调用记录才发现的。于是有了一条规则：别猜，去读代码。类似的还有：真去搜代码库、该用子 Agent 就用、没验证过别说修好了。
她的管理类比是：把 Agent 当成一个刚入职五秒、代码能力很强但完全不懂业务的工程师。技能就是一份 Markdown，但它是把业务背景交到这个人手里的方式。
用评测检验技能
产品变了，怎么知道技能还管用？Lauren 把 eval（评测） 当成 Agent 的单元测试，而且说不需要专门的框架。
她的做法：让一个协调 Agent 先写评分标准，再在名字很普通的文件夹里启动多个子 Agent，让它们意识不到自己在被测（Agent 知道被测时表现可能不同），最后由协调 Agent 打分。Cursor 支持很多模型，她就用同一套评测跑一遍不同模型；每次改技能都重跑，有时一直循环到全部 10 分。
她还建议当个”后座司机”：打开工具调用，看 Agent 为什么这么做，而不是只看最后结果。
把审查意见变成硬规则
如果你总在 PR 里留同一句意见，你就是在当人肉 linter。Lauren 的建议是把每条重复意见都当成信号，想办法变成 lint 规则、CI 报错，或者干脆让坏写法在结构上写不出来。
她举了 Grok Bot 代码库里的例子（框架叫 Dune）：
- 禁用 React 的
useEffect，出现就让 CI 失败。 - 禁止写代码注释，因为 Agent 老写”Lauren 说过不要这样做”之类会过时的历史。
- Electron 主进程和渲染进程代码分目录放，CI 检查导入关系，防止重活混进 UI 线程造成掉帧、卡顿。
- 每个功能放一个目录，最短的路就是正确的路。Agent 爱抄近道，那就让近道本身是对的。
她把这看成分层：书面规则、技能、风格指南是软约束，Agent 会忘；静态检查和 CI 报红是硬约束。她也顺带提到，Rust 这类严格语言在大量用 Agent 的团队里受欢迎，因为能编译通过本身就挡掉了很多问题。
花这么多 token 值不值
有人问普通预算能不能这么干。Lauren 承认她所在的地方 token 几乎不限量，Grok Bot 的重构用了 600 多个 PR。她把它当成投入产出的问题：前期成本是真的，但代码库一旦足够严格，连非顶级模型也能在里面写出好代码；反过来，靠人手做同样的重构可能要好几年。
先本地，再上云
她建议先在自己电脑上跑，能亲眼看到 Agent 在干什么。等这套流程靠得住了，再交给云端 Agent 自己去接信号。她的例子是 Benny：一个接收新 bug 报告、在云端打开 Cursor 尝试复现的 Agent，有一次发现修复其实已经在 main 上了，替人省了一小时。
不只是工程师的事
有了这些护栏，她团队里的产品经理和设计师也能提 bug、让 Agent 修、再把 PR 交给工程师审。在 Lauren 看来，这才是架构过关的标志：不是专职工程师的人也能参与，代码库却不会变烂。
我的理解
YepSoso 基本是我一个人在做，“100 个 Agent”不是我的问题。真正有用的是这个顺序：先让一个 Agent 的产出能被检查。对我来说就是：提需求前先写清楚怎么验；同一个纠正说到第二遍，就想想能不能交给脚本或检查去拦。相关想法我在反馈回路和怎么向 AI 提更好的问题里也写过。
相关阅读
- 反馈回路
- 怎么向 AI 提更好的问题
- 个人 AI Agent 和聊天机器人有什么区别
- Kimi 创始人如何用 Agent 集群扩展 AI
- 想从任何视频整理出这样的笔记？试试 YepSoso 字幕工具。