跳到主要内容

工程拆分与演进路线

羽忆当前采用的是 Multi-Repo 策略。这个决定不是为了看起来“更工程化”，而是因为不同部分的技术栈、发布节奏和职责边界已经天然分开。

当前仓库分工​

仓库定位
memory-serverJava 核心服务端，承载全部重逻辑
client-sharedTypeScript 接入层，统一维护 CLI、MCP 与共享调用层
memory-web浏览器工作台与管理端
memory-deploy联合部署资产、Compose、代理与环境模板

为什么不继续使用单体总仓​

主要原因有三点：

  • Java 和 Node 侧工程约束差异很大
  • 服务端、接入层和前端控制台的发布节奏并不一致
  • 当前阶段重点是收稳能力边界，而不是为了统一治理额外引入一层复杂仓库编排

因此，把边界清晰的部分拆成独立仓库，维护成本反而更低。

四仓的职责边界​

memory-server​

这里是唯一的业务规则中心。作用域、Judge、召回、控制、安全等核心逻辑都应该收口在这里，而不是分散到接入层。

client-shared​

CLI 和 MCP 本质上都是“薄接入层”。它们共享同一套 REST 协议、错误处理和认证方式，因此统一在一个 TypeScript 仓库维护，可以有效降低协议漂移。

memory-web​

浏览器管理台已经不是简单的 API 调试页，而是一个真正的控制面。它需要独立的前端节奏、设计体系和部署形态，因此单独成仓是合理的。

memory-deploy​

联合部署资产既依赖服务端，也依赖前端工作台，把它挂在任何单个业务仓下都会造成边界歧义。独立部署仓更符合前后端可分别部署、也可联合部署的目标。

后续演进方向​

在闭环稳定之后，后续可以优先考虑：

  • 更成熟的 Recall 质量反馈机制
  • 更完善的导入导出能力
  • 更细粒度的权限与团队协作
  • 更丰富的 Adapter 生态
  • 公开 SDK 的抽离与版本治理

但这些增强都应该建立在现有服务端边界不被破坏的前提下。羽忆后续演进的关键，不是功能堆叠，而是继续保持“Java 端承载重逻辑，接入层保持薄，控制面独立演进”的整体结构。