Frame Endor as an AI operating environment with object pools and agents

content/docs/04-endor-purpose-draft.md

@@ -4,6 +4,18 @@
 
 > **讨论草案**：以下是希望探索的系统组织方式。图中进程和对象的数量、对象关系与操作路径都是示意，不表示当前实现或性能测量。
 
+## Endor：面向 AI 的操作系统
+
+**我们可以把 Endor 理解为面向 AI 的操作系统：以对象池组织工作对象，以 Agent 承载和推进任务。** 用户与 AI 不必始终围绕一个个程序和进程组织工作，而是能够围绕对象、关系和可执行的能力继续处理同一件事。
+
+在这个定位下，我们希望把用户需要面对的进程管理，简化为对 **Object data pool（对象数据池）** 中对象及其关系、状态的管理。工作材料和结果不必只存在于某个程序的私有上下文里；它们可以作为有身份、可引用的对象，由不同入口和任务继续使用。对象池是统一的逻辑组织方式，不要求所有对象都位于同一台机器或同一个物理存储实例。
+
+**Agent 充当以往操作系统中进程在任务层面承担的角色**：承载一项正在进行的工作，组织所需对象与能力，保留相关上下文，并推进执行。用户关注的可以是“这项工作处理哪些对象、进行到哪里、下一步做什么”，而不只是“启动了哪个程序、背后有几个进程”。这些是希望建立的任务与生命周期模型，具体的暂停、恢复、调度和状态保留机制仍需定义。
+
+这是一种上层运行环境的组织方式。对象池负责数据与对象关系，Agent 负责组织任务行为，实际执行仍需要运行时、调度和资源隔离。它们不意味着用存储替代全部执行机制，也不要求 Agent 与底层 OS 进程一一对应；一个 Agent 的工作可以包含普通函数调用，普通计算也不必全部改写成 Agent。
+
+这一定位希望形成的体验是：**对象池构成持续可用的工作世界，Agent 成为其中执行工作的主体，Endor 语言让对象和行为能够被表达、检查与组合。** 用户与 AI 因而可以在同一套对象基础上发起、接续和检查工作。这是本文的设计方向，不表示所有系统能力已经实现。
+
 ## 一对图：我们希望改变什么
 
 ![从程序入口到对象操作的对比：上图中 OS 分出九个进程，按二、四、三个分为三组，对应三个程序；对象以进程内的随机小圆圈表示，用户通过程序入口访问。下图中 OS 只分出少量进程，承载 Endorphin 的对象关系网络，用户与 AI 用多条贝塞尔曲线直接指向选定对象；OS、进程区与 Endorphin 都位于 Endor OS 边界内](/figures/endor-purpose.svg)
@@ -22,7 +34,7 @@
 
 用户与 AI 的多条曲线分别指向部分对象，表达我们希望提供的能力：**在授权范围内，直接找到所需对象，对它们执行操作，并把不同对象的能力组合起来**。图中没有把所有对象都连向用户，因为操作权应当是有范围、可控制的。
 
-OS、进程区与 Endorphin 被共同框在 **Endor OS** 的边界内。这是此处对整体系统的命名；是否涉及内核层面的替换、哪些职责由底层 OS 保留，尚未在这张概念图中定义。
+OS、进程区与 Endorphin 被共同框在 **Endor OS** 的边界内。这是此处对面向 AI 的整体运行环境的命名：对象池组织工作对象，Agent 承载任务。图中仍保留底层 OS，具体的内核与运行时职责划分尚需继续定义。
 
 ## 为什么程序不该是唯一入口
 
@@ -143,6 +155,8 @@ Endor 的意义不能只停留在界面上可以点击一张对象关系图。
 
 ### Agent 也是程序结构的一部分
 
+在“面向 AI 的操作系统”这一定位中，Agent 是任务的执行主体，承担类似传统进程在任务层面的职责。语言需要能够表达它使用的对象、逻辑和上下文，让任务不只是一段外部聊天记录；对象池则为这些任务提供可以持续引用的工作对象。
+
 现有设计将 agent 与 class、function 一起纳入语言资源体系，讨论工具、记忆、状态与运行控制如何在共有模型中组织。AI 因而不只是从语言外部发送指令，也可以通过语言定义和组合行为。
 
 如果 Agent 能引用已有函数、处理类型化结果并保留与对象的关系，它就有机会成为这个对象世界的参与者。人编写的逻辑与 AI 组织的逻辑可以使用共同的资源与调用约定，便于检查、复用和交接。