Add tentative control and tradeoff discussion chapters

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

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