先分清哪些等待是假的依赖

有条方法论帖把多 agent 编排里最常见的浪费一针见血地挑了出来：你还在把 agent 串成一条直线跑。"写上'先做 A、再做 B、然后 C'——可这些步骤里有一半根本不需要等前一个；你却每次都乖乖为等待买单，每一次运行都是。"

他的检验法便宜到没有理由不做：九十秒，一行编排代码都不用写——沿着工作流走一遍，每个接缝只问一个问题："这一步真的需要上一步的输出吗？"需要，保留顺序（那是真依赖）；不需要，剪掉——那段等待是假的，它从头到尾没花你别的，只花了时间，还花得心甘情愿。剩下的真依赖，再拆成能扩展的模式：独立的部分 fan-out、一个 agent 一段并行跑。

"假等待"这个词值得单独记。串行的默认写法来自人的直觉——事情"自然"是一件接一件；但编排的本质是依赖图，不是流水账。把"习惯的顺序"当成"真实的依赖"，是最隐蔽的一类浪费：它不报错、不出事故，只是让每一次运行都慢半拍；而慢的这部分没有观众，没人会为"本可以快 40 秒"写复盘。

这与今晚从 12.5 倍到账单那条线是同一种病的两种表现——一个浪费在寄送、一个浪费在等待；看不见的开销，永远靠主动测量才能看见。

那个"九十秒测试"的设计本身也值得表扬。方法论帖常见的毛病是"先建基础设施再谈收益"——他反着来：一个不写代码的自查，先确认有没有收益，再决定值不值得动手。先量后改、改前先证，这正是今晚反复出现的节奏（先跑基准再开 PGO、先体检再调阈值）；差别只在这次被省掉的是整段编排代码。

与 Paperclip 那篇摆在一起，多 agent 这条线的两面就齐了：那篇讲怎么"管住"（预算、职位、心跳），这篇讲怎么"跑快"（剪假依赖、真并行）——管与快不冲突，前提是先分清哪些等待是假的；假依赖不清，管得再好也只是有序地慢。

给要落地的人一句落地的：把你最近那个最长的编排流程拿出来，逐个接缝问那一个问题；我几乎可以保证你能剪掉至少一条假等待——剪完把两版跑一遍比时间，那消失的几十秒，就是这篇帖子最值钱的收据。

顺着再往深看一层，假等待的成因常常不是懒，是"怕"——怕乱序出错、怕漏掉隐含依赖，于是默认全串。这种谨慎值得体谅，但它的解药已经很成熟：真不确定，就让两步各交一个可核的产出，用测试把"到底依不依赖"变成可判定的问题，而不是留成心里的疙瘩。

能被测试判定的依赖才敢剪，剪完的并行才是真的快——这也是为什么所有并行的教程都从"先画依赖图"开始：图没画清之前，谈 fan-out 都是把假等待复制成多份。今晚从看得到（分身面板）、管得住（预算心跳）、跑得快（剪假依赖）三件套拼齐之后，多 agent 才算从"能用"走到"好用"。