Performance bottlenecks within the `agent-autoloop` kernel, worker, and host components, specifically concerning excessive I/O, redundant computation, and inefficient data access.

# 几个随历史/worker 数线性放大的固定开销（建议先加测量再改）

**版本**：`3930f09`（2026-11-04 上游 HEAD） · **区域**：`kernel/`、`worker/`、`host/`

下面的数字不是实测，是代码路径；仓库已有 `scripts/benchmark.ts` 和 `scripts/history.ts`，建议先补对应场景再改实现。四项按「收益/风险」排序。

## 1. 忙碌时心跳每秒写一条 `seen` 事实（写放大）

- `worker/worker.ts:455-460`：手上有 run 时 `wait: 1`，每秒一轮；
- `kernel/http.ts:146`：每个 `/v1/work` 都 dispatch `heartbeat`；
- `kernel/decide.ts:480-489`：每次都更新 `seen_at` → 必然追加一条事实（WAL + FULL，一条一次 fsync）。
- 一次 30 分钟的任务约 1800 条事实，8 小时忙碌约 2.9 万条；而 `seen` 只用于 `WORKER_FRESH = 2 分钟` 与 `RUN_LEASE = 5 分钟`（`kernel/due.ts:6-12`），秒级精度完全过剩。
- 建议：`heartbeat` handler 里按 15–30 秒节流（`now - seen_at >= 15_000` 才写；run 的 `seen_at` 按 30–60 秒更新），worker 仍可每秒来问活/查取消，语义不变。节流后同样的测试（租约/离线）应全部通过，并断言 1 分钟心跳只产生 2–4 条事实。

## 2. 每个输入都全量重算到期表

- `kernel/decide.ts:63-71`：`decide` 末尾无条件调用 `deadlines()`；
- `kernel/due.ts:14-53`：扫描 schedules、timers、全部 queued runs、deliveries、`workers × waitingOn`。
- 忙碌时每秒心跳 × worker 数，每个输入都做一遍全量扫描；而外壳的 `arm()`（`host/server.ts:76-90`）只关心最小值。
- 建议（按风险递增）：(a) 只对会改变到期时间的输入重算（tick、later/cancel、claim/finish、delivery 状态、rules）；(b) 把 `due` 做成像 `projection_pending` 一样由 `evolve` 增量维护的投影。保持 `decide(view, input, now, environment)` 的确定性，用 `sim/invariants.ts` 校验「due 表 == 直接重算」。

## 3. 配置行与规则对象被反复查询/解析/深冻结

- `kernel/query.ts:7-11`：`configuration`/`workerOf` 每次 `view.get`；
- `kernel/query.ts:23-28`：`waitingOn` 对每个 worker 扫全部 queued+claimed run，并对每个 run 调 `workerOf`；
- `kernel/evolve.ts:97-104`：`View.get` 无缓存，每次 SQLite `SELECT` + `JSON.parse` + 递归 `Object.freeze`。
- 结果...