Vyane · 偃
林爝的执行与账本底座
偃（Vyane）是林爝的执行与账本底座。它把模型、provider、引擎、任务、长期会话、agent 协作、审查、账本和可观测能力收进同一套系统边界。面向人的产品面是 重明；再往上的 御天 还在把这些能力收成一次操作。
一句话：把任务交给合适的模型或 agent，让它们能够协作、互审、接力，并让整个过程可见、可控、可追溯。
两种使用方式
| Vyane 个性化版 | Vyane 开源版 | |
|---|---|---|
| 用途 | 服务特定个人工作流，允许专属集成和更快实验 | 提供公开、可复用、可贡献的通用实现 |
| 实现方向 | 逐步收敛到 Rust 核心之上 | Rust；当前仓库名为 vyane-rs |
| 能力状态 | 以本站对应页面为说明 | 以公开仓 README、架构、roadmap 和 CI 为准 |
| 私有内容 | 配置、凭据、数据与环境适配不公开 | 不接收任何私有数据或部署细节 |
🚧 正在向统一 Rust 核心收敛
目标是共享一套 Rust 内核，而不是永久维护两套实现。迁移期间两条线的能力不会时时一致；看到某项能力时，请先确认它属于哪条使用方式。
当前能力与接入边界
现在已有
- 多目标派发、并行比较与可编程 workflow。
- 长任务、session 与 goal 的持续执行和交接。
- agent 协作消息、独立审查、任务账本、HTTP / MCP / CLI 接口和可观测数据。
- 用独立字段记录 provider、protocol、harness 与 model，避免把账号、传输协议、引擎和模型混成一个选择器。
🚧 仍在开发
Vyane 正在把 Codex CLI、Claude Code、OpenCode、Kimi Code、Grok Build 等编码引擎的活动会话 统一登记为可信运行事实，再把消息回复、取消、恢复和其他原生操作按各自能力开放给 Horus。
“能识别某个引擎”不等于“已经能控制它”。只有真实运行身份、原生会话标识、心跳和终态都能确认， 对应操作才应开放；无法确认时必须显示未知或不可用，而不是根据进程名、模型名或工作目录推测。
文档入口
🧭
为什么是 Vyane
透明编排、注意力路由和可靠执行背后的设计判断。
🧱
四层架构
provider / protocol / harness / model 的共同心智模型。
⚙️
能力
从派单、协作和审查到 workflow、daemon 与可观测。
📦
版本与仓库
区分个性化能力、公开 Rust 实现和文档事实来源。
选择版本
与重明、御天的关系
偃不把人的交互都塞进 CLI 或 API。对话、任务、审批和系统状态由 重明 呈现；偃专注执行语义、服务接口、事件流与持久化。 御天 位于二者之上。那一层是 🚧：方向已经写明，还不是一次能走完的操作。