Memory Center 40｜复盘：哪些设计值得保留，哪些需要重新判断

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 40 篇，位于“验证与完整实践”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

系统跑通之后，最容易把当前选择当成永远正确。实际开发项目的规模、宿主和使用方式会变，好的复盘应说明哪些条件支撑当前方案，以及什么信号会触发调整。

保留能够解释的约束

稳定身份、单一登记真源、证据边界和成功后发布，可以持续降低错误。但它们都有实现成本：更多元数据、额外读取、历史空间以及状态协调。文章应同时写收益和代价。

复盘：哪些设计值得保留，哪些需要重新判断：设计链路示意

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

用测量决定下一步

单实例是否足够、SQLite 是否合适、向量是否值得开启，都需要根据当前负载和质量样例判断。先补足观测和失败回归，再考虑增加复杂组件。功能多不等于可靠，架构简单也不等于没有边界。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/service/app.py，函数 storage_status，起始行 51。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

def storage_status(config: ServiceConfig) -> dict[str, Any]:
    """后端能力边界；SQLite 与 PostgreSQL 并不等价，必须对调用方与页面显式可见。"""
    if config.database_url:
        return {
            'backend': 'postgresql',
            'persistence': 'postgres+pgvector',
            'vector_recall': 'distance_index',
            'hnsw_max_dimension': 2000,
            'exact_scan_chunk_limit': 0,
            'note': '向量按距离查询；维度不超过 2000 的模型档案建立 HNSW 索引，更高维度退回精确检索。',
        }
    budget = sqlite_vector_limit()
    return {
        'backend': 'sqlite',
        'persistence': 'sqlite',
        'vector_recall': 'exact_scan',
        'hnsw_max_dimension': 0,
        'exact_scan_chunk_limit': budget,
        'note': f'SQLite 向量使用流式精确召回，只保留 Top-K 候选；扫描上限 {budget}（0 为不限制）。耗时随分块数量增长，大规模或高并发建议 PostgreSQL + pgvector。',
    }

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

列出三个当前决策及其失效条件。
选择一条真实失败样例。
记录需要补足的测量而非先指定新技术。

**要核对的结果：**复盘输出应包含保留、调整和待验证三类结论，不能把所有未来想法列成已实现能力。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。

专题目录

复盘：哪些设计值得保留，哪些需要重新判断