- 将 3000 主入口继续收口到 mnote-web,补齐 /favicon.ico、/api/auth、session alias、AI run 等 Rust Web 路由边界。 - 更新登录页与 Convex Auth 代理,支持测试账号快速登录写入真实 Convex Auth cookie。 - 推进页面设置、Wolai 对齐、Phase 7 AI kernel/CLI-first 设计文档与相关 smoke 脚本。 - 更新 leptos-tiptap 生成资产、mnote-cli/bridge-runtime、前端依赖和 dev/prod 启动脚本。
26 KiB
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/done/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 passedcd /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- 2026-05-05 口径修正:
- 本稿记录的
openai-agents-python文档页主链收口,当前仅作为过渡阶段基线- 长期方向已被
/mnt/Data1T/mnote/design/07-ai/process/7-phase7-ai-kernel-projection-plan-v4.md覆盖- 当前长期口径固定为:
mnote-cli是唯一长期 agent 执行面;openai-agents-python、Hermes、Codex 都视为可插拔外置 agent
1. 文档目的
这份 v2 只做一件事:
把
Phase 7从“抽象地谈 AI 最终形态”改写成“能接在当前 page aggregate / tree command / realtime 主线之后执行的现实方案”。
当前不再适合继续直接沿用 v1 的原因,不是方向完全错了,而是:
v1更像长期判断稿- 它对当前真实工具面、命令面、依赖顺序仍然写得过于理想化
- 它没有充分吸收
Page Aggregate这几天已经形成的收口事实
因此本稿要解决的不是“要不要做 Phase 7”,而是:
- 如果现在开始做
Phase 7,第一交付物到底是什么 Phase 7应该接在哪条现有主线之后,而不是另起一套理想结构- 过渡期
openai-agents-python适配链到底如何接入当前文档页 AI 主链 - 哪些
v1里的目标继续保留,哪些必须降级到后续阶段
一句话收口:
Phase 7当前第一目标不是“做完整 AI 平台”,而是让文档页 AI 先沿着page aggregate command family进入主编辑区正式主链。
2. 当前结论
当前推荐口径固定如下:
本稿原始判断是“Rust kernel / Rust runtime 做唯一事实源与真执行面,
openai-agents-python作为mnote专用编排层,Hermes退回过渡与实验平台”。该判断现已退化为历史过渡口径;当前长期口径改为:
Rust kernel / Rust runtime做唯一事实源与真执行面,mnote-cli做唯一长期 agent 执行面,openai-agents-python与Hermes都作为可插拔外置 agent。
但如果按真实执行顺序来排,当前 Phase 7 必须服从下面这个前置条件:
Page Aggregate继续作为文档页真相收口主线tree command cutover继续作为页面生命周期正式命名面主线tree realtime event stream继续作为工作区树实时主线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 / pageSubtreegetter 组织 - 文档页 AI 可以以 page aggregate snapshot 作为第一上下文来源
3.3 页面命令面已经开始收口到 page.*
当前前端与 route 执行面已经开始统一到下面三组页面命令:
page.head.updateTitlepage.layout.updateOptionspage.body.save
这组命令面已经成为文档页 AI 后续接入的第一正式写入口。
这也是本稿与 v1 的关键差异之一:
Phase 7第一阶段不再直接凭空引入一套全新的editor.*产品命名面,而是优先挂接已经开始收口的page aggregate command family。
3.4 树域命令面正在切到 tree.*
当前页面新建、重命名、移动、归档、恢复、嵌入等生命周期命令,长期正式命名已固定为:
tree.node.createtree.node.renametree.subtree.movetree.node.archivetree.node.restoretree.node.purgetree.node.embedtree.subtree.copy
这意味着:
- AI 若需要跨页面生命周期操作,不应继续以
documents.*作为长期契约 - 但
Phase 7第一闭环仍以当前页正文编写为先,不先扩大全树操作面
3.5 当前 AI runtime 仍以 Hermes 兼容桥为主
当前文档页 AI 面板仍主要通过 Hermes bridge 工作,前端默认工具面仍以这些运行时工具为主:
slash_rundoc_getdoc_finddoc_insert_blocksdoc_replace_rangedocs_searchdocs_readimage_read
并且当前结构化结果恢复,明确只对以下文档页写工具做了正式回接:
slash_rundoc_insert_blocksdoc_replace_range
这意味着当前现实不是:
- 已有一套完整
mnote-nativeagent 编排层
而是:
- 已有一个可工作的文档页 AI 过渡链
- 这条链已经开始向
page aggregate command family回接 Phase 7的第一任务,应是把这条链从 Hermes 兼容桥收口到统一mnote-clihost / adapter;openai-agents-python、Hermes、Codex 只作为可插拔外置 agent
4. 为什么 v1 不能直接当执行稿
v1 里最需要修正的不是方向,而是以下四个执行偏差。
4.1 工具命名过于理想化
v1 直接把第一批工具写成:
editor.insert_block_aftereditor.replace_blockeditor.delete_blockkernel.summary.createkernel.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 nodeai_note nodereference edgePDF / Book -> kernel index
这些目标仍然重要,但当前如果要先做 Phase 7,第一交付物不应是它们。
当前第一交付物应是:
文档页 AI 直接编写主编辑区,人审核后应用,且整个过程沿
page aggregate正式命令面回写。
4.4 没有充分吸收当前 Hermes 兼容桥已形成的过渡事实
当前已经存在一条可运行的 Hermes 文档页 AI 过渡链,且它已经开始把结果恢复成:
page.body.save语义page.head.updateTitle语义
所以 Phase 7 的正确做法不是假装这条链不存在,而是:
- 明确它是过渡链
- 冻结它的保留边界
- 用
mnote-cli统一承接长期 agent 执行面,而不是把openai-agents-python或 Hermes 继续写成长期主编排
5. 架构边界冻结
5.1 长期推荐结构
Document Page / Read View / AI Panel
|
v
AI Gateway / SSE Event Adapter
|
+---- long-term execution surface: mnote-cli
| |
| +---- external agent adapter: openai-agents-python
| +---- external agent adapter: Hermes
| +---- external agent adapter: Codex
|
+---- current fallback: Hermes bridge
|
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 编排框架
- 通用聊天产品壳
mnote-cli
负责:
- 文档页 AI 会话编排
- 外置 agent adapter 调度
- mnote page tools / tree tools 统一入口
- CLI host / Web AI host 之间的执行契约
不负责:
- 保存产品真相
- 绕过 Rust runtime 直接写产品数据
- 自己持有第二套页面真相
openai-agents-python
负责:
- 作为可插拔外置 agent adapter / 对照实现
- tools / handoffs / tracing / guardrails / HITL
- 调用 OpenAI
Responses API - 通过
mnote-cli暴露的工具合同接入mnote
不负责:
- 保存产品真相
- 绕过 Rust runtime 直接写产品数据
- 自己持有第二套页面真相
- 文档页 AI 长期默认主编排
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.4gpt-5.4-minigpt-5.3-codexgemini-3.1-pro-previewthird
其长期原则固定如下:
model_key是前端设置与产品语义真源resolved_combo是运行时解析结果,例如slow / fast / codexresolved_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 已注册工具
- 工具显示至少包含:
namedescriptionscoperead/writestatusversion(如有)
这样后续若新增 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 nodeai_note nodereference edgePDF / Book -> kernel index
它们属于 Phase 7 的后续扩展,不再作为第一交付物。
7. 第一闭环的冻结验收口径
当前如要宣称 Phase 7 进入执行,应只以以下验收口径作为第一阶段成功标准。
7.1 读侧
AI 至少能稳定拿到:
documentId- 当前页
blocks - 当前页
pageSubtree pageOptionseditorRuntimePageOptions- 必要时的
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.updateTitlepage.layout.updateOptionspage.body.save
树域命令面
tree.node.createtree.node.renametree.node.archivetree.node.restoretree.node.purgetree.node.embedtree.subtree.movetree.subtree.copy
8.2 过渡运行时工具面
这是当前 Hermes 兼容链与 bridge-runtime 已经真实承接的工具面:
slash_rundoc_getdoc_finddoc_insert_blocksdoc_replace_rangedocs_searchdocs_readimage_read
固定原则如下:
Phase 7不删除过渡工具面,但也不把过渡工具名继续写成长期产品契约。
8.3 外置 agent adapter 的接入原则
openai-agents-python、Hermes、Codex 作为外置 adapter 接入时,优先接的不是抽象理想工具名,而是 mnote-cli 暴露的统一工具契约:
- 当前页最小闭环所需的正式命令语义
- 当前已真实存在的过渡运行时工具能力
- 两者之间的明确映射关系
也就是说:
- 对外长期文档写正式命令语义
- 对内迁移期允许 adapter 调用当前 bridge-runtime 能跑通的过渡工具
8.4 工具注册表可见原则
文档页 AI 长期不能只做到“后端注册工具”,还必须做到“前端能看见当前真正注册了哪些工具”。
因此冻结如下:
- 后端需要提供正式能力面 / 注册表接口
- 前端页面 AI 设置页默认展示当前 scope 的真实工具注册表
- 前端手动工具选择只允许在真实注册工具集合内进行
- 新增
mindmap、阅读态、搜索态工具时,必须同步进入注册表可见面
一句话收口:
工具不是隐藏在编排层里的实现细节,而是页面 AI 产品能力面的一部分。
9. 分阶段实施计划
阶段 0:冻结 Phase 7 依赖关系
目标
明确 Phase 7 是文档页主线的下一层,而不是脱离 Page Aggregate 单独启动的平行工程。
需要完成
- 明确
Phase 7第一依赖是5-6 Phase J - 明确当前第一闭环只覆盖文档页 AI 主写链
- 明确
summary / ai_note / reference / index降为后续扩展 - 明确
Hermes只保留为 fallback / 对照链 - 明确
openai-agents-python仅作为过渡期可插拔外置 agent / adapter 示例 - 明确页面 AI 模型配置真源是
model_key,不是 combo 名或 provider model - 明确
profile前端可设、后端持有真源 - 明确 tool registry 必须前端可见
完成判定
- 团队口径统一为“先文档页最小闭环,再扩结构化知识写链”
- 团队口径统一为“
model_key / profile / tool registry都有正式真源,不再散落在隐式实现里”
阶段 1:冻结文档页 AI 正式语义面
目标
先把文档页 AI 到底面向哪一组正式语义面写清楚。
需要完成
- 冻结当前页 AI 写入第一批正式动作:
- 改标题
- 插入正文
- 改写正文
- 冻结这些动作对应的长期正式命令语义:
page.head.updateTitlepage.body.save
- 冻结树域相关动作的长期正式命令语义为
tree.* - 写清
过渡工具面 -> 正式命令面的映射关系 - 禁止新增第三套 AI 专用产品命名面
- 冻结页面 AI 模型配置真源为
model_key - 冻结
model_key -> resolved_combo -> resolved_runtime_model的分层关系 - 冻结
profile前端可设、后端 registry 持有真源 - 冻结当前 scope tool registry 必须前端可见
完成判定
- 文档页 AI 已有一套与
page aggregate command family对齐的稳定语义面 - 文档页 AI 已有一套与
model_key / profile / tool registry对齐的稳定配置语义面
阶段 2:冻结文档页 AI 上下文装配
目标
让 AI 输入上下文显式锚定到 page aggregate,而不是继续围绕零散页面壳字段。
需要完成
- 固定当前页 AI 最小上下文字段:
documentIdblockspageSubtreepageOptionseditorRuntimePageOptionsoutlineevidence
- 明确上下文优先级:
- page aggregate snapshot
- page subtree / outline / evidence
- 必要的兼容页面壳快照
- 不再继续扩散新的 AI 私有页面 getter
- 为 AI 会话定义上下文裁剪规则
完成判定
- 文档页 AI 读侧可以被明确描述为“消费 page aggregate 上下文”
阶段 3:整理并保留 openai-agents-python 过渡适配链
目标
在不推翻现有文档页 AI 回写链的前提下,保留 openai-agents-python 这条已跑通的过渡外置 adapter,用它作为 mnote-cli-first 迁移期间的对照与行为基线,而不是把它定义成长期默认文档页编排层。
需要完成
- 建立独立的
mnote-ai-orchestratorPython 服务或 sidecar - 接入 OpenAI
Responses API - 先只注册文档页第一闭环所需工具
- 打通 session / tracing / guardrails / HITL 最小能力
- 对齐当前前端 SSE 协议,或提供新的稳定 event adapter
- 前端 provider 切换具备
Hermes fallback - 建立页面 AI capability/config route,至少返回:
model_key列表- 默认
profile - 当前 scope tool registry
resolved_combo / resolved_runtime_model调试字段
- 让 online provider 也能稳定进入正式 session 模式,而不只是在 codex provider 下启用
完成判定
- 在不依赖 Hermes 主编排的情况下,文档页 AI 已能跑通第一闭环
- 当前过渡 adapter 已具备“模型 / profile / 工具”统一能力面出口
阶段 4:切文档页 AI 默认执行路径
目标
让文档页 AI 在产品可见行为上从 Hermes 兼容链过渡到 mnote-cli host / adapter;当前已跑通的 openai-agents-python 链只保留为外置 adapter 行为基线。
需要完成
- 历史基线中,文档页 AI panel 曾默认走
openai-agents-python - 长期口径中,文档页 AI panel 默认应走
mnote-clihost / adapter - 标题改名沿
page.head.updateTitle回写 - 正文改写沿
page.body.save回写 - 主编辑区 island 稳定回显 AI 结果
- 审核与继续编辑行为维持在主编辑区内完成
- Hermes 仅保留 fallback 开关
- 页面 AI 设置页显示正式
model_key下拉,而不是自由文本底层 model - 页面 AI 设置页显示当前
profile - 页面 AI 设置页显示当前 scope 已注册工具列表
- 页面 AI 设置页显示当前
resolved_combo / resolved_runtime_model作为调试信息,而不是产品主键
完成判定
- 可以明确说“AI 已正式进入当前页主编辑区主链”
- 可以明确说“页面 AI 的模型 / 设定 / 工具状态对用户是可见且可解释的”
阶段 5:扩展结构化知识写链
目标
在文档页最小闭环稳定后,再向更完整的 Phase 7 目标扩展。
需要完成
summary nodeai_note nodereference edgePDF / Book -> kernel index- 对这些写链补齐 trace / audit / rollback / evidence
完成判定
Phase 7才能开始被描述为“进入结构化知识写链阶段”
10. Hermes 的过渡策略重写
当前不建议立刻删除 Hermes,但必须缩边界。
10.1 继续保留的价值
- 承接现有文档页 AI 运行链
- 作为
mnote-clihost 与其他外置 adapter 的回归对照 - 作为 fallback 开关
- 承接非主链实验场景
10.2 明确禁止的事情
- 不让 Hermes 成为文档页长期主编排
- 不让 Hermes memory 取代 page aggregate / kernel-aware retrieval
- 不让 Hermes 工具名继续成为长期产品契约
- 不让 Hermes 默认 shell/fs 能力绕过 Rust runtime 写业务数据
10.3 最终可接受状态
最终可接受状态有两种:
- Hermes 退化为非主链实验平台 / 外置 agent adapter
- Hermes 完全下线,只保留
mnote-cli+ Rust runtime,并按需接入openai-agents-python/ Codex 等外置 agent adapter
11. 非目标
本稿当前不覆盖:
- 完整 AI 平台产品化
- 完整 suggestion review 产品壳
- 多平台消息网关
- 通用桌面 agent / shell agent
- mindmap AI 主线
- OnlyOffice AI 主线
- 完整长期记忆产品壳
这些都不是当前 Phase 7 的第一任务。
12. 当前冻结口径
当前冻结如下:
本稿原始判断里,
openai-agents-python曾被写成长期推荐编排层;该口径现已失效。当前长期口径应以v4为准:mnote-cli是唯一长期 agent 执行面,Rust runtime 仍是唯一事实源与真执行面;openai-agents-python、Hermes、Codex 都只是可插拔外置 agent。
但当前
Phase 7的第一交付物不再定义为“完整 AI 平台”或“完整结构化知识写链”,而是“文档页 AI 直接进入主编辑区,并沿page aggregate command family正式回写”。
Hermes可以继续作为过渡平台与实验平台存在,但不再作为文档页 AI 的长期语义中心。openai-agents-python也只保留为外置 adapter。
页面 AI 的模型真源固定为
model_key,resolved_combo / resolved_runtime_model只作为运行时调试信息;profile前端可设但由后端持有真源;tool registry 必须前端可见。
一句话收口:
当前如要先做
Phase 7,正确起点不是继续抽象谈 kernel-aware AI,而是先让 AI 真正沿page aggregate -> 主编辑区 island这条当前主线闭环。