摘要：协调者-子智能体（orchestrator-subagent）正成为 Agent 工程主流范式：协调者管全局与验收，子智能体并行处理局部任务。
Cursor Projects 把"协调者-子智能体"（orchestrator-subagent）这套架构推到了台前，但它其实代表了一个正在成形的 Agent 工程范式。核心思想很简单：别让一个模型从头扛到尾，而是用一个协调者保持全局视野、做任务拆分与验收，再用一群子智能体并行处理互不依赖的局部工作，结果回传协调者汇总。Cursor 的协调者"自己不写代码"，正是这套分工的极端写照。它把"一个超级程序员"换成了"一个包工头加一支无限规模的施工队"。
为什么单智能体会撞墙？因为上下文窗口和注意力都有限。面对几十万行仓库、跨多个服务的迁移，一个模型要把所有信息塞进上下文、还要维持长程一致性，很容易顾此失彼。分治之后，每个子智能体只看自己那块，注意力更聚焦，错误也更不容易污染全局——只要协调者的验收闸门够硬。这就像大厂把一个巨型项目拆成多个小队并行，PM 不写代码但把控全局，关键在于 PM 的验收标准够不够硬。
工程上要解决的几个关键点：一是拆分策略，怎么把任务切成既独立又能汇总的粒度；二是上下文传递，子智能体之间怎么共享必要的"已知信息"而不互相拖累；三是验收与回退，子智能体跑偏时协调者能不能及时发现、能不能安全回滚。Cursor 把"协调者不写代码"当成卖点，反过来也把质量完全压在了编排逻辑上——这是这套范式的阿喀琉斯之踵。一个子智能体埋了隐患，协调者若只看结果不看过程，bug 会被悄悄汇总进主干。
对开发者，启示是：未来做 Agent 系统，瓶颈越来越可能不是"模型多聪明"，而是"你如何定义任务、设计验收、管理状态"。编排的智慧，会像当年的系统架构一样，成为核心工程能力。把协调者当"项目经理"来设计，把子智能体当"外包团队"来管理，这套心智模型比追新模型更保值。一个实用的心法是：给每个子智能体写清楚"输入是什么、输出长什么样、错了怎么验"，协调者才好兜底。
这套范式也不是银弹。任务耦合度高、拆分成本超过并行收益时，硬上分治反而更慢。而且数千个子智能体并行，意味着成本、权限和错误传播都被放大——一个失控的子智能体，影响面是全局的。所以真正成熟的协调者系统，必然配有预算上限、权限白名单和全局回退。把这套"交通规则"想清楚，比多接几个子智能体重要得多。
