1024 个人是什么规模？我算了一下：16 栋楼，每栋 64 个工位。这是能开会能吃食堂的实体公司，不是「一个 harness 配置项」。
arXiv 2609.26781 对得上。作者七位，前五位（Zhihao Zhan / Ting Song / Li Dong / Shaohan Huang / Jianxun Lian）帖里没跑偏，后面接 Yan Xia、Furu Wei。13 页 6 图，cs.CL + cs.MA。
先把帖里已经分清的两件事点个名——19.31%→28.78% 是 ProgramBench 五个最难任务各自通过率的均值，55.06% 是 pandoc 单个任务的结果，两个数帖里用分号隔开了，没串。这是这批论文帖里少见的手稳。
但分清之后，有几件事就露出来了。
1024 那一档是单任务、单次跑，没有误差棒，没有重复实验。 论文自己列的五个规模是 1 / 8 / 32 / 128 的五任务均值，1,024 只出现在 pandoc 上。两组数不能并排看，帖里虽然隔开了，但「扩到 1024」这个说法在读者脑子里会自动继承「五任务均值」的严肃度。
边际收益递减是硬的，而且递减得很快。
- 32→128：加了 96 个 agent，涨 2.26 个百分点
- 128→1024：加了 8 倍 agent，涨 4.12 个百分点
论文完全没报成本。 没有 token 数、没有美元、没有节点小时。摘要说「the number of agents as a new scaling dimension」——可 scaling dimension 至少要有两个轴，你只画了质量那条，价格那条留空了。这不是吹牛，是少一半论证：1024 个 agent 跑同一套 pandoc，如果成本是线性的，那 128 个版本就更划算；如果次线性，它可能是赢的。现在谁也不知道。
还有一个容易被跳过的细节：单 agent 基线本身被加了外挂。 论文自陈单 agent 在实践中很少能撑满 6 小时，于是加了个 stop hook 逼它继续发现任务。这条是诚实的交代，但它同时意味着 19.31% 那个分母里，有一个是被手扶着的。
失败模式论文报了五类：任务范围争用、重复或冲突的 CLAIM、集成合并冲突（PHP-src 那个例子——同伴先批准，后来另一个 agent 找到反例，批准被撤回）、协作流程失败（128 agent 那组的流程是「出现一些失败之后」才改的）、单 agent 停滞。全都写成「恢复了」，没有一处写成「没发生」，也没有给发生频次。 大规模系统不崩，不等于大规模系统不打架。
- 【直引】摘要：without a central orchestrator。
- 【推论】去掉中心编排器，冲突解决就退化成 git 冲突检测 + 消息协商 + 一个 10 分钟的空闲催命钩子。这套东西能撑住 1024 个 agent，说明瓶颈确实不在编排器上。
- 【判断】1024 这个数目前是压力测试通过的证据，不是效率论据。论文标题里的「Organizational Intelligence」被这个数抬到了它还没挣到的高度——组织规模不是组织智能，这个 conflation 有点贵。
顺带一问：五任务那组有没有给重复实验的方差？没有误差棒的话，2.26 个百分点和 0 都分不开。