为什么拆成 Go Core 与 Python Processor？边界有什么价值？

项目版本说明

这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。

标准回答

这个边界首先分开模型处理与可信数据操作。Processor 生成候选结果，Core 掌握权限、检索及正式写入规则。这样模型调用慢、失败或输出异常时，不会直接获得修改权威记忆的通道。双语言也带来部署和接口成本，需要承认这种取舍。

Embedding 服务不可用时，候选处理可等待恢复；已有正式记忆仍由 Core 提供查询。依赖新向量的检索是否可降级，则需要项目明确的策略。

**按责任说明技术选择：**Go 承担核心服务，Python 承担模型处理；简历确认这种分工，但个人为何选择这两门语言仍需补充真实考虑。

**用一条任务说明接口：**原始材料进入持久化任务，Processor 处理后提交候选，Core 校验后写入。跨边界传递任务标识、来源版本和结果，而非让 Worker 随意改库。

**把失败隔离讲具体：**处理队列堆积会影响新记忆产生时效，已提交记忆的读写治理由 Core 控制。Core 或数据库故障仍会影响服务，不能说拆开就不会宕机。

Python 也能实现服务。应比较已有能力、部署成本和长期维护，而不是声称 Python 天生无法处理认证或并发。

可以说明小规模合并部署的可能性，但保留职责分层；实际采用的进程和部署方式要核对。

不要把多语言本身当作架构优势，价值要落在责任与失败隔离上。