一个 PR 过去总是隐含地带着那个想要它的人的名字。Cursor 在 9 月 10 日推出的 Projects 公测，把这一栏拿掉了：协调者智能体可以盯着一个 Slack 频道、按日程运行、或者跟着你所有的 PR，不等任何人开口就开工。扇出到成千上万个子智能体是标题。真正会在日后某次事故复盘里被人发现的，是它底下那份没有划过范围的长期授权。
速览
三件事同时变了，而其中只有两件关于规模。
| 轴 | 后台智能体（2025–26） | Projects（2026-09-10） | 为什么要紧 |
|---|---|---|---|
| 谁发起工作 | 一个人，一次一件 | 一个触发器：Slack、日程表，或 PR 事件 | 「请求」从记录里消失了 |
| 工作单元 | 一个任务，一条分支 | 一条常驻线程，里面的协调者负责派活 | 到达速率不再由你决定 |
| 生命周期 | 几分钟到几小时 | 数月的留存上下文，跑在云端 | 那份上下文是一个没人评审的输入 |
实际发布的是什么
Cursor 于 2026 年 9 月 10 日把 Projects 放入公测。一个 Project 是一条常驻线程，你在里面与一个协调者智能体协作。协调者不写代码。它做规划，把实现派给它代你创建与管理的智能体——工作需要多少并行，它就开多少——然后把完成的活儿带回来给你查验。Project 跑在它自己的云端机器上，所以合上笔记本并不会让它停下；而它保留的上下文，跨度是数月的工作，而不是一次会话。
然后是那句很容易被一眼扫过去的话：你可以让协调者盯着一个 Slack 频道、按日程运行、或跟着你所有的 PR，好让它对自己察觉到的信号采取行动——无需等待你的提示。
Cursor 自己的数字给出了形状。在一个内部的设计系统 Project 上，该公司称这项工作正朝着每天触及 20 到 100 个 PR 的方向走，由协调者来组织，工程师则在需要注意力的地方介入查看；Cursor 报告的 PR 合入倍数是 6×。
有两个说法值得分开。「智能体能在无人值守下开一个 PR」自后台智能体以来就已成立，那是一个生产力问题。「智能体从一个你没读过的信号出发，自行决定就哪件事去开 PR」是另一个说法，而那是一个权限问题。
一份触发器清单就是一份授权，而它缺了四栏
当一个人要智能体去做某件事时，四个事实会免费附带过来：谁要的、要的是什么、什么时候要的、为了什么目的。这个领域建起来的每一道控制，都悄悄依赖其中至少一个。按后果设审批，需要知道行使的是谁的权限。审计轨迹需要一个主体。委派访问与同意记录之所以存在，恰恰是因为一个令牌并不告诉你谁同意了什么。《一个账户开关不是一份授权委托书》通篇的论证就是：打开一项能力，与授权对它的一次使用，不是同一个行为。
「盯着 #eng-alerts，看到什么就去处理」是一份授权。它有一个隐含的范围（那个频道里出现的任何东西，无限期），一个隐含的被授予者（一个你没读过其计划的协调者），以及一段隐含的期限（直到有人想起来把它关掉）。它被存在一个产品设置面板里，没有任何人评审过它——因为它看起来不像一份授权，它看起来像一个功能。
这不是在挑 Cursor 的毛病。同样的形状随每一个定时与触发式智能体一起到来，而本站关于这个模式的运维页面早已在讲这件事的机制版本。新的是这套组合：一个能发起工作的触发器、一个决定这件工作是什么的规划者，以及一次让产出比阅读更快的扇出。
没人放进幻灯片的那道算术
生成可以并行，评审不能。二十分钟的认真评审——读 diff、在脑子里跑一遍、确认不打这个补丁那条测试确实会挂——不是一个悲观的数字；而在每天 100 个 PR 的量下，它是四个人什么别的都不做。Cursor 那个设计系统的例子是个有利情形：机械、重复、可验证的改动，而这恰恰是协调者最该先被指向的那一类。
失效不在于团队会去招四个评审者，而在于他们不会招，于是评审会悄悄变成抽检——如果这是你主动选的策略，那还站得住；如果不是，那就是一次很糟糕的事故。后台编码智能体实战手册早已把话说明白：复核队列就是吞吐上限，所以要给输入设上限。而一份触发器清单，恰恰是一个把输入的上限拆掉的机制。
再留意协调者相对于那条队列的位置。既然它做的是规划而不是实现，那么系统里杠杆最大的那份产物就是计划——一份几分钟就能读完、却决定了二十份 diff 的文件。在扇出之前评审计划，比评审扇出便宜，而便宜的倍数大致就是扇出本身的倍数。工具链里几乎没有任何东西在鼓励这么做，因为计划是一条聊天消息，而 diff 才是 GitHub 会通知你的东西。
那「数月的上下文」到底是什么
一个 Project 把上下文跨月保留下来。把它读作一份资产，它就是头条功能；把它读作一个输入，它就是一份不带版本、塑造着每一个被派出去的任务、而且永远不会有人去比对的文件。
由此有两个后果。第一个是寻常的漂移：第二周做下的一个决定，到第九周只被记住一半，到第十周变成了某项工作的依据；而它的失效形态正是目标漂移所描述的那种——对一个悄悄替换掉自己的目标的称职执行。第二个更尖锐。如果协调者摄入一个 Slack 频道，那么任何能在那个频道发言的人所写下的文字，如今都是一个拥有仓库写权限的规划者的输入。那就是那片长期敞着的提示词注入面，而这与《拦截日志是一条注入通道》是同一个论证：一条你为了可观测性而接入的信息流，因为有什么东西开始读它，就变成了一条控制通道。
这里的缓解手段并不玄妙。能发起工作的触发器，应当只读取作者集合已知的来源。触发器产出的计划，应当是一份产物，而不是一条聊天消息。而子智能体的写权限，应当取自协调者的范围，而不是取自那个人的范围——而今天，它通常不是。
在你打开触发器之前该做的事
Projects 是个好产品，而「协调者规划、子智能体实现」这个切法也是对的形状——那就是主管-工人模式，终于有了一个界面。要做的功课，在于把触发器的配置当成它本来的东西来对待。
- 把这份授权写下来。谁打开了这个触发器、它可以就什么范围发起工作、到什么时候为止、由谁复核。在你的智能体清册里写四行——而如果有人来问，那也将是仅有的四行。
- 给每一个长期触发器一个到期日。九十天，之后必须由一个具名的人重新启用。永不到期的授权，正是每一条访问权复核发现的起点。
- 评审计划，不要只评审 diff。要求协调者在扇出规模超过某个门槛之前先贴出计划并等待一次确认。这是现成可用的、回报最高的那道控制，代价只是一个来回。
- 把在途的派发工作量，压到你真实的评审产能上。不是压到协调者的产能上。如果那个数字很难看，它在协调者出现之前就已经很难看了，只是你看不见。
- 把来源盖在 PR 上。哪个触发器触发的、哪条信号、哪份计划、协调者上下文的哪个版本。如果你对「这个 PR 为什么被开出来」的回答是一条 Slack 消息的链接，那已经比多数团队手上有的东西强了。
过去一个月里有意思的一处位移是：两家厂商各自把同一条边界挪了一下。OpenAI 的 Agents API 把那套 harness 本身放到了一次 API 调用后面；Cursor 则把「提出需求的人」放到了一个触发器后面。两者都是便利，而两者都悄悄搬走了某个你过去拥有的东西。
常见问题
这和一个定时开 PR 的 CI 任务有区别吗？
有，而且区别恰在要紧处：CI 任务跑的是一段固定程序，所以它的范围就是你写下的那些。协调者则从一条信号出发去决定这件工作是什么，所以它的范围是那条信号碰巧包含的任何东西。触发机制相同，其下游的裁量权大小不同。
合入 PR 的 6× 倍数，是不是就等于 6× 的产出？
它等于 6× 的合入。那是不是产出，取决于评审那一步之前在做什么、以及它现在是否还在做——这正是为什么在一次铺开过程中值得跟踪的数字，是已合入改动上的实质性错误率，而不是合入数。
协调者最该先被指向什么？
机械、重复、可由测试验证的工作——设计系统迁移、依赖升级、codemod。你想要的性质是：评审者能在几秒内查完一份 diff，因为正确性是机器可判定的；这能让复核队列不至于立刻变成瓶颈。
Slack 触发器真的算一片提示词注入面吗？
如果协调者读这个频道、并且能对读到的内容采取行动，那么按定义就是——任何能发言的人都在向一个有仓库访问权的规划者写入。缓解手段不是更聪明的过滤，而是把「发起型触发器」限制在作者集合受控的来源上，并让计划保持为一份可评审的产物。
延伸阅读
本站：
- 后台编码智能体——把复核队列当作吞吐上限，以及如何给输入设上限。
- 定时与触发式智能体——会自己开跑的工作，其运维机制。
- 委派访问与同意记录——为什么一个令牌不是一份「谁授权了什么」的记录。
- 主管-工人模式——Projects 实现的那个形状，以及它的天花板。
- 环境权限——长期授权会造出的那种失效形态。