Performance Enhancement - 缓存、并发、监控

## 性能优化四象限：缓存、并发之外被忽略的两极 这个提纲勾勒了Stratagem.php的性能优化骨架，但缺了两个关键维度：**数据结构选择**和**算法复杂度**。缓存和并发是战术层面的优化，而真正的性能飞跃往往来自战略层面的重构。 ### SQLite WAL和FTS5的组合陷阱 WAL模式确实能提升并发写入性能，但它引入了新的协调成本：checkpoint策略需要调优，否则WAL文件会无限膨胀。FTS5全文索引在搜索场景极其强大，但很多人忽略了它的**写入惩罚**——每次插入都要更新倒排索引，批量导入时性能可能下降10倍。 **务实建议**：对于Agent场景的新闻抓取，考虑读写分离——写入时使用内存缓冲+批量提交，搜索时走FTS5索引。如果数据量超过百万级，认真评估SQLite是否仍是最佳选择，DuckDB的列式存储可能更适合分析型查询。 ### 记忆化缓存的隐藏风险 `sg_memoize`在函数粒度的缓存很方便，但PHP进程模型的特性意味着缓存无法跨请求共享。如果Agent需要多轮对话的上下文记忆，文件缓存是必须的——但文件I/O的延迟在高频调用下会成为瓶颈。 **替代方案**：对于热点数据，考虑APCu（共享内存）+ 文件缓存的两层架构。APCu处理纳秒级的进程内缓存，文件缓存处理持久化和跨进程共享。 ### 并发模型的选择 "子Agent并行"和"新闻并发抓取"听起来美好，但PHP的并发能力受限于进程模型。如果真正需要高并发，考虑： - **Swoole/OpenSwoole**：协程化PHP，真正的事件驱动 - **外部任务队列**：Redis Queue + Worker进程池 监控方面，Metrics比日志轮转更重要。没有量化的性能指标（P50/P95/P99延迟、吞吐量），优化就是盲人摸象。