[Bug]:harnessAgent编排模式,Memory 的 `concatWith` 后置钩子阻塞了 `call()` Flux complete处理，导致编排长时间等待？是否有其他方案

[rogerlmj123]

结论（已坐实）

根因就是 Memory 的 concatWith 后置钩子阻塞了 call() Flux complete。

父编排器感知逻辑正常；子 Agent 业务结果也早已产出。慢在：

1. MemoryMaintenance.consolidate().block()（约 44.6s，首次）
2. MemoryFlush.flushMemories LLM（FlushTrigger{ALWAYS}，每次约 19–27s）

总耗时 244 秒。

---

product-recommend-agent 耗时拆解

阶段	耗时	日志
工具 searchProducts	~0.6s	TOOL_DONE
二次 LLM 出文案	~19.8s	TOOL_DONE → AGENT_RESULT
核心结束	—	AGENT_END（与 RESULT 同 ms）
CONSOLIDATE_LLM	44.6s	CONSOLIDATE_LLM_START → END
FLUSH_LLM（ALWAYS）	19.6s	FLUSH_LLM_START → END
offload	20ms	可忽略
AGENT_RESULT → CALL_COMPLETE	64.3s	几乎全是上面两段 Memory LLM

时间线：

18:36:36.169  AGENT_RESULT / AGENT_END
18:36:36.177  CONSOLIDATE_LLM_START
18:37:20.810  CONSOLIDATE_LLM_END (44633ms) + MEMORY.md consolidated
18:37:20.816  FLUSH_LLM_START (ALWAYS)
18:37:40.441  FLUSH_LLM_END (19625ms)
18:37:40.462  CALL_COMPLETE

期间父侧 task_output 空等约 60s（18:36:17 → 18:37:17），因为 Task 要等 CALL_COMPLETE 才变终态。

---

product-consult-skill

• Maintenance：SKIP（minGap=30min 节流）
• Flush：仍 ALWAYS，约 25.7s / 27.3s
• 同会话还被 spawn 两次（两套 sub-session），各跑一遍 Flush → 又叠约 50s+

---

因果链（最终版）

业务工具很快
  → AGENT_RESULT（结果已出）
  → MemoryMaintenance.concatWith（consolidate LLM block）  ← P0
  → MemoryFlush.concatWith（flush LLM ALWAYS）            ← P0
  → CALL_COMPLETE 才到
  → wait_async / task_output 才结束

不是「父没检测到」，是 官方把记忆维护串在 call 完成路径上，且子 Agent（Harness 叶子）默认开启了这些 hooks。

---

修复建议（优先级）

优先级	改法	预期收益
P0	子 Agent / 编排叶子：disableMemoryHooks()	直接砍掉 AGENT_END 后 40–70s
P0	或把 Flush/Maintenance 改成 fire-and-forget（不 concatWith）	call 可立即 complete，记忆后台做
P1	Flush 从 ALWAYS 改为 NEVER / THROTTLED	至少去掉每次 20s+ Flush LLM
P2	编排内静默 DirectOutput	再省工具后二次 LLM ~20s
P2	避免同波重复 spawn consult	少一轮 Flush

单跑快，是因为 BaseAgent 路径通常没有这套 Harness MemoryFlush/Maintenance concatWith；编排 spawn 出的是完整 Harness 叶子，所以才会慢。

[ningmeng0503]

我也遇到这个问题，AgentEvent 转换 AguiEvent 时，AGENT_END 已经转换完了，但是还要等 MemoryFlush/Maintenance 结束才能结束sse，严重影响用户体验。MemoryFlush/Maintenance 不知道能不能改为异步实现。
我目前手动调整了一下，对 Flux< AgentEvent > 进行缓存和多路订阅。第一个订阅是 sse 推送，接收到 AgentEndEvent 就停止订阅。另外一个订阅是订阅完整的 AgentEvent，完成 MemoryFlush/Maintenance 等其他 AgentEvent 的消费。当 sse 中断或者取消时，把这个订阅也关闭。