摘要：Cursor 发布 Projects（beta），用协调者智能体处理大型开发任务，本身不写代码，而是调度数千个子智能体并行。
编程工具 Cursor 这次放出的 Projects（beta），思路有点反直觉：协调者智能体自己不写代码，它只负责"派活儿"。面对功能开发、大规模迁移、持续性维护这类庞杂任务，协调者把工作拆成小块，调度数千个子智能体并行执行，自己待在中间做编排、验收和兜底。换句话说，它把"一个超级程序员"换成了"一个包工头加一支无限规模的施工队"。
为什么这个设计值得关注？因为过去的 Agent 编程，大多是"一个模型从头写到尾"，遇到几十万行的大型仓库、跨多个服务的迁移，单智能体很容易在上下文和注意力上撑不住。Cursor 的解法是分治：协调者保持全局视野，子智能体各自处理局部、互不干扰，再回传给协调者汇总。官方还给了内部使用数据，说明这套结构已经在真实工程里跑过，而不是 PPT 演示。对一个维护百万行代码库的大厂来说，"几千个智能体同时改不同模块"听起来像科幻，但正是这类场景最能榨出分治架构的价值。
对开发者，这意味着"一个人管一个项目"的工作方式开始松动。你不再需要亲自把每一行改完，而是要学会给协调者定好题、划好边界、定好验收标准——人的角色从"写代码"转向"定义问题和管理质量"。这恰好呼应了本期职场那条的主线：执行在贬值，定题与判断在升值。工具越强，掌舵的人越不能缺席。
横向看，协调者-子智能体（orchestrator-subagent）正成为 Agent 工程的主流范式，后面技术篇会专门拆解它的工程原理。对创业公司，这种架构的启发是：与其追求单个模型更聪明，不如把"如何拆分任务、如何并行、如何验收"做成系统能力。编排的智慧，可能比模型本身更决定成败。
当然风险也在：数千个子智能体并行，意味着成本、权限和错误传播都会被放大。一个子智能体跑偏，协调者若验收不严，bug 会被悄无声息地汇总进主干。Cursor 把"协调者不写代码"说成卖点，但反过来也意味着它把"质量闸门"完全压在了编排逻辑上。这套机制到底多稳，还得靠大量团队用真实仓库去验证。对初级开发者，也别误读成"以后不用学编程了"——恰恰相反，你得比现在更懂架构，才看得懂机器交回的答卷对不对。
