274 lines
26 KiB
Markdown
274 lines
26 KiB
Markdown
# Endor 的意义：从程序入口到对象操作
|
||
|
||
这篇文档用来逐步整理我们为什么要做 Endor。先记录一个切入点：**把对象的操作权交还给用户与 AI**。后续讨论可以在这里补充、修正，暂不把它写成一份已经定稿的项目宣言。
|
||
|
||
> **讨论草案**：以下是希望探索的系统组织方式。图中进程和对象的数量、对象关系与操作路径都是示意，不表示当前实现或性能测量。
|
||
|
||
## 一对图：我们希望改变什么
|
||
|
||
|
||
|
||
### 第一张图：用户面对程序
|
||
|
||
从 OS 出发，许多进程组成不同的程序。每个程序可以对应不同数量的进程；图中分别画了两个、四个和三个。进程区里的许多小圆圈表示对象，它们散布在各进程中。
|
||
|
||
用户通常通过程序提供的界面访问能力，也可能通过 Web 或 API。这里想强调的是操作入口：用户先选择程序，再在程序提供的功能中寻找自己要做的事。图中的对象仍然存在，但通常隐藏在程序的组织和入口之后。
|
||
|
||
这是一种用于对照的简化视角，并不是说现有程序都无法开放对象或让外部系统组合能力。
|
||
|
||
### 第二张图：用户与 AI 面对对象
|
||
|
||
仍然从 OS 出发，但这次只画少量进程，用来承载 Endorphin。接下来展开的是许多相互连接的小圆圈：对象不再只作为程序内部的实现细节出现，而成为可以被引用、选择和操作的基本单位。
|
||
|
||
用户与 AI 的多条曲线分别指向部分对象，表达我们希望提供的能力：**在授权范围内，直接找到所需对象，对它们执行操作，并把不同对象的能力组合起来**。图中没有把所有对象都连向用户，因为操作权应当是有范围、可控制的。
|
||
|
||
OS、进程区与 Endorphin 被共同框在 **Endor OS** 的边界内。这是此处对整体系统的命名；是否涉及内核层面的替换、哪些职责由底层 OS 保留，尚未在这张概念图中定义。
|
||
|
||
## 为什么程序不该是唯一入口
|
||
|
||
设想我们要把一段会议录像整理成可执行的项目计划。录像在媒体库里，讨论结论写进文档，行动项录入任务工具，补充资料又放在另一个位置。用户需要把时间点、原话、负责人和截止时间反复搬运，才能让这些程序中的内容对上。
|
||
|
||
困难不只在于点击次数。任务里粘贴的会议摘要，可能无法跟随原始结论的修改；文档里的一段文字，可能没有保留它来自哪个视频片段的关系。用户知道这些内容属于同一件事，系统却往往只保存了分别属于几个程序的数据副本。
|
||
|
||
AI 参与时也会遇到这种分割。它可能通过 Web 界面、API 或工具调用取得内容，再把结果写进另一套入口。每个入口都能提供有用能力，但对象身份、关联关系和状态变化不一定在这些入口之间保持连续。一次自动化任务成功，也不等于下一次还能准确找到并更新同一对象。
|
||
|
||
Endor 想探索的是：录像、片段、结论、任务和负责人之间的关系，能否成为可以继续访问和操作的系统结构，而不是只由用户记住、再通过复制粘贴维持。
|
||
|
||
已有程序也可以用链接、共享数据库、开放 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 语言应当能表达其中的对象类型、引用和业务能力，前端负责呈现和交互，运行环境则支撑实际的访问与执行。
|
||
|
||
## 用户怎样保持控制（试写，待确认）
|
||
|
||
> **本章是待讨论的体验设想，不是已确认的权限规范。** 语言设计已有 workspace 整体授权、资源编辑与程序使用的区分；下面关注用户应能看懂什么、决定什么。操作身份、Agent 委托、撤销和记录的具体机制仍需设计。
|
||
|
||
“交还操作权”最终需要体现在用户能够作出的决定上。用户应当知道自己正在查看什么、以谁的身份操作、操作会影响哪些对象，以及什么结果已经发生。仅仅让对象可以被调用，而用户看不清影响范围，并不足以实现这个目标。
|
||
|
||
### 看懂对象、身份与预期影响
|
||
|
||
在会议整理的例子里，用户应能分辨 AI 正在处理的是哪次会议、哪些片段和哪些候选结果；也应能区分“生成了一份建议”与“已经创建任务”这两种状态。
|
||
|
||
对于会改变业务状态的操作，可以探索先展示目标、主要输入和预期效果，再让用户判断是否继续。哪些操作需要确认、哪些可以在既定范围内连续执行，应根据任务与风险讨论，不在这里规定所有动作都弹窗确认。
|
||
|
||
图中让曲线指向某个对象，不表示每个对象、字段或函数都需要一份独立的用户权限表。现有语言设计以 workspace 为整体授权边界，对象定位、代码可视域、入口允许的业务效果与用户授权应各自清楚，避免在这篇意义讨论中另造一套冲突规则。
|
||
|
||
### 委托给 AI，仍能区分谁在作决定
|
||
|
||
一个值得探索的目标是：用户可以将某项工作交给 AI，同时理解这次委托的目标、允许产生的效果和停止条件。AI 能引用对象或生成代码，不应自动获得修改任意对象或管理成员的权限。
|
||
|
||
委托的具体表示、运行身份如何绑定、长期任务是否重新检查授权、用户怎样收回委托，仍未定稿。这里先记录用户需要的体验，不把某种令牌、权限语法或审批流程提前确定为方案。
|
||
|
||
### 能检查结果，也能面对失败
|
||
|
||
用户需要区分未开始、执行中、成功、部分完成和失败。若一个流程只完成了部分任务创建，系统应尽量提供足够信息，让用户判断是否继续，而不是只返回一个无法解释的失败提示。
|
||
|
||
操作记录和来源关系可以帮助检查，但记录哪些内容、保存多久、谁能查看，仍需要权衡。我们可以讨论撤销、补偿操作或恢复到某个版本的能力，不能假定每次操作都可以回滚：已经发生的外部效果可能无法收回，跨系统执行也未必具有一个统一事务。
|
||
|
||
### 部署选择与控制之间的关系
|
||
|
||
本地、自部署和平台端提供了不同的运行与数据放置选择。它们可以帮助用户决定在哪里运行对象、由谁维护服务，但部署在自己机器上并不自动解决授权、备份或错误操作问题。
|
||
|
||
如果用户希望迁出数据、替换前端或更换运行位置，系统需要有可解释的边界。哪些对象、关系和执行状态可以导出，怎样保留引用与依赖，以及离开某个服务后还能使用什么，都应继续讨论，而不是仅用“支持自部署”代替这些问题。
|
||
|
||
## Endor 的代价、边界与验证标准（试写，待确认）
|
||
|
||
> **本章提出评估问题，不是已经达成的性能、兼容性或可靠性承诺。** 我们需要用真实工作流判断对象模型带来的收益，是否值得它引入的复杂度。
|
||
|
||
### 对象共同基础也会带来成本
|
||
|
||
| 需要承担的代价 | 为什么会出现 | 应当检查什么 |
|
||
| --- | --- | --- |
|
||
| 对象身份与引用的维护 | 对象被多个入口长期使用，关系不能只存在于一次调用中 | 改名、替换、删除和迁移后，引用是否仍有可理解的行为 |
|
||
| 类型与业务语义的协调 | 多个程序要对同一对象的含义形成约定 | 类型演进与不兼容变化是否使其他入口失效 |
|
||
| 跨端状态和网络成本 | 本地与远端对象不共享同一块内存 | 延迟、断线、过期状态和部分失败是否会造成错误判断 |
|
||
| 运行环境与运维成本 | 对象的执行、保存和访问需要相应基础设施 | 小规模使用是否也必须承担不必要的部署负担 |
|
||
| 学习和集成成本 | 开发者需要理解新的语言与对象模型 | 完成同一业务是否比已有语言、API 和工具增加更多工作 |
|
||
| 共同基础的依赖风险 | 多个入口可能依赖相同运行时与对象服务 | 故障影响范围、版本兼容和退出路径是否明确 |
|
||
|
||
图里更少的进程只是组织方式的示意。实际的内存、启动时间、吞吐量、隔离性和故障影响需要分别测量；进程少不天然意味着成本低，也不证明系统更可靠。
|
||
|
||
### 哪些事情不应勉强统一
|
||
|
||
专业程序可以保留适合自己的内部结构和交互方式。对于已有明确接口、成熟工作流或特殊执行约束的系统，建立适度的连接也许比全部迁入新的对象体系更合适。
|
||
|
||
对象关系不应抹平真实边界：一个远端对象可能不可达，一个业务操作可能被拒绝，一次结果更新可能尚未传播。语言可以帮助表达和处理这些情况，不能把它们变成“看起来像本地调用，因此一定立即成功”。
|
||
|
||
Endor 也不应仅凭对象之间可连接，就宣称用户可以无损迁移全部程序、消除所有格式转换或让 AI 理解全部业务。需要保留什么、转换什么、失去什么，应在具体对象和连接机制中说明。
|
||
|
||
### 用同一条工作流验证意义
|
||
|
||
可以先用前面的会议整理故事做一个范围有限的原型，对比现有工具的正常用法与 Endor 原型。两边使用同一份材料、同样的目标和相近的辅助条件；如果现有工具已经有良好的链接与自动化能力，也应纳入比较。
|
||
|
||
| 想验证的主张 | 可以观察的结果 |
|
||
| --- | --- |
|
||
| 减少重复组织数据 | 从录像到任务，需要多少次重复录入、复制和人工重建关联 |
|
||
| 保留同一对象与来源 | 换入口或重新进入流程后，能否准确找到原任务及其依据 |
|
||
| 支持人和 AI 交接 | 人能否修正 AI 的候选结果，AI 能否在修正后继续处理正确目标 |
|
||
| 操作效果容易理解 | 用户能否判断哪些只是建议，哪些已经改变业务状态 |
|
||
| 组合能力值得复用 | 加入第二种视图或工作流时，需要新增多少适配逻辑 |
|
||
| 失败时仍可继续 | 遇到断线、拒绝访问或部分完成后，能否辨认状态并继续工作 |
|
||
|
||
这些观察需要同时记录用户体验、实现工作量与运行成本。不能只比较演示中最顺利的一次，也不能把更多后台复杂度隐藏起来，再把少几个界面步骤当成全部收益。
|
||
|
||
### 什么结果意味着需要调整方向
|
||
|
||
如果保留对象身份仍然离不开大量手工映射，换一个界面仍然要复制一套数据，或者简单任务必须先部署过多基础设施，那么当前设计还没有兑现它的意义。
|
||
|
||
如果 AI 操作对象之后更难解释结果，或开发者为了接入对象模型付出的工作远高于已有接口带来的成本，也应调整对象粒度、语言边界或集成方式。
|
||
|
||
这里先不设任意的数值门槛。第一步应是做出可重复的具体工作流，记录收益和问题，再决定哪些目标值得继续投入，哪些假设需要修改。
|
||
|
||
## 继续整理的方向
|
||
|
||
这一版先把程序入口、对象、操作权、AI 与语言之间的关系串起来。后续可以用真实工作流修订这些描述，进一步确定对象身份、执行与挂载的语义。
|
||
|
||
[系统架构](/docs/00-endor-concepts-draft)讨论部署与存储，[节点与对象挂载](/docs/02-mounting-draft)讨论运行位置和挂载边界；本文关注它们为何能给用户带来值得验证的变化。
|