[RFC] 一个最小集成示例方案：Chroma 负责静态检索，OpenViking 负责 session context 和 archive memory

[Zoean-z]

RFC 背景

我想讨论一个可能适合作为 OpenViking example 的最小集成示例方案。

目标不是做完整应用，而是做一个边界清楚、可本地复现、适合放进 examples/ 的最小样例，用来回答一个很具体的问题：

• 如果静态知识放在向量数据库
• 动态上下文和记忆交给 OpenViking

那么一个最小、清晰、可运行的组合示例应该怎么设计？

提议的职责分层

当前方案是：

• Chroma
  • 负责静态文档导入
  • 负责切分、向量存储、相似检索
• OpenViking
  • 负责当前 session 的上下文
  • 负责 commit 之后的 archive / memory recall

换句话说：

• Chroma -> static retrieval
• OpenViking session context -> immediate follow-up
• OpenViking archive / memory -> long-term recall after commit

为什么提出这个方案

我提出这个方案，主要有两个原因。

1. 职责边界更清楚

如果把静态检索、即时上下文、长时记忆全部混在一起演示，example 很容易变得不够清楚。

而拆开之后，语义会更稳定：

• 静态证据来自 Chroma
• 当前对话上下文来自 OpenViking session context
• 长时记忆来自 OpenViking archive / memory

2. 对这个示例目标来说，静态检索更适合独立出来

我一开始也尝试过让 OpenViking 同时承担静态检索和动态上下文。

但在这个最小示例里，我最后还是把静态层拆给了 Chroma，原因是：

• 对“上传文件后做简单静态搜索”这类场景，向量数据库链路更直接
• 我本地实验时也感觉静态检索时延更低
• OpenViking 更适合承担它更有区分度的部分：session context、archive、memory

目前这部分还没有整理成正式 benchmark 文档，但如果这个方向本身是合理的，我可以补一个可复现的静态检索 benchmark，只比较：

• Chroma 的静态检索
• OpenViking 的静态检索路径

不把 session / commit / archive 混进基准里。

提议的 example 形态

我目前倾向于把这个 example 固定成两个独立场景，而不是一个混合 demo。

场景 1：短时上下文 demo

入口可以是 /ask：

• Chroma 提供静态证据
• OpenViking 提供当前 session context
• 演示即时 follow-up
• 不依赖 archive 可见性

场景 2：长时记忆 demo

单独演示：

• 完成一轮对话
• 显式 commit
• 等待 archive / memory 可见
• 再做 recall

这样可以避免把“即时上下文”和“归档后的长时记忆”混成一个叙事。

非目标

为了让 example 保持最小，我倾向于明确排除这些内容：

• 不做 UI
• 不做复杂 workflow
• 不做多后端横向对比
• 不把 /ask 设计成长时记忆总入口
• 不把 archive recall 混进即时 follow-up

想请教维护者的几个问题

1. 你们是否认可这种职责分层适合作为一个 example？

   • Chroma for static retrieval
   • OpenViking for session context + archive memory

2. 对 OpenViking 来说，把“当前 session context”和“commit 后 archive / memory”拆成两个独立 demo，是否比混成一个 demo 更符合产品语义？

3. 如果要放进 examples/，这种仓库更适合定位为：

   • 一个 integration-style minimal example
   • 还是应该继续收缩成更接近 basic-usage 的风格

4. 如果这个方向本身合理，你们更建议：

   • 先继续在 discussion 里收敛设计
   • 还是直接在仓库层面整理成 PR

如果这个方向被认可，我下一步准备做的事

• 继续压缩 README，让结构更像 examples
• 补齐项目内可复制的 ov.conf.example
• 补一个可复现的静态检索 benchmark
• 最后整理成 example PR

补充说明：我并不是想把这个方案定义成 OpenViking 的默认最佳实践，而是想确认这是否适合作为一种清晰、最小、可运行的集成示例。