智能体记忆上线前，应该怎样评估
2026年7月29日研究
云端、自托管还是桌面版？先决定谁负责故障
2026年7月18日研究阅读约 11 分钟
根据数据权威、运维责任、协作与恢复选择部署方式，而不是比较一张泛化功能表。
部署问题常被描述为“控制与便利”的取舍，但这个说法太模糊，无法产生可长期执行的决定。真正有用的问题是：记忆闭环失败时，谁负责身份、数据恢复、模型运行、升级、事故和成本？
FishMem Desktop、开源服务与 FishMem Cloud 共享核心记忆语义，但它们是不同的运营产品。选择其中一个，就是选择一条权威边界。
先说结论
- 一个本地操作者、同一台机器上的智能体工具，选择 Desktop。
- 基础设施控制是硬要求，且团队能负责完整运营闭环时，选择自托管。
- 产品需要托管项目、组织、worker、计量与恢复时，选择 Cloud。
- 不要给个人工作流增加多租户基础设施，也不要让生产团队依赖一台笔记本。
- 无论选哪一种，都把导出与迁移写进验收标准。
比较责任，而不是比较勾选项
| 责任 | Desktop | 自托管 | Cloud |
|---|---|---|---|
| 主要操作者 | 个人用户 | 你的平台团队 | FishMem 服务与你的应用团队 |
| 数据权威 | 本地 SQLite 与用户备份 | 你配置的存储与对象存储 | 托管工作区资源 |
| 模型运营 | 本地多语言嵌入；没有聊天 LLM | 你的供应商、限制与凭据 | 托管推理和提取路径 |
| 身份 | 一个本地智能体边界 | 你的 API key、用户与项目 | 托管账户、项目、组织和 key |
| 恢复 | 用户导出与恢复快照 | 你的备份、恢复演练和修复任务 | 托管运营加可迁移命名空间导出 |
| 计费 | 产品内无计费 | 你的基础设施和供应商账单 | FishMem 订阅与用量账本 |
Desktop：个人工作流的本地权威
Desktop 面向一台机器上的 Codex 与 Claude Code 工作流。应用拥有一个私有本地服务和一个 SQLite/libSQL 权威。智能体 skill 负责提炼持久内容；Desktop 在关闭推理的情况下写入；嵌入由本地量化多语言 E5 模型完成。
这个狭窄边界是一项特性：没有托管兜底、远程 LLM 提取、组织层、Webhook 服务或用量计费。用户负责设备、应用更新、磁盘健康和备份位置。
当多个应用服务器需要并发访问、队友需要共享策略和审计，或恢复不能依赖某个人设备时，Desktop 就不是合适形态。
自托管：基础设施控制，也意味着基础设施责任
Apache-2.0 引擎可以直接嵌入，开源服务则提供更完整的 API 与控制台。团队自行选择图和向量适配器、供应商凭据、持久存储、网络边界和部署拓扑。
同一份自由也带来清晰的责任清单：
- 容量规划与供应商配额；
- 持久卷、对象保留与加密；
- 数据库与向量迁移；
- 队列投递、任务修复与 Webhook 重试；
- API key 生命周期与租户隔离；
- 监控、值班、备份与恢复演练；
- 版本固定与升级回滚；
- 安全补丁与事故沟通。
当这些控制是产品硬要求，或已经是平台团队现有能力时，自托管才合理；“开源版在价格页看起来便宜”不是充分理由。
Cloud：托管完整运营闭环
FishMem Cloud 围绕相同核心契约，增加托管项目与组织、API key、异步推理 worker、文档提取、对象与向量资源、用量证据、订阅计费和托管恢复操作。
应用仍然拥有产品策略：记住什么、怎样获得用户同意、怎样组装上下文，以及哪些答案需要额外验证。托管基础设施不会替产品决定这些事。
建立一份故障账本
做选择前，写下产品必须承受的故障。
| 故障 | 必须回答的问题 |
|---|---|
| 设备丢失 | 独立备份在哪里，谁测试过恢复？ |
| 供应商不可用 | 任务会持久排队、失败关闭，还是降级？ |
| 索引损坏或滞后 | 能否从规范记录与来源重建投影？ |
| 凭据撤销 | 谁看见错误，怎样恢复访问？ |
| 坏版本发布 | schema 和应用能否回滚而不丢失已确认写入？ |
| 租户隔离缺陷 | 检索前哪条边界会阻止跨项目数据？ |
| 操作者不可用 | 系统是否仍可支持与恢复？ |
估算总运营成本
比较时不能只看订阅价格。要包括搭建、升级、值班、存储、模型调用、备份、合规证据和事故恢复所需的工程时间，也要包括同一团队同时维护智能体和记忆基础设施而延误产品的机会成本。
Desktop 要计入用户时间和未测试备份的风险；Cloud 要计入用量与供应商依赖；自托管则要计入托管方案原本会吸收的运营工作。
选择足够用的最小形态
- 列出参与者：个人、团队、应用服务器、客户与操作者。
- 定义外层数据权威和结构化作用域。
- 设定恢复时间与数据丢失目标。
- 识别必要的协作、审计、计费和合规控制。
- 估算负载和模型依赖。
- 测试一条代表性的写入、召回、纠正、删除、导出与恢复旅程。
- 上线前写清退出路径。
常见类别错误
把 Desktop 当作免费的私有云
本地应用不会因为提供 CLI 就成为多用户服务。它的信任与可用边界仍是那台已经登录的设备。
把自托管当作没有供应商
团队仍依赖数据库、模型供应商、库和负责运行它们的工程师。控制改变依赖图，并不会消除依赖。
把 Cloud 当作外包产品策略
服务可以运行记忆层，但同意、保留、风险动作，以及检索上下文如何影响用户，仍由应用负责。
