值得信赖的循环

管理智能体的最佳方法，始于一枚三分钟的鸡蛋。

假设你经营几家餐馆，供应早餐高峰时段蜂拥而至的客流。每位顾客都点同样的套餐：一个鸡蛋、一片吐司和一杯咖啡。他们期望所有三样东西同时上桌，温热、时间可预测且品质稳定。鸡蛋耗时最长。等待时，吐司可能会烤焦。咖啡会变凉。任何一个环节的延迟都会拖累整盘餐点。当然，我们还需要盈利。

你会从哪里开始？你会衡量什么？你会让多少工作在同时进行？你会在哪里检查质量？

这是安迪·格鲁夫在《高产出管理》开篇提出的问题。他用这个想象中的早餐工厂来解释瓶颈步骤、吞吐量、质量控制和经理杠杆。而这些概念对于管理智能体以及构建值得信赖的智能体循环出奇地有用。

在加入 Cursor 之前，我已经做过几次从个人贡献者到经理的转型，我一直在积累的技能和智能体，都源于把智能体当作才华横溢但患有失忆症的新员工。让我惊讶的是，管理一个智能体团队与管理人类有多么相似。我不断回到同样的问题：瓶颈在哪里？哪些工作可以并行完成？验证应该在何处进行？哪些 bug 会影响到我们的用户？我的注意力在哪里能产生最大的杠杆作用？

sysls@systematicls·6月22日
成为一名优秀的智能体工程师，实际上就是成为一名优秀的经理，管理一个在某些领域比你更聪明但在商业意识上远逊于你的人。

你的主要工作是指导并辅导下属了解业务的方式和背景，并且
显示更多
263K 8416 24K

在上一篇文章中，我写道，智能体的瓶颈在于验证。此后，我一直在持续运行这些系统，并学到了更多关于如何使一个循环足够可靠，以至于可以放手不管。

瓶颈步骤

加入 Cursor 的第二天，我收到了经理的一条意外私信：

“我们需要你的帮助。Glass（即智能体窗口）的性能不太好，你对 React 应该有些了解。想来帮忙吗？”

“哦，顺便说一句，Glass 几天后就要上线了。祝你好运。”

好吧，糟了。我对代码库一无所知，那我该怎么应对？我是不是要速通被解雇的流程？

我打开 Chrome DevTools 立刻开始排查。Cursor 是一个 Electron 应用，所以我可以用我熟悉的工具。但内存已经升高到一定程度，以至于应用有时会在完成 trace 之前就触碰到 Electron 的 4GB 限制而崩溃。崩溃开始堆积，我的恐惧也随之增加。向智能体求助也没用。它们只是自信地陈述某些内容，而我的 BS 探测器一直响个不停。

我面临两个选择：继续手动暴力破解并接受自己永远处于底层，或者想出一个办法让智能体高效地参与进来。

时间回到 2025 年 4 月，当时人们还用手写代码，我开始为 React Compiler 构建一个玩具 MCP。MCP 最终证明不是正确的媒介，但我的想法是：智能体应该获得人类工程师用来编写好代码的相同信号：编译器诊断、lint、静态分析等等。智能体需要能够看到我所看到的，并使用我使用的工具。

困扰 Cursor 智能体窗口的性能问题，成了验证这个假设的新机会。我需要让智能体能够访问我拥有的相同工具，而且我需要快速做到这一点。

所以我迅速为 Cursor 拼凑了一个 /control-glass 技能。它让智能体能够启动一个启用了 Chrome DevTools 协议的开发版本。这使得智能体可以点击和输入、检查无障碍树、截取屏幕截图、录制视频、限制 CPU 或网络、捕获 CPU profile 以及获取堆快照。

我修复性能问题的经验，让我明白了智能体需要访问什么、什么可能出错、好的结果是什么样子。但现在，一个智能体可以重现问题、对其进行 profiling、做出更改，然后再次运行相同的测量。未来每一个智能体都免费获得了这些能力。

在你开始考虑循环之前，你必须教会智能体验证它们的工作是否正确并达到质量标准。没有一种方法来信任工作已完成得正确，天真地运行循环只会产生滚雪球式的渣滓，给人类带来更多工作——而人类已经比以往任何时候都带宽更低、干扰更多。验证已经成为软件开发中的瓶颈步骤，或者说长杆：它是约束整个循环输出的环节。

在早餐工厂的例子中，鸡蛋需要三分钟，因此餐点必须围绕它来安排时间。让吐司和咖啡做得更快，并不能更早地提供早餐。

在代码中，重现和验证花费的时间最长，因为它们通常依赖人工监督。赋予智能体这种能力，可以显著缩短所需时间，并把你——最宝贵的资源——解放出来，去同时构建和运行多个循环。

在循环中建立信任

我们的 Cursor 开发版本共享端口、进程和本地用户数据。两个试图使用相同版本的智能体会以滑稽的方式相互干扰，所以我迅速增加了 worktree 支持。每个智能体现在都能获得自己的检出、构建、端口、浏览器状态和隔离的 Cursor 实例。多个智能体可以并行调查不同问题而不会碰撞。

现在我可以同时运行一堆智能体。但由于 /control-glass 的帮助，它们的修复确实有效，但代码质量仍然很低。并行化只是给了我更多需要审查和丢弃的内容。吞吐量增加了，但代价是更多的返工。

经理是根据他们团队完成的工作来衡量的。智能体让这个想法变得非常字面化。你可以通过雇佣更多人、或让他们工作更快或更长时间来增加团队的输出。但你也可以通过用新技能培训他们、并为他们提供更好的工具来做到这一点。

《高产出管理》将这种想法称为“经理杠杆”。应用到智能体上，意思就是，人类可以通过创建可复用的技能和工具一次性完成工作，从而提高整个智能体团队的输出。

“给我一根足够长的杠杆，我就能撬动世界。”一个配备了高质量工具、技能和验证自己工作方法的智能体团队，可以完成原本需要人类数月的项目。

我从未打算构建 pstack——我个人的一套用于与智能体进行严谨工程的技能。我只是开始把每一个重复出现的失败模式变成一项技能：在触碰代码之前重现 bug；形成几个假设并排除它们；先编写失败测试；检查变更的波及范围；在选择一个方案之前比较替代方案；捕获真正的产品前后对比。智能体之所以改进，是因为它们的指令承载了之前运行的伤痕。

pstack 是一套技能，你可以作为循环的一部分运行，使智能体以更高的工程严谨性完成工作。它附带强大的 playbook，智能体可以连续工作数小时来自主完成大型任务，并生成决策日志和测试等人工产物，供你稍后审查。

无论你是使用 pstack 还是构建自己的一套技能，观察智能体在哪里挣扎，并构建帮助它们成功的系统，现在已成为工程工作的重要组成部分。其中一些看起来像技能和规则，另一些则看起来像重构和选择能让智能体默认做正确事情的架构。

lauren@poteto·6月12日
回复 @theostart 什么也不要做。不要下载任何插件或技能。也不要写 AGENTS.md。直接提示(prompt)并观察失败模式。当它们重复出现时，将其编纂为技能。更好的是，编写 lint 规则或结构化你的代码库，使得某些错误不可能发生。

每位厨师都有自己的风格
显示更多
471K 524.7K

如果循环可以自行运行呢？

既然智能体编写了大部分代码（而且数量如此之多），维护已经变成了一场噩梦。而且即使有 pstack，除非我自己启动它们，否则智能体仍然什么都不做。我必须注意到问题，启动一个智能体，运行一个 pstack 循环，并查看结果。熵增的速度比你控制它的速度更快。

然后，Cursor 在三月份推出了自动化功能。这就是缺失的那一块！我终于可以将 pstack 和 /control-glass 组合成可以自动运行的循环。软件维护似乎是尝试自动化的最明显领域。报告已经通过 Slack 涌入，工作自然分为几个阶段：分类报告、重现 bug、修复它、验证结果。

所以，这就是我构建的东西。我从分类开始。自动化会下载附件（如截图和视频），分析它们，并从模糊的用户消息中推断出正在报告的是哪个功能。它还会检查报告者的版本、搜索重复项，并查看代码和近期历史。当它找到一个明确的 bug 时，它会留下一个工单和一份交接单，交给重现自动化。

分类自动化首先弄清楚正在报告什么以及哪些功能有问题

分类自动化首先弄清楚正在报告什么以及哪些功能有问题

重现自动化等待那个判断结果，在云中打开一个真实的 Cursor 构建，并遵循与报告者相同的路径。它必须恰好两次命中相同的故障状态，并捕获截图和视频。这些证据成为修复自动化的输入。

当重现步骤明确定义后，另一个自动化尝试在云中用自己的计算机执行这些步骤

当重现步骤明确定义后，另一个自动化尝试在云中用自己的计算机执行这些步骤

在修复开始之前，线程保持开放，供人类纠正或拒绝重现。如果没有人反对，并且根本原因明确，修复自动化就会接手上一步的 warm build 和所有证据。它会在可能时编写一个测试，做出它能证明的最小修复，运行前后对比，并打开一个草稿 Pull Request。

人类在 Slack 中提供反馈

人类在 Slack 中提供反馈

我们将一直清理 useEffect，直到我们死去。

我们将一直清理 useEffect，直到我们死去。

重现和修复自动化会发布截图和视频以增加信任度。人类可以审查这些人工产物，快速判断智能体是否在修复正确的事情，以及它是否理解和正确修复了 bug。这使得 PR 审查变得简单得多，因为我可以将剩余时间都用于只看代码本身——因为我已经信任它运行正确。

自动化还可以做的一件事是验证已经在进行中的工作。有时一个 PR 已经打开但尚未合并。重现自动化找到它，运行前后对比，检查它是否修复了报告的问题。如果是，它就确认这一点，给作者更多信心，认为这是正确的修复。

不错，另一个 PR 已经修复了这个问题！

不错，另一个 PR 已经修复了这个问题！

构建可信赖循环的一个关键方面是，每个阶段都可以停止生产线。分类智能体可以根据它所做的研究决定这不是一个 bug 而是预期行为。重现智能体可能无法重现它。修复智能体可以决定更改风险太大。这些都是有用的结果，因为它们阻止了糟糕的工作流入下一阶段——在那里纠正它的代价会高得多。

现在，一个自动化可以喂给下一个，而无需等待我在它们之间传递上下文。Slack 已成为控制室，我可以在那里看到整个生产线的状态，并在出现问题时介入。pstack 循环最终可以在没有我的情况下启动。

今天领养 Benny 吧！

今天领养 Benny 吧！

如果你读到了这里，作为奖励，我还开源了一些示例技能，你可以用它们作为自己 Cursor 自动化的参考，来构建你自己的循环。

只需将你的智能体指向 README，它就会为你设置好。

信任但要验证

我反复提到的一句话是“信任但要验证”。无论是聊天中的智能体，还是自动化中运行的智能体，我都要求同样的事情：向我展示你的工作。

“我修复了它”是不够的。向我展示失败的测试和通过的测试。向我展示前后的视频。向我展示 trace、堆快照或截图。如果修复已合并，在 main 分支上再运行一次，也展示给我看。通常，我会将这些模式重新构建到智能体技能中，让智能体证明它们正确完成了工作。

人工产物，比如截图或视频，胜过听起来合理但可能是错误的解释。一个人工产物给了我一些可以自己检查和挑战的东西。这也意味着我不必重放整个运行过程来判断是否应该信任结果。

当我在循环中时，我会密切关注聊天，特别是思考块。这是找出潜在失败模式的好方法。这也是我如何决定某个步骤是否需要智能体。如果一个脚本可以确定性地完成它，就使用脚本。智能体对于模糊的部分很有用：选择假设、解释证据、以及决定何时需要人类判断。

对于长时间运行，pstack 的 /show-me-your-work 技能会维护一个仅追加的决策日志。每一行都说明智能体决定了什么、为什么、使用了什么证据以及发生了什么。最后，它会将该日志与记录进行核对，并启动一个来自不同模型族的智能体来审查自己的工作流程。我可以在不阅读整个会话的情况下审查重要决策。

/show-me-your-work

/show-me-your-work

一个经典的人工产物如何成为你时间杠杆的例子，是将代码从一种语言或框架迁移到另一种语言或框架。你可以用数百个智能体暴力破解迁移，但这样你就必须验证数百个由智能体编写的更改。

pstack 将此称为“构建杠杆”。先手动完成第一个单元来学习配方，然后让智能体为机械部分编写一个 codemod，以及一个证明输出的检查器。审查者可以阅读并重新运行这些工具。

智能体可以为自己构建杠杆。当我看到一个智能体反复手动做某事时，我会让它编写它希望拥有的工具或技能。未来的每一次运行都会继承它。

这就是我如何逐渐放心地给予智能体更多自主权。循环完成工作，检查自己的工作，然后把证据交给我。我可以将审查时间花在仍然需要人类判断的部分上。

从一次真实迁移中学到的教训

最近一个关于验证的教训，来自将我们的共享 UI 库迁移到 StyleX。那个 PR 将近 40 万行，尽管其中很大一部分是生成的验证证据。我的智能体构建了确定性脚本，比较旧 SCSS 的计算输出与新的 StyleX。生成的 CSS 从超过 30,000 行缩减到大约 6,000 行，而我们捕获的状态达到了视觉一致。

🥃

🥃

然后我们进行了内部试用（dogfooding）。

最初的迁移是像素完美的，但内部试用仍然发现了 z-index bug、全局 class 消费者以及隐藏在那些远程样式中的 !important 优先级冲突。这很痛苦，但是必要的。StyleX 迫使意大利面条式代码暴露出来，我终于可以理清它。PR 的规模使得每一次发现都代价高昂。

于是我把这次经历变成了下一个循环的训练。现在，StyleX 自动化一次迁移 Cursor 中的一个叶子组件。它在选择组件之前会寻找警告信号，包括所有权不明确、动态 class 组装、关系型选择器、层叠、变换和优先级冲突。在删除一个 class 之前，它会搜索代码库中是否存在行为、测试、自动化和消费者依赖。

对于每个组件，自动化会在亮色、暗色和高对比度主题下捕获前后计算样式。它覆盖了 hover、focus、active、disabled 以及组件特定的状态。它记录