当前范围（2026-09-06 收口）
本 issue 跟踪下列 4 项后端候选：custom-agent request context 已完成限定修复，Timeout / FileStore / SQLite 已完成限定负载测量；新发现的 checkpoint 差分/清理遗漏已由 #2335 / #2336 复现修复。这不是已证明的全局性能瓶颈清单。旧前端/注释条目已分别由 #2279、#2305 等处理，前端总索引 #2274 已收口；不再按原 round-65 的 16 条摘要重新施工。
| 候选 |
当前状态 |
有效证据与裁决 |
| E-P2-3：service / repository 的 request context 传递 |
SCOPED FIXED — #2329 / #2330 |
custom-agent CRUD 的 6 次数据库访问已绑定请求 context。真实 PostgreSQL 表锁下，旧代码取消后再等 2 s 仍占满单连接池；修复后 deadline / disconnect 均在锁仍持有时结束 SQL、释放池容量。完整 L1 race 与 required gates 已通过。仅证明该链路，不外推其他 service 或生产频率。 |
| E-P2-4：缓冲式 Timeout 的响应复制成本 |
MEASURED — #2331；基准已由 #2332 合并（七项 required checks 与最终 head race smoke 通过） |
真实 Hub JSON 的 28,772 / 287,522 / 2,207,522 B 负载，GOMAXPROCS 1/4 各 5 次：缓冲相对流式增量约 11–18 / 65–70 / 353–515 us。完整原始数据与分配量在 #2331。保留 buffered Timeout 的响应原子性，不因微基准改成流式；无 RSS/生产频率结论。行数上限不等于通用字节上限。 |
| E-P2-6：FileStore 的全量快照持久化 |
MEASURED / 保留现状 — #2333 / #2334 |
10 / 100 / 1000 runs 的完整显式 flush 中位数为 1.557 / 6.744 / 53.545 ms；最大 fixture 的 10.55 MB JSON 编码约 42.343 ms，snapshot 约 1.090 ms。已区分复制、编码和实际 Sync/rename 路径；不把残差当作纯 fsync 或把显式 flush 外推为现场频率。 |
| E-P3-8：SQLite 单连接与 WAL 并发 |
MEASURED / 不改连接池 — #2333 / #2334 |
0 / 1 / 4 个真实 facade 读者加单写者，45 个样本均无 SQL pool waits 或写入/锁错误；读面仍在内存，争用结果不能证明单 SQL 连接瓶颈。发现单 run 写产生 13 / 103 / 1003 个 SQL row changes，checkpoint baseline/清理遗漏已由 #2335 / #2336 修复：同一 fixture 的 SQL row changes 降为 3，真实 SQLite 删除/重开和合法更新回归通过，不借此改 PRAGMA。 |
必须更正的旧前提
旧评论把 E-P2-6 FileStore 与 EventLog 称为“共用 l.mu”，并据此要求 FileStore / SQLite 测量必须先配置 AGENTHUB_EVENT_LOG_PATH。这不成立。
在 5809d577 的代码中：
FileStore.syncPersist 使用自己的 persistMu，随后调用 Store.snapshot()（自己的 Store.mu.RLock）和 JSON/fsync/rename；见 file_store.go 与 store.go。events.EventLog 的 l.mu 是另一个对象的独立锁；其路径配置只决定 EventLog 持久化是否启用。- 因此 FileStore、SQLite 可以用各自的隔离持久化夹具测量，不需要打开现役 Edge 的 EventLog；也不能把三个组件的锁等待合计为“同一把锁”。
上面的锁归属校正本身不包含性能结论。request-context 已在 #2329 / #2330 获得独立的新测量和修复；Timeout 的限定负载测量见 #2331；FileStore / SQLite 的 105 条原始样本、环境、分配量和尾延迟桶见 #2333 测量证据。
已完成或移出的条目
处置纪律
没有 measurement 不直接优化；测量显示当前规模/频率下收益不足时，可降级或关闭，不为算法形式改代码。独立 benchmark 只能证明其注明环境和负载，不能冒充持久化现场频率或生产收益。历史过程和原始数据保留在评论与关联 PR。
收口裁决
四项限定候选已分别完成：custom-agent context scoped fix；Timeout / FileStore 量化后保留现状；SQLite 保留单连接与 WAL，修复了测量发现的 checkpoint 生命周期和 delta baseline 缺陷。#2330 / #2332 / #2334 / #2336 均已合并且各自 required gates 全绿；主线为 4e3739e39402d1de7dec83c4f6f4be3609d181b9。
checkpoint 红绿证据与45 条原样复测已保存。旧库中已存在的孤立 checkpoint 不会自动修复，本次没有数据迁移、开发/生产服务变更或新的 L3/L4 验收。#2304 的 EventLog 结构性变更仍需持久化现场负载证据；#1663 上游目前仍无修复版本，二者独立保留，不在此处冒充已完成。
当前范围（2026-09-06 收口）
本 issue 跟踪下列 4 项后端候选：custom-agent request context 已完成限定修复，Timeout / FileStore / SQLite 已完成限定负载测量；新发现的 checkpoint 差分/清理遗漏已由 #2335 / #2336 复现修复。这不是已证明的全局性能瓶颈清单。旧前端/注释条目已分别由 #2279、#2305 等处理，前端总索引 #2274 已收口；不再按原 round-65 的 16 条摘要重新施工。
必须更正的旧前提
旧评论把 E-P2-6 FileStore 与 EventLog 称为“共用 l.mu”，并据此要求 FileStore / SQLite 测量必须先配置
AGENTHUB_EVENT_LOG_PATH。这不成立。在
5809d577的代码中：FileStore.syncPersist使用自己的persistMu，随后调用Store.snapshot()（自己的Store.mu.RLock）和 JSON/fsync/rename；见 file_store.go 与 store.go。events.EventLog的l.mu是另一个对象的独立锁；其路径配置只决定 EventLog 持久化是否启用。上面的锁归属校正本身不包含性能结论。request-context 已在 #2329 / #2330 获得独立的新测量和修复；Timeout 的限定负载测量见 #2331；FileStore / SQLite 的 105 条原始样本、环境、分配量和尾延迟桶见 #2333 测量证据。
已完成或移出的条目
处置纪律
没有 measurement 不直接优化；测量显示当前规模/频率下收益不足时，可降级或关闭，不为算法形式改代码。独立 benchmark 只能证明其注明环境和负载，不能冒充持久化现场频率或生产收益。历史过程和原始数据保留在评论与关联 PR。
收口裁决
四项限定候选已分别完成：custom-agent context scoped fix；Timeout / FileStore 量化后保留现状；SQLite 保留单连接与 WAL，修复了测量发现的 checkpoint 生命周期和 delta baseline 缺陷。#2330 / #2332 / #2334 / #2336 均已合并且各自 required gates 全绿；主线为
4e3739e39402d1de7dec83c4f6f4be3609d181b9。checkpoint 红绿证据与45 条原样复测已保存。旧库中已存在的孤立 checkpoint 不会自动修复，本次没有数据迁移、开发/生产服务变更或新的 L3/L4 验收。#2304 的 EventLog 结构性变更仍需持久化现场负载证据；#1663 上游目前仍无修复版本，二者独立保留，不在此处冒充已完成。