# ADR-0010: 方案③触发采用独立 OpenClaw session

**状态**: 已接受
**日期**: 2026-08-18
**决策者**: 架构团队
**相关**: ADR-0009（触发式执行取代 Cron 池）、CONTEXT.md（触发式执行）

## Context

方案③（ADR-0009）以 `docker exec openclaw-eval openclaw agent --agent main -m "<worker/planner skill>" --json` 触发 OpenClaw headless agent 执行 worker / planner skill。t480 实测发现：评估进入 executing 后**一直卡"等待 OpenClaw 创建会话"**——任务入队（pending）但 worker 从不认领。

排查（diagnosing-bugs 闭环）确认：
- scan loop 每 60s 正常触发 worker（时间戳证实）
- worker 被触发后 **0 次工具调用**，直接幻觉输出"评估 pending_approval"（实际 executing）
- model usage 显示 **cacheRead ~12 万 token**：`--agent main` 复用 **main 持久 session**，多次触发累积了大量历史上下文缓存
- **验证**：手动用独立 `--session-id` 触发 → worker 恢复正常（取任务、建会话、close）

根因：OpenClaw main agent 的持久 session 在多次触发后上下文缓存膨胀，LLM 不再执行 worker skill 的 API 步骤，而是从旧上下文幻觉输出——复用 main session 的"缓存命中"收益在触发式执行（高频、长链工具调用）下不可靠。

## Decision

方案③的 worker / planner 触发命令**加 `--session-id`（每次唯一）**：

```bash
docker exec openclaw-eval openclaw agent --agent main \
  --session-id agenteval-worker-<unix-ts> \
  -m "<worker skill 指令>" --json
```

- worker 用 `agenteval-worker-<ts>`、planner 用 `agenteval-planner-<ts>`，每次触发独立 session
- 触发 timeout 从 300s 调到 600s（独立 session 首次加载 skill + 执行更慢）

**为什么独立 session 可行**：worker/planner 的决策完全基于平台状态（任务队列、评估/会话/决策日志 API），**不依赖跨触发记忆**——每次干净 session 无副作用。

**时段分布约束**（同一决策）：触发指令明确"仅执行当前 offset 所在时段内欠账的会话，绝不创建未来时段会话"；worker 完成当前时段后 complete 任务，平台每 60s 再次触发推进后续时段——保证 1h 窗口的交互按时段（如 0-20/20-40/40-60min）分布，而非一次性建完。

## Consequences

- **每次触发新建 session**：无上下文缓存命中，首次加载 skill 更慢（触发一次约 1-5 分钟），但行为可靠（不再幻觉）
- **无跨触发状态**：worker/planner 无记忆，全部状态在平台 DB（设计本如此）
- **scan loop 节奏**：worker 执行当前时段（分钟级），完成后平台每 60s 触发推进；与 1h 窗口时段匹配
- 旧 main session 的历史缓存不影响新触发（独立 session 隔离）