旧的那群代理，不到两小时就彻底崩了。不是跑得慢，是整个任务流散成一团乱麻，内存撑爆，上下文互相覆盖，到最后连自己在修哪个表都搞不清楚。而新架构——同一批模型，同一个Grok 4.5的推理能力——四个小时后刷出了80%的SQL测试通过率。中间没有人类插手，也没有重新启动。你要问区别在哪儿，一句话：把脑和手分开了。
旧代理群为什么会撞墙，新系统凭什么翻盘
记忆污染和上下文拥塞，这不是偶然，是必然
传统的多智能体协作很像让一群实习生共用一张草稿纸。你写一行，我接一句，每个人都在同一片上下文里涂抹。当任务变复杂时，这种共享内存的策略会立刻撞上两面墙。第一面墙叫注意力稀释：代理A需要关注的状态信息被代理B改写了，代理B的临时结论被代理C当成事实继续推理，错误在链条上逐级放大。第二面墙更致命——上下文窗口膨胀。每次函数调用、每一次中间结果都被塞进同一个上下文窗口，窗口满了就开始截断，而截断最先砍掉的就是最初的规划。一旦规划被遗忘，代理就只能应激式地修补局部问题，整个任务从有目的变成布朗运动。
Cursor在实验中观察到的旧代理群失败，恰好卡在第二小时这个节点。不是因为模型能力不够，而是上下文管理的债还到了头。代理开始重复执行已经完成的步骤，或者跳过关键的约束条件，SQL语句里出现表名不匹配、外键约束被直接忽略。有意思的是，单独看每一步的日志，每个代理都表现得“挺合理”，合在一起就成了一出荒诞剧。
把任务拆成树，让规划者只画图，让执行者只干活
新架构的设计哲学朴素得惊人：别让想事情的人和做事情的人同处一室。于是有了规划者-执行者树状结构。规划者不写一行SQL，不调一下数据库接口。它拿到一个多表关联的复杂查询需求之后，只做一件事情——把任务递归拆解成子任务树。每个子任务都有明确的输入契约和输出约束，子任务之间不共享任何运行时内存。
执行者代理被分配到树的叶子节点上，只负责把规划者划定的那一亩三分地种完。它拿到的是一个带着严格接口定义的“任务盒子”，干完活，把结果塞回盒子，销毁自己的上下文，然后宣告结束。如果某个叶子执行失败，规划者不必理解失败的具体细节，只需要重新分派一个等价子任务，或者把节点进一步拆分。这套架构让故障隔离变成了物理属性而非编程习惯——一个内存泄漏的执行者不会污染全局，一个产生幻觉的查询不会顺着调用链传染。
四小时跑出80%通过率的结果让很多人觉得“还行，但不到惊艳”。我不这么看。重要的不是80%这个绝对值，而是从零到80%的路径完全没有人类介入，而且曲线的斜率在第四小时还没有变平的迹象——这意味着只要给更长的计算时长和更细粒度的任务分解，天花板远未到来。
每秒一千次提交，逼出了一套从零写的版本系统
现成工具不是不够快，是根本不想陪你玩
峰值提交速度冲到每秒一千次的那一刻，工程团队发现他们面对的根本不是性能优化问题，而是一个更底层的尴尬：现有的版本控制系统，无论Git还是更轻量的方案，设计之初就没考虑过每秒有上千个并发写入主体。锁竞争、索引更新、磁盘刷新，这些在人类开发者看来可以接受毫秒级延迟的操作，在代理群面前就是堵死整条流水线的血栓。
而且代理的提交模式和人类完全不同。人类写代码是一段一段地提交，每个commit带有明确的语义边界。代理的提交是爆炸式的、碎片化的、极度高频的——有时一个代理在三十秒内提交了数百次小改动，每一个都对应子任务执行过程中的中间状态。团队很快发现，如果不为代理专门设计提交语义和存储结构，磁盘I/O会先于模型推理能力成为瓶颈。
合并冲突不再是bug，而是架构设计的燃料
所以有了那个被内部称为“Agent-Native VCS”的东西。它最不像Git的地方就是对于合并冲突的态度：不试图避免，不标记为异常事件，而是把冲突当作数据流里的第一公民来管理。每一个代理写入的记录不是文件差异，而是带有时序和来源标记的操作日志。当两个执行者同时修改了SQL语句中同一行条件时，系统不报警，而是把冲突版本按照任务树的分支关系归并，交给上层规划节点再裁决一次。
这种设计把IOPS从传统Git操作的数量级直接拉升了几个台阶。在没有重试风暴的前提下，系统在实验中最高的实测连续提交速率稳定在每秒一千次上下，而这还是在运行SQL测试的同时、规划者同步生成下一轮子任务图的背景压力下达到的。整个实验跑完，没有因为版本管理原因出现过一次死锁或者数据竞态。这对做过高并发系统架构的人来说，比80%的通过率更令人兴奋。
规划者-执行者架构不止能写SQL，它正在吞噬更多任务
构建浏览器，以及为什么分层抽象救了这个任务
SQL测试之所以被选作第一个基准，是因为它严格、可复现、出错便即崩。但团队很快把同一套架构扔到了完全不同的领域：构建浏览器缺陷修复代理。浏览器的渲染引擎是出了名的耦合怪兽，一个CSS属性的行为改动可能影响到布局、合成、光栅化三个阶段，而这三个阶段的代码分布在完全不同的模块里。传统的多代理方案在这一点上极易失足——每个代理看到的都只是自己那块内存里的DOM子树，没人拥有全局的渲染流水线心智模型。
规划者-执行者树在这里的优势被放大到了战略级别。规划者把一个浏览器bug的修复需求分解成“影响面分析”、“根因定位”、“最小化回归测试生成”、“跨模块适配修改”四个分支，每个分支下面再长出更细的叶子。执行者不需要知道浏览器到底多复杂，它只需要在规划者划定的模块边界内完成原子任务。结果出乎意料地干净：某次字体回退逻辑的内存泄露修复，从bug报告到可合并的补丁，代理群只用了不到一个半小时，期间还自动生成了覆盖十二种语言环境的回归测试用例。
数十亿token合成数据，多代理流水线的一种新可能
如果说bug修正是手外科手术，那么生成数十亿token的合成数据就是石油炼化。这个任务不仅对吞吐量要求极致，更麻烦的是质量波动——人类团队很难想象，当你要生成供对齐训练用的代码推理对时，中间出现哪怕5%的错误链，整批数据的可用性就会跳水。
规划者-执行者架构在这里被改造成一个质量控制流水线。规划者负责设计“题目生成规则”，把代码推理对的生产分解成问题空间采样、生成、静态验证、动态执行、输出质量打分五个阶段树。每个阶段由专门的执行者群体并行处理，他们不共享任何内存，只通过树形结构传递结果。如果打分节点发现某个生成批次质量低于阈值，它会回溯提交日志，定位到出问题的生成规则或执行者实例，然后规划者裁掉那个分支，换一个新的生成策略重新跑。
这种数据质量闭环让团队可以在无人参与的条件下持续吐出符合公司内部对齐标准的训练数据。某种程度上，这套系统不是在“生产数据”，而是在“耕种数据”——它播种规划，培育执行，收获验证，淘汰不合格的种子，整个过程自循环。
Cursor的这篇实验记录，最让人回味的不是某个具体数字，而是一个判断：他们把多代理问题的本质重新定义为抽象层次的隔离问题，而不是模型能力的强弱问题。当规划者可以信任执行者会把叶子任务做到合格，当执行者可以信任规划者给的边界不会越界，代理群的产出就从概率游戏变成了可工程化的系统行为。这在今天充斥着“更大模型、更贵API”叙事的环境里，是一个值得用力打上高亮的信号。
<--BODY-->
