mirror of
https://github.com/ThearchyHelios/AgentLab.git
synced 2026-11-15 02:41:58 +00:00
ThearchyHelios
00f8dd78a9
图上一个节点连出多条边就是 fan-out，LangGraph 在同一个 superstep 里并发执行
——这一直是真并发。但在时间线上它们只是穿插出现的几行，"这三路是同时跑的、
因此省下了 3.6 秒"一个字都没说。上一轮给协作团队做了泳道，这条同样的信息
在 fan-out 这边还是缺的。
现在按时间跨度把同时跑的节点收进一个分组，标题写明几路、meta 写明省了多少：
⑂ 3 路并行 合计 6.6s，实际 3.0s
├ 查销售库 2.2s
├ 查库存库 3.0s
└ 查客户库 1.5s
**判据是"同一批出发"，不是"跨度重叠"。** 第一版按包含关系排除嵌套，结果漏掉了
先跑完的那一路：三路同时开始但先后结束时，长的那条在时间上确实"包含"短的。
实测 leg0 [0.05,2.21] / leg1 [0.05,3.01] / leg2 [0.05,1.51]，被漏掉的正是
最快的 leg2——而漏掉最快那路会让"省下多少"算少。改成看开始时刻是否落在同一批
（250ms 窗口），fan-out 的几路实测相差不到 1ms，子工作流那种真嵌套则是父节点
明显更早开始，自然分得开。
组内要求两两都同批，而不是链式传递：否则 A|B 重叠、B|C 重叠但 A|C 不重叠的
三个节点也会被串成一组，而它们并不是同时在跑。瞬时节点（<30ms）不参与——
它们谁跟谁都"重叠"，是噪音不是信息。
**误报比漏报更糟**：它会让人以为省了时间。所以断言里专门守了反向——db、human、
loop_approve 三份顺序执行的样本一个都不能被判成并行。
fixtures 里新增的 fanout 是真跑出来的，不是手写的：三路分别 sleep 1.8 / 2.6 /
1.1 秒，事件原样收进来，所以 6.6s / 3.0s 这两个数和后端量到的是同一份。
验证：check-decode 新增 6 条（含三份顺序样本的反向断言）；check-stream 新增
10 条，宽窄两栏都验了不溢出；后端 276 passed 不受影响；tsc 干净。