外观
为什么采用 Go Core 加 Python Processor？
标准回答
我把 EachOf 拆成 Go Core 和 Python Processor，主要是为了划清“谁能修改权威状态”和“谁负责耗时处理”这两个边界。
Core 负责认证授权、检索和权威写入。Processor 负责抽取、泛化、Embedding 这些依赖模型和数据处理生态的工作。Processor 生成结果后交给 Core 校验，而不是把模型输出直接当成已经成立的记忆。这样模型侧可以迭代和重试，最终的权限、来源与提交规则仍集中在一个入口。
故障隔离也是这个拆分的收益。比如抽取任务超时，可以留在任务链中重试，已经提交且索引可用的记忆不必等待这次抽取完成。不过这个隔离有前提：Core 和数据库仍然可用；如果一次语义查询本身需要在线生成查询向量，它仍可能受模型服务故障影响。所以我不会说 Processor 出问题就绝对不影响任何查询。
两种语言也增加了部署、接口版本和排障成本。如果项目规模很小，统一技术栈完全可能更合适。我采用这套组合，是把核心状态管理与模型处理分开，利用各自的生态，而不是简单认为 Go 一定快、Python 不适合服务端。
关键机制
- Core 对外维持受控的数据契约；Processor 产生候选结果，而不是绕过核心直接修改权威状态。
- 异步任务把模型延迟与部分失败隔离开；已有有效记忆的读取应尽量不等待新的模型处理。
- 跨进程要处理协议版本、错误码、关联标识和超时；单人维护时尤其要权衡复杂度。
通俗例子
某个 Embedding 服务超时，新记忆处理可以排队或失败重试；已提交且索引可用的记忆仍可走查询链路。
追问与回答
为什么不统一成一种语言？
统一语言能减少部署和接口维护，尤其适合小团队。我这里已经把模型处理设计成独立职责，Python 侧便于使用抽取和模型相关工具，Go 侧集中管理服务入口和状态。但语言并不是这套架构成立的前提，用一种语言也能实现同样的职责隔离。如果继续维护两套服务带来的成本超过收益，我会优先考虑合并，而不会为了形式保留双语言。
Processor 能不能直接连库写？
在我的架构契约里，Processor 只能提交候选，不能绕过 Core 完成权威写入。因为如果它直接写库，权限校验、来源版本和策略检查就可能被绕开。真正落实这个约束还需要数据库账号权限或网络边界配合；仅仅在代码里约定“不要写”不够。具体凭据权限需要以部署配置为准，不能把接口设计自动等同于物理隔离已经完成。
易混淆点
“Worker 异常不影响查询”只描述部分隔离边界：Core、数据库、已有索引仍要可用，向量查询若依赖在线生成查询向量也可能受影响。
参考资料
内容来源
- Android 技术札记 · 原条目
eachof-core