From 5b614c7df05c82d235994f85e13efb2bf76fb21f Mon Sep 17 00:00:00 2001 From: Codex Bot Date: Wed, 28 Oct 2026 03:25:25 +0800 Subject: [PATCH] Expand Endor purpose with object workflows and language chapter --- content/docs/04-endor-purpose-draft.md | 173 +++++++++++++++++++++++-- 1 file changed, 162 insertions(+), 11 deletions(-) diff --git a/content/docs/04-endor-purpose-draft.md b/content/docs/04-endor-purpose-draft.md index 7484f25..40434cc 100644 --- a/content/docs/04-endor-purpose-draft.md +++ b/content/docs/04-endor-purpose-draft.md @@ -24,19 +24,170 @@ OS、进程区与 Endorphin 被共同框在 **Endor OS** 的边界内。这是此处对整体系统的命名；是否涉及内核层面的替换、哪些职责由底层 OS 保留，尚未在这张概念图中定义。 -## 先记录下来的主张 +## 为什么程序不该是唯一入口 -我们希望讨论的变化，是让用户与 AI 不必总以一个个程序为唯一操作入口，而能以对象及其关系来组织工作。程序仍可以承担展示、交互和专业工作流；对象则有机会成为跨这些入口引用和组合能力的共同单位。 +设想我们要把一段会议录像整理成可执行的项目计划。录像在媒体库里，讨论结论写进文档，行动项录入任务工具，补充资料又放在另一个位置。用户需要把时间点、原话、负责人和截止时间反复搬运，才能让这些程序中的内容对上。 -“交还操作权”不是开放任意内存访问，也不是绕过权限。它需要对象能够被明确定位，需要操作接口与授权边界，也需要让用户知道一次操作改变了什么。这些能力怎样落地，还需要后续设计。 +困难不只在于点击次数。任务里粘贴的会议摘要，可能无法跟随原始结论的修改；文档里的一段文字，可能没有保留它来自哪个视频片段的关系。用户知道这些内容属于同一件事，系统却往往只保存了分别属于几个程序的数据副本。 -## 接下来慢慢整理 +AI 参与时也会遇到这种分割。它可能通过 Web 界面、API 或工具调用取得内容，再把结果写进另一套入口。每个入口都能提供有用能力，但对象身份、关联关系和状态变化不一定在这些入口之间保持连续。一次自动化任务成功，也不等于下一次还能准确找到并更新同一对象。 -- **对象是什么**：哪些东西应该成为可操作对象，身份和生命周期如何定义？ -- **操作权是什么**：读取、修改、调用、组合与委托分别意味着什么，怎样授予和撤销？ -- **AI 如何参与**：如何发现对象能力、请求授权，并让操作结果可以检查？ -- **程序的位置**：Tessera、Web 与其他程序如何成为同一对象世界的不同入口？ -- **运行边界**：对象跨进程、设备、自部署和平台运行时，哪些语义需要保持一致？ -- **怎样验证意义**：用什么具体工作流说明这种组织方式给用户带来的变化？ +Endor 想探索的是：录像、片段、结论、任务和负责人之间的关系，能否成为可以继续访问和操作的系统结构，而不是只由用户记住、再通过复制粘贴维持。 -本文先保留这些问题，随讨论逐项展开。[系统架构](/docs/00-endor-concepts-draft)讨论部署与存储，[节点与对象挂载](/docs/02-mounting-draft)讨论运行位置和挂载边界；这里关注的是它们最终为什么值得做。 +已有程序也可以用链接、共享数据库、开放 API 或其他方式解决这些问题。Endor 的意义需要通过更连贯的使用体验证明，不能只靠“现有程序彼此隔离”这个前提成立。 + +## 什么是用户真正想操作的对象 + +用户想修改的通常不是某个进程里的内存地址，而是有实际含义的东西：一篇文档、一段视频、一个任务、一组设备，或这些内容之间的联系。 + +在会议整理的例子里，可以先讨论以下对象与关系。这里列的是业务建模示例，不是已经确定的内置类型。 + +| 对象 | 用户可能希望执行的操作 | 需要保留的关系 | +| --- | --- | --- | +| 会议录像 | 查看、选择片段、引用内容 | 片段来自哪份录像 | +| 讨论结论 | 修订、核对来源、交给其他流程使用 | 依据哪些片段形成 | +| 行动任务 | 修改状态、指派负责人、调整时间 | 对应哪条结论 | +| 项目计划 | 汇集任务、查看进展、调整组织方式 | 包含哪些任务和依赖 | + +一个对象能被多个入口使用，不意味着把它复制成多份互不关联的数据。我们希望同一任务可以出现在项目看板、会议记录和个人待办里，入口变化时仍能辨认它是同一个任务。需要快照或独立副本时，也应明确表达这种区别。 + +对象的身份、当前名称、显示位置和所属进程不能混为一谈。改名、换一个视图或迁移执行位置，是否改变对象身份，应有明确规则。对象删除、替换或不可访问时，保留的引用又如何表现，也是对象模型必须回答的问题。 + +这不要求把每个临时计算值都做成一个可联网访问的资源。哪些对象需要独立身份、保存和跨端引用，哪些只在一次执行中存在，需要由类型、生命周期和系统成本共同决定。 + +## “把操作权交还给用户”是什么意思 + +这里的操作权，首先是让用户能够理解并使用自己的工作对象：找到目标、保留引用、选择合适的入口，并在获准范围内发起操作。它不仅是把程序界面的按钮换成一个通用调用按钮。 + +- **可定位**：之后仍能找到同一对象，知道名称与引用指向什么。 +- **可理解**：能够识别对象的类型、可用操作和当前状态，不必猜测某个界面动作的含义。 +- **可操作**：通过明确的输入和操作契约读取、修改或调用能力，并取得可检查的结果。 +- **可组合**：把一个对象或操作结果交给其他获准使用它的能力，保留必要的身份和关系。 +- **可选择入口**：根据任务选择不同界面或自动化方式，不因更换入口就被迫重新建立全部数据关系。 + +这些是体验目标，不表示数据所有权、访问权和操作权天然相同。能查看一项任务，不一定能修改；能调用“提交”能力，也不一定能编辑它的实现或直接修改相关的全部资源。对象属于谁、用户此刻能做什么、程序允许产生什么业务效果，需要分别表达。 + +“交还”也不意味着消除程序提供的业务约束。例如用户调用一个约定好的提交能力，应遵守它的输入、状态和操作范围。把系统的内部存储或任意内存暴露出来，并不能自动带来清晰的对象操作权。 + +## 程序在 Endor 中还有什么意义 + +对象成为共同的操作单位后，程序仍然可以提供有价值的组织方式。项目看板擅长安排任务，视频编辑器擅长选择时间片段，专业业务界面则可以把复杂约束组织成容易理解的工作流。 + +区别在于，我们希望程序不必成为对象唯一的归属入口。同一任务可以由一个界面创建，由另一个界面展示，再交给 AI 协助整理；这些入口使用同一对象身份和约定好的能力，而不是各自建立一份无法关联的任务。 + +在这个方向上，程序可以承担几种职责： + +| 职责 | 对用户的价值 | +| --- | --- | +| 视图与编辑器 | 针对当前任务选择合适的呈现和交互方式 | +| 专业工作流 | 将多个操作、检查和业务步骤组织成可靠流程 | +| 可复用逻辑 | 把一组能力实现为可引用、可调用的程序结构 | +| 与其他系统连接 | 在外部格式和接口与 Endor 对象之间建立明确映射 | + +Tessera 可以作为进入对象世界的一种前端；Web 和其他专业程序也可以提供不同入口。这是希望形成的关系，不表示所有现有程序都已经能直接接入，也不表示一个通用界面可以替代全部专业工具。 + +## 为什么 AI 需要对象，而不只是更多工具 + +工具让 AI 能够采取动作，对象则让这些动作有一个可以持续引用和理解的目标。以会议整理为例，AI 不只需要“新建任务”这个工具，还需要知道这次处理的是哪次会议、哪条结论、哪些任务已经存在，以及它们之间有什么关系。 + +如果每次调用只得到一段文本，AI 可能需要反复从描述中重新识别目标。若结果能够保留对象身份、类型和来源关系，后续操作就有机会继续作用于同一目标，而不必每次重建上下文。 + +我们希望对象模型能够帮助 AI： + +- 根据类型和可访问的能力理解目标，而不只依靠界面位置或名称猜测。 +- 把操作结果作为后续步骤的输入，保留其来源和关联。 +- 在用户、程序和 AI 之间传递同一工作对象，支持继续处理。 +- 将“准备修改什么”和“实际修改了什么”组织成可以让用户检查的结果。 + +这些能力也可以由设计良好的 API 和工具系统提供。Endor 希望进一步让它们成为语言与运行环境中一致的组织方式，减少每个工具单独定义一套对象标识、结果格式和上下文约定的负担。是否真的减少了集成成本，需要在具体工作流里验证。 + +对象模型不会自动解决 AI 的理解错误，也不会因为对象有类型就保证操作正确。发现能力、理解业务意图、遵守授权和验证结果仍然是不同问题。 + +## Endor 语言：让对象成为可编程的共同基础 + +Endor 的意义不能只停留在界面上可以点击一张对象关系图。开发者、用户编写的逻辑和 AI 生成的程序，需要能够表达这些对象、关系与操作，并把它们交给运行环境执行。**Endor 语言应当是连接对象世界与可执行行为的核心部分。** + +现有语言文档使用 **Endorphin** 作为语言名称；本文的“Endor 语言”指这套语言在整个项目中的角色。下面依据现有语言设计稿整理其意义，不把设计约定等同于已经完成的软件能力。 + +### 统一对象模型，而不只是统一调用入口 + +现有设计以 Object 为共同基础，把数值、文本、容器、引用、类型定义、代码、函数和运行实体纳入对象体系。类型本身也是对象，由 Object 与 Type 的关系组织实例和类型定义。 + +这使我们能够讨论同一个工作对象的不同层面：它是什么类型，能被什么结构引用，支持哪些操作，由什么规则管理生命周期。类型的意义也不限于检查一个函数参数是否合法，还包括对象怎样组织、使用和呈现。 + +“一切皆对象”不能直接推导为“一切对象都独立保存、远程暴露或永久存在”。设计稿用 atom 讨论可独立识别、保存和引用的资源单元；哪些对象需要成为这样的单元，应与具体类型和生命周期规则一起确定。 + +### 身份、引用与命名，让组合能够延续 + +用户希望反复操作同一任务，语言就需要区分任务本身与当前拿到它的名字或引用。引用应当使程序能够继续关联目标，而不只是把某次显示得到的文本复制到另一个位置。 + +现有设计由 workspace 管理资源归属，namespace 提供命名和组织入口。资源身份、命名路径与用户身份承担不同职责；代码引用也不自动改变资源归属或取得授权。 + +对项目意义而言，这种区分让“跨入口使用同一对象”有了可表达的基础。一个对象可以被不同程序引用，用户不必为了更换呈现方式就重新建立它与其他对象的关系。具体的引用失效、资源回收、命名变更和跨端行为，仍应以语言规范及系统设计逐项落实。 + +### 函数与类型，表达对象能够做什么 + +有对象身份还不够，语言还需要表达怎样操作对象。类型描述结构与能力，函数表达输入、计算和结果，使可复用逻辑能够被其他程序引用和组合。 + +会议整理可以被拆成选择片段、形成结论、整理行动项和建立关联等能力。这里的重点不是预先发明一套内置会议 API，而是让业务逻辑能够用可检查的类型和调用关系表达，而不只能藏在某个界面的事件处理里。 + +函数本身与调用结果也要区分。用户查看一个函数，不代表已经执行；函数可以被引用，也不代表调用者已经具备执行它的授权。界面、AI 与其他程序使用这些能力时，应共享明确的调用含义。 + +### Preflight 与 inflight，连接定义和实际执行 + +现有设计把程序处理分为 Preflight 与 inflight：前者负责理解声明和引用、检查名称与类型并建立关联，后者使用实际输入执行逻辑，管理调用、实例和任务的运行状态。 + +对于 Endor 的目标，这意味着生成或编辑一段逻辑，与实际执行它应当有清楚的边界。AI 写出一段程序，不应仅因生成了文本就被视为已经就绪或已经执行；它仍需要进入相应的检查和运行过程。 + +这些是语言设计中的阶段职责，不等于本文已经确认所有编译器、虚拟机和平台路径都实现了同样的语义。语言设计与当前实现之间的对应，需要分别核对。 + +### Agent 也是程序结构的一部分 + +现有设计将 agent 与 class、function 一起纳入语言资源体系，讨论工具、记忆、状态与运行控制如何在共有模型中组织。AI 因而不只是从语言外部发送指令，也可以通过语言定义和组合行为。 + +如果 Agent 能引用已有函数、处理类型化结果并保留与对象的关系，它就有机会成为这个对象世界的参与者。人编写的逻辑与 AI 组织的逻辑可以使用共同的资源与调用约定，便于检查、复用和交接。 + +语言层面的 Agent 结构并不自动授予运行权限。操作身份、委托、任务恢复时的授权检查等仍有待定义，不能从“Agent 在某个 workspace 中”推导出它能以管理员身份执行。 + +### 从对象类型到界面呈现 + +语言设计还讨论客户端根据资源或调用结果的类型选择呈现方式，并用普通函数返回可渲染值来表达界面。这让界面与业务逻辑有机会围绕同一对象模型组织，而不是在前后端之间反复重建对应的数据结构。 + +同一个任务对象，可以在任务列表中显示摘要，在会议记录中显示来源，在专业编辑界面中展示更多操作。不同入口需要适合各自场景的呈现，同时保留对同一对象的关联。 + +类型驱动呈现不意味着所有对象都自动拥有完整 UI，也不意味着跨设备共享内存或瞬时一致。呈现契约、本地副本、同步状态和失败行为仍需要具体实现。 + +### 语言应该承担什么，系统又应该承担什么 + +语言应当把对象、类型、引用和行为表达清楚，让程序可以检查、组合和执行。Nexus、Aster、Aerarium、存储与通信机制负责支撑相应运行能力；不能仅靠增加一个语法结构就宣称已经解决分布式运行、持久化或故障恢复。 + +对用户来说，成功的结果应当是更容易表达一件事、继续处理同一对象，并把已有能力组合成新的工作流。语言的价值需要落在这种表达与操作的连续性上，而不只在于少写了几个请求或多了一种声明形式。 + +语言章节会随设计继续整理。当前依据可查阅：[语言概览](https://gitea.entroia.com/Zayden-Jung/Endorphin-Document/src/branch/main/guide/01-overview.md)、[Object 与类型系统](https://gitea.entroia.com/Zayden-Jung/Endorphin-Document/src/branch/main/guide/07-top-level-types/README.md)、[资源访问与呈现](https://gitea.entroia.com/Zayden-Jung/Endorphin-Document/src/branch/main/guide/11-resource-access-and-presentation.md)和[规范状态](https://gitea.entroia.com/Zayden-Jung/Endorphin-Document/src/branch/main/appendices/specification-status.md)。这些资料记录语言设计，不能作为实现完成度的证明。 + +## 一个完整的使用故事：从会议录像到项目计划 + +下面是一条用来检验项目意义的目标工作流，不是现有功能演示。它沿用同一次会议，让对象在用户、程序与 AI 之间连续流转。 + +### 从分散入口开始 + +用户打开录像，手工记下重要时间点，把结论复制到文档，再切换到任务工具创建行动项。AI 可以协助转写和提炼，但如果交接只剩几段文本，之后仍需要人工确认每个任务来自哪里、是否重复、对应哪一次修改。 + +当结论变化时，用户要重新找到相关任务和文档。原有工具可以通过链接和集成改善这个过程；我们需要明确比较的是这些已经可用的做法，而不是只和纯手工操作比较。 + +### 在对象世界中完成同一件事 + +1. **找到会议**：用户在 Tessera 中打开会议录像对象，选择需要处理的片段，保留它们与原始录像的关联。 +2. **交给 AI 整理**：用户要求 AI 基于这些片段形成结论和候选行动项。候选结果继续关联来源，先供用户检查，不把生成内容直接当成已确认计划。 +3. **核对并形成任务**：用户修正结论、去掉无效行动项，再通过约定的程序能力建立任务与来源的关系。 +4. **换一个入口继续处理**：同一任务出现在项目看板、会议记录和个人工作视图中。不同入口展示不同信息，但引用的是同一任务。 +5. **继续修改**：用户调整任务或结论后，可以沿关系找到受影响的内容。哪些变化自动传播、哪些需要重新确认，由具体对象与工作流规则决定。 +6. **交接工作**：另一个获准参与的人或 AI 能够继续引用这些对象，了解其来源和当前状态，而不必仅凭上一轮聊天摘要重建整个过程。 + +这个故事的关键不是“一次指令自动完成全部工作”，而是中途可以检查、修改、换入口并继续处理。Endor 语言应当能表达其中的对象类型、引用和业务能力，前端负责呈现和交互，运行环境则支撑实际的访问与执行。 + +## 继续整理的方向 + +这一版先把程序入口、对象、操作权、AI 与语言之间的关系串起来。后续可以用真实工作流修订这些描述，进一步确定对象身份、执行与挂载的语义。 + +[系统架构](/docs/00-endor-concepts-draft)讨论部署与存储，[节点与对象挂载](/docs/02-mounting-draft)讨论运行位置和挂载边界；本文关注它们为何能给用户带来值得验证的变化。