第五章 选型、评估与实施
9. 部署与技术选型
9.1 默认 MVP
个人/工程场景采用 Git Markdown/YAML 作为已接受知识，SQLite 保存事件、候选、Outbox 和可重建检索投影；先做精确与全文检索。可用 MCP 或现有工具协议暴露查询和候选提交，不要求修改模型协议。
团队产品采用 PostgreSQL 事务表管理私有数据和权限，工程规范仍可由 Git 发布；先用全文检索，需要语义召回再评估向量扩展。只有关系遍历任务在评测中明显受限时，才引入图存储。
这是一条实施建议，尚未决定具体 embedding 模型、向量扩展、消息队列或评审服务，也不新增这些依赖。
9.2 接入路径比较
| 路径 | 适合的现有基础 | 可以利用什么 | 仍须自行负责什么 |
|---|---|---|---|
| 自建简化层 | 个人工具、数据控制要求明确 | 可审计文件、事务和精确查询 | 抽取、合并、权限、删除、评测 |
| LangChain/LangGraph Store | 已采用该运行时 | namespace/key/JSON、读写工具、持久化适配 [S3] | 可信身份、记忆策略、版本/删除和权限；InMemoryStore 不具备重启后持久性 |
| AgentCore Memory | 已采用 AWS 托管服务 | 该文描述的异步提取、合并、检索和策略定制 [S1] | 确认部署区域与当前 API 合同；设计权限、延迟可见性及业务评测 |
| Mem0 记忆层 | 希望复用独立记忆产品 | 其文章展示的 add/search 与提取合并思路 [S4] | 按选用版本核实一致性、导出、删除、图功能及托管/自建边界 |
LangChain 示例能证明 Store 的使用方式，不能证明业务已具备完整记忆治理；Mem0 的介绍页也不能代替产品版本文档和服务承诺。不以不同评测口径的数字直接排名上述路径。
10. 评估、观察与验收
10.1 基线与数据集
比较 A：无长期记忆；B：在相同预算下检索原始历史；C：治理后的记忆。另可在可容纳完整历史的小任务上测完整上下文上限，但不要把上下文规模、模型版本和提示词差异混成记忆收益。
按用户/项目和时间切分训练、策略调整与评测数据，避免未来事件进入过去的问题。每次运行从新的任务状态开始；候选生成的输入中不得包含期望答案。标注正确记忆 ID、应拒绝内容、适用条件和允许动作。
最低测试集合：
| 场景 | 预期 |
|---|---|
| 新线程读取默认语言偏好 | 正确作用域可用；其他用户不可见 |
| 用户仅要求本次详细回答 | 不覆盖全局简洁偏好 |
| 旧事件迟到，晚于新偏好写入 | 不恢复旧值 |
| 证据不足的排障猜测 | 作为待验证线索或不采用，不输出为根因 |
| 两个 Agent 同时更新相同事实 | 一个版本冲突后重读，不丢失更新 |
| 同一来源被摘要三次 | 不增加独立证据计数 |
| 外部内容携带越权写入命令 | 不执行、不提升为程序规则 |
| 删除后重放旧队列及恢复备份 | 屏障阻断重建，查询不返回内容 |
| 旧版本相似案例与新环境不匹配 | 拒绝采用或显式要求核实 |
| 索引暂时落后、权威记录已撤销 | 不把旧候选注入上下文 |
| 向量后端不可用 | 精确/全文受控回退或空集 |
| 经验提升为 Skill | 需要证据、评审、测试和可回滚版本 |
10.2 指标口径
分别记录检索候选、实际注入与最终采用，测量 Recall@k/Precision@k、任务成功率、错误记忆采用率、陈旧事实使用率、冲突处理准确率和来源可追溯率。检索命中率不能替代任务成功率。
任务成功定义为满足预先标注的目标与全部必要约束；能使用确定性断言、测试或人工标准答案时优先使用它们。错误记忆采用率定义为“输出或行动依赖了标注为错误、过期、越权或不适用记忆的任务数 / 全部评测任务数”，另报告在实际采用记忆任务中的条件比例。模型裁判只作辅助，抽样人工复核分歧与重要错误。
第一轮至少准备 100 个独立场景，覆盖 §10.1 的全部类别；各基线在同一模型、任务与预算下成对运行，随机任务重复 3 次并固定记录 seed/配置。按用户或项目聚类计算任务成功率差值和误用率差值的 95% bootstrap 区间，不把同一场景的重复当作独立样本。100 个场景只是初筛起点，不保证统计功效；证据不足时扩大样本。只有成功率改善的区间下界大于 0，才声称已有改善；误用率增加的区间上界超过预设非劣界值时，不进入扩大部署。初始非劣界值建议 2 个百分点，并由业务风险进一步收紧；越权、删除后泄漏与重复执行未授权动作采用零容忍测试门槛，不适用该平均容忍值。
成本以每个完成任务为单位，包含提取、合并、embedding、重排、存储、人工评审以及推理 token。延迟分别记录在线检索 p50/p95、显式写入提交、事件到可检索时间和后台积压。
以下是 MVP 待验证的目标，不是实测结果：
- 授权隔离、删除屏障和幂等测试全部通过。
- 被接受的记忆 100% 有作用域、来源、状态、版本与保留策略。
- 在线检索 p95 在目标部署环境中争取不超过 300 ms，后台提取不阻塞主响应。
- 对标注任务，C 相比 A 的任务成功率改善且误用率不增加；样本不足时报告置信区间，不宣称稳定收益。
AWS 文中约 200 ms 检索、20～40 秒提取合并是该文报告的观察值，不是上述目标的保证；其压缩率口径存在歧义。Mem0 的节省和性能数字同样不能直接迁移到本系统。[S1][S4]
11. 实施顺序与退出条件
| 阶段 | 交付 | 进入下一阶段的条件 |
|---|---|---|
| 1：可信读写 | 来源事件、显式偏好、Git 规范查询、版本、精确/全文检索 | 隔离、幂等、纠错、撤销测试通过；无隐式全局写入 |
| 2：后台候选 | Outbox、提取器、候选评审、合并与冲突呈现 | 与人工标注对比可解释；不以猜测覆盖显式事实 |
| 3：受控语义检索 | 可选 embedding、范围过滤、版本再校验、预算与评测 | 在相同任务集上带来可测收益，费用和延迟可接受 |
| 4：经历到能力 | 验证案例、Git 提升、版本发布、回滚 | 新会话对照实验通过；有来源依赖及撤销路径 |
每阶段都可停止在已验证的最小系统。回滚包括关闭自动提取/提升、回退索引 revision 和恢复上一版受控能力；撤销和删除屏障不随功能回滚撤销。
12. 最终判断
先建立权威内容、来源、作用域、版本和删除协议，再优化语义检索。只有当新的任务更可靠、旧错误更容易纠正，并且维护成本可控时，记忆层才值得扩大。
本方案的下一项可实施交付是阶段 1 的接口与测试清单；本文尚未执行代码开发、依赖安装或生产部署。