3.8 KiB
Endor 的意义：从程序入口到对象操作
这篇文档用来逐步整理我们为什么要做 Endor。先记录一个切入点：把对象的操作权交还给用户与 AI。后续讨论可以在这里补充、修正，暂不把它写成一份已经定稿的项目宣言。
讨论草案：以下是希望探索的系统组织方式。图中进程和对象的数量、对象关系与操作路径都是示意，不表示当前实现或性能测量。
一对图：我们希望改变什么
第一张图：用户面对程序
从 OS 出发，许多进程组成不同的程序。每个程序可以对应不同数量的进程；图中分别画了两个、四个和三个。进程区里的许多小圆圈表示对象，它们散布在各进程中。
用户通常通过程序提供的界面访问能力，也可能通过 Web 或 API。这里想强调的是操作入口：用户先选择程序，再在程序提供的功能中寻找自己要做的事。图中的对象仍然存在，但通常隐藏在程序的组织和入口之后。
这是一种用于对照的简化视角，并不是说现有程序都无法开放对象或让外部系统组合能力。
第二张图：用户与 AI 面对对象
仍然从 OS 出发，但这次只画少量进程，用来承载 Endorphin。接下来展开的是许多相互连接的小圆圈：对象不再只作为程序内部的实现细节出现，而成为可以被引用、选择和操作的基本单位。
用户与 AI 的多条曲线分别指向部分对象，表达我们希望提供的能力：在授权范围内，直接找到所需对象，对它们执行操作，并把不同对象的能力组合起来。图中没有把所有对象都连向用户，因为操作权应当是有范围、可控制的。
OS、进程区与 Endorphin 被共同框在 Endor OS 的边界内。这是此处对整体系统的命名；是否涉及内核层面的替换、哪些职责由底层 OS 保留，尚未在这张概念图中定义。
先记录下来的主张
我们希望讨论的变化，是让用户与 AI 不必总以一个个程序为唯一操作入口，而能以对象及其关系来组织工作。程序仍可以承担展示、交互和专业工作流；对象则有机会成为跨这些入口引用和组合能力的共同单位。
“交还操作权”不是开放任意内存访问，也不是绕过权限。它需要对象能够被明确定位，需要操作接口与授权边界，也需要让用户知道一次操作改变了什么。这些能力怎样落地，还需要后续设计。
接下来慢慢整理
- 对象是什么：哪些东西应该成为可操作对象，身份和生命周期如何定义？
- 操作权是什么：读取、修改、调用、组合与委托分别意味着什么，怎样授予和撤销？
- AI 如何参与：如何发现对象能力、请求授权，并让操作结果可以检查？
- 程序的位置：Tessera、Web 与其他程序如何成为同一对象世界的不同入口？
- 运行边界：对象跨进程、设备、自部署和平台运行时，哪些语义需要保持一致？
- 怎样验证意义：用什么具体工作流说明这种组织方式给用户带来的变化？
本文先保留这些问题，随讨论逐项展开。系统架构讨论部署与存储，节点与对象挂载讨论运行位置和挂载边界；这里关注的是它们最终为什么值得做。