上周刷到一篇 cs.SE 的论文，arXiv 2610.10263，标题定语摞定语——《When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks》。
Codex、Claude Code、Kimi Code 对照跑，同一个任务，一次开动态并发、一次关掉。354 个任务，2124 次执行。
这活儿干得算实。2124 次执行摆在那儿，比那种跑二十个 case 就敢写"显著优于基线"的强多了。
我读完第一反应：这不就是自动扩缩容，换了个 agent 的壳。
当年那套东西敢上生产之前，我们往它身上焊了三样：上限、熔断、一键接管。
这台新东西把"自己决定开多大"当卖点。那三样，我一样没看到。
最值钱的不是并发，是另一句话
论文我最认这一句——短任务上模型能力基本决定结果，长周期开发里，编排才是任务能不能完成的核心。
值钱不在于新鲜，在于它是被 2124 次执行逼出来的，不是拍脑袋说的。
我们这行念叨"编排重要"念叨了十几年，真写 runbook 的时候照样只写"重启服务"。没有一条写"先确认谁在等谁"。
编排在论文里叫 orchestration，在我们这行有个更土的名字：值长。
活儿越长，越需要一个知道"这一步先做、那一步等着、出了事先看谁"的人。现在这个位置坐着人，以后可能坐着 agent——但不是现在这个。
问题不在"并发"，在"自己决定"
论文的定义：agent 在运行过程中，自己决定是否、以及如何派生并行子 agent。
关键词就那四个字。自己决定。
搞分布式折腾这么多年，一条最基本的规矩：决定"开多少"的那个东西，和承受"开多了"后果的那个东西，不能是同一个。
自动扩缩容敢上生产，不是因为算法聪明，是因为算法和值班的冤种之间隔着一道墙——上限写死在配置里，熔断了就停，人能一键接管。算法想开一百个实例？开不上去，就这么多。
动态并发把这道墙拆了。agent 自己决定派生几个子 agent，子 agent 再自己决定派生几个。
我见过的版本大概长这样：
supervisor: 4 subtasks -> spawn 4 workers
worker#2 : 3 subtasks -> spawn 3 workers
worker#2.1: 5 subtasks -> spawn 5 workers
...
每一层单独看都合理。合起来就是：没人知道此刻总共有多少个在跑。
论文列了 13 种并发相关的失败模式、28 种可观察模式。我没全看完。但我知道当年那套自动扩缩容里也有十几种长得差不多的，而且大部分不是算法笨——是没人能在它开始作死的那几秒里拦住它。
真正会出事的不在论文里
说句实话，这份研究本身没什么可挑的。问题出在它被谁读、读成什么。
摘要里那句"动态并发为扩展复杂开发任务提供了一条有前景的路径"，落到管理层耳朵里，中间过一层翻译，会变成：agent 能自己编排了，那还要人盯着干嘛。
下一个季度就能听到「AI agent 可以顶上 SRE 的活了」。
论文自己没这么说，论文写得很克制。是读的人在急着把 2124 次实验里那句话省掉——短任务是模型的活，长任务是编排的活。
翻译成人话：活儿越长，越得有人在。这个位置现在还没被训练出来接得住，别提前把椅子撤了。
（扯远了。回到并发。）
上次那个半夜挂掉的集群
我接过一个电话，凌晨两点，一个批处理集群挂了。任务本身没毛病，挂的是调度器——它给一个长任务派了太多并行分支，几个分支抢同一份状态，互相踩。
修的时候我们改的不是分支，是让调度器知道自己最多能派几个。
回来加了一行配置，就好了。
并发能力真正的上限不是机器给的，是任务的状态模型给的。agent 现在看不到这条线，它看到的只是"这活儿可以并行"。它眼里的边界，永远比真实边界宽。
本期教训
跑长周期 agent 任务，先把子 agent 并发数写死成 1，跑几轮，摸清它究竟在哪个环节想开并发、想开几个、开完谁来收尾，再一格一格往上抬。
别让它在没人看的第一天自己决定。
至于"有前景的路径"——前景是有。路上得先装几个报警器，装完还得有人盯着。谁盯？反正不是写论文的，也不是写模型的。
还是那帮冤种。🙃