lix/mnote
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
41e958769e8330e3bab4fa21cc767798b8b7f4b4
mnote/design/07-ai/process/7-phase7-ai-kernel-projection-plan-v2.md
T
lix-2026 41e958769e feat: land page aggregate and phase7 document ai mainline 
- 收口 page aggregate 读取、本地状态与命令客户端\n- 接入 phase7 document ai sidecar 与前端编排入口\n- 更新 architecture 与 design 状态迁移
2026-04-23 07:38:34 +08:00

780 lines
24 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 7 [process] mnote Kernel Phase 7 AI 编排与 Kernel Projection 实施计划 v2
> 更新时间：2026-04-22
>
> 当前主线依据：
> - `/mnt/Data1T/mnote/ARCHITECTURE.md`
> - `/mnt/Data1T/mnote/design/01-05-current-priority-overview.md`
> - `/mnt/Data1T/mnote/design/01-tree-first-graph-kernel/process/1-tree-first-graph-kernel-v1.md`
> - `/mnt/Data1T/mnote/design/03-rust-web/process/3-rust-web-long-term-architecture-v1.md`
> - `/mnt/Data1T/mnote/design/03-rust-web/process/3-3-rust-web-tree-realtime-event-stream-v1.md`
> - `/mnt/Data1T/mnote/design/04-tree-domain/process/4-6-tree-command-protocol-cutover-stage2-v1.md`
> - `/mnt/Data1T/mnote/design/05-editor-mainline/process/5-5-page-aggregate-single-truth-alignment-v1.md`
> - `/mnt/Data1T/mnote/design/05-editor-mainline/process/5-6-page-aggregate-alignment-checklist-v1.md`
>
> 本稿与 `v1` 的关系：
> - `/mnt/Data1T/mnote/design/old/07-ai/process/7-phase7-ai-kernel-projection-plan-v1.md` 已降级为上一轮判断稿
> - 当前如要真正执行 `Phase 7`，应以本 `v2` 为执行口径
>
> 当前状态补充：
> - `/mnt/Data1T/mnote/design/07-ai/done/7-1-phase7-document-ai-minimum-loop-checklist-v1.md` 对应的“文档页 AI 最小闭环”已完成
> - 但本 `v2` 的后续阶段，尤其 `summary node / ai_note node / reference edge / kernel index` 仍未完成，因此本稿继续保留在 `process/`
> - 2026-04-23 验证补充：
> - `cd /mnt/Data1T/mnote/wolai-backend && ./.venv/bin/python -m pytest -q tests/test_ai_document_agent.py` -> `15 passed`
> - `cd /mnt/Data1T/mnote/wolai-frontend && pnpm test -- --runInBand src/app/api/ai-agent/run/route.test.ts src/app/api/ai-agent/document/config/route.test.ts src/components/editor/DocumentAiAgentPanel.runtime.test.tsx src/components/ai-agent/panelShared.test.ts` -> `202 passed`
---
## 1. 文档目的
这份 `v2` 只做一件事：
> **把 `Phase 7` 从“抽象地谈 AI 最终形态”改写成“能接在当前 page aggregate / tree command / realtime 主线之后执行的现实方案”。**
当前不再适合继续直接沿用 `v1` 的原因，不是方向完全错了，而是：
- `v1` 更像长期判断稿
- 它对当前真实工具面、命令面、依赖顺序仍然写得过于理想化
- 它没有充分吸收 `Page Aggregate` 这几天已经形成的收口事实
因此本稿要解决的不是“要不要做 Phase 7”，而是：
1. 如果现在开始做 `Phase 7`，第一交付物到底是什么
2. `Phase 7` 应该接在哪条现有主线之后，而不是另起一套理想结构
3. `openai-agents-python` 到底如何接入当前文档页 AI 主链
4. 哪些 `v1` 里的目标继续保留，哪些必须降级到后续阶段
一句话收口：
> **`Phase 7` 当前第一目标不是“做完整 AI 平台”，而是让文档页 AI 先沿着 `page aggregate command family` 进入主编辑区正式主链。**
---
## 2. 当前结论
当前推荐口径固定如下：
> **`mnote` 的长期 AI 主线仍然采用“Rust kernel / Rust runtime 做唯一事实源与真执行面，`openai-agents-python` 作为 `mnote` 专用编排层，`Hermes` 退回过渡与实验平台”的结构。**
但如果按真实执行顺序来排，当前 `Phase 7` 必须服从下面这个前置条件：
1. `Page Aggregate` 继续作为文档页真相收口主线
2. `tree command cutover` 继续作为页面生命周期正式命名面主线
3. `tree realtime event stream` 继续作为工作区树实时主线
4. `Phase 7` 只在这三条主线已形成可接入的最小面之后，切入文档页 AI 最小闭环
因此当前不能把 `Phase 7` 表述成：
- 先做一套完整 AI 产品平台
- 先把所有 AI 工具都切到全新命名
- 先把 `summary node / ai_note node / reference edge / kernel index` 全部一口气打通
当前正确表述应是：
> **`Phase 7` 的第一闭环，是“文档页 AI 读取 page aggregate 上下文，并通过 `page.head.updateTitle / page.body.save / tree.*` 正式命令面回写主编辑区”。**
---
## 3. 当前真实基线
`v2` 必须建立在当前已经真实成立的代码事实之上。
### 3.1 文档页主编辑器已经切到正式 island
当前默认主编辑区已经是页面内 `leptos-tiptap` island，不再是 `iframe bridge`，`BlockNote` 只保留为 fallback / 对照链。
这意味着 `Phase 7` 的文档页 AI 主写链，默认目标已经不是旧编辑器壳，而是当前正式主编辑区。
### 3.2 文档页已经开始消费统一 page aggregate
当前文档页首屏与客户端补拉已经围绕 `PageAggregateProjection` 收口，页面本地状态也开始收口到统一 client aggregate state。
这意味着：
- AI 上下文已经不必继续只围绕零散 `title / content / options / pageSubtree` getter 组织
- 文档页 AI 可以以 page aggregate snapshot 作为第一上下文来源
### 3.3 页面命令面已经开始收口到 `page.*`
当前前端与 route 执行面已经开始统一到下面三组页面命令：
- `page.head.updateTitle`
- `page.layout.updateOptions`
- `page.body.save`
这组命令面已经成为文档页 AI 后续接入的第一正式写入口。
这也是本稿与 `v1` 的关键差异之一：
> **`Phase 7` 第一阶段不再直接凭空引入一套全新的 `editor.*` 产品命名面，而是优先挂接已经开始收口的 `page aggregate command family`。**
### 3.4 树域命令面正在切到 `tree.*`
当前页面新建、重命名、移动、归档、恢复、嵌入等生命周期命令，长期正式命名已固定为：
- `tree.node.create`
- `tree.node.rename`
- `tree.subtree.move`
- `tree.node.archive`
- `tree.node.restore`
- `tree.node.purge`
- `tree.node.embed`
- `tree.subtree.copy`
这意味着：
- AI 若需要跨页面生命周期操作，不应继续以 `documents.*` 作为长期契约
- 但 `Phase 7` 第一闭环仍以当前页正文编写为先，不先扩大全树操作面
### 3.5 当前 AI runtime 仍以 Hermes 兼容桥为主
当前文档页 AI 面板仍主要通过 `Hermes bridge` 工作，前端默认工具面仍以这些运行时工具为主：
- `slash_run`
- `doc_get`
- `doc_find`
- `doc_insert_blocks`
- `doc_replace_range`
- `docs_search`
- `docs_read`
- `image_read`
并且当前结构化结果恢复，明确只对以下文档页写工具做了正式回接：
- `slash_run`
- `doc_insert_blocks`
- `doc_replace_range`
这意味着当前现实不是：
- 已有一套完整 `mnote-native` agent 编排层
而是：
- 已有一个可工作的文档页 AI 过渡链
- 这条链已经开始向 `page aggregate command family` 回接
- `Phase 7` 的第一任务，应是把这条链从 Hermes 兼容桥迁到正式 `openai-agents-python` 编排层
---
## 4. 为什么 `v1` 不能直接当执行稿
`v1` 里最需要修正的不是方向，而是以下四个执行偏差。
### 4.1 工具命名过于理想化
`v1` 直接把第一批工具写成：
- `editor.insert_block_after`
- `editor.replace_block`
- `editor.delete_block`
- `kernel.summary.create`
- `kernel.ai_note.create`
这在长期上未必错，但它跳过了当前已经开始成形的两层真实命名：
- 页面命令面：`page.head.* / page.layout.* / page.body.*`
- 树域命令面：`tree.*`
如果现在按 `v1` 直接执行，容易在现有 `page.*` / `tree.*` 之外，再长出第三套 AI 专用命名面。
### 4.2 没有明确把 Phase 7 锚定到 Page Aggregate
`v1` 虽然提到了 `Page Aggregate`，但没有把它明确设为 `Phase 7` 的第一依赖。
而当前真实主线已经很明确：
> **文档页 AI 若不先对齐 `Page Aggregate`，后面很容易再次绕回“前端局部快照 + 兼容副作用链”的旧路。**
### 4.3 第一阶段战线铺得过宽
`v1` 把下面这些目标放得过于靠前：
- `summary node`
- `ai_note node`
- `reference edge`
- `PDF / Book -> kernel index`
这些目标仍然重要，但当前如果要先做 `Phase 7`，第一交付物不应是它们。
当前第一交付物应是：
> **文档页 AI 直接编写主编辑区，人审核后应用，且整个过程沿 `page aggregate` 正式命令面回写。**
### 4.4 没有充分吸收当前 Hermes 兼容桥已形成的过渡事实
当前已经存在一条可运行的 Hermes 文档页 AI 过渡链，且它已经开始把结果恢复成：
- `page.body.save` 语义
- `page.head.updateTitle` 语义
所以 `Phase 7` 的正确做法不是假装这条链不存在，而是：
1. 明确它是过渡链
2. 冻结它的保留边界
3. 用 `openai-agents-python` 替换它的编排层，而不是推翻整条文档页 AI 回写链
---
## 5. 架构边界冻结
### 5.1 长期推荐结构
```text
Document Page / Read View / AI Panel
|
v
AI Gateway / SSE Event Adapter
|
+---- current fallback: Hermes bridge
|
+---- target mainline: openai-agents-python
| |
| +---- provider: OpenAI Responses API
| +---- mnote page tools
| +---- mnote tree tools
|
v
Rust runtime / mnote-web / bridge-runtime
|
+---- page aggregate command family
| - page.head.updateTitle
| - page.layout.updateOptions
| - page.body.save
|
+---- tree command family
| - tree.node.*
| - tree.subtree.*
|
v
Rust kernel truth
```
### 5.2 各层职责
#### Rust kernel / Rust runtime
负责：
- 对象真相
- projection / query / command
- page aggregate 命令面
- tree command 命令面
- 审计、trace、失败回放与回滚基线
不负责：
- 通用 agent 编排框架
- 通用聊天产品壳
#### `openai-agents-python`
负责：
- 文档页 AI 会话编排
- tools / handoffs / tracing / guardrails / HITL
- 调用 OpenAI `Responses API`
- 组织 `mnote` 的文档页 AI 工具合同
不负责：
- 保存产品真相
- 绕过 Rust runtime 直接写产品数据
- 自己持有第二套页面真相
#### Hermes
负责：
- 过渡期 fallback
- 回归对照
- 试验非主链场景
不负责：
- 文档页 AI 长期主编排
- 产品正式工具契约
#### 前端 AI Host / Panel
负责：
- 会话 UI
- 流式事件渲染
- 审核与应用入口
- 挂接当前页面的 page aggregate snapshot
- 展示当前页面 AI 的正式配置真源与运行时能力面
不负责：
- 私下拼出第二份页面真相
- 私下定义长期 AI 工具协议
- 私下持有 `profile` 真源
- 私下硬编码一份长期工具注册表
### 5.3 页面 AI 配置真源冻结
当前页面 AI 的配置真源，必须额外冻结为下面三层。
#### 模型层：前端保存 `model_key`，不保存底层 provider model
页面 AI 的模型配置真源，不应是：
- `slow / fast / codex` 这类 combo 内部路由名
- `ju/gpt-5.4` 这类底层 provider model id
页面 AI 应保存的是**产品层可识别的 `model_key`**，例如：
- `gpt-5.4`
- `gpt-5.4-mini`
- `gpt-5.3-codex`
- `gemini-3.1-pro-preview`
- `third`
其长期原则固定如下：
- `model_key` 是前端设置与产品语义真源
- `resolved_combo` 是运行时解析结果，例如 `slow / fast / codex`
- `resolved_runtime_model` 是最终底层节点 / provider model，仅用于调试、trace 与排障
也就是说：
> **页面 AI 配置真源固定为 `model_key -> resolved_combo -> resolved_runtime_model`，而不是直接把 combo 名或底层 provider model 暴露成产品配置键。**
#### 设定层：前端可设 `profile`，后端持有真源
当前 `Soul / Profile` 的正确落点不是前端自由文本壳，也不是 `openai-agents-python` 自己的长期真相层，而是：
- 前端可以选择与查看 `profile`
- 后端持有正式 `profile registry`
- 编排层把 `profile` 编译成最终 instructions / policy / defaults
固定原则如下：
- 前端只提交 `profileId`
- `profile` 内容、版本、默认值、升级策略由后端持有
- 前端可显示 profile 说明、用途、默认工具集、session 策略
- 不允许前端静态硬编码出第二份长期 `profile` 真相
#### 工具层：工具注册表必须前端可见
当前页面 AI 的正式工具面，不允许只在后端注册、前端不可见。
必须固定为：
- 后端持有正式 tool registry
- 前端设置页可以看见当前 scope 已注册工具
- 工具显示至少包含：
- `name`
- `description`
- `scope`
- `read/write`
- `status`
- `version`（如有）
这样后续若新增 `mindmap`、阅读态、搜索态等工具，前端设置页会直接反映真实能力面，而不是继续依赖人工记忆。
---
## 6. `Phase 7` 的当前目标重写
本稿把 `Phase 7` 当前目标重写为两层。
### 6.1 第一层目标：文档页 AI 最小闭环
这是当前必须优先完成的唯一第一闭环。
完成口径如下：
- AI 读取当前文档页 page aggregate 上下文
- AI 能对当前页正文执行插入、改写、重命名
- AI 回写沿正式 `page aggregate command family`
- 主编辑区 island 能正式回显结果
- 人可以作为审核者决定是否应用或继续编辑
- 人可以在页面 AI 设置中看见当前 `model_key / profile / tool registry` 的正式状态
一句话说：
> **先让 AI 真正进入当前页主编辑区主链，而不是先做大而全的 AI 能力矩阵。**
### 6.2 第二层目标：结构化知识写链
下面这些目标保留，但降到文档页最小闭环之后：
- `summary node`
- `ai_note node`
- `reference edge`
- `PDF / Book -> kernel index`
它们属于 `Phase 7` 的后续扩展，不再作为第一交付物。
---
## 7. 第一闭环的冻结验收口径
当前如要宣称 `Phase 7` 进入执行，应只以以下验收口径作为第一阶段成功标准。
### 7.1 读侧
AI 至少能稳定拿到：
- `documentId`
- 当前页 `blocks`
- 当前页 `pageSubtree`
- `pageOptions`
- `editorRuntimePageOptions`
- 必要时的 `outline / evidence`
说明：
- 当前不要求所有上下文都来自 Rust 原生 `Page Aggregate route`
- 允许过渡期继续使用当前文档页已经收口出的 page aggregate loader 与 client aggregate snapshot
- 但不再允许继续围绕零散页面壳对象拼装新的 AI 私有上下文
### 7.2 写侧
AI 第一批正式写能力只冻结为：
- 当前页标题改名
- 当前页正文插入
- 当前页正文改写
其长期命令语义分别锚定为：
- 标题改名 -> `page.head.updateTitle`
- 正文插入 / 改写 -> `page.body.save`
说明：
- 过渡期运行时仍可继续通过 `slash_run / doc_insert_blocks / doc_replace_range` 承接
- 但这些运行时工具必须被视为过渡工具，不得继续上升为长期产品契约
### 7.3 审核侧
当前文档页 AI 的产品定位固定为：
> **AI 直接接入主编辑区编写，人负责审核、继续编辑、确认结果。**
因此第一闭环里必须明确：
- AI 输出不是单纯聊天文本
- AI 输出必须能映射到页面正式写链
- 人能在主编辑区中继续接手与修订
### 7.4 不在第一闭环内的项
当前不纳入第一闭环：
- 页面设置类 AI 写工具
- 跨页大规模树操作
- mindmap AI 主链
- PDF / Book 结构化摄取
- `summary node / ai_note node / reference edge`
### 7.5 配置侧
第一闭环内，页面 AI 的配置面至少要有可冻结的正式口径：
- 模型真源为 `model_key`
- `resolved_combo / resolved_runtime_model` 只作为运行时调试信息
- `profile` 前端可设，但由后端 registry 持有真源
- 当前 scope 的 tool registry 必须前端可见
说明：
- 第一闭环不要求一开始就做完整 AI 设置产品壳
- 但必须把“谁是配置真源、哪些信息必须可见”冻结下来
- 否则后续模型、profile、工具会继续散落在前端本地状态、后端环境变量和隐式注册代码里
---
## 8. 正式工具面与过渡工具面的双层口径
为避免混乱，本稿把工具合同拆成两层。
### 8.1 长期正式命令面
这是产品长期应围绕的正式语义面：
#### 页面命令面
- `page.head.updateTitle`
- `page.layout.updateOptions`
- `page.body.save`
#### 树域命令面
- `tree.node.create`
- `tree.node.rename`
- `tree.node.archive`
- `tree.node.restore`
- `tree.node.purge`
- `tree.node.embed`
- `tree.subtree.move`
- `tree.subtree.copy`
### 8.2 过渡运行时工具面
这是当前 Hermes 兼容链与 bridge-runtime 已经真实承接的工具面：
- `slash_run`
- `doc_get`
- `doc_find`
- `doc_insert_blocks`
- `doc_replace_range`
- `docs_search`
- `docs_read`
- `image_read`
固定原则如下：
> **`Phase 7` 不删除过渡工具面，但也不把过渡工具名继续写成长期产品契约。**
### 8.3 `openai-agents-python` 的接入原则
`openai-agents-python` 接入时，优先接的不是抽象理想工具名，而是：
1. 当前页最小闭环所需的正式命令语义
2. 当前已真实存在的过渡运行时工具能力
3. 两者之间的明确映射关系
也就是说：
- 对外长期文档写正式命令语义
- 对内迁移期允许 adapter 调用当前 bridge-runtime 能跑通的过渡工具
### 8.4 工具注册表可见原则
文档页 AI 长期不能只做到“后端注册工具”，还必须做到“前端能看见当前真正注册了哪些工具”。
因此冻结如下：
1. 后端需要提供正式能力面 / 注册表接口
2. 前端页面 AI 设置页默认展示当前 scope 的真实工具注册表
3. 前端手动工具选择只允许在真实注册工具集合内进行
4. 新增 `mindmap`、阅读态、搜索态工具时，必须同步进入注册表可见面
一句话收口：
> **工具不是隐藏在编排层里的实现细节，而是页面 AI 产品能力面的一部分。**
---
## 9. 分阶段实施计划
## 阶段 0：冻结 `Phase 7` 依赖关系
### 目标
明确 `Phase 7` 是文档页主线的下一层，而不是脱离 `Page Aggregate` 单独启动的平行工程。
### 需要完成
- [x] 明确 `Phase 7` 第一依赖是 `5-6 Phase J`
- [x] 明确当前第一闭环只覆盖文档页 AI 主写链
- [x] 明确 `summary / ai_note / reference / index` 降为后续扩展
- [x] 明确 `Hermes` 只保留为 fallback / 对照链
- [x] 明确 `openai-agents-python` 为长期推荐编排层
- [x] 明确页面 AI 模型配置真源是 `model_key`，不是 combo 名或 provider model
- [x] 明确 `profile` 前端可设、后端持有真源
- [x] 明确 tool registry 必须前端可见
### 完成判定
- [ ] 团队口径统一为“先文档页最小闭环，再扩结构化知识写链”
- [ ] 团队口径统一为“`model_key / profile / tool registry` 都有正式真源，不再散落在隐式实现里”
---
## 阶段 1：冻结文档页 AI 正式语义面
### 目标
先把文档页 AI 到底面向哪一组正式语义面写清楚。
### 需要完成
- [x] 冻结当前页 AI 写入第一批正式动作：
- 改标题
- 插入正文
- 改写正文
- [x] 冻结这些动作对应的长期正式命令语义：
- `page.head.updateTitle`
- `page.body.save`
- [x] 冻结树域相关动作的长期正式命令语义为 `tree.*`
- [x] 写清 `过渡工具面 -> 正式命令面` 的映射关系
- [x] 禁止新增第三套 AI 专用产品命名面
- [x] 冻结页面 AI 模型配置真源为 `model_key`
- [x] 冻结 `model_key -> resolved_combo -> resolved_runtime_model` 的分层关系
- [x] 冻结 `profile` 前端可设、后端 registry 持有真源
- [x] 冻结当前 scope tool registry 必须前端可见
### 完成判定
- [x] 文档页 AI 已有一套与 `page aggregate command family` 对齐的稳定语义面
- [x] 文档页 AI 已有一套与 `model_key / profile / tool registry` 对齐的稳定配置语义面
---
## 阶段 2：冻结文档页 AI 上下文装配
### 目标
让 AI 输入上下文显式锚定到 page aggregate，而不是继续围绕零散页面壳字段。
### 需要完成
- [x] 固定当前页 AI 最小上下文字段：
- `documentId`
- `blocks`
- `pageSubtree`
- `pageOptions`
- `editorRuntimePageOptions`
- `outline`
- `evidence`
- [x] 明确上下文优先级：
- page aggregate snapshot
- page subtree / outline / evidence
- 必要的兼容页面壳快照
- [x] 不再继续扩散新的 AI 私有页面 getter
- [x] 为 AI 会话定义上下文裁剪规则
### 完成判定
- [x] 文档页 AI 读侧可以被明确描述为“消费 page aggregate 上下文”
---
## 阶段 3：引入 `openai-agents-python` 文档页编排层
### 目标
在不推翻现有文档页 AI 回写链的前提下，用 `openai-agents-python` 替换 Hermes 作为长期文档页编排层。
### 需要完成
- [x] 建立独立的 `mnote-ai-orchestrator` Python 服务或 sidecar
- [x] 接入 OpenAI `Responses API`
- [x] 先只注册文档页第一闭环所需工具
- [ ] 打通 session / tracing / guardrails / HITL 最小能力
- [x] 对齐当前前端 SSE 协议，或提供新的稳定 event adapter
- [x] 前端 provider 切换具备 `Hermes fallback`
- [x] 建立页面 AI capability/config route，至少返回：
- `model_key` 列表
- 默认 `profile`
- 当前 scope tool registry
- `resolved_combo / resolved_runtime_model` 调试字段
- [x] 让 online provider 也能稳定进入正式 session 模式，而不只是在 codex provider 下启用
### 完成判定
- [x] 在不依赖 Hermes 主编排的情况下，文档页 AI 已能跑通第一闭环
- [x] 新编排层已具备“模型 / profile / 工具”统一能力面出口
---
## 阶段 4：切文档页 AI 默认主路径
### 目标
让文档页 AI 在产品可见行为上真正从 Hermes 过渡到新编排层。
### 需要完成
- [x] 文档页 AI panel 默认走 `openai-agents-python`
- [x] 标题改名沿 `page.head.updateTitle` 回写
- [x] 正文改写沿 `page.body.save` 回写
- [x] 主编辑区 island 稳定回显 AI 结果
- [x] 审核与继续编辑行为维持在主编辑区内完成
- [x] Hermes 仅保留 fallback 开关
- [x] 页面 AI 设置页显示正式 `model_key` 下拉，而不是自由文本底层 model
- [x] 页面 AI 设置页显示当前 `profile`
- [x] 页面 AI 设置页显示当前 scope 已注册工具列表
- [x] 页面 AI 设置页显示当前 `resolved_combo / resolved_runtime_model` 作为调试信息，而不是产品主键
### 完成判定
- [x] 可以明确说“AI 已正式进入当前页主编辑区主链”
- [x] 可以明确说“页面 AI 的模型 / 设定 / 工具状态对用户是可见且可解释的”
---
## 阶段 5：扩展结构化知识写链
### 目标
在文档页最小闭环稳定后，再向更完整的 `Phase 7` 目标扩展。
### 需要完成
- [ ] `summary node`
- [ ] `ai_note node`
- [ ] `reference edge`
- [ ] `PDF / Book -> kernel index`
- [ ] 对这些写链补齐 trace / audit / rollback / evidence
### 完成判定
- [ ] `Phase 7` 才能开始被描述为“进入结构化知识写链阶段”
---
## 10. Hermes 的过渡策略重写
当前不建议立刻删除 Hermes，但必须缩边界。
### 10.1 继续保留的价值
- 承接现有文档页 AI 运行链
- 作为 `openai-agents-python` 的回归对照
- 作为 fallback 开关
- 承接非主链实验场景
### 10.2 明确禁止的事情
- 不让 Hermes 成为文档页长期主编排
- 不让 Hermes memory 取代 page aggregate / kernel-aware retrieval
- 不让 Hermes 工具名继续成为长期产品契约
- 不让 Hermes 默认 shell/fs 能力绕过 Rust runtime 写业务数据
### 10.3 最终可接受状态
最终可接受状态有两种：
1. Hermes 退化为非主链实验平台
2. Hermes 完全下线，只保留 `openai-agents-python + Rust runtime`
---
## 11. 非目标
本稿当前不覆盖：
- 完整 AI 平台产品化
- 完整 suggestion review 产品壳
- 多平台消息网关
- 通用桌面 agent / shell agent
- mindmap AI 主线
- OnlyOffice AI 主线
- 完整长期记忆产品壳
这些都不是当前 `Phase 7` 的第一任务。
---
## 12. 当前冻结口径
当前冻结如下：
> **`Phase 7` 仍然以 `openai-agents-python` 作为长期推荐编排层，以 Rust runtime 作为唯一事实源与真执行面。**
> **但当前 `Phase 7` 的第一交付物不再定义为“完整 AI 平台”或“完整结构化知识写链”，而是“文档页 AI 直接进入主编辑区，并沿 `page aggregate command family` 正式回写”。**
> **`Hermes` 可以继续作为过渡平台与实验平台存在，但不再作为文档页 AI 的长期语义中心。**
> **页面 AI 的模型真源固定为 `model_key`，`resolved_combo / resolved_runtime_model` 只作为运行时调试信息；`profile` 前端可设但由后端持有真源；tool registry 必须前端可见。**
一句话收口：
> **当前如要先做 `Phase 7`，正确起点不是继续抽象谈 kernel-aware AI，而是先让 AI 真正沿 `page aggregate -> 主编辑区 island` 这条当前主线闭环。**
Reference in New Issue View Git Blame Copy Permalink