Cursor 多 Agent 加 Verifier：写和验分开更稳
Cursor 多 Agent 公开架构里补了 Verifier：Planner 派 Worker 写代码，也派 Verifier 跑验证，不过再修。写与验拆开，比「一个对话既当厨子又当质检」稳；先写清怎样算过。
多 Agent 这事大家聊了很久：拆任务、派工人、再汇总。Cursor 这次公开的补充很短，但点在了痛处，就是加了 verifiers。
原话差不多是这样：这是在既有多 Agent 研究上的延伸；Planner 会拉起写代码的 Worker，也会拉起跑验证的 Verifier；验证不过，Planner 再派一个新的 Worker 去修。没堆形容词，流程却完整了。
先把图读一遍
封面这张图从上到下大致是：
Cursor SDK进来，落到Planner。Planner往下分叉：左边Subplanner，中间Verifier，右边Worker。Subplanner还能再拆一层，底下又有自己的Worker和Verifier。- 红色虚线标着
Verifies：Verifier 盯的是同层的 Worker，不是空挂的装饰框。 - 底下收束到
Git，改动最终还是要进版本库，不是聊完就散。
有两点容易看漏。一是结构可以嵌套：总规划下面还能再开 Subplanner，子树里同样配齐写与验。二是 Verifier 和 Worker 是成对出现的，图上不是「写完再找个人随口看看」，而是一条明确的校验边。
Verifier 到底补了哪一块
以前很多演示停在「能生成」。生成和「能合并」中间差的那截，通常靠人肉点测试、看 CI。Verifier 把这截写进了编排：Worker 改代码，Verifier 去跑它（测试、检查、你定义的门槛，图本身没写死具体命令），失败的时候 Planner 不硬推 Git，而是再 spawn 一个 Worker 去修。
听起来像 CI。差别在于，CI 多半是你推完才骂你，这里校验被放进了 Agent 循环里，失败直接变成下一轮派工的输入。人还是可以当最终守门员，但第一轮「跑没跑过」不用每次都自己摁。
和你在 Cursor 里日常用法怎么对齐
你未必已经在用图上那套 SDK 编排，本地也能借这个形状改习惯。先写清「怎样算过」，一两句就行：单测命令、该绿的路径、不许动的目录，这相当于给未来的 Verifier 喂标准，没有标准，Worker 只会一直「看起来能跑」。别让同一个对话又当厨子又当质检，可以开一轮专门改，再开一轮（或换个更抠的模型）只负责跑测、读失败日志，这就是人肉版的 Planner。失败日志原样丢回去修，少写「再优化一下」，Verifier 的价值之一就是输出可执行的否决理由。大任务才拆 Subplanner，改个文案也上三层 Agent，账单和噪声都会很难看，嵌套是能力，不是 KPI。
Rules / Skills / MCP 怎么把重复约束写进编辑器，可以看 Agent、Rules、Skills、MCP。模型别全程顶配的理由，报告和成本图里也有旁证：模型组合成本、习惯报告里的接受行成本。
怎么确认自己没理解歪
拿一个小仓库试半小时就够：故意留一个会挂的测试，让「写代码」的那轮先改；另开一轮只跑测试，把红字贴回去；看它能不能对着失败修到绿，而不是去重写无关文件。绿了再谈 Git。要是修三次还在同一处打转，多半是验收条件含糊，或者上下文塞了太多无关目录，先收窄，再加 Agent，别先加层数。
别急着神话
公开描述没保证 Verifier 永远公正，也没说一切仓库都能零人工。测试本身会写错，集成环境比单测脏，有些问题只有真人盯 diff 才看得见。Verifier 解决的是「没跑就声称完成」，不是「业务一定对」。
另外，多一轮验证就多一轮模型调用。上下文已经越来越贵的时候（习惯报告里 input 占比在抬头），无意义的嵌套 Planner 会先烧钱、再烧耐心。
CUDA 场景的公开数字见 NVIDIA / CUDA 优化；PR 审查向见 Bugbot。