Task task-xfkjid — 执行日志

[main/爱衣] 调研报告 — Session 冷启动延迟优化方向

时间： 2026-02-23 GMT+8
背景： coder（04:46:26 收到消息）→ reviewer 开始处理（04:48:40），延迟 2 分 14 秒。而 reviewer→main 同样路径仅 5 秒。差异根因：receiver session 是否处于活跃（热）状态。

方向一：是否有可调的 inter-session 唤醒间隔参数

调查过程：

查阅了以下源码和文档：
- /usr/lib/node_modules/openclaw/docs/gateway/configuration-reference.md
- dist/reply-B2UJINPw.js 中 sessions_send 的 execute 实现

关键发现：

sessions_send 在 timeoutSeconds=0（fire-and-forget）时，代码路径是：

// timeoutSeconds === 0 分支
const response = await callGateway({
    method: "agent",
    params: sendParams,
    timeoutMs: 1e4   // 等待 Gateway 接受（最多10秒）
});
startA2AFlow(void 0, runId);
return jsonResult({ runId, status: "accepted", ... });

即：发起方调用 callGateway({ method: "agent" })，Gateway 同步接受（10秒超时内返回 runId），然后立即返回 "accepted"。
消息传递本身是即时的（实测 4 秒内到达目标 session），不存在轮询间隔。

真正的延迟来源：
目标 session 收到消息后，需要获取 CommandLane.Nested（嵌套 lane）的执行权。源码中：

const AGENT_LANE_NESTED = CommandLane.Nested;

Lane 是一个串行队列。如果目标 session 当前有其他 Nested lane 任务在跑（或有某种 backoff/debounce），新消息要等前面的任务完成。

但 reviewer 当时是完全空闲的（38 分钟没有任何活动），不存在 lane 竞争。

进一步分析（最可能的原因）：

查看配置参考中的 messages.inbound.debounceMs：

{
  messages: {
    inbound: {
      debounceMs: 2000  // 0 disables
    }
  }
}

还有 session.reset.idleMinutes（默认 60 分钟）——空闲超时会创建新 sessionId，但 reviewer 才空闲 38 分钟，不会触发。

目前没有找到任何文档中明确记录的"冷 session 唤醒间隔"参数。延迟更可能是：

1. Debounce 叠加：messages.inbound.debounceMs（默认 2000ms）只占 2 秒，不足以解释 2 分钟
2. Prompt caching TTL：从 session-pruning.md 看，Anthropic prompt cache TTL 约 1 小时，空闲 38 分钟的 session cache 仍然有效，不应导致重建
3. 最可能：Gateway 对空闲 session 的 dispatch 有内部延迟，可能是某种心跳轮询机制在驱动，约 2 分钟周期

结论：
❌ 文档中无可直接调整的"唤醒间隔"参数。延迟机制是 Gateway 内部实现，不对外暴露配置。方向一无法直接优化。

方向二：预热（Preheat）reviewer session

思路： 在 coder 任务开始前，爱衣先 sessions_send 一条 ping 消息给 reviewer，使其保持活跃，这样 coder 完成后 reviewer 仍处于热状态。

可行性分析：

✅ 技术上完全可行，无需任何代码修改，只需在爱衣的任务创建流程中加一步。

实现方式：

爱衣创建 task.md →
sessions_send("preheat", sessionKey=agent:reviewer:main, timeoutSeconds=30) →
coder 开始工作 →
coder 完成后 reviewer 仍处于刚结束 preheat turn 的热状态 →
sessions_send 真正通知 reviewer →
reviewer 立即处理（预计延迟 <10s）

问题分析：

1. preheat 消息会触发 reviewer 的 model run：reviewer 需要处理这条消息，会有 token 消耗（约 1 个 turn 的 input tokens，~15K-20K tokens）
2. preheat 的 session"热度"持续时间未知：如果 coder 需要 10 分钟，preheat 完成后 reviewer 可能又冷却了
3. 从实验数据看：reviewer 在 04:08:01 结束任务，04:46:26 收到消息时已冷却（38分钟）→ 热度窗口 < 38 分钟
4. 但 main session 在 04:49:38 收到消息时仍是热的，因为主对话一直在进行
5. 热度窗口估算：可能只有几分钟
6. preheat 消息内容的设计：reviewer 收到 preheat 后会做什么？需要设计一条让 reviewer 快速处理并待命的消息（如 REPLY_SKIP 指令）

优化后的 preheat 方案：

不用一次 preheat，而是在 coder 任务还在进行时，由爱衣监控 coder 进度，在 coder 预计完成前 N 分钟（如 1 分钟）发送 preheat。

但这引入了新的复杂性（需要估算 coder 剩余时间）。

简单可行的方案：

不 preheat，而是改变通知方式：coder 完成后，由爱衣（而非 coder）来通知 reviewer。因为爱衣始终是热的（有主对话驱动），由爱衣转发通知可以在毫秒级完成，reviewer 收到的仍然是来自 Gateway 的 callGateway 调用，延迟取决于 reviewer 的冷热状态。等等，这和 coder 直接发没有区别。

更好的简单方案：在发任务前用 timeoutSeconds>0 发一条"等待激活"消息让reviewer活跃起来。

实际上，最简单有效的 preheat 是：在 sessions_send 给 coder 的同时，也 sessions_send 一条轻量消息给 reviewer（timeoutSeconds=30，等待回复）。这样 reviewer 在 coder 工作期间处于 REPLY_SKIP 后的 warm 状态。

结论：
✅ 方向二可行，但效果取决于 coder 执行时长。如果 coder 快（<2分钟），preheat 有效；如果 coder 慢（>5分钟），reviewer 可能再度冷却。适合短链任务，长链任务效果不保证。

方向三：用 enqueueSystemEvent 替代 sessions_send

思路： 昨天调研发现 enqueueSystemEvent 可以直接注入到目标 session 的消息队列，理论上比 sessions_send 更直接。

调查过程：

查看 enqueueSystemEvent 的实现：

// dist/reply-B2UJINPw.js
function enqueueSystemEvent(text, options) {
    const key = requireSessionKey(options?.sessionKey);
    const entry = queues.get(key) ?? (() => { ... })();
    // 去重检查
    if (entry.lastText === cleaned) return;
    entry.queue.push({ text: cleaned, ts: Date.now(), ... });
    // 注意：push 到队列后，函数就返回了！
}

关键发现：enqueueSystemEvent 只往内存队列里 push 一条消息，它本身不触发任何 model run。

它需要等 session 的下一次"被触发"时才会被消费（drainSystemEvents）。触发条件：
- 有新的 inbound message 到来 → 处理时会 drain system events 一起带入 prompt
- heartbeat 触发 → drain system events
- 没有任何自动的"有新 system event → 立即 dispatch"机制

对比 sessions_send（timeoutSeconds=0）：

// 调用 callGateway({ method: "agent", ... })
// Gateway 收到后立即 dispatch 一个新的 agent run

sessions_send 通过 callGateway({ method: "agent" }) 让 Gateway 立即创建并 dispatch 一个新 agent run。这个 run 会被放入目标 session 的执行 lane。

结论：
❌ 方向三不可行，结论与昨日调研相反需要修正：
- enqueueSystemEvent 不会触发 model run，只是把文本塞进内存队列等待下次触发
- sessions_send 已经是"触发目标 session 立即 dispatch agent run"的最直接方式
- 用 enqueueSystemEvent 反而更慢，因为它需要等待下一个触发事件（可能是 heartbeat，30 分钟后）

但是，enqueueSystemEvent 有一个潜在用法：结合 Plugin Hook 的 message:received 事件，可以在 Agent A 发消息时，hook 拦截并立即调用 enqueueSystemEvent+某个触发机制唤醒 Agent B。但这比直接用 sessions_send 复杂，没有优势。

综合结论

最根本的优化建议：

冷启动延迟的根因是 reviewer session 长时间空闲后 Gateway 对其 dispatch 有额外延迟，本质上是 Gateway 内部的调度行为，不对外暴露控制参数。

可行的缓解手段（按推荐优先级）：

1. 任务级预热（推荐）：爱衣在创建任务链时，同时向链路中所有专家 Agent 发一条轻量消息（timeoutSeconds=5，快速唤醒），然后再启动 coder。代价：约 2 turn × 15K tokens ≈ 30K tokens 额外消耗，但可将 reviewer 延迟从 2 分钟降至 <10 秒。

2. 保持 Agent 活跃：如果任务频繁，可以用 heartbeat（每 25 分钟）定期 ping 一下 reviewer，让其维持热状态。但会持续消耗 token，不适合低频场景。

3. 接受现状：2 分钟延迟对于任务总耗时（本次 coder 3分钟 + reviewer 3分钟 = 6分钟）来说占比 ~33%，如果任务更复杂（耗时更长），比例会下降到可接受范围。

[reviewer/爱衣-审查] Factcheck 报告 — Session 冷启动延迟调研

时间： 2026-02-23 GMT+8
核查对象： 爱衣调研报告（上述「爱衣调研报告」章节）

一、callGateway({ method: "agent" }) 是同步触发还是入队？

原报告声明： sessions_send(timeoutSeconds=0) 通过 callGateway({ method: "agent" }) 让 Gateway 立即创建并 dispatch 一个新 agent run。

核查结论：✅ 基本正确，但表述需要精细化

源码证据（reply-B2UJINPw.js 第 52282–52296 行）：

if (timeoutSeconds === 0) try {
    const response = await callGateway({
        method: "agent",
        params: sendParams,
        timeoutMs: 1e4   // 等待 Gateway 接受，最多10秒
    });
    if (typeof response?.runId === "string" && response.runId) runId = response.runId;
    startA2AFlow(void 0, runId);
    return jsonResult({ runId, status: "accepted", ... });
}

callGateway 是对 Gateway 进程的 RPC 调用，Gateway 同步接受（10秒超时内返回 runId）。Gateway 接受并不等于 model run 已开始：Gateway 会把任务放入目标 session 的 CommandLane.Nested（串行队列），然后立即返回 accepted。目标 session 的实际 model run 开始时间取决于 lane 是否空闲及 Gateway 内部调度。

修正：callGateway({ method: "agent" }) 是"同步入队"而非"立即 dispatch model run"。报告中描述为"立即 dispatch"在语义上略有夸大——应为"立即提交给 Gateway，由 Gateway 调度 dispatch"。

二、enqueueSystemEvent 是否真的不触发 model run？

原报告声明： enqueueSystemEvent 只往内存队列 push，不触发任何 model run，需要等下次触发（heartbeat 或新 inbound message）才会被消费。

核查结论：✅ 完全正确

源码证据（reply-B2UJINPw.js 第 1637–1660 行，完整函数）：

function enqueueSystemEvent(text, options) {
    const key = requireSessionKey(options?.sessionKey);
    const entry = queues.get(key) ?? (() => { ... })();
    // ...去重、裁剪...
    entry.queue.push({ text: cleaned, ts: Date.now(), ... });
    if (entry.queue.length > MAX_EVENTS) entry.queue.shift();
    // 函数结束，无任何 dispatch / callGateway 调用
}

函数内没有任何调用 callGateway、enqueueCommandInLane、或其他触发 model run 的机制。drainSystemEventEntries 是单独函数，需要外部主动调用。

原报告"但是"段落（关于 Plugin Hook 的 message:received 事件）属于推测扩展，非事实误判，可接受。

三、方向一（无可调唤醒间隔参数）的结论是否准确？

原报告声明： 文档中无可直接调整的"唤醒间隔"参数；延迟最可能是 Gateway 对空闲 session 的 dispatch 有内部延迟，约 2 分钟周期。

核查结论：✅ 结论正确，但"2分钟周期"的推测缺乏依据

通过搜索文档和源码，确认：
- messages.inbound.debounceMs（默认 2000ms）仅影响同一发送者的消息批处理，不影响 A2A session dispatch
- session.reset.idleMinutes 控制 session ID 重置，不控制 dispatch 延迟
- 配置文档（configuration-reference.md）中未发现任何"inter-session 唤醒间隔"或"冷 session dispatch 延迟"相关参数

需要修正的推测：报告中"约 2 分钟周期"的根因推测——"Gateway 对空闲 session 的 dispatch 有某种心跳轮询机制"——此推测无源码支撑。CommandLane 的 drainLane 实现（第 3685–3722 行）是事件驱动的（任务完成后 pump()，新任务入队后 drainLane()），不存在轮询间隔。

更准确的根因推测：延迟可能来自 Gateway 进程侧对该 session 的某种 throttle / backoff / rate-limit 机制（未能从 minified 代码中找到直接证据），或者是目标 session 进程内的某种冷启动开销（模型上下文加载、prompt cache 验证等）。2分钟延迟的具体机制仍是黑盒，原报告对此已有诚实承认，但"约 2 分钟周期心跳轮询"的具体推测属于过度延伸。

四、方向二（preheat 预热）可行性评估

原报告声明： 技术可行，但热度窗口估算"可能只有几分钟"。

核查结论：✅ 可行性结论正确；热度窗口估算合理但保守

从实验数据分析：
- reviewer 在 04:08:01 完成任务，04:46:26 收到消息时延迟 2 分钟 → 38 分钟空闲后仍会冷启动
- main session 始终热（有持续对话驱动）

"几分钟"的热度窗口估算属于保守推断，实际窗口上限取决于 Gateway 内部机制。考虑到 38 分钟后仍冷，可合理推断窗口在分钟级别（可能 5–15 分钟范围内）。报告中的估算方向正确。

综合 Factcheck 判断

总体评级：报告质量良好。 核心技术事实（方向三的关键翻转结论、enqueueSystemEvent 机制）核查准确。两处需要注意：
1. callGateway({ method: "agent" }) 措辞应从"立即 dispatch model run"改为"同步提交入队，由 Gateway 异步 dispatch"
2. "2分钟心跳轮询周期"是未经证实的推测，建议在报告中明确标注为推测，或删除该具体推断

这两处修正不影响三个方向的可行性结论，综合优化建议（任务级预热）仍然有效。