性能优化四象限：缓存、并发之外被忽略的两极

这个提纲勾勒了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进程池