可信的循环
管理 agent 的最好办法，要从一只煮三分钟的鸡蛋说起。
假设你经营着几家餐厅，每天早上要应付成批涌入的早餐客流。每位客人点的都一样：一只鸡蛋、一份吐司、一杯咖啡。他们希望三样一起上桌，是热的，上桌时间可预期，品质稳定。鸡蛋耗时最久。等鸡蛋的工夫，吐司会烤糊。咖啡会放凉。任何一步延误，整盘都要等。当然，我们还得赚钱。
你会从哪里下手？你会测什么？同时在手上的活要留多少？你会在哪一环检查品质？
这是 Andy Grove 在 High Output Management 开篇抛出的问题。他用这座想象中的早餐工厂讲限制步骤、吞吐、品质管控和管理杠杆。这些概念用在管理 agent、搭建可信的 agent 循环上，好用得出乎意料。
加入 Cursor 之前，我在 IC 和管理者之间来回切换过几次。我一直在做的那些 skill 和 agent，都长自同一个念头：把 agent 当成聪明但健忘的新员工。让我意外的是，带一队 agent 和带一队人有多像。我反复回到同几个问题。瓶颈在哪？哪些活可以并行？验证该放在哪一步？哪些 bug 会跑到用户面前？我的注意力放在哪里杠杆最大？
Being a great agentic engineer is actually just being a great manager to someone who is smarter than you in some domains but has significantly less business sense than you.
Your job primarily, is to coach and mentor the subordinate in the ways and context of the business, and help narrow down the infinite possibilities of a genius mind into one optimal path that is best for the business. You are channeling the productivity of a genius.
Then, you must let go and pass on the responsibilities of technical implementation to your subordinates.
You are patient with their mistakes, hold a high standard for what is acceptable, and ultimately own the outcome of the end product.
You design systems, policies and impart memories that give him your great sense of the business, your wisdom of being in the field for decades. You are a mentor to the gifted young.
You understand that almost everything that is beautiful is a product of iteration, and you partake in a cycle of feedback and iteration with your genius subordinate that allows him to improve and go further.
That is how you become a great agentic engineer, by first being a great manager.
My amusement is the realization that people who are frustrated by their agents and can’t seem to get anything useful out of them are just bad managers.
我在上一篇里写过，agent 的瓶颈是验证。那之后这些系统一直在跑，我对「一个循环要可靠到什么程度才能放手不管」有了多得多的认识。
入职 Cursor 第二天，我收到经理一条意料之外的私信：
「我们需要你帮忙。glass（也就是 Agents Window）性能不太行，而你对 React 懂点门道。来搭把手？」
「哦对了，glass 过几天就发布。祝你好运」
好家伙。我对这个代码库一无所知，怎么管得了？我这是要刷新被开除的最快纪录吗？
我打开 Chrome DevTools 就开始看。Cursor 是 Electron 应用，所以我能用上本来就熟的工具。但内存已经高到有时会撞上 Electron 的 4gb 上限，trace 还没录完应用就崩了。崩溃越攒越多，我的心慌也是。问 agent 同样没用。它们张口就是一堆笃定的说法，我的胡扯探测器一直在响。
摆在面前的是两条路。一条是继续纯手工硬扛，认命做永远的底层。另一条是想办法把 agent 真正拉进这个过程。
早在 2025 年 4 月，人们还在手写代码的时候，我做过一个给 React Compiler 用的玩具 MCP。MCP 最后被证明是错的载体，但我当时的想法是，agent 应该拿到人类工程师写好代码时所依赖的同一批信号，编译器诊断、lint、静态分析等等。agent 要能看到我看到的，用我用的工具。
Cursor 里困扰 Agents Window 的那些性能问题，正好是验证这个假设的新机会。我得让 agent 用上我手里这套工具，而且得快。
于是我飞快拼了一个给 Cursor 用的 /control-glass skill。它让 agent 能启动一个开了 Chrome DevTools Protocol 的 dev build。这样 agent 就能点击和输入、检查无障碍树、截图、录视频、限制 CPU 或网络、抓 CPU profile、取 heap snapshot。
我自己修性能问题的经验告诉我 agent 需要能碰到什么、哪里会出错、什么算好结果。而现在，agent 可以复现问题、做 profile、改一版、再跑同一套测量。之后的每个 agent 都白得这些能力。
在你开始琢磨循环之前，必须先教会 agent 验证自己的产出是对的、达到了品质线。没有办法相信活干对了，傻跑循环只会产生越滚越多的 slop，给人类添更多活，而人类的带宽本来就比以往更少、干扰本来就比以往更多。验证已经成了软件开发的限制步骤，也就是那根最长的杆。它是决定整个循环产出的那一段。
在早餐工厂那个例子里，鸡蛋要三分钟，所以整顿饭都得围着它排。把吐司和咖啡做得更快，早餐并不会更早上桌。
在代码里，复现和验证最耗时，因为它们常常依赖人工盯着。把这份能力交给 agent，所需时间能大幅缩短，也把你这个最宝贵的资源解放出来，去同时搭建和运行多个循环。
建立对循环的信任
Section titled “建立对循环的信任”我们的 Cursor dev build 共用端口、进程和本地用户数据。两个 agent 去用同一个 build，会以各种离谱的方式互相干扰，所以我很快加上了 worktree 支持。现在每个 agent 都有自己的 checkout、build、端口、浏览器状态和隔离的 Cursor 实例。几个 agent 可以并行调查不同问题，互不打架。
这下我能同时跑一堆 agent 了。靠着 /control-glass，它们的修复确实管用，但代码质量还是低。并行只是给了我更多要 review、要丢掉的东西。吞吐上去了，代价是更多返工。
衡量管理者的，是他的团队完成了什么。agent 让这句话变得非常字面。你可以靠多招人、让人干得更快或干得更久来提高团队产出。你也可以靠培训新技能、配更好的工具来提高。
High Output Management 把这个想法叫「管理杠杆」。放到 agent 身上，就是人类把活干一次，写成可复用的 skill 和工具，整个 agent 团队的产出都因此提高。
「给我一根足够长的杠杆，我能撬动地球」。一队 agent，配上高质量的工具、skill 和验证自己工作的手段，能做完人类原本要花几个月的项目。
我从没打算做 pstack，我这套用 agent 做严谨工程的个人 skill 集。我只是开始把每一种反复出现的失败模式写成一个 skill：动代码前先复现 bug、列几个假设再逐个排除、先写会失败的测试、检查 diff 之外的爆炸半径、选定之前先比较备选、抓下真实产品改前改后的样子。agent 变强了，因为它们的指令里带着前几轮留下的疤。
pstack 是一组 skill，放进你的循环里跑，让 agent 以更高的工程严谨度干活。它自带一批强力 playbook，agent 可以连续跑几个小时，自主完成大任务，并产出决策 log、测试这类你事后能 review 的人工制品。
不管你用 pstack 还是自己搭一套 skill，观察 agent 在哪里卡住，再造出帮它们成功的系统，已经是工程师这份工作里很大的一块。一部分会长成 skill 和 rule，另一部分会长成重构，以及选那些让 agent 默认就做对的架构。
start with nothing. don’t download any plugins or skills. no AGENTS.md either. just prompt and observe the failure modes. codify them into skills when they repeat. even better, write lint rules or structure your codebase so certain mistakes are impossible.
every chef has their own set of knives, you should too
or just use pstack heheh
— @poteto
如果循环能自己跑起来呢
Section titled “如果循环能自己跑起来呢”现在大部分代码是 agent 写的（而且量大得惊人），维护变成了噩梦。就算有 pstack，agent 也得我亲自踢一脚才动。我得先注意到问题，启动一个 agent，跑一轮 pstack 循环，再盯着结果。熵增的速度比你能压住的快。
然后 Cursor 在三月上线了 automations。缺的就是这一块！我终于能把 pstack 和 /control-glass 拼成会自己跑的循环。软件维护显然是最该先试 Automations 的地方。报告本来就在 Slack 里流动，而这摊活天然就能拆成几段：分诊报告、复现 bug、修复、验证结果。
我就照这个做了。先从分诊开始。这个 automation 会下载截图、视频这类附件，分析它们，再从用户含糊的描述里推断报的是哪个功能。它还会查报告者的版本、搜重复报告、翻代码和近期历史。确认是个明确的 bug 时，它留下一张工单，以及给复现 automation 的交接说明。
分诊 automation 先弄清在报什么、哪些功能出了问题
复现 automation 等这个结论，在云上打开一个真实的 Cursor build，走和报告者一样的路径。它必须两次命中完全相同的出错状态，并抓下截图和视频。这些证据成为修复 automation 的输入。
复现步骤清楚之后，另一个 automation 会在云上用自己的电脑尝试复现
修复开始之前，讨论串保持打开，人类可以纠正或否掉这次复现。没人反对、根因又清楚时，修复 automation 接手那个还热着的 build 和上一步的全部证据。能写测试就写测试，做出它能证明的最小修复，跑一遍改前改后，然后开一个 draft PR。
人类在 Slack 里给反馈
我们会清理 useEffect，直到我们死
复现和修复这两个 automation 都会贴截图和视频来提高可信度。人类看这些人工制品，很快就能判断 agent 修的到底是不是该修的东西，以及它有没有理解并正确修好这个 bug。这让 PR review 简单很多，因为我已经相信它确实能跑通，剩下的时间可以只看代码本身。
这些 automation 还能验证正在进行中的工作。有时 PR 已经开了但还没落地。复现 automation 会找到它，跑改前改后，看它是否修好了所报的 bug。如果修好了，它会确认一下，让作者更有把握这是对的修复。
不错，已经有另一个 PR 修好了！
搭可信循环有一个关键点，每一段都能叫停整条线。分诊 agent 可以根据自己的调研判定这不是 bug，而是预期行为。复现 agent 可能复现不出来。修复方可以判定这个改动风险太大。这些都是有用的结果，因为它们挡住了坏活流进下一段，而在下一段纠正的代价要高得多。
现在一个 automation 可以直接喂给下一个，不必等我在中间搬运上下文。Slack 成了控制室，我在那里能看到整条线的状态，有不对劲的地方就插手。pstack 的循环终于可以不靠我来启动。
今天就领养 Benny！
你要是读到了这里，作为回报，我也把一批示例 skill 开源了，你可以拿它们当参考，为自己的 Cursor Automations 搭自己的循环。
把 README 指给你的 agent，它会替你配好。
信任，但要验证
Section titled “信任，但要验证”我反复想起的一句话是「信任，但要验证」。不管是聊天里的 agent，还是跑在 Automations 里的 agent，我的要求都一样：把你的过程给我看。
「我修好了」不够。给我看失败的测试和通过的测试。给我看改前改后的视频。给我看 trace、heap snapshot 或者截图。修复要是合并了，就在 main 上再跑一遍，也给我看。这些模式我常常会反过来写进 agent skill，逼 agent 证明自己把活干对了。
截图、视频这类人工制品，胜过一段听起来合理但可能是错的解释。人工制品给我一个能自己检查、自己质疑的东西。它也意味着我不必重放整次运行，就能判断该不该相信这个结果。
我在循环里的时候，会仔细看聊天，尤其是 thinking block。这是摸清潜在失败模式的好办法。我也靠它判断某一步到底需不需要 agent。脚本能确定性地做完，就用脚本。agent 擅长的是模糊的那部分，挑假设、解读证据、判断什么时候需要人类来定。
跑长任务时，pstack 的 /show-me-your-work skill 维护一份只追加的决策 log。每一行记下 agent 决定了什么、为什么、用了什么证据、后来发生了什么。结束时它会拿这份 log 和 transcript 对一遍，还会从另一个模型家族起一个 agent 来 review 自己的工作流。我不用读完整个会话，就能 review 那些重要决策。
/show-me-your-work
人工制品成为时间杠杆的经典例子，是把代码从一种语言或框架迁到另一种。你可以用几百个 agent 硬推这次迁移，但接着你就有几百份 agent 写的改动要验证。
pstack 把这叫 Build the Lever。第一个单元自己手工做一遍，摸清配方，然后让 agent 给机械的部分写 codemod，再写一个能证明产出的 checker。reviewer 可以读这些工具，也可以重跑。
agent 也能给自己造这根杠杆。看到某个 agent 反复手工做同一件事，我就让它写出它希望自己有的那个工具或 skill。之后的每次运行都继承它。
我就是这样才敢给 agent 更多自主权。循环把活干了，自己检查自己，再把证据交到我手上。我的 review 时间可以花在仍然需要人类判断的部分。
一次真实迁移的教训
Section titled “一次真实迁移的教训”最近一次关于验证的教训，来自把我们共享的 UI 库迁到 StyleX。那个 PR 将近 40 万行，虽然其中很大一部分是生成的验证证据。我的 agent 写了确定性脚本，把旧 SCSS 的 computed 输出和新 StyleX 的对比。生成的 CSS 从三万多行缩到六千行左右，我们抓取的那些状态达到了视觉等价。
🫧
然后我们拿它吃狗粮。
最初那次迁移是像素级精确的，但吃狗粮还是翻出了 z-index bug、全局 class 的消费方，以及藏在那堆远距离样式里的 !important 优先级之争。过程很痛，但必要。StyleX 把这团意大利面逼到了明处，我终于能把它解开。PR 的体量让每一次发现都代价高昂。
于是我把这段经历变成了下一个循环的训练。现在 StyleX automation 每次只迁 Cursor 里的一个叶子组件。选组件之前它会找警示信号，包括归属不清、动态拼 class、关系型选择器、层叠、transform 和优先级之争。删掉一个 class 之前，它会在仓库里搜行为、测试、automation 和消费方的依赖。
每个组件，automation 都会在浅色、深色和高对比度主题下抓取改前改后的 computed style。它覆盖 hover、focus、active、disabled 以及组件特有的状态。它录下交互，把截图配对，再请另一个 agent 检查这些媒体。build 失败或等价检查不过，这次运行就结束。
过去这几天，automation 每天迁一个组件。每个 PR 都很小，附带大量截图和视频。那次巨型迁移教会了这个循环，怎么安全地做完剩下的迁移。
教训很简单。在价值最低的那一段就抓住缺陷。一个小组件上的检查失败很便宜。巨型迁移落地之后才发现的回归很贵。
组建你的 agent 团队
Section titled “组建你的 agent 团队”想要米其林星，你的团队得够强。主厨不可能每一盘都亲手做。他设计菜单、培训厨师、布置工位、在出菜口检查每道菜，服务崩掉时修这套系统。
agent 本该让我们的日子更轻松。但一百个 agent 等着你喂 prompt，再把一堆 slop PR 丢到你腿上，反而让我们比以往更忙。
几个月前，我问的是我能同时跑多少个 agent。现在我问的是，一个循环产出什么证据、它能在哪里快速失败、哪些失败让它更安全、我的时间在哪里杠杆最高。我想让一个循环跑着，回来时能准确知道发生了什么。
- 先自己手工做一遍，这样你才知道什么叫做得好。
- 把你用的工具和信号同样给 agent。
- 让每一段都证明自己的产出，达不到标准就停下。
- 读 transcript，把反复出现的失败变成工具、skill 或 eval。
- 只有在循环赢得你的信任之后，才让它自主运行。
准备好了，你可以用 Cursor Automations 搭这些系统，拿 pstack 当起跑优势。
如果你觉得这些有用，我强烈推荐读 High Output Management。感谢阅读！