Vyane 规划

Vyane 是 Eosphor 的执行与组织内核。这一页说清楚接下来往哪走,以及哪些在文档里出现的能力属于"已定方向、尚未落地"——避免把目标状态当成当前能力。

🚧 怎么读这份规划

文档全站用 🚧 标记注明"设计方向 / 未落地"的部分。看到 🚧,表示那是规划中的能力,当前实现里还没启用或只是雏形。规划页里的"尚未完全落地"章节整体都按 🚧 阅读。

已定方向,尚未完全落地

🚧 内核强制守门(kernel enforce) —— 目前 DispatchKernel 跑在 off / shadow 档,只做并行决策对比、不拦截执行。目标是推进到 enforce:由内核统一做权限收窄、路由准入和 prompt 安全扫描,拒绝不可绕过。详见一个任务怎么跑通。
🚧 scheduler 独占调度 —— daemon 的 scheduler 目前多在 shadow 档与旧的自主循环并行验证,还没正式接管调度。
🚧 workflow 预设脚本化 —— 把 broadcast / collaborate 这类常用协作范式沉淀成可复用的内置 workflow 脚本。

🚧 愿景:从个人底座到「超级组织」

Vyane 更远的方向,是从"一个人的多 agent 编制",渐进演化成"家庭 / 小团队的协作系统"。这不是要做公开 SaaS——owner 数据隔离已经落地,但它是为真实的多用户需求(比如和家人共享一部分工作)准备的,不是为虚构的百万用户超前设计。

渐进的三步:

个人多 agent 编制(当前) —— 一个人指挥若干长期 agent,各司其职。
双人 / 小范围协作 —— 权限与知识库有选择地共享,但各自保留私密空间。
小团队(远期) —— 扩展到创业项目、社区这类真实小组织。

组织学的地基:三张独立的图

支撑这个愿景的核心设计判断是:多人协作的关键,不是"我能不能看到",而是"我对哪些事负责、哪些由我发起、哪些得被知会"。 所以权限体系要能表达组织语义,而不只是简单的读写开关。

Vyane 的设计里,「谁能和谁通信」「谁能看到什么」「谁有权改什么」是三张相互独立的图,不混为一谈。再叠加一个明确的责任归属(一件事有唯一 accountable owner)。这借鉴的是人类组织的分治智慧,而不是把权限拍平成一张 RBAC 表。

🚧 这是设计方向,不是当前能力

目前已落地的是 owner-aware 的数据隔离(任务 / 会话 / goal / 历史等都按 owner 归属)。完整的「超级组织」底座——三张图的完整表达、能力寻址、跨组织审批——仍在设计推进中。

一个专管"治理"的角色

还有个正在酝酿的设计:引入一个专门做信息治理的长期 agent 角色——它不写代码、不产出交付物,专门管那些容易腐烂的横切事务:记忆去重与防陈旧、权限巡检、一致性维护。就像人类组织里"建造的人"和"治理的人"是分开的、互相制衡的。这标志着 Vyane 从"工具"往"组织系统"升维。(🚧 概念设计阶段。)

方向:续接 Horus

Vyane 是执行与协作的底座,它本身不追求做一个面向人的完整前端。接下来的产品化方向是续接 Horus——由 Horus 承担面向人的交互层(agent 控制台、任务视图、对话入口),Vyane 在底下提供调度、协作、账本和可观测能力。

这意味着 Vyane 会更聚焦"把接口和数据面做扎实":稳定的 HTTP API、清晰的事件流、可靠的账本读写,让上层前端能干净地接。

方向:统一到公开 Rust 核心

Vyane 不再把 Rust 仓仅仅视为一条长期平行的“公开实现线”。更清楚的长期目标是:通用内核全面收敛到 Rust,个性化版本建立在同一核心之上。

这意味着:

通用的 kernel、protocol、harness、ledger、session、workflow、daemon 和服务接口优先进入公开核心。
个性化层只保留个人配置、专属集成、私有数据连接和需要快速验证的实验能力。
已在个性化使用中验证、且具有通用价值的能力逐步回流公开核心,避免永久分叉。
当前仓库名 vyane-rs 后续可以调整;文档与产品对外统一称 Vyane 开源版。

🚧 收敛尚未完成

当前两种使用方式仍有能力差异。公开版本的准确状态以其 README、架构、roadmap、release 与 CI 为准;完整边界见版本与仓库。

Rust 对单二进制分发、类型化内核、async protocol、进程控制和跨端维护更有利,但不会自动抹平不同操作系统的 sandbox、microVM、服务管理和 coding CLI 登录态差异。这些仍需按平台明确实现与验证。

持续在做

快速迭代中 —— Vyane 本体仍在高频演进,四层调度、goal 接力、workflow 引擎、review 流水线都在持续打磨。文档会跟着定期更新。
配置与私有化边界 —— 把框架层(接口 / 协议适配 / 账本 / 审计)和私有配置(账号 / provider 组合 / 路由偏好)进一步分清,让底座本身更干净、可复用。