版本与仓库
Vyane 个性化版、开源 Rust 版与 Eosphor 文档的关系
Vyane 正从“两条实现线”收敛为“一个 Rust 核心、两种使用方式”。这页只解释产品与事实来源，不把尚未完成的迁移写成现状。
先按目的选入口
| 你想做什么 | 去哪里 | 说明 |
|---|---|---|
| 理解 Eosphor 产品地图 | 生态与产品边界 | 解释 Vyane、Horus 与 Aletheia 的关系 |
| 理解 Vyane 的完整产品能力 | 本站 Vyane 文档 | 同时标明个性化能力和公开能力的边界 |
| 运行、审查或贡献公开代码 | zleo-ai/vyane-rs | 当前公开 Rust 实现仓；名称后续可能调整 |
| 查看本站源码 | zleo-ai/eosphor-docs | Eosphor 文档门户源码 |
长期结构：一套核心，两种使用方式
| 维度 | Vyane 开源版 | Vyane 个性化版 |
|---|---|---|
| 目标 | 可公开审查、复用、分发和贡献 | 服务特定个人工作流与实验需求 |
| 核心实现 | Rust | 逐步建立在同一 Rust 核心之上 |
| 包含 | 通用内核、CLI、服务接口、标准适配 | 个人配置、专属集成、实验能力和私有数据连接 |
| 不包含 | 凭据、个人数据、私有部署细节 | 一套永久分叉的平行内核 |
| 状态来源 | 公开仓 README、架构、roadmap、release 与 CI | 本站明确标为“个性化版”的页面 |
这比“私有版永远领先、公开版不断追赶”更健康：通用能力应该回流到公开核心，个性化层只保留无法或不应公开的配置与适配。
🚧 当前仍在迁移
现在不能假设两种使用方式已经完全对齐。本站出现的能力不一定已经进入公开 Rust 实现；公开仓已经实现的能力也可能拥有不同的命令或约束。运行公开版本时，始终以公开仓自身文档为准。
为什么文档不再把 vyane-rs 当产品名
vyane-rs 适合表示当前仓库和实现语言，但不适合长期承担产品品牌：
- 使用者真正使用的是 Vyane，不需要先理解仓库迁移历史。
- 当 Rust 成为主实现后，
-rs不再提供有意义的区分。 - 仓库名可能调整，产品概念和站内链接不应再次整体震荡。
所以本站采用：
- Vyane 开源版：长期产品称呼。
vyane-rs：当前具体仓库名，只在链接仓库或说明过渡状态时使用。
公开 Rust 实现现在到哪一步
公开仓处于 pre-release 阶段，已经提供真实的多模型 dispatch、broadcast、failover，以及配置、账本、session、workflow、后台任务、daemon、REST、MCP、路由与 review 等能力；部分能力与个性化版本的语义和覆盖范围仍不相同。
状态变化很快，本站不复制完整 crate 清单或完成度矩阵。请直接查看：
README.md—— 定位、当前能力与使用入口。docs/ARCHITECTURE.md—— 模块边界与执行模型。docs/ROADMAP.md—— 里程碑与后续方向。CONTRIBUTING.md—— 本地检查与贡献方式。
共同不变的模型
迁移与命名可以变化，下面这些产品边界应保持稳定：
- provider、protocol、harness、model 四层相互独立。
- dispatch、broadcast、failover 共享统一执行内核。
- session、ledger 和 owner scope 属于可持久化数据面。
- Horus 通过服务接口和事件流消费 Vyane，不复制调度逻辑。
- 私有凭据、个人数据和只对单一环境成立的配置不进入公开仓。