【反馈】实测智能体团队会话耗时过长-当前版本：0.2.0-rc.2

[oSunnyo]

我解析了 ~/.dsh/sessions/ 下这次会话的 5 份日志（Lead + 4 名 teammate，共 1998 次工具调用、1564 个 step），下面全部结论都有实测数据。

结论

不是"正常耗时"，但也不是"某处坏了"。 总墙钟 153 分钟（15:05:08 → 17:38:28，加最终收尾约 2h40m）。其中约 60–65% 是这类工作的固有成本（52 模块 Maven 验证、真实代码量、被强制的依赖串行、模型生成延迟），约 35–40% 是流程缺陷造成的可压缩开销——可以省下 40–55 分钟。

你感觉"工具调用特别长"是对的，而且定位很明确：长的不是普通工具，是 wait_agent——最长一次 901.8 秒，且它返回的是 {"timedOut":true}（15 分钟零进展）。

时间去向（agent-分钟，实测）

agent	活跃 turn	工具耗时	其中 wait_agent	其中 Maven	模型/其它	steps
Lead	131.1	98.4	72.1	1.6	32.6	291
engine-exec	99.4	69.8	0	33.7	29.6	564
connection-core	60.9	35.5	25.5	2.5	25.4	253
ingestion-exec	37.0	17.9	0	6.0	19.2	326
verifier	16.4	5.6	0	0.8	10.8	130
合计	344.8	227.2	97.6	44.5	117.6	1564

• 墙钟 153 min，agent 活跃 turn 合计 345 min → 平均并发仅 2.3（你要求的并行宽度是 2，加上我监督）。
• 工具耗时里 wait_agent 占 43%；真正"干活"的工具时间只有 227 − 98 = 129 min。
• 模型/思考 117.6 min / 1564 步 ≈ 4.5 s/step——正常。
• 普通工具本身不慢：read 24 次共 28 s、edit 62 次共 136 s、write 6 次共 15 s、bash 130 次共 441 s（均 3.4 s/次）。

交付量作为对照：176 文件、+12,275/−852 行、18 个提交、5 条任务 + 5 条补强。

属于固有成本的部分（约占 60%）

1. Maven 验证本身就是 44.5 分钟：全仓 221 次 mvnw 调用，./mvnw -o verify 单次 1:23–1:28（52 模块，Docker 跑 Testcontainers）。-am 在离线环境是必需的，会把依赖几十个模块重新编译。
2. 真实代码量与强制串行：196 → 197 → {198,199}、196 → 200 是你定案的串行链；196 冻结前四条任务都不能动。
3. 模型生成延迟：1564 个 step × 4.5 s ≈ 118 agent-分钟，其中相当部分是各自产出长报告（每条任务报告 100–200 行）。

属于缺陷的部分（约占 35–40%）

缺陷 1：Lead 用 900 秒 ceiling 阻塞等待 —— 72.1 min，占我全部工具时间的 73%

• 证据：29 次 wait_agent，ceiling 全是 600–900 s，最长 901.8 s；其中 1 次直接 timedOut:true（16:11:12→16:26:14，15 分钟零进展）。
• 根因：我把"等 teammate"当成了 Lead 的默认动作，而不是先排满 Lead 自己的活再等。那 15 分钟里我本可以写 Lead 独占的 registry/status/distribution 改动。
• 修法：ceiling 压到 60–120 s，循环内 re-list；等待前先把 Lead 侧任务排上。
• 预计节省：20–30 min。

缺陷 2：互相等待（双向阻塞）—— connection-core 25.5 min 卡在 wait_agent

• 证据：connection-core 一次 35.8 min 的 turn 里 25 min 在 wait_agent，等待窗口与我等待别人的窗口重叠；它 21 次调用的 ceiling 最大 3,600,000 ms（1 小时）。
• 根因：teammate 在任务中途堵在"等 Lead 回复"上，而不是结束 turn 让 Lead 用 send_message 唤醒（send_message 本来就会 resume）。双方同时空转。
• 修法：明确禁止 teammate 中途等 Lead；把"结束 turn + 写状态"作为标准动作。
• 预计节省：15–20 min（在关键路径上）。

缺陷 3：并行写者导致构建互相打断 —— 35% 的 Maven 调用失败

• 证据：221 次 mvnw 里 78 次失败/编译错（35%），失败本身耗 11.7 min；engine-exec 最惨（46/123 失败）。
• 最直接的证据：engine-exec 写了一个补偿性重试循环，单次工具调用跑了 601.8 秒：

  for i in $(seq 1 24); do out=$(./mvnw -o -q -pl architecture-tests -am test 2>&1);
    ... grep "BUILD SUCCESS" ... grep -E "data-ingestion|找不到符号|COMPILATION" ... sleep 20; done
  

  它因为 ingestion-exec 正在改 data-ingestion，反复遇到编译错误，于是"重试 24 次、每次 sleep 20"。结果被 harness 的 600 s 上限切成后台任务，10 分钟没产出有用结果——而这 10 分钟正是我那次 902 s 盲等。
• 根因：文件写范围不重叠 ≠ 构建不冲突。-am 会把别人在办模块一起编译；没有构建串行化（锁）或"写者静止窗口"约定。
• 修法：给 ./mvnw 加一把锁（或规定根验证期间写者必须静止）；teammate 遇到跨模块编译错时应暂停并上报，而不是自旋重试。
• 预计节省：15–20 min。

缺陷 4：门禁失败发现太晚，整轮返工 —— 约 40 min

• 证据：两次都由我的根验证才发现，而执行者已报"全绿"：
  1. SecretProviderRegistry 没有 @Bean → knowledge-engine-application 7 个集成测试全部 Failed to load ApplicationContext；
  2. Spotless 拦下未使用 import（模块级命令不带 Spotless）。
• 根因：执行者的 DoD 用的是"本模块 -am test"，而我的验收命令是"根 verify"。两者不等价，我在交付中途才补上这个要求。
• 修法：DoD 从第一天起就要求执行者跑与 Lead 相同的命令（含 spotless:check 与一次上下文加载冒烟）。
• 预计节省：25–40 min。

缺陷 5：对抗验证跑在"移动靶"上，轮次没合并 —— 约 25–35 min

• 证据：4 轮独立验证 + 5 条补强任务。第一轮只读复审时 connection-api 还在被人改；第二轮 20 条注入又发现 6 处证伪，于是又一轮修复 + 复验。
• 根因：没有"冻结点"。正确顺序是 冻结 → 一次性对抗 → 一批修复 → 一次复验。分开做时，同一主题（凭证边界）被拆成了三轮。
• 修法：把"独立对抗验证"固定在每个冻结提交之后，修复合并为单轮。
• 预计节省：20–30 min。

另外两条是 harness 层面的设计限制（不是我的错，但值得反馈）

1. wait_agent 看不见 peer 的工具活动：它只观察 status/mailbox/shared-task 变化。engine-exec 在那 15 分钟里虽然只发了 3 个 step，但它正卡在一次 10 分钟 Maven 里——我没有任何途径"观察进度"，只能盲等或轮询。日志里唯一那次 timedOut:true 就是这么来的。
2. Lead 没有"边等边做"的原语：要么阻塞在 wait_agent，要么放弃等待。这次我选了阻塞 29 次。如果存在"后台订阅 teammate 进展、同时继续自己的 step"的机制，缺陷 1 基本可以消除。

总账与建议

项	实测	判定
Maven 验证	44.5 min / 221 次	固有，但 35% 失败率是缺陷
Lead 阻塞等待	72.1 min（29 次，1 次 15 min 空等）	缺陷
互相等待	25.5 min	缺陷
迟到门禁返工	2 次整轮返工	缺陷
验证轮次未合并	4 轮 + 5 补强	缺陷
模型生成	117.6 min / 1564 step	固有

可压缩 40–55 min，即 25–35%；下限约 1h45m–1h55m，不是把它压到 30 分钟——因为余下的是 52 模块 Java 构建与真实代码量的硬成本。

下次同类交付我会改四条：① wait_agent ceiling 降到 120 s 并循环 re-list，等待前先把 Lead 自己的活排上；② 禁止 teammate 中途等 Lead，改为结束 turn + 写状态；③ 从第一天起把"根 verify（含 Spotless）+ 一次上下文加载"写进执行者 DoD；④ 冻结提交后才做一次性对抗验证，修复只开一轮。