#Codex做了20个小弟给自己干活##Codex还没做完的东西把我看傻了# Codex 一次派 20 个并行小弟：省下的人力，与放大的账单是同一笔交易

有人给 Codex 的 /goal 派了个任务，醒来发现它自己拆解、自己派了 20 个并行子智能体，在云端沙箱里跑了一整夜。一个开发者自述 18 个功能里完成了 14 个、成本约 4.2 美元；另一个用户反馈单次烧掉约 2200 万 token，a16z 投资人称自己用 Codex 跑项目时 token 用量翻了 1 万倍。同一件事，两种账单。

真正值得拆的不是“AI 能不能一人成团”，而是多智能体并行把效率天花板抬高的同时，把代价结构也改了——而且改在两个地方同时放大。

省下的工时和放大的账单，是同一笔交易的两面。​ 并行数乘以运行时长再乘以每个智能体重复读入的上下文，决定了这次杠杆的力臂。智能体越多、跑得越久，省下的人力工时和失控的算力账单同步放大。你不再按“人天”计价，而是按 token 计价；4.2 美元和 2200 万 token 之间，隔的不是一个工具的优劣，而是有没有给这个杠杆设上限。

更隐蔽的迁移是验收瓶颈。​ 黑客松曾因 Codex 服务器崩溃、重度依赖它的团队直接罢工离场，这指向的其实不是生成环节失灵，而是交付物数量爆发后人工逐个校检成了新天花板。当一晚能产出 14 个功能，谁来确认它们真的能用、没有互相打架、没有引入回归？瓶颈从“谁来做”迁移到了“谁来校检与设上限”。团队若只把投入从生成交给调度，而没同步投到评审和测试门禁上，杠杆放大的就只是失控的风险。

所以接下来的工程动作不是“能不能派更多小弟”，而是给 /goal 派发设并行数与运行时长上限、给单任务设 token 预算、给失败重试加熔断、给交付物强制回归测试门禁。这些护栏不是限制效率，而是让 4.2 美元那一面能稳定复现、让 2200 万 token 那一面不被默认触发。

值得观察的不是 20 这个数字，而是当 token 计价成为多智能体默认账单后，哪些团队会把“验收产能”当成和“生成产能”同等的一阶资源来配置——以及哪些平台会率先把 token 预算和并行上限做进产品，而不是留给用户自己踩坑。