Compare commits
13
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 weichen
|
95a7c111d5 | ||
|
weichen
|
95e5c9d307 | ||
|
weichen
|
228cf74468 | ||
|
weichen
|
0f5df5147e | ||
|
weichen
|
b3ca409cfc | ||
 weichen
|
4a3ca0eb5a | ||
|
weichen
|
9a46785ee0 | ||
|
weichen
|
cc54cdac76 | ||
|
weichen
|
b37f45ff61 | ||
|
weichen
|
077ebdf184 | ||
|
weichen
|
e986a85436 | ||
|
weichen
|
19b77a28bc | ||
|
weichen
|
3a82eec74c |
@@ -192,10 +192,10 @@ sha256/mtime 清单复核，不可当作完整快照。
|
||||
|---|---|---|---|
|
||||
| E1（P0 快修）✅ | F1 委派回传、F2 reasoning_split、F5 并行工具、F3 依赖层 | 无 | **已完成（2026-10-10）**：Agent-Native #42/#43/#44 + Backend #127 + Dev PR（任务卡 feature/agent-e1-parallel-fixes）。验证：F2 实测正文 0 泄漏、F3 sandbox 实测 IMPORTS-OK、F5 实测同回合并发重叠；eval 对照工具失败 19→11，未核实数字 7→12（E3 待做，见任务卡） |
|
||||
| E2 | R1 Claude 原生协议 + 缓存观测 | E1（F2 同类协议改动可同批） | dmxapi 需充值 |
|
||||
| E3 | D4 证据账本 + 数字闸门 | 无（接质量计划 P5） | 与 P5 事实一致性检查合流 |
|
||||
| E4 | R2 角色路由 + D5 画像 | E2 | 设置与画像面 |
|
||||
| E5 | R3+R4 路由 A/B 与升级规则 | E2–E4 | 出选型报告 |
|
||||
| S0（仅记录） | §4 工作区沙箱设计定稿为独立实施任务 | 用户批准启动 | 本文即主记录 |
|
||||
| E3 ✅ | D4 证据账本 + 数字闸门 | 无（接质量计划 P5） | **已完成（2026-10-10）**：Backend #130、Dev #311（任务卡 feature/agent-e3-evidence-gate）。标注感知豁免（分句判定）+ 两轮修正（变化才二拦）+ base.deliverables v6 数字溯源规则 + 子代理引用格式；eval 对照未核实数字 12→5（未标注 3）、工具调用 93→63 |
|
||||
| E4 ✅（R4+账本） | R2 角色路由 + D5 画像 | E2 | **R4 与账本已完成（2026-10-11，MiniMax 版）**：Backend #131–#134、Dev #315（任务卡 feature/agent-e4-escalation-ledger）——滑窗失败提醒（端到端日志实证）、检索空命中提醒、source_id 账本（83 标记）；Claude 角色档按模型指示暂缓；eval 四轮对照无恶化 |
|
||||
| E5 ✅（R3 部分） | R3+R4 路由 A/B 与升级规则 | E2–E4 | **R3 已完成（2026-10-10，MiniMax 家族版）**：Dev #313（任务卡 feature/agent-e5-model-ab）三臂对照（hs / 全M3 / hs+M3轻量）——建议默认 chat=MiniMax-M3（未标注编造 1、失败最少、时长持平、单价减半）；R4 升级规则仍待做 |
|
||||
| S0-1 ✅ | §4.4 首个落地形态：冻结基底 overlay + CAS 回收 + 变更摘要（--exec-workspace overlay） | 用户 2026-10-11「继续完成下一步」 | **已完成（2026-10-11）**：Backend #135/#136、Dev #318（任务卡 feature/agent-s0-workspace-overlay）——bwrap 集成 3 + live 端到端（失败零落地/新增/修改/-ws 清理）；S0-2（fs 联合读/任务级工作区/封存）待授权 |
|
||||
|
||||
## 6. 与既有规划的关系
|
||||
|
||||
|
||||
@@ -0,0 +1,505 @@
|
||||
---
|
||||
title: Generative UI research and plugin proposal
|
||||
date: 2026-10-10
|
||||
type: feat
|
||||
revision: r1
|
||||
product_contract_source: user-request-and-current-source
|
||||
---
|
||||
|
||||
# Generative UI 调研与插件方案
|
||||
|
||||
确认状态：**三项关键取舍已由用户裁定（2026-10-11，见文末"用户裁定记录"）**；全文随发布 PR 评审。推进状态：方案成稿并进入发布评审；原型、业务实现、运行验收、部署均为 **NOT_RUN**。
|
||||
来源：2026-10-10 用户请求——先调研参考与仓库，再判断能否加入本系统，给出可随时启禁的插件方案。
|
||||
负责人：裁定与验收 weichen（用户）；方案整理与执行 Agent；更新时间：2026-10-11。
|
||||
本文是唯一主记录；任务卡引用本文。文内路径除相对链接外，均相对 Agent-System-Dev 根目录。
|
||||
用户授权本轮调研、思考和完整方案准备，不表示已批准本文的产品取舍、原型试验或后续实施。
|
||||
|
||||
## 结论与目标
|
||||
|
||||
**可以加入，而且当前系统已有合适基础。推荐新增独立的 Generative UI 插件，配合小范围、通用的宿主能力扩展。**
|
||||
Agent 负责决定何时需要页面、采用哪些组件、怎样排列内容与交互；宿主负责设计系统、身份权限、事实读取、渲染、动作执行和恢复。
|
||||
页面结构可以每次不同，组件实现与权限规则保持确定。
|
||||
|
||||
首选路线：复用现有 Agent-Native、Go Backend、Core UINode 和 React UI；以版本化 Surface 表达可保存、可更新的动态页面。
|
||||
借鉴 A2UI 的组件目录与数据/交互协议，以及 json-render 的 catalog/registry 分工；首期不要求替换现有运行时或另起 Node 服务。
|
||||
外部 renderer 是否比扩展现有 UIRenderer 更划算，由受控试验决定，当前没有实际集成证据。
|
||||
|
||||
建议先覆盖对话产出的完整阅读/分析页面，再加入交互表单与任务工作页，最后扩展到项目工作区。
|
||||
登录、项目切换、停止执行、设置和审批保留可预测的宿主入口；业务主内容可以动态组织。
|
||||
该演进顺序已于 2026-10-11 获用户确认：首试点为对话中的完整分析页（场景 1）；它不把长期目标缩减为“几个固定卡片模板”。
|
||||
|
||||
插件首期采用**可信 Go 编译扩展 + 声明资产**（该交付方式已于 2026-10-11 获用户确认）：功能开关实时生效，安装/升级插件代码需要重新构建组合二进制并重启。
|
||||
“功能随时启禁”与“无需重启安装任意插件包”是不同能力；用户未把后者列为本期硬要求，sidecar 路线保留为备选并随实际需求重评。
|
||||
|
||||
---
|
||||
|
||||
## 外部调研
|
||||
|
||||
调研日期：2026-10-10。引用来自官方文档或官方源码，说明的是当场文档/仓库状态；本轮未安装或运行这些项目。
|
||||
不以 star 数量、演示视频或作者自述推断生产可靠性；正式选依赖时仍须固定版本、审许可证与传递依赖并进行组合验证。
|
||||
|
||||
### Generative UI 的不同层次
|
||||
|
||||
| 类型 | Agent 实际决定什么 | 与本目标的关系 |
|
||||
|---|---|---|
|
||||
| 固定工具结果组件 | 调用什么工具、向预制组件传什么参数 | 适合起点，但单独使用不足以实现自由组织页面 |
|
||||
| 声明式生成页面 | 组件树、布局、内容重点、数据绑定与动作引用 | 本方案主路线；页面可变，执行边界明确 |
|
||||
| 可持续交互的生成工作区 | 页面随用户输入、任务进展和数据版本变化 | 本系统中期目标；需要状态、版本、权限与回放协议 |
|
||||
| 生成 HTML/JS/React 小应用 | 连组件实现和程序逻辑一起生成 | 表达力高；需独立沙箱、资源与网络边界，后续单独评估 |
|
||||
|
||||
运行时按任务生成页面，与开发期间让 Agent 写前端代码不同。后者交付后仍可能是固定页面。
|
||||
AG-UI 这类事件协议、A2UI 这类 UI 描述协议、MCP Apps 这类嵌入式应用契约解决的层面也不同，不能互相替代。
|
||||
|
||||
### 核心参考与采用判断
|
||||
|
||||
| 参考/官方仓库 | 能力定位 | 本系统采用判断 |
|
||||
|---|---|---|
|
||||
| [A2UI](https://github.com/a2ui-project/a2ui) / [文档](https://a2ui.org/) | 声明式组件、Surface、数据绑定和用户动作；组件目录可映射自己的设计系统 | 最值得借鉴的协议。Go 可产生 JSON，前端可保持自身 UI。是否严格实现某版本，留给独立适配器与一致性测试 |
|
||||
| [json-render](https://github.com/vercel-labs/json-render) / [Catalog](https://json-render.dev/docs/catalog) | 为 AI 定义组件与动作词汇，由 registry 绑定真实 React 等实现 | 最值得试验的 renderer 依赖；可将目录映射到 @ui。不能未经比较就再建一套状态和渲染系统 |
|
||||
| [CopilotKit](https://github.com/CopilotKit/CopilotKit) / [AG-UI](https://github.com/ag-ui-protocol/ag-ui) | Agent 与应用之间的流式事件、状态与交互集成 | 参考工具 UI、共享状态和事件设计；现有系统已有 runtime/SSE/store，首期不整体替换。AG-UI 本身不定义完整页面布局 |
|
||||
| [Vercel AI SDK](https://github.com/vercel/ai) / [Generative UI 指南](https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces) | 工具调用与结果驱动组件渲染，应用开发者实现组件 | 很好的最小入门与工具组件范例；不是整页自主规划的全部方案，不为此把 Go 后端迁到 TypeScript |
|
||||
| [assistant-ui](https://github.com/assistant-ui/assistant-ui) / [生成 UI 文档](https://www.assistant-ui.com/docs/tools/generative-ui) | 除工具 UI 外，当前有 present 工具生成组件 JSON 树、动作注册与流式 props | 借鉴显式 present 入口；不必替换聊天壳。官方明确 renderer 不按 props schema 执行校验，仍需自己的运行时验证 |
|
||||
| [Thesys OpenUI](https://github.com/thesysdev/openui) / [现行文档](https://www.openui.com/docs) | OpenUI Lang、parser、React 流式 renderer 与自定义组件；Crayon 旧仓已转向该仓 | 作为表达能力/流式体验备选。可用自己的模型；开源 runtime 与可选 OpenUI Cloud/Gateway（原 C1）分开评估，不把开源许可等同托管服务条款 |
|
||||
| [Tambo](https://github.com/tambo-ai/tambo) | 注册 React 组件与 schema，Agent 选择组件并更新状态；包含后端编排 | 设计参考。官方已公告 Tambo Cloud 将于 2026-10-31 关闭 API，2026-11-30 删除托管数据；开源可自托管，但不建议作为新系统的默认托管依赖 |
|
||||
| [MCP Apps](https://github.com/modelcontextprotocol/ext-apps) | 工具返回交互式 UI resource，宿主通过桥接在隔离容器内嵌应用 | 适合未来插件小应用与外部工具 UI 互通；它不自动生成页面，也不代表现有 Agent-Native MCP 工具支持已具备 Apps 宿主能力 |
|
||||
|
||||
A2UI 官方主页当前列出 v0.9.1 为 current、v1.0 为 candidate；它的 [catalog 指南](https://a2ui.org/concepts/catalogs/) 建议成熟应用围绕现有设计系统定义目录。
|
||||
已有[官方 React renderer](https://a2ui.org/reference/renderers/)；这证明有实现可供验证，不证明该版本已经在本系统构建/运行通过。
|
||||
不能混合旧 v0.8 的消息字段和新版本字段后声称协议兼容。
|
||||
json-render 的 [registry 文档](https://json-render.dev/docs/registry) 将组件实现与动作处理留在应用侧，适合本系统“生成数据、宿主执行”的边界。
|
||||
Tambo 的停服状态以[官方仓库公告](https://github.com/tambo-ai/tambo#readme)为依据，旧教程中的 Cloud 快速接入方案已不适合作为新项目默认选型。
|
||||
|
||||
许可初筛：A2UI、json-render、AI SDK 为 Apache-2.0；CopilotKit、AG-UI、Tambo、assistant-ui、OpenUI 的当前仓库为 MIT，具体包及附带资产在锁版本时再核对。
|
||||
[MCP Apps LICENSE](https://github.com/modelcontextprotocol/ext-apps/blob/main/LICENSE) 处于 MIT 向 Apache-2.0 迁移，部分旧贡献保留 MIT，文档另有 CC-BY-4.0，不能统一简写为“任选双许可”。
|
||||
当场仓库活动检查未发现上述候选被归档；活动不等于稳定或维护承诺，Tambo Cloud 公告说明需要把代码可用与运营持续性分开判断。
|
||||
AI SDK 的 [RSC 路径仍为实验状态](https://ai-sdk.dev/docs/ai-sdk-rsc/overview)，首期没有理由为此将现有 Vite 应用迁到 Next.js/RSC。
|
||||
|
||||
### 三条可行路线
|
||||
|
||||
| 路线 | 优点 | 主要代价 | 结论 |
|
||||
|---|---|---|---|
|
||||
| A. 原生 UINode/Surface 插件 | 复用权限、Agent、事件流、设计系统与部署形态；无强制新服务 | 要补齐 schema 校验、版本、交互和启禁 | **首选** |
|
||||
| B. json-render/A2UI renderer 嵌入插件 | 利用现成组件目录、绑定和流式能力 | React 集成之外还需 Go 校验、动作授权、版本与状态适配；可能重复 UIRenderer | 受控试验中的挑战方案；显著减少总维护成本才采用 |
|
||||
| C. 隔离的代码生成小应用或整套平台 | 表达力最高，适合复杂专用工具 | 沙箱、网络、会话桥、制品供应链、依赖升级和审计面明显增加 | 后续独立方向，不作为首个增量 |
|
||||
|
||||
路线 A 不是从零重造外部框架：首期范围只包含本系统用得到的有限词汇、快照、授权动作和页面容器。
|
||||
若需求发展为大量复杂表单、表达式和跨平台 renderer，重新比较 B；不要不断扩展内部 DSL 以维持最初选型。
|
||||
|
||||
---
|
||||
|
||||
## 当前系统的可行性依据
|
||||
|
||||
以下为 **SELF·源码级观察**，不是运行能力验收。审计基线为 Dev `104a4142c918f7325d3a78e3e6e270e46739baea`。
|
||||
|
||||
| 组件 | 固定 SHA |
|
||||
|---|---|
|
||||
| Core | `a253a40b8e5563119b00c4e71fb61fe0d11d6d6a` |
|
||||
| Backend | `017b40f76156905eabe8323ae2bfe800f47fb8bd` |
|
||||
| Frontend | `339a9ebc2d827eaf990346b91d36f4ad5a13f090` |
|
||||
| UI | `76d6633736a7abb36ac1ecca42fe4e6f120d0558` |
|
||||
| Agent-Native | `c348441691e8bdab784a03aa9be64d53dacff341` |
|
||||
| Documents | `3a82eec74ce6b2b548a7a943f8382d64df14316e` |
|
||||
|
||||
| 当前源码事实 | 依据（上述固定版本） | 设计影响 |
|
||||
|---|---|---|
|
||||
| React 19、Vite 6；Core 已有 16 种有限 UI 词汇 | `modules/frontend/package.json`；`modules/core/ui.go:9-50` | 不必另换技术栈或设计系统 |
|
||||
| UIRenderer 能画 table、compare、tabs、timeline 等 | `modules/ui/src/UIRenderer.tsx:22-35` 及各 case | 动态选择和组合已有组件有基础 |
|
||||
| submit_card 的 body 仍是字符串，包装成 Markdown | `modules/backend/internal/runtime/hostbridge.go:128-148` | 当前 Agent 还不能通过这个工具输出任意结构化页面 |
|
||||
| form 没有提交回传，节点按数组 index 作为 key；table 行 action 未渲染 | `modules/ui/src/UIRenderer.tsx:22-29,73-95,184-200` | 有类型不等于完整交互；稳定 nodeId、草稿与动作桥必须补 |
|
||||
| 卡片 body 渲染未传 onAction | `modules/ui/src/ActivityCardView.tsx:66-74` | 不能只把按钮塞进 body 就声称接通动作 |
|
||||
| cardsvc 有保存与事件发布；运行管理有卡片端口 | `modules/backend/internal/cardsvc/cardsvc.go:73-139`；`internal/runmgr/runmgr.go:637-715` | 复用其分层与持久化后发布原则，避免第二条无审计通道 |
|
||||
| 上下文回灌仅取卡片顶层 markdown/kv | `modules/backend/internal/ctxasm/ctxasm.go:373-411` | 需要递归语义投影；否则下一轮 Agent 不知道页面里有哪些内容 |
|
||||
| SSE 服务端先订阅再重放并按 seq 过滤；前端没有完整拒旧/切会话保护 | `modules/backend/internal/server/server.go:375-429`；`modules/frontend/src/api.ts:189-194`、`store.ts:375-414` | Surface 投影须明确 seq、revision 与 generation 防卫 |
|
||||
| enabled 写入 owner+plugin grants，主要被 ListFor 消费 | `modules/backend/internal/server/platform_api.go:130-142`；`internal/store/platform.go:13-32`；`internal/plugins/host_v2.go:160-175` | 现有“禁用”不能当作请求/执行禁用；新能力必须服务端闭环 |
|
||||
| ESM loader 存在，但未找到实际页面挂载调用；桥未接主认证/命名事件处理 | `modules/frontend/src/pluginHost.ts:9-13`；`modules/ui/src/pluginSdk.ts:9-25` | 首期不能依赖现成 ESM 页面宿主；动态 import 也不是代码沙箱 |
|
||||
| 公开扩展可注册命令 handler，命令可 exposeAsTool | `modules/backend/pkg/extension/extension.go:34-48`；`internal/cmdbus/cmdbus.go:47-64`；`internal/app/app.go:417-422` | 插件命令可供现有 Agent 调用，无须新增任意 native executor 插口 |
|
||||
| 公开 Host 缺会话/任务完整上下文及 Surface 发布端口 | `modules/backend/pkg/extension/host.go:26-68` | 需申请最小公开契约，不能从插件导入 Backend internal |
|
||||
|
||||
现有 context assembler 可复用消息、附件、可见知识和用户偏好；不等于已经自动读取所有项目背景。
|
||||
跨会话读取仍须满足现有开关、同项目/租户与隐私限制（`internal/runmgr/runmgr.go:934-1005`）；生成页面不能扩大数据可见范围。
|
||||
当前 `Host.Complete` 是简单 prompt→string，且主要走 owner 路由，不能当作已有 project 级结构化/流式生成接口。
|
||||
|
||||
本轮阅读了规划索引、基座路线图、插件 v2 与扩展兼容相关记录；没有发现既有 Generative UI 专项主记录。
|
||||
2026-10-10 本轮查询 Dev/Documents/Core/Backend/Frontend/UI 的 open PR，结果均为空；这是当时快照，后续开工须重验。
|
||||
规划索引中的 Agent 质量、模型路由、RDM 扩展仍有剩余范围，不因没有 open PR 就视为全部完成或不冲突。
|
||||
|
||||
---
|
||||
|
||||
## 需求与用户体验
|
||||
|
||||
### 需求表
|
||||
|
||||
所有实施需求当前为候选，待人工确认。符合度“需调整后符合”表示本方案指出了必需宿主改动，不表示已实现。
|
||||
|
||||
| ID | 需求与来源 | 符合度 / 优先级 | 可判定验收条件 | 处理与依赖 |
|
||||
|---|---|---|---|---|
|
||||
| R1 | 根据内容、上下文、任务、项目背景自主组织页面（用户） | 需调整后符合 / P0 | 同一组事实分别完成“比较、风险分析、进度查看”，生成不同且合适的结构；不是同模板换标题 | 纳入试点；U1/U3/U4 |
|
||||
| R2 | 以插件封装，随时启禁（用户） | 需调整后符合 / P0 | 禁用后 UI、直接 API、旧按钮、在途发布均受控；原有系统仍可用；重启后保持禁用 | 纳入首期；U2/U3/U4 |
|
||||
| R3 | 页面可追溯事实与来源（本系统约束） | 符合 / P0 | 数据值来自授权数据引用；分析结论标为生成判断；能定位材料与版本 | 纳入首期；U2/U3 |
|
||||
| R4 | 使用本系统设计系统、易用且可访问（DESIGN） | 符合 / P0 | 令牌/动效/折叠守护通过；键盘与窄屏可完成主要流程；唯一预览落位 | 纳入首期；U4 |
|
||||
| R5 | 页面可保存、刷新恢复、版本可解释（长期工作流） | 需调整后符合 / P0 | 刷新恢复已保存视图；同版本可确定渲染；断线、旧帧与切项目不串页 | 纳入首期；U2/U4 |
|
||||
| R6 | 用户继续修改页面，Agent 理解当前结构（用户目标的闭环） | 需调整后符合 / P0 | “改为对比、突出风险”生成新 revision；上下文包含结构、来源与已确认用户输入 | 纳入首期；U3/U4 |
|
||||
| R7 | 动态表单和动作，沿用权限与审批（扩展交互） | 需调整后符合 / P1 | 表单可提交、校验、重试；旧 revision/越权/重复动作受控；必要审批不能由模型伪造 | 后续增量；U5 |
|
||||
| R8 | 任务/项目工作区随阶段组织（用户长期目标） | 需调整后符合 / P1 | 当前任务可组织计划/产物/待决策信息；项目聚合符合跨会话读取权限；固定布局可恢复 | 后续增量；U6 |
|
||||
| R9 | 外部协议可演进，禁用不丢历史（可维护性） | 符合 / P1 | 固定 schema/catalog/插件版本；不兼容时静态/文本降级；旧动作不自动重放 | U2/U7 |
|
||||
| R10 | 有真实收益与成本证据（交付规范） | 符合 / P0 | 对照固定 UI 的任务成功率、耗时、事实错误、延迟和 token 成本；真实模型结果可复核 | U1/U7；当前 NOT_RUN |
|
||||
|
||||
### 三个试点场景
|
||||
|
||||
1. **调研和文档分析页**：比较多个方案时，Agent 组织“结论→对比表→证据→风险”；用户改问实施顺序后，调整为阶段与依赖。数据与判断分开，来源能打开原工件。
|
||||
2. **当前任务工作页**：需求阶段突出待澄清项，执行阶段突出步骤和产物，验收阶段突出验证结果与缺项。完成状态取自真实任务记录，模型不能画一个绿色标记就更改任务状态。
|
||||
3. **方案选择和需求表单**：Agent 根据缺失信息组织输入项；用户填写后形成明确的结构化输入，再触发下一轮。表单提交不自动批准其后所有业务操作。
|
||||
|
||||
首个完整增量以场景 1 为主；保留场景 2/3 的契约扩展空间，但不要求同时交付所有交互。
|
||||
普通文本回答仍是有效结果；没有可视化价值时 Agent 应保持文本，不强行生成页面。
|
||||
|
||||
### 页面落位与自主程度
|
||||
|
||||
对话中的卡片是生成页面的入口与简短摘要，完整页面进入现有预览位置的 Surface 模式；全屏是同一实例的放大。
|
||||
预览区关闭时，用户仍能从对话入口打开或在对话中继续操作，遵守 DESIGN 的“右栏收起零功能缺失”。
|
||||
之后的项目工作区只是同一 Surface 的另一种打开入口，不复制另一套事实与状态。
|
||||
可以保留多份页面，活动预览只有一个；新结果不抢占用户当前打开的其他对象。同一 Surface 的入口聚合到同一实例，用户从对话引用选择历史页面。
|
||||
|
||||
建议提供三档产品行为：关闭；按需生成；自动建议/生成。
|
||||
首期默认关闭，启用后按需触发；用户明确请求页面时直接生成，Agent 在复杂比较/时间线等任务中可自主选择组件与结构。
|
||||
自动触发只监听明确任务阶段/材料完成等语义事件，后续增量再开启；不按每个 token 或每条 SSE 事件重排页面。
|
||||
用户可以固定布局、切回原视图、重新组织；“固定布局”冻结结构，授权范围内的数据仍可更新，需显示数据时间。
|
||||
用户正在输入、选择或执行动作时，结构更新暂存并提示应用，不挪动焦点或覆盖草稿。
|
||||
|
||||
---
|
||||
|
||||
## 架构与关键决策
|
||||
|
||||
### KTD1. 插件策略与宿主执行分离
|
||||
|
||||
插件拥有组件使用策略、生成提示、布局选择、schema 修复策略、试点场景与质量评估。
|
||||
宿主拥有授权上下文、持久化、稳定渲染容器、请求鉴权、事件序列、动作执行和插件启禁。
|
||||
通用组件实现归 UI；契约归 Core；前端投影与导航归 Frontend；Backend 实现受限公开接口。
|
||||
新目录/仓库位置建议为独立 Generative UI 组件仓，在 Dev 固定组合中引用；正式建仓和最终名称待实施前确认。
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A[用户任务与展示偏好] --> B[既有 Agent Runtime]
|
||||
C[宿主授权上下文与组件能力] --> B
|
||||
P[Generative UI 插件策略与命令] --> B
|
||||
B --> D[插件 present 命令：声明式页面]
|
||||
D --> E[宿主校验与 Surface 服务]
|
||||
E --> F[保存快照与事件]
|
||||
F --> G[Frontend 唯一状态投影]
|
||||
G --> H[SurfaceHost 与 UI Renderer]
|
||||
H --> I[用户交互]
|
||||
I --> J[宿主动作校验与命令总线]
|
||||
J --> B
|
||||
K[插件启禁与资源权限] --> C
|
||||
K --> E
|
||||
K --> J
|
||||
```
|
||||
|
||||
### KTD2. 复用现有 Agent，不增加独立 UI 模型调用
|
||||
|
||||
首选由当前工作 Agent 根据插件提供的能力目录，通过公开命令的 `exposeAsTool` 生成并提交页面规格。
|
||||
插件命令可概念性分为“读取可用展示能力/上下文”“提交或替换页面”“恢复原视图”；准确命名在接口评审中确定。
|
||||
页面规格由主 Agent 作为工具参数产生；插件负责校验与发布编排，无需默认再调用一次 `Host.Complete`。
|
||||
工具返回已接受的 Surface/revision 与语义摘要，或者带字段路径的有限校验错误；后者允许原 Agent 至多重提一次。这会增加原回合的模型轮次，必须计入成本，不能宣称零额外 token。
|
||||
因此插件可以自主组织页面，而不接管主 Agent 的对话循环、模型凭据或任务执行权。
|
||||
后续只有真实评测显示收益，才加入专用 UI planner 或轻量模型修复；届时单独定义 project 级模型路由、预算与取消接口。
|
||||
|
||||
### KTD3. Surface 是有版本的呈现产物
|
||||
|
||||
方向性数据模型（不是已实现接口）：
|
||||
|
||||
| 层 | 必需内容 | 权威来源 |
|
||||
|---|---|---|
|
||||
| 身份信封 | surfaceId、owner、projectId、conversationId、sourceRunId、pluginId | 服务端分配/从当前请求绑定；模型不能自报 owner |
|
||||
| 兼容标识 | schemaVersion、catalogVersion、pluginVersion、rendererCompatibility | 已安装组件与宿主协商 |
|
||||
| 版本 | revision、baseRevision、contextVersion、activationEpoch | 服务端事务与当前授权状态 |
|
||||
| 页面 | title、稳定 nodeId、受限 layout、UINode 内容及结构 | 模型提议，服务端验证 |
|
||||
| 数据 | resourceRef、源版本、字段白名单、读取时间 | 宿主解析后的授权数据 |
|
||||
| 交互 | 服务端保存的 action binding、参数 schema、执行级别 | 命令目录与当前授权；模型仅引用允许动作 |
|
||||
| 回放 | semanticText/结构摘要、来源、生成用途、静态降级文本 | 服务端递归投影为主，不能只信模型自述 |
|
||||
|
||||
首期采用完整、经过校验的快照原子替换，不渲染半截 JSON，不把流式 token 当作结构更新。
|
||||
revision 单调递增，更新必须带 baseRevision；版本冲突拒绝并返回当前版本，不自动覆盖他人更新。
|
||||
发布以当前身份、插件、sourceRunId、toolCallId/发布请求 ID 建幂等键，重复工具结果返回已保存 revision，不能生成重复页面；相同键但不同规格拒绝。
|
||||
复杂的流式 patch、表达式求值和跨页面组件引用均后置；若后续引入 patch，必须保留同样的原子性与版本检查。
|
||||
现有卡片保存 Surface 引用与文本摘要，不把一份可交互页面同时复制进卡片 body、工件和工作区三处。
|
||||
|
||||
持久化建议增加宿主通用 Surface 及 revision 记录，支持现有 SQLite/PG 档位；按 owner/project/conversation 建权限索引。
|
||||
页面快照、最小 action binding 与待发事件在同一事务落盘，再由宿主事件管道发布；发布失败靠持久事件或重建快照恢复，不能只依赖内存总线。
|
||||
业务实体仍由原业务服务维护，Surface 不成为项目/任务事实的第二份数据库。
|
||||
新表采用增量迁移，默认关闭功能时不影响老路径；回退应用不删除表和用户产物。保留周期沿用所属会话/工件策略，最终清理策略随数据契约评审，不在开关中隐式删除。
|
||||
|
||||
### KTD4. 上下文是授权后的事实快照
|
||||
|
||||
宿主根据当前身份和请求，提供任务目的、当前会话摘要、项目允许读取的背景、指定工件、相关检索结果、用户展示偏好与允许动作目录。
|
||||
浏览器只提供关注对象 ID 和偏好，不能提交可信权限声明或任意数据库查询。
|
||||
先按权限过滤再裁剪；只按当前任务相关度取必要字段；不直接将整个项目、原始系统提示或敏感凭据塞入模型。
|
||||
材料与工具结果作为不可信数据处理，不能覆盖组件目录、开关或动作权限；页面内容里的指令不能自行触发后续动作。
|
||||
上下文快照记录源版本与裁剪情况；缓存必须包含身份、权限版本、项目/会话、源版本、catalog 和配置，不按问题文本跨用户复用。
|
||||
已有跨会话读取限制保持有效；缺少授权时只生成当前会话范围的页面，并明确范围。
|
||||
|
||||
事实字段尽量采用宿主数据绑定，展示值由服务端解析；模型生成的解释、建议和风险判断显式属于分析内容。
|
||||
快照记录完整来源集合，包括自由文本分析的来源。读取/导出/回放时任一来源权限失效，首版拒绝整份旧快照并提供重新生成入口，不能只隐藏引用链接而继续显示泄露内容。
|
||||
下一轮上下文提供经过权限复核的结构摘要、来源和确认过的交互结果；不只回灌 markdown/kv，也不把前端未提交草稿当作用户指令。
|
||||
禁用插件时不再注入生成策略/动作能力；历史语义内容按正常授权保留为普通文本上下文。
|
||||
|
||||
### KTD5. 组件目录约束表达，不固定页面模板
|
||||
|
||||
首期选取已有 section、markdown、kv、list、table、compare、timeline、steps、chart-lite、doc-ref；需要时扩展受控 row/grid 布局。
|
||||
每个节点必须有稳定 ID；组件目录定义 props、嵌套、数据类型和支持的动作，禁止任意 CSS、脚本、eval、远程组件 URL。
|
||||
只允许语义尺寸/密度/强调枚举，映射 @ui tokens；新视觉规则按 DESIGN 与 UI gitlink 组合变更评审。
|
||||
渲染器采用既有 safeHtml、Collapsible 和 motion 原语；表格提供溢出与分页/截断提示，不能静默丢数据。
|
||||
未知组件或版本产生可见降级原因与文本视图；未知动作一律拒绝。不能沿用“未知节点静默消失”作为新 Surface 成功状态。
|
||||
|
||||
初始试验上限建议：每页 200 节点、8 层嵌套、256 KiB 规格、单表首屏最多 100 行；值为待测的资源预算，不是既有性能承诺。
|
||||
同时限制字符串、数据总量、图表点数、解析时间和外部资源；图片/链接沿用宿主来源策略。
|
||||
可访问性检查覆盖标签、标题层级、键盘顺序、焦点、屏幕阅读器状态提示和 reduced-motion；不能只验证 JSON 合法。
|
||||
|
||||
### KTD6. 动作由宿主重新授权
|
||||
|
||||
生成的按钮不是批准。模型只能选择已允许的 action 名称/资源引用，宿主解析为当前 Surface 的 binding。
|
||||
客户端提交 surfaceId、revision、actionId、requestId 与受限表单数据；服务端重新验证当前身份、项目、插件状态、参数、资源版本与命令权限。
|
||||
简单筛选、排序、页签切换留在客户端确定逻辑，不额外调用模型；需要重组织或分析时才进入现有 Agent 回合。
|
||||
业务变更通过既有命令总线和 HITL，表单通过不扩大其授权范围。
|
||||
幂等记录绑定身份、Surface、revision、action 和请求内容；重复点击返回已有结果，未知外部结果先查询，不因超时自动重做。
|
||||
同一 requestId 但不同参数必须拒绝；重试先做当前读权限/启禁检查，再查询已有执行回执，已执行回执不能因资源版本已变化而被当作新动作重放。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 用户
|
||||
participant F as SurfaceHost
|
||||
participant S as 宿主 Surface 服务
|
||||
participant C as 命令总线
|
||||
participant A as 既有 Agent
|
||||
U->>F: 提交输入或点击动作
|
||||
F->>S: revision、action、requestId、data
|
||||
S->>S: 当前权限、启禁、参数、资源版本和幂等检查
|
||||
alt 需要业务审批
|
||||
S->>C: 既有审批流程
|
||||
C-->>U: 展示真实动作与参数
|
||||
else 允许读取或已满足审批
|
||||
S->>C: 执行已授权动作
|
||||
end
|
||||
C-->>S: 确定结果或未知结果状态
|
||||
S-->>F: 动作状态与最新投影
|
||||
S->>A: 必要时追加已确认交互结果
|
||||
A->>S: 新页面提议
|
||||
S-->>F: 已保存且校验后的新 revision
|
||||
```
|
||||
|
||||
### KTD7. 真正可验证的插件启禁
|
||||
|
||||
新插件默认关闭，不沿用现有“缺少 grant 默认 true”的行为。适用关系是安装存在、全局允许、owner 显式启用、manifest 范围与当前资源权限的交集。
|
||||
首期采用实例总开关 + owner opt-in；project 开关可后续新增，不能允许项目设置覆盖实例禁用或扩大 manifest 范围。
|
||||
管理员可以全局禁用；用户仅在管理员允许的范围控制自己的使用。
|
||||
|
||||
| 状态/动作 | 必须发生的行为 |
|
||||
|---|---|
|
||||
| 关闭 | 不贡献可调用工具/提示策略，不启动生成，不接受写页面与动作；原有固定 UI 可用 |
|
||||
| 启用 | 校验组件兼容与配置，建立新的 activationEpoch，按请求授权能力；不重放旧动作 |
|
||||
| 禁用请求成功返回 | 先持久化禁用并提升 epoch，再通知前端；返回后新请求、旧按钮和旧 generation 的提交都应被拒绝 |
|
||||
| 禁用时有生成在途 | 取消该 owner/plugin 的独立宿主操作，撤销发布资格；提交前再次核对 epoch 并拒绝迟到页面。共享主模型回合继续，不调用 CancelRun 取消整个主任务 |
|
||||
| 禁用时已有动作在执行 | 尚未进入执行的动作拒绝；已提交业务操作按原命令记录收尾，不能承诺撤销既成副作用；结果不明则查询恢复 |
|
||||
| 历史页面 | 权限仍有效时以宿主通用静态渲染/文本查看，动作禁用；资源权限撤销后旧快照也不能继续泄露数据 |
|
||||
| 再次启用 | 重验 schema、来源与权限，创建新 capability/binding；保留产物，不自动执行先前点击 |
|
||||
| 卸载/升级 | 功能停用与代码包移除分开；旧产物靠宿主降级；代码升级走构建兼容验证 |
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> Disabled
|
||||
Disabled --> Enabled: 授权启用且兼容
|
||||
Enabled --> Generating: 当前 Agent 请求页面
|
||||
Generating --> Ready: 校验与事务提交
|
||||
Generating --> Fallback: 无效规格或失败
|
||||
Ready --> Generating: 请求重组织
|
||||
Ready --> Disabled: 禁用并撤销动作
|
||||
Generating --> Disabled: 撤销发布并拒绝旧 epoch 提交
|
||||
Fallback --> Generating: 有限重试或用户重试
|
||||
Fallback --> Disabled: 禁用
|
||||
```
|
||||
|
||||
该状态图描述呈现能力，不等同业务任务状态。历史快照存在不代表插件 Enabled。
|
||||
主 Agent 已收到的生成提示和已发生的 token 成本不能在禁用后收回；下一次能力组装移除插件策略，当前回合即使继续提议页面也会被执行端拒绝并转为文本结果。
|
||||
epoch 核对与页面提交/新动作准入必须共享可证明的事务或串行化边界，不能“先查开关、释放锁、再执行”。禁用返回是准入截止点，截止点前已准入的操作按上表在途语义处理。
|
||||
启禁守卫覆盖发现、命令分发、工具执行、上下文能力注入、Surface 读取/提交与动作；标明归属的能力不能通过另一入口绕过。
|
||||
编译插件是可信代码扩展，不是恶意第三方代码的隔离边界。sidecar 目前继承环境并使用共享 Host token 的现状，不足以承担不可信插件沙箱。
|
||||
首期只补这条能力闭环及共享执行边界；通用热重载原子化、插件市场和所有旧插件资产清理另立任务，不无限扩大本次范围。
|
||||
|
||||
### KTD8. 一个状态所有者，明确恢复规则
|
||||
|
||||
后端是 Surface 与业务状态权威；Frontend store 维护一份投影；UI 只渲染 props 并发出用户事件。
|
||||
表单草稿、页签与展开状态归前端按 surfaceId/nodeId 管理；提交后成为服务器确认的输入，不能同时被模型与组件局部 state 无序覆盖。
|
||||
复用主认证与 SSE 通道，不另用现有未接完整的 pluginSdk EventSource 作为第二所有者。
|
||||
事件绑定会话/项目/Surface 与 seq；前端丢弃过期 seq、旧 revision、旧页面 generation；检测缺口后获取授权快照重建。
|
||||
切项目、退出登录、撤权或禁用立即作废在途请求和可见敏感投影；不同身份不复用浏览器缓存。
|
||||
撤权阻止继续访问和重新加载，不承诺抹去用户此前已合法下载的数据；敏感快照不写入持久浏览器存储。
|
||||
普通 reconnect 不重新调用模型，先恢复已保存的快照；重新生成是用户动作或经允许的策略动作。
|
||||
|
||||
### KTD9. 可演进但不虚报标准兼容
|
||||
|
||||
内部首版使用系统自己的版本化 Surface + UINode 扩展，不能命名为“A2UI 兼容实现”后省略协议测试。
|
||||
未来可加 A2UI 适配器：固定协议版本与目录版本，只支持明确子集，不支持的组件/动作显式报错，不静默损失含义。
|
||||
AG-UI 仅在需要跨 Agent 框架互通时评估事件适配；MCP Apps 仅在需要外部工具应用时评估宿主资源与沙箱能力。
|
||||
三者不作为首期串联依赖；避免为了 Generative UI 同时迁移模型运行、传输与前端框架。
|
||||
|
||||
---
|
||||
|
||||
## 最小宿主改动与插件交付边界
|
||||
|
||||
| 模块 | 建议变更 | 明确保留的职责 |
|
||||
|---|---|---|
|
||||
| Core | Surface/版本/节点 ID/受控布局/动作信封与兼容标识；保持旧 UINode/卡片可读 | 跨仓公开类型权威；同步 Go、TS 及契约快照 |
|
||||
| Backend public extension | 授权 ContextSnapshot、Surface 读写/发布、插件 capability/activation；按需要增加受限上下文投影扩展 | 不暴露 raw DB、完整 session、通用任意 HTTP 或事件发射器 |
|
||||
| Backend internal | 实现上述端口、执行级启禁、事务存储、事件恢复与动作鉴权 | 服务端最终授权与业务事实 |
|
||||
| UI | 稳定节点与受控布局的通用 renderer；表单事件、行操作、无障碍、降级 | 纯展示、token/motion/Collapsible/safeHtml；不持网络状态 |
|
||||
| Frontend | SurfaceHost、单一状态投影、预览落位、开关、结构更新/草稿协调 | 身份、路由、事件、用户输入草稿 |
|
||||
| Generative UI 插件 | prompts/skills、目录选择、present/revise 等命令、生成校验编排、试点策略 | 只消费公开扩展，默认随当前 Agent 生成；无独立任务事实库 |
|
||||
| Documents/Dev | 契约申请、使用说明、评测结论、精确组件组合与索引 | 方案/实现/验证/部署状态分别记录 |
|
||||
|
||||
公开扩展优先使用新增可选能力接口或版本协商，避免给现有必实现 Host 接口直接加方法而破坏所有消费者。
|
||||
修改公开导出时更新 `SurfaceVersion`、`pkg/extension/surface.txt` 与相关兼容快照；Core/UI/Frontend/Backend 的依赖 gitlink 同步验证。
|
||||
已有命令投影可以承载 Agent 工具，因此不申请通用 native executor 注册口作为前置。
|
||||
首期不需要开放任意前端 ESM 注入；插件只输出既有/新批准的通用 UI 词汇。
|
||||
|
||||
如果要求“下载插件包后不重启安装”，则改为隔离 sidecar + 同一 Surface 契约。
|
||||
增加独立身份、最小环境、按插件/owner capability 令牌、健康检查、取消/退出协议、版本升级与回滚；前端仍可用通用 renderer，不必加载任意 JS。
|
||||
这属于另一档交付成本，不应通过当前 `exec.Command` 与共享 token 简单包装后宣称完成。
|
||||
|
||||
---
|
||||
|
||||
## 分阶段计划
|
||||
|
||||
下列为可评审的实施候选，不是已经获准执行的待办。每个增量继续按 `policy/delivery.md` 人工评审；试验结果允许回改选型和范围。
|
||||
功能代码与生产实例本轮不变。近期 U1 具体，其余单元在试验评审后细化精确 API 与数据迁移。
|
||||
|
||||
### U1. 受控价值与选型试验
|
||||
|
||||
- 关联 R1/R4/R10；依赖：已满足——2026-10-11 用户批准试验范围（见文末“用户裁定记录”）；作为独立任务另行启动并评审。
|
||||
- 对象：固定当前组件 SHA，在隔离工作区用合成或获准的脱敏材料，覆盖调研比较、任务概览、需求输入三类。
|
||||
- 方法：先比较“固定 UI/文本”与“原生 UINode 动态组合”；再用少量相同样本比较 json-render/A2UI renderer 接 @ui 的复杂度与缺口。后者是 renderer 选型挑战，不另建全套后端。
|
||||
- 文件范围：专用实验目录、组件契约夹具与评测说明；全部明确为原型，不替换生产路径。
|
||||
- 试验预算：3–5 人日；30 个固定任务、每项至少 2 次模型运行；首轮最多 60 次/方案。费用上限已由用户指定为 **¥200**（2026-10-11）；模型限 MiniMax M3 与 M2.7-highspeed，材料限合成或已脱敏样本；超限即停。
|
||||
- 判据：结构选择确实随目标变化；信息来源可追溯；可通过现有设计令牌渲染；列出外部依赖节省与新增的实际代码/状态维护面。
|
||||
- 停止：出现越权数据、无法限制生成代码执行、超过预算、依赖要求替换既有 runtime，暂停该路线并提交调整。
|
||||
- 产物：A/B 结果、renderer 取舍、失败样本、建议目录与修订版方案；不是生产代码验收。
|
||||
|
||||
### U2. 通用契约、启禁与持久化
|
||||
|
||||
- 关联 R2/R3/R5/R9；依赖 U1 的设计评审。
|
||||
- 文件范围：`modules/core/ui.go`、Core 新 Surface 契约及对应测试；`modules/backend/pkg/extension/`、`internal/plugins/`、`internal/store/`、`internal/server/` 及对应测试/迁移。
|
||||
- 方法：先固定兼容与授权信封，再实现 owner 隔离的 Surface 存储、revision CAS、activationEpoch 和命令执行守卫；能力缺失明确拒绝。
|
||||
- 验证：旧消费者可用；关闭状态下 direct API/工具/旧 action 不绕过；并发更新有一方冲突；写快照后事件发布失败可恢复；SQLite/PG 路径一致。
|
||||
- 完成条件：最小公开契约审过，故障/拒绝路径有证据，插件能通过公开接口保存/读取页面；此时不宣称生成体验完成。
|
||||
|
||||
### U3. 生成插件与上下文闭环
|
||||
|
||||
- 关联 R1/R2/R3/R6；依赖 U2。
|
||||
- 文件范围：独立插件的 manifest、commands、prompts/skills、目录和测试；Backend `internal/ctxasm/` 的通用语义投影、授权快照适配及测试。
|
||||
- 方法：沿用 AddCommandHandler/exposeAsTool；当前 Agent 接收可用词汇和授权快照，产出页面参数；插件校验，宿主原子发布。解析/语义修复最多 1 次，失败回到文本，禁止无限自修复循环。
|
||||
- 验证：同素材换任务得到合适不同结构；伪造数据引用与未知动作被拒；下一轮可以解释并修改之前的 table/compare/tabs；禁用不再注入能力。
|
||||
- 完成条件：真实模型“任务→规格→保存→继续修改”闭环可回放，来源与成本被记录；不另造 Agent runtime。
|
||||
|
||||
### U4. 只读生成页面与可恢复体验
|
||||
|
||||
- 关联 R1/R2/R4/R5/R6；依赖 U2，最终集成依赖 U3。
|
||||
- 文件范围：`modules/ui/src/UIRenderer.tsx` 及测试、通用 Surface 展示组件、`modules/frontend/src/store.ts`、`api.ts`、预览/卡片入口、插件设置及对应组件/浏览器测试。
|
||||
- 方法：稳定 nodeId、布局语义、受控 renderer、唯一 SurfaceHost；加载/失败/回退/来源/重新组织入口；单一 store 校验 seq/revision/generation。
|
||||
- 验证：刷新/断线/切项目/迟到响应；关插件固定界面仍完整；页面未知版本可读；键盘、窄屏、暗浅主题；输入焦点与布局变化规则。
|
||||
- 完成条件：场景 1 可通过真实浏览器完整使用；此增量提供展示和重新组织，业务写动作未开放。
|
||||
|
||||
### U5. 动态表单和动作闭环
|
||||
|
||||
- 关联 R7，依赖 U2/U3/U4；必须先评审本阶段动作范围。
|
||||
- 文件范围：Core 动作/字段 schema、UI 表单与行操作及测试、Frontend 草稿/提交桥、Backend action service/cmdbus 适配及权限/幂等测试。
|
||||
- 方法：输入草稿由宿主管理；服务端绑定 action；必要时进入既有 HITL；失败留在当前页面并保留可恢复输入。
|
||||
- 验证：旧 revision、资源被删、撤权、关插件、双击、超时未知结果、两个标签页同时提交；无审批旁路；用户未提交输入不传给模型。
|
||||
- 完成条件：场景 3 可完成明确读取/决策动作，再逐类批准业务写动作，不能一次开放所有命令。
|
||||
|
||||
### U6. 自适应任务与项目工作区
|
||||
|
||||
- 关联 R8，依赖 U4/U5 的收益与可靠性证据。
|
||||
- 文件范围：Frontend workspace/任务页容器、插件上下文选择与触发策略、Backend 授权聚合适配、相关测试。
|
||||
- 方法：先当前任务，后项目；任务阶段触发有限更新；固定布局/恢复原视图；自动模式单独 opt-in。
|
||||
- 验证：不同阶段突出不同信息；任务事实不能被页面改写；私有会话不泄露；输入时不自动重排；自动触发有预算且不递归自激。
|
||||
- 完成条件：实际任务效率改善，关闭后原工作区完整，跨会话汇总授权能复核。
|
||||
|
||||
### U7. 组合验收、兼容与交付
|
||||
|
||||
- 关联 R2/R5/R9/R10；按每个可交付增量执行，不只在最后一次执行。
|
||||
- 文件范围：各模块相关测试、Documents 使用/评测记录、Dev 任务卡和精确 gitlink 组合；涉及治理脚本才追加治理测试。
|
||||
- 方法：先组件 PR，再组合 PR，固定 Dev SHA+组件 SHA+schema/catalog/model/profile；复放正常、异常、权限、禁用与恢复链路。
|
||||
- 验证：CI `make test`/`make build` 与独立重放；业务智能体改动附真实模型前后对照；本地 SELF 不升级为 GATE。
|
||||
- 完成条件：用户批准该增量、功能与回退均有证据、文档和开关说明完整；是否部署仍是独立授权与运行验收。
|
||||
|
||||
粗估：U1 3–5 人日，U2–U4 首个可靠只读闭环再需约 10–18 人日，U5 约 5–8 人日，U6 约 5–10 人日。
|
||||
这些是范围估计，假设熟悉现有代码且使用可信编译插件；不含人工等待、全量外部协议兼容和不可信插件沙箱，不是交付承诺。
|
||||
|
||||
---
|
||||
|
||||
## 验证与评估
|
||||
|
||||
### 试点评价方法
|
||||
|
||||
采用相同材料、权限、模型/profile、任务和重复次数比较固定 UI/文本基线与生成 UI。
|
||||
分别记录冷启动/缓存、模型时间、验证时间、渲染时间、额外 token 与调用次数；不把缓存命中混作生成加速。
|
||||
默认观测记录规格/目录版本、耗时、字节数、token、错误码和回退原因；原始上下文、输入值与模型全文不进入普通日志，评测原始材料按既有 eval 规则保存在受控环境且不进仓。
|
||||
以下阈值为**建议评审目标**，本轮无实测结果：
|
||||
|
||||
| 维度 | 建议目标/方法 |
|
||||
|---|---|
|
||||
| 任务有效性 | 任务成功率至少不低于基线；选定比较/梳理场景的人类中位完成耗时改善约 20% 才考虑扩大自动模式 |
|
||||
| 事实可靠性 | 验证集中的资源/数值引用可追溯；关键事实错误为 0；分析判断独立标注 |
|
||||
| 规格有效率 | 首次合法页面 ≥90%；最多一次修复后 ≥98%；最终失败 100% 有可用文本降级 |
|
||||
| 延迟 | 浏览器先给确定加载状态；本地校验+渲染 P95 目标 <300ms；模型生成单独统计。显式页面请求的初始展示等待预算为 20s，超时转文字等待/回退并撤销该次发布，不因此中断共享主 Agent 回合 |
|
||||
| 干扰 | 普通文本任务不额外调用 UI 模型；不会每个 token 重排；用户输入与焦点不丢失 |
|
||||
| 开销 | 展示额外 token、调用数、失败重试成本与收益；是否可接受在真实模型对照后决定，不先声称“更快更省” |
|
||||
| 开关正确性 | 禁用成功后所有新副作用入口拒绝；旧 epoch 页面不能提交；保留授权历史与原 UI |
|
||||
|
||||
30 个任务的小试验用于发现问题和决策，不足以证明长期生产可靠率；报告样本量、失败数和每类任务结果，不只报百分比。
|
||||
若收益只体现在“更好看”而任务成功率/效率下降，保留按需模式，收窄场景或停止推广。
|
||||
|
||||
### 必测故障与权限矩阵
|
||||
|
||||
- 正常：同材料不同任务、纯文本无需页面、生成后改布局、来源打开、刷新恢复。
|
||||
- 结构：未知节点、循环/过深结构、超大表格、非法数据类型、畸形 JSON、未知 schema/catalog、非法 URL/脚本属性。
|
||||
- 权限：跨 owner/project/doc 引用、跨会话私有内容、生成后撤权、切账号/项目、直接 API 调用、伪造动作 ID。
|
||||
- 异步：重复/乱序/缺口事件、断线重放、两个标签页、旧 revision、切页后的迟到响应、保存成功但事件未发布。
|
||||
- 启禁：生成前/中/提交前禁用，动作前/审批后/执行中禁用，服务重启，重新启用，兼容版本缺失。
|
||||
- 交互：表单校验、重复提交、业务冲突、输入中更新、取消、失败后保留草稿、外部结果未知不重复执行。
|
||||
- 回退：插件完全缺失、模型不可用、预算耗尽、renderer 出错；固定 UI 和授权文本历史仍可用。
|
||||
- 回归：旧 UINode、卡片、命令、工件预览、侧栏关闭、单二进制构建、SQLite/PG、设计守护与可访问性。
|
||||
|
||||
正式实现期按各组件 PROJECT 的命令验证，并在 Dev 精确组合运行 `make test`、`make build`。
|
||||
涉及智能体提示/工具/上下文变化时，按 `policy/delivery.md` 的真实模型任务级前后对照要求执行；mock 只能证明机制。
|
||||
证据由 `make evidence` 写入任务卡，保留 SELF/REPLAY/GATE 和固定对象，未运行项保持 NOT_RUN。
|
||||
本轮只检查方案差异、引用与链接、源码对应关系；没有运行上述功能试验或业务测试。
|
||||
|
||||
---
|
||||
|
||||
## 风险、待确认项与下一步
|
||||
|
||||
| 风险 | 具体处置 |
|
||||
|---|---|
|
||||
| 页面自主性变成固定模板填充 | 用同事实不同目标的验证例证明结构变化；逐步开放组合能力，而非预设三种页面硬路由 |
|
||||
| 模型幻觉变成“业务事实” | 事实字段绑定授权源、生成判断标注、来源版本可回查；业务状态只走原服务 |
|
||||
| 自主重排破坏可用性 | 稳定宿主入口、布局固定、输入期间冻结结构、按语义事件有限更新 |
|
||||
| 声明式 schema 被误当安全边界 | 仍对资源、URL、动作、执行权限和数据泄露做服务端校验；可信插件代码另有信任边界 |
|
||||
| 禁用只藏按钮 | 执行端统一守卫、epoch 与提交前复核；直接 API 和在途测试列为必过项 |
|
||||
| 引入第二套状态/runtime | 复用主 Agent、主 SSE 和 Frontend store；外部包只在明确 renderer 边界试验 |
|
||||
| 公开接口扩大过快 | 小型能力接口、版本协商、兼容快照；不暴露内部 store，避免泛化插件市场 |
|
||||
| 外部项目快速变化 | 固定依赖版本，锁 catalog，保留适配层；Tambo Cloud 停服作为实际供应商生命周期样例 |
|
||||
|
||||
### 用户裁定记录（2026-10-11）
|
||||
|
||||
以下三项已由用户（weichen）裁定，原“进入试验前需确认”问题随之关闭：
|
||||
|
||||
1. **接受“动态业务页面 + 稳定宿主入口”**：首试点为对话中的完整分析页（场景 1），随后推进任务/项目工作区。
|
||||
2. **“随时启禁”采用可信编译插件交付**：功能启禁无需重启，插件代码安装/升级需重建并重启；不要求本期免重启安装，sidecar 路线保留为备选。
|
||||
3. **试验参数**：裁定与验收负责人为用户（weichen），执行由 Agent 承担；模型限 MiniMax M3 + M2.7-highspeed；材料限合成或已脱敏样本；U1 费用上限 ¥200。
|
||||
|
||||
注：裁定后权威 main 又合入前端三栏工作台（Dev PR #322）。本文“当前系统的可行性依据”按调研时固定 SHA 记录、不改写；U1 开工时须在新 HEAD 上重验该源码事实表。
|
||||
|
||||
首选下一任务是 **U1 受控价值与选型试验**，不是直接实现所有宿主契约。
|
||||
其前置（批准试验范围与预算）已由 2026-10-11 裁定满足；产物为固定样本 A/B 报告、实际 renderer 取舍、失败清单与 r2 方案。
|
||||
验收依据为 R1/R4/R10 的可判定结果，随后再决定 U2–U4 的正式投入。
|
||||
U1 按独立任务启动并继续逐阶段人工评审；本文发布（推送、合入）随裁定记录一并进入 PR 评审，部署仍不在本轮范围。
|
||||
@@ -0,0 +1,253 @@
|
||||
---
|
||||
title: 多人协作存储与分布式演进方案 - Plan
|
||||
type: refactor
|
||||
date: 2026-10-11
|
||||
execution: code
|
||||
product_contract_source: ce-plan-bootstrap
|
||||
---
|
||||
|
||||
# 多人协作存储与分布式演进方案 - Plan
|
||||
|
||||
修订：r1；确认状态：**已批准（2026-10-11 用户指示「按方案开始改造」）**；推进状态：方案获批发布，实施自首选增量 U1+U2 启动；业务实施/迁移/压测/部署仍为 NOT_RUN，逐项以实施任务卡为准。
|
||||
需求来源：2026-10-11 用户要求完善 SQLite、PostgreSQL/pgvector、Redis 分工；随后确认“10–100 人，多人多项目多会话并行，未来支持多服务分布式”。
|
||||
需求负责人：weichen；方案编制：Codex；实施及运维负责人：待指定。更新时间：2026-10-11（Asia/Shanghai）。
|
||||
关联任务：Dev `.task/feature-collaboration-storage-plan.md`（方案任务，已发布）；后续 U1+U2 实施由独立任务承接。
|
||||
正文中的源码路径以 Agent-System-Dev 为根；工作包中的 `internal/` 简写指 `modules/backend/internal/`；文内相对链接以本文为根。
|
||||
|
||||
## 1. 推荐结论与边界
|
||||
|
||||
团队部署以 PostgreSQL 作为共享业务状态的唯一权威，pgvector 承担数据库内向量查询，Redis 承担可丢失的缓存与限流。SQLite 保留给个人嵌入式使用、离线工具及可以重建的本机状态，不承载团队共享写入或跨主机运行所有权。
|
||||
|
||||
第一阶段交付单应用实例的可靠团队部署；第二阶段补齐执行所有权、持久命令、共享工件与事件追赶，再开放多个应用实例和 Worker。通过接口和数据归属为服务拆分做准备，当前不要求微服务化、Kubernetes、分片或引入另一套消息中间件。
|
||||
|
||||
“不会出现错误”不能成为无条件承诺。工程目标是：在定义的故障模型下，不静默丢失已确认数据、不覆盖他人的并发更新、不产生未经识别的重复副作用、不越权；异常可发现、可追踪、可恢复。冲突可以返回明确的 409，超载可以返回 429，依赖故障可以返回 503，它们必须有清楚的重试语义。
|
||||
|
||||
本方案是[双档存储 D17–D24](2026-09-30-dual-tier-storage-and-multitenancy.md)的候选增补，批准前不改写原已采纳决策。拟调整的是团队部署的默认与必需条件，以及 D24 原来排除的跨实例执行能力；保留个人 SQLite 档、非容器部署、现有检索契约与序号语义。
|
||||
|
||||
## 2. 当前事实与差距
|
||||
|
||||
源码调查基线：Dev `73c901fa341a3653d6e0826d0da3497507995482`，Backend `eda90ed310f37f7352e24a8096d932dbf320cd73`，Documents `9a46785ee0f19540c79f83b4e4544572b5217ac2`，Agent-Squad `490b0b2dfa1567cb16ff7a7230fd78e52bc2938e`，Agent-Native `c348441691e8bdab784a03aa9be64d53dacff341`。
|
||||
来源均为 **SELF·源码/本机只读观察**；没有真实并发故障重放。命令、对象 SHA 和原始输出见[调查收据](../records/2026-10-11-collaboration-storage-audit-receipt.json)，启动收据见任务卡。
|
||||
|
||||
| 对象 | 当前可核实事实 | 方案含义 |
|
||||
|---|---|---|
|
||||
| Dev 运行实例 | `runtime/dev/bin/agent-system`、8788 端口打开 `runtime/dev/data/agent-system.db` 及 WAL；二进制 build revision 为 `017b40f76156905eabe8323ae2bfe800f47fb8bd` | 当前服务确实使用 SQLite；运行版本与上述源码基线不同，源码缺陷不冒充已在该二进制重现 |
|
||||
| 本机安装 | Homebrew 列出 PostgreSQL 18.6、pgvector 0.8.7、Redis 8.10.2 | 仅证明安装；目标 PG 实例、目标库扩展启用、角色与可用性未验证，不据此批准切换 |
|
||||
| Backend 存储 | `internal/app/app.go:105` 按 DSN 选 PG，否则 SQLite；`store/store.go:50` SQLite WAL、busy_timeout=5000、单连接；PG 池固定 16/8 | 无需重写全部存储层；需团队档显式配置、连接预算和真实 PG 测试 |
|
||||
| 已有一致性基础 | `store/dialect.go:49` PG 事务咨询锁；消息 seq 唯一约束、requestId 去重和 HITL 条件更新 | 保留并扩展，不把已有能力列作全新建设；这些能力不等于跨实例运行互斥 |
|
||||
| Run 所有权 | `runmgr/runmgr.go:1113` 用进程内 map 占用会话；`store/messages.go:120` 直接创建 run | 两实例可能各自认为空闲；需共享占用和有效执行代次 |
|
||||
| 取消与审批 | `runmgr/runmgr.go:1326,1422` 依赖本实例 active 句柄；HITL 先落卡，再查句柄 | 请求落在非执行实例时存在命令不生效或卡已处理但执行未被唤醒的风险 |
|
||||
| 跨实例事件 | `pgbus/pgbus.go` 每批通知末 seq，Listener 只 `EventAt` 取末条；断线后对原连接继续 Wait | 静态可见批内中间事件遗漏及重连缺口；`server/server.go:376` 的 SSE 重放/去重不能修复已越过的游标 |
|
||||
| schema 迁移 | `store/migrate.go:migrate` 每次 Open 执行迁移；DDL 事务提交后另行插入迁移版本 | 并发启动与两步间崩溃存在风险；切 PG 前先改为单迁移入口与原子版本登记 |
|
||||
| 向量查询 | `store/vectors.go` 读取 BYTEA，应用内计算余弦；`migrate.go` 未把向量列建成 pgvector 类型 | 安装 pgvector 不代表启用；复用 RRF 管线，分阶段改为数据库 top-k |
|
||||
| Redis | `ratelimit/ratelimit.go:65` 独立 INCR/EXPIRE，EXPIRE 错误未处理；请求异常默认放行；app 默认限额 0 | 当前只是可选共享限流，需原子窗口、鉴权/TLS配置、容量保护与可观察的降级 |
|
||||
| 本地文件 | `blobstore` 默认本地目录；Backend Squad 入口未传 Store，回落 FileStore；checkpoint 写 `.agentx/checkpoints.jsonl` | PG DSN 不会迁走这些状态；工件、执行工作区、checkpoint 要分别处理 |
|
||||
| 独立 Squad | 独立 CLI 使用 `adapters/sqlite/runstore.go` 的 `orchestration.db`；这不是 Backend 实际接线 | 不把迁移该 SQLite 文件当作 Backend 分布式改造完成 |
|
||||
| 验证 | PG/Redis 集成由 `AGENT_PG_TEST_DSN`/`AGENT_REDIS_TEST_ADDR` 控制；当前 CI YAML 没有显式准备这两种服务 | 缺变量会跳过关键测试；CI 通过不能自动证明真 PG/Redis 或双进程链路通过 |
|
||||
|
||||
已有规划衔接：Q1 已记录 Store 收敛但仍留 platform→squad 队列桥接等余项；N3 原案与归档卡的 JournalOnly 落地不同，应以当前接线确定权威。共享权限沿用 EXT-8 授权适配器与 RDM 的成员/角色职责，不新建第二套成员模型。历史报告用于定位，不能替代当前验收。远端调查发现 Backend [#135](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/135) 正在增加 S0 工作区 overlay/frozen base/CAS apply；U5 必须复用并核对其契约，不能另造冲突的工作区实现。该 PR 尚未作为本案已合入依赖。其他被查仓当时未返回 open PR，详见收据；实施启动时重新核对。
|
||||
|
||||
## 3. 需求与可判定结果
|
||||
|
||||
| ID | 需求 | 优先级 | 验收条件 |
|
||||
|---|---|---|---|
|
||||
| R1 | 支持 10–100 人、多项目、多会话并行 | P0 | 在固定环境与下述负载下完成真实业务链路；容量结果绑定组件 SHA、配置和数据集 |
|
||||
| R2 | 团队数据有唯一共享权威 | P0 | 团队档无有效 PG 配置或连接失败时拒绝就绪，不自动建立本地 SQLite 继续服务 |
|
||||
| R3 | 并发提交和编辑不静默覆盖 | P0 | 同 requestId 返回同一逻辑结果；同版本竞争写入最多一个成功，其余明确冲突；不同会话并行 |
|
||||
| R4 | 跨实例运行与命令可恢复 | P1，多实例前置 | 同会话主 run 单一有效 owner；旧 epoch 写入拒绝；任意 API 实例取消/HITL 均到达执行者 |
|
||||
| R5 | 事件有序、可追赶 | P0/P1 | 批处理、掉通知、重连和慢消费者后可按游标补齐全部已提交事件；不因收到末 seq 而跳过中间事件 |
|
||||
| R6 | 项目权限在所有数据入口一致 | P0 | 读取、写入、SSE、检索、下载与工具入口均校验当前授权；撤权后的新请求无泄漏 |
|
||||
| R7 | 数据和运行状态可恢复 | P0 | SQLite→PG 演练无遗漏；备份恢复含文件与权限映射；未知副作用停在可见恢复状态，不盲目重试 |
|
||||
| R8 | 高负载下有界且可观察 | P0 | 队列、活跃 Agent、DB 连接、工具/模型请求都有上限；超载行为、等待时间和错误分类可观测 |
|
||||
| R9 | 向量检索随数据增长扩展 | P1 | 数据库 top-k 与原精确基线对照；授权过滤正确；模型/维度/版本不混用；ANN 有召回率与延迟证据 |
|
||||
| R10 | 支持未来多服务部署 | P1/P2 | 先验证两个真实 API/Worker 进程共享服务；业务表有模块 owner，后续服务通过契约操作他方数据 |
|
||||
|
||||
R1 的人数及未来分布式方向由用户确认；下列量化指标是**建议的验收合同，待批准，不是当前性能结论**：
|
||||
|
||||
- 基准环境建议：Linux、8 vCPU、32 GiB RAM、NVMe，记录 PG/应用的实际配额与网络；两实例验证分为同机多进程和后续双主机两种证据。
|
||||
- 阶梯负载：10→30→100 在线用户，最多 300 SSE 连接；初始全局活跃 Agent 执行预算 20（包含子代理）、每用户 2、索引任务 4。待执行队列最多 200，按用户/项目公平分配。已接纳 run 数与实际执行许可分别计数；父 run 等待子代理/HITL 时让出执行许可、保留会话所有权，恢复执行须重新获许可，避免额度用尽时父子互等。以上阈值由实测调整。
|
||||
- 数据量建议：100 万条消息/事件量级、10 万知识分块、多个项目与交叉授权用户；另测 100 万分块扩展档。记录数据分布与热点，不能只测空库。
|
||||
- 非模型普通 API：P95≤300ms、P99≤1s；SSE 持久事件可见延迟 P95≤1s；非预期失败率≤0.1%。预期限流/冲突单列，不能排除后不报告。
|
||||
- 先跑 60 分钟稳定负载，再跑 2 小时混合长稳；持续记录实际成功吞吐、排队、CPU/内存/IO、连接等待和模型配额。模拟模型用于容量基线，另保留真实模型少量全链路验证。
|
||||
- 数据正确性不变量在全部测试中零违反。数据库/Worker 故障恢复建议 RTO≤15 分钟；灾难恢复建议 RPO≤5 分钟、RTO≤60 分钟。主机/存储全毁不在单机“零丢失”承诺内；若要求该场景 RPO=0，需另行批准同步复制、故障域与可用性取舍。
|
||||
|
||||
## 4. 技术决策与目标结构
|
||||
|
||||
KTD1. **区分 local 与 team 部署档。** local 保留 SQLite；team 强制 PG、认证、独立实例 ID、受控工具执行和启动诊断。PG 暂时不可用时返回未就绪，不切回 SQLite。个人档不因浏览器人数变多而自动升级。
|
||||
|
||||
KTD2. **PG 保存持久业务与调度事实。** 用户/项目/会话/消息/卡片/运行/幂等记录/命令/事件/checkpoint 元数据以 PG 为准。Redis 不成为任务完成、审批通过或永久幂等的唯一证据。初期使用同一 PG 实例和有归属的逻辑表/角色；后续拆服务时明确表的唯一写入模块，避免所有服务无约束共享整库。
|
||||
|
||||
KTD2 的全部状态收敛以 U5 完成为界；此前有明确的单实例过渡边界，不能提前把本地状态当成缓存：
|
||||
|
||||
| 数据 | 首期单实例团队版 | U5 后多实例版 |
|
||||
|---|---|---|
|
||||
| Backend 业务记录、幂等与恢复隔离标记 | PG 权威 | PG 权威 |
|
||||
| 尚未改造的 Squad FileStore、checkpoint、续跑标记 | 唯一实例的本地权威文件，联合备份，禁止跨机接管 | 版本/归属元数据在 PG，大内容在共享对象存储 |
|
||||
| 工件 | 本地对象目录，持久备份与 DB 清单绑定 | 共享不可变对象与 PG 发布记录 |
|
||||
| 临时执行目录 | 单实例/单 owner；先分类再清理 | owner+epoch 控制的可恢复工作区 |
|
||||
|
||||
KTD3. **一个会话一次主执行，不同会话并行。** 推荐独立 conversation_execution 占用行，以 owner/会话唯一键、run_id、epoch、lease_until 约束；不对所有 runs 加“会话唯一”，以免禁止正常子代理。事务内完成权限检查、请求幂等、消息、主 run 和调度记录，接收成功以事务提交为准。
|
||||
|
||||
KTD4. **短事务领取，租约与 fencing 配套。** Worker 通过 PG 行锁和 SKIP LOCKED 领取到期任务；事务提交后执行，模型/工具等待不得持有数据库事务。续租、事件追加、checkpoint、终态写入都校验 run+epoch。租约用 DB 时间，执行实例 ID 与每次启动的 generation 分开。旧 Worker 恢复后不能提交；租约过期也不等于外部命令已经停止。
|
||||
|
||||
KTD5. **持久命令与提交事件同事务。** 取消/HITL/调度命令写入 PG inbox/outbox，带唯一 command_id、逻辑 run、执行代次与处理状态。运行级取消意图交给当前 owner，即使接受后发生接管也不能丢失；HITL 绑定稳定 gate_id+gate_version，新 owner 消费时重验 gate 与权限，过期审批明确拒绝而不静默丢弃。执行结果及确认仍须校验当前 epoch。批准数据与待投递命令原子提交，执行者幂等消费，处理确认与执行效果分别记录。关键外部动作必须有目标端幂等键、可查询凭据或人工恢复路径；超时结果未知时进入 recovering，不宣称任意工具 exactly-once。
|
||||
|
||||
KTD6. **事件表是重放依据，NOTIFY 仅作唤醒。** 事件提交与 outbox 同事务；需要时在同事务使用 pg_notify。监听端维护每流连续 cursor，从 EventsAfter 分页追赶到通知水位；不能直接跳到末 seq。重建连接→LISTEN 生效→补查水位/积压，再转实时。增加周期补查，覆盖通知丢失、断线与通知前后竞争。只有落库事件才能发布可恢复的 SSE ID；纯瞬时进度明确可丢失，不冒充已确认业务数据。
|
||||
|
||||
KTD7. **数据库乐观并发控制。** 项目设置、卡片、文档元数据等读改写带 version/expected_version；冲突返回 409 及新版本引用。重要唯一性/外键落在数据库，事务失败按错误类型有界重试整笔事务；提交结果未知先按幂等键查询。不能无限重试模型调用或发送动作。[PG 事务隔离与重试](https://www.postgresql.org/docs/current/transaction-iso.html)。
|
||||
|
||||
KTD8. **数据库迁移独立于普通启动。** 单一 migrator 取得数据库锁，执行 append-only 版本；可事务化 DDL 与版本登记同事务。应用仅核对兼容版本和就绪状态。不能放入事务的在线索引变更单列可恢复运维步骤，不夹入普通迁移后声称原子。使用扩展→回填→切读写→收缩，保留兼容窗口。
|
||||
|
||||
KTD9. **工件共享，工作区有执行 owner。** 先保留 blobstore 接口；跨主机上线前实现并验收 S3 兼容对象存储，DB 保存不可变对象键、校验和、版本与就绪状态。发布前先完整写对象再提交引用，失败孤儿可清理；删除采用标记和延迟 GC。工作区、检查点与 Squad 状态分开设计：checkpoint/调度版本入 PG，大内容入对象存储，本地工作区是受 owner/epoch 控制的暂存执行目录；需要接管时按清单恢复。共享目录和文件 rename 不能替代跨机所有权。
|
||||
|
||||
KTD10. **Redis 只保存可恢复的加速状态。** 保留共享限流，改为 Lua 原子计数+过期或等价原子算法，键包含实例群/完整时间窗/owner，支持 ACL 凭据/TLS、连接与请求超时。故障时普通读取可降到本地保守限流；创建 Agent/昂贵工具等写入口仍受 PG admission 硬预算保护，不能无界放行。缓存带授权/内容版本，撤权同步失效或重新校验；先证明命中收益再加缓存。[Redis INCR 限流模式](https://redis.io/docs/latest/commands/incr/)、[分布式锁限制](https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/)。
|
||||
|
||||
KTD11. **pgvector 按“正确→测量→ANN”推进。** 复用现有全文+RRF+可选 rerank，先补 embedding profile/model/revision/dimension/content_hash/generation 身份，禁止同维不同模型混查；迁移为 vector 列并在 PG 做过滤和精确 top-k，再用基线对照决定 HNSW。权限适配器不能直接变成 SQL 时，由适配器提供受限授权候选集合或采用有界分批取候选+最终实时鉴权，不得无界加载所有 owner 后在内存过滤。授权过滤后的召回率单独验证；ANN 需要迭代扫描/分区等策略时以模型维度和版本实测选择。[pgvector 官方说明](https://github.com/pgvector/pgvector)。
|
||||
|
||||
KTD12. **先管理连接池，再决定 PgBouncer。** 使 MaxOpen/Idle/IdleTime/Lifetime、查询超时可配置并输出脱敏有效值；总连接预算包含所有 API、Worker、LISTEN、migrator、监控与维护预留。100 在线用户不等于 100 DB 连接。未来接 PgBouncer transaction pooling 时 LISTEN 必须使用直连或 session pool 独立 DSN，迁移也走直连，并验证 pgx prepared statement 配置。[PgBouncer 兼容表](https://www.pgbouncer.org/features.html)。
|
||||
|
||||
KTD13. **共享可读不等于可写或可批准。** 当前 EXT-8 `ProjectAuthz` 是只读 bool 契约。U3 先列 read/edit/approve/execute/admin 的动作授权矩阵，复用下游角色，不另建成员权威；需要共享写入时以版本化公开契约扩展 action-aware 授权，旧只读适配器不得自动获得写入能力。未配置的动作默认拒绝，Host/工具/API 均走同一授权结论；审批职责分离仍由下游规则判定。SSE 发送后续数据、异步任务开始和工件下载时重新校验当前授权，缓存失效不承担唯一安全责任。
|
||||
|
||||
KTD14. **迁移副本按原数据敏感级别保护。** 备份、导出、WAL、工件和测试副本使用专用角色及受限目录；传输与静态备份加密，解密材料保存在独立受管秘密存储并纳入恢复演练。日志/报告只留统计与哈希，禁止正文、令牌及密钥明文；测试使用脱敏数据。U1 固定保留期限、存放位置、访问者与清理责任，未知项阻塞正式导出。正式恢复演练同时验证凭据可用性与非授权者无法访问副本。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[10–100 用户] --> G[入口与认证]
|
||||
G --> A[API 实例 A / B]
|
||||
A --> P[(PostgreSQL + pgvector)]
|
||||
A --> R[(Redis 限流 / 可重建缓存)]
|
||||
P --> W[Worker 领取任务 / 持久命令]
|
||||
W --> P
|
||||
W --> X[受控工具工作区 / 模型服务]
|
||||
W --> O[(共享对象存储)]
|
||||
A --> O
|
||||
P --> E[事件追赶 / 本地订阅]
|
||||
E --> U
|
||||
```
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant C as 用户
|
||||
participant A as 任意 API
|
||||
participant P as PostgreSQL
|
||||
participant W as 执行 Worker
|
||||
C->>A: 提交 requestId / expected_version
|
||||
A->>P: 短事务：鉴权、幂等、占用、消息、run、任务
|
||||
P-->>A: commit / 冲突
|
||||
A-->>C: 已受理与 runId / 明确冲突
|
||||
W->>P: 领取任务并取得 epoch
|
||||
W->>W: 事务外执行模型与工具
|
||||
W->>P: 按 epoch 提交结果与事件
|
||||
P-->>A: 唤醒后按 cursor 补齐
|
||||
A-->>C: SSE 已提交事件
|
||||
```
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> queued
|
||||
queued --> running: 原子领取并分配 epoch
|
||||
running --> waiting: 持久 HITL
|
||||
waiting --> running: 幂等命令消费
|
||||
running --> completed: 有效 epoch 原子结算
|
||||
running --> recovering: 失联或副作用结果未知
|
||||
waiting --> recovering: owner 失效
|
||||
recovering --> queued: 已核对可安全重试
|
||||
recovering --> interrupted: 需人工处理或不可恢复
|
||||
queued --> cancelled: 取消命令生效
|
||||
running --> cancelled: 执行者确认停止
|
||||
```
|
||||
|
||||
## 5. 实施顺序与工作包
|
||||
|
||||
每个阶段评审后再进入下阶段；以下均为待批准计划，不因写入文档取得实施授权。新测试文件标“新增”；现有测试只作为扩展入口，本次未运行。普通基座改动在 Backend；公开持久接口确需变化时才同步 Native/Squad/Core，并由 Dev 固定组合测试，不全库改造。
|
||||
|
||||
### U1. 冻结目标、数据归属与基准环境
|
||||
|
||||
对应 R1/R2/R7/R8。先确定目标为 Dev 团队实例及其实际发布制品，记录脱敏配置来源、DB 实例/版本/扩展、数据数量与归属、文件清单、磁盘容量、峰值和恢复目标。RDM 独立业务库、旧 Agent-System 治理库另列，不能把一次 DSN 切换宣称覆盖它们。
|
||||
范围：`runtime/dev` 部署配置（实施时核对文件位置）、`modules/backend/internal/config/config.go`、文档运行手册。
|
||||
产物：固定部署清单、迁移映射、容量合同（区分接纳与执行许可）、隔离测试库/目录/端口方案、KTD14 的副本保护与保留合同；确认暂态 Worker 文件哪些可重建，哪些必须迁移。
|
||||
验收：仅操作批准的实例和测试资源；共享数据凭据不打印；未知 owner 或未定位的权威文件阻塞迁移。测试：脱敏配置诊断及缺项校验，业务压测依后续 U7。
|
||||
|
||||
### U2. 团队 PG 档、迁移器与真实数据库门禁
|
||||
|
||||
依赖 U1；对应 R2/R3/R7。修改 `internal/config/config.go`、`internal/app/app.go`、`internal/store/store.go`、`internal/store/migrate.go` 及 CLI；按 KTD1/KTD8/KTD12 实施。
|
||||
CI 增加隔离原生 PG/Redis 生命周期及明确必跑标记，固定组件/扩展版本；缺少真实测试服务时该 job 失败而非跳过。
|
||||
测试：扩展 `internal/config/config_test.go`、`internal/store/store_test.go`；新增 `internal/store/migrate_atomic_test.go`。覆盖 team 缺 DSN/PG 故障拒绝启动、local SQLite 正常、两个 migrator 竞争、DDL 与账本中间崩溃、旧 schema 升级、PG bool/时间/空 JSON/唯一约束与全文扩展。
|
||||
出口：真 PG 完整 CRUD/认证/会话/SSE/检索/卡片链路通过；仅该出口不宣布多实例安全。schema 变更的组合测试与业务迁移是不同动作。
|
||||
|
||||
### U3. 请求原子性、版本冲突与受控容量
|
||||
|
||||
依赖 U2；对应 R3/R6/R7/R8。修改 `internal/server/server.go`、`internal/store/messages.go`、`internal/store/cards.go`、`internal/cardsvc/cardsvc.go`、设置读改写及 `internal/runmgr`。收口 KTD3/KTD7 的事务边界；保留现有 seq 约束。按 KTD10 完成 Redis 原子限流、配置与异常策略；PG 记录共享 admission 预算。按 KTD13 完成动作授权矩阵与所需公开扩展的兼容计划；涉及共享编辑时 Core/Host 与下游适配器一起验收。
|
||||
先补最小持久恢复隔离：为未知副作用记录 recovery hold，`ResumeInterruptedChildren` 等所有启动续跑入口必须跳过，人工核对后显式解除。概念状态 recovering 可以先由独立隔离记录表达；扩展 Core 枚举时走公开契约版本，不假定当前已有此状态。完整租约接管留 U5。
|
||||
测试：扩展 `internal/server/admission_test.go`、`internal/ratelimit/ratelimit_test.go`；新增 `internal/store/admission_pg_test.go`、`internal/store/card_version_test.go`、`internal/runmgr/recovery_hold_test.go`。覆盖相同请求重放、事务部分失败、同版本竞争、动作越权、子代理预算计入全局、所有父 run 占满额度后同时派生仍能前进、未知副作用重启不自动续跑、队列满、Redis 断连/恢复/键过期。
|
||||
出口：单 API 团队模式达到不变量与有界行为；不会把 20 个 Agent 配置值当作已证明容量。
|
||||
|
||||
### U4. 可切换的迁移与恢复演练
|
||||
|
||||
依赖 U2/U3；对应 R2/R7。新增 `modules/backend/cmd/storage-migrate/` 或等价受管运维入口，明确只处理 Backend 库；不得直接执行 SQLite dump 作为 PG SQL。迁移实例以 migration_id、source_snapshot_id、source_schema_version 固定来源，记录表级完成与最终验证完成标记；仅同一冻结快照可续传，其他非空目标拒绝。迁移报告包括每表计数、主键映射、按主键分批规范化内容校验和、外键/owner/权限检查及工件哈希。
|
||||
测试：新增迁移工具的 `main_test.go` 与 `integration_test.go`，固定脱敏 SQLite 夹具覆盖全部当前 schema、布尔/空值/时间/JSON/Unicode/二进制向量/秘密字段、幂等重复导入、缺文件、未知 owner、断点重试及目标已含数据拒绝。
|
||||
操作顺序与回退见第 6 节。出口：隔离环境迁移与恢复验证完成，由用户批准窗口后才切正式服务。
|
||||
|
||||
### U5. 执行所有权、持久命令与共享状态
|
||||
|
||||
依赖 U3，团队现网切换不必等待整个 U5；对应 R4/R6/R7/R10。修改 `internal/runmgr`、`internal/store/recovery.go`、`internal/squadadapter`、`internal/runtime/squad_runner.go`、`internal/blobstore`；新增 Store 的 lease/inbox/outbox 与 PG RunStore 适配器。
|
||||
按 KTD4/KTD5/KTD9 设计 Native checkpoint 接口，继续支持 local 文件实现；不把 JournalOnly 日志误当作业务上下文权威。Worker 工具沙箱与访问范围沿用现有方向，在执行端检查当前身份和 epoch。
|
||||
测试：新增 `internal/runmgr/multi_instance_test.go`、`internal/store/lease_pg_test.go`、`internal/blobstore/object_store_test.go`；扩展 `internal/runmgr/recovery_test.go`。必须启动两个真实进程：同会话争抢、不同会话并行、跨实例取消/HITL、命令提交后消费前 owner 换代、旧 gate 的审批明确失效、Worker 被杀、旧 Worker 迟到结算/写事件/写文件、失联重连、副作用结果未知、文件缺失/重复发布。
|
||||
出口：所有写入和工具副作用的失效 owner 处理有实证后，才允许第二实例承接写请求；故障状态可见，不能仅靠粘性路由。
|
||||
|
||||
### U6. 事件追赶与数据库向量检索
|
||||
|
||||
U6 内分三个交付切片，稳定工作包 ID 不变：事件追赶/重连修复依赖 U2，可与 U3 并行；事务 outbox 与投递闭环依赖 U5；向量 schema 与查询改造依赖 U2 迁移器及 U3 授权合同。对应 R5/R6/R9。
|
||||
事件：修改 `internal/pgbus/pgbus.go`、`internal/runmgr/events.go`、`internal/server/server.go`、Store 事件接口。扩展 `internal/pgbus/pgbus_test.go`，新增 `internal/server/sse_gap_test.go`：批次 64 条全部可见、断线补齐、通知丢失、订阅与补查竞争、1000+ 分页、慢消费者、撤权后新事件拒绝。第一切片完成只证明追赶修复，不声称 KTD6 的事务 outbox 已就位。
|
||||
向量：修改 `internal/store/vectors.go`、`internal/store/migrate.go` 与现有知识索引管线；新增 `internal/store/pgvector_test.go`。验证模型身份/维度隔离、内容更新/删除原子性、回填中重启、索引未完成可降级、中文全文混合、共享授权后 top-k、撤权、与精确检索 Recall@10 对照（建议≥0.95，待批准）。索引构建不得拖垮前台连接/IO。
|
||||
出口：先验证正确与有界，再按容量结果决定 HNSW 与缓存；绝不以 extension 存在替代查询计划/召回证据。
|
||||
|
||||
### U7. 压测、故障验收与分布式放行
|
||||
|
||||
依赖 U2/U3/U4；双实例验收另依赖 U5/U6。对应全部 R。首期单实例放行必须完整重放现有入口的 R6 权限矩阵（含 SSE 后续事件、共享检索、下载、Host/工具与撤权），并证明 U3 恢复隔离；不能等 U5/U6 才验证这些 P0 要求。跨实例传播与接管的新增验证随 U5/U6。新增 Dev `tests/load/collaboration/` 与 `tests/integration/multi-instance/`，由隔离测试入口负责启动/回收自己创建的资源。
|
||||
按第 3 节负载合同和第 7 节矩阵测量，记录原始 k6/pgbench、服务指标与数据不变量；pgbench 只测数据库能力，不能替代业务 API/SSE/Agent 验收。正式测试不打生产服务。
|
||||
出口：单实例团队、双进程、双主机分别出具结果；CI 身份/链接/SHA 或独立 REPLAY 可核验才用于放行。本地 SELF 只能作辅助。变更智能体行为时补真实模型前后任务级对照。
|
||||
|
||||
远期 P2：需求达到后再拆 API/Worker/索引服务，按表归属收紧角色；引入 PG 高可用与自动故障转移、对象存储冗余、可选 PgBouncer。服务拆分与 DB 复制是两件事；Redis 集群、读副本和缓存不能替代主库一致性，读后写敏感路径保持主库读取或显式一致性令牌。
|
||||
|
||||
## 6. SQLite → PostgreSQL 切换和恢复
|
||||
|
||||
1. 固定源服务制品、全部数据库/文件路径与目标空库；指定迁移 owner、窗口、可接受中断和回退判据。先做只读盘点与隔离演练，不接触其他服务的数据。
|
||||
2. 为 SQLite 做一致性备份（应用已有 Backup/VACUUM INTO 或官方备份路径），同时生成工件/checkpoint/工作区清单。活跃 WAL 数据库不能只复制 `.db` 文件；检查备份可打开且内容与清单匹配。
|
||||
3. 预演使用独立测试目标 PG，由 migrator 建 schema/扩展，再按依赖顺序导入。显式保留 ID、幂等键、事件 seq、哈希/秘密、用户归属、共享范围、审批状态，调整序列值和类型。预演库不成为正式目标；所有副本遵守 KTD14。
|
||||
4. 最终窗口暂停新写与调度，等待或安全收口在途 run；无法确认外部副作用的 run 写入 U3 的持久 recovery hold。停止全部旧写者后取最终一致性快照，导入新空正式目标；按 U4 的同快照迁移身份续传。全量对账与验收抽样完成并写入完成标记后才可切入口，保留只读源备份及过渡期权威文件。目标已服务或身份不同的非空库不得覆盖。
|
||||
5. 仅一个入口切到 PG，检查版本/配置指纹、库身份与数据归属，执行用户登录、项目、会话、审批、检索、下载的冒烟；应用 fail-closed，不能故障后回 SQLite。原库不再写，不使用临时双写制造两个权威。
|
||||
6. **PG 接受新写入前**可撤回切换，确认目标未产生业务写后恢复 SQLite。**PG 接受新写入后**禁止直接指回旧 SQLite；优先保留 PG 回退兼容应用或向前修复。确需反向迁移，重新冻结写者、导出 PG 增量、对账并批准专门回迁方案。
|
||||
7. 建立 pg_dump 逻辑备份，以及 pg_basebackup（或等价物理基础备份）+ 连续 WAL 归档/PITR，并与对象存储版本/清单联合恢复；pg_dump 不能用作 WAL 回放的基础备份，保留足够不可变对象。每次演练恢复到新目标，核对应用可用与权限/文件完整性，不能把“备份命令成功”当作可恢复。
|
||||
|
||||
SQLite 本身支持可靠事务与多人经同一应用访问；WAL 提升读写并发，但同一数据库仍只有一个 writer，且不适合多主机通过网络文件系统共享 WAL。取舍基于写负载、进程拓扑、恢复与运维目标，不用“超过某人数 SQLite 就出错”的判断。[SQLite WAL 官方文档](https://sqlite.org/wal.html)。
|
||||
|
||||
## 7. 最小验收矩阵
|
||||
|
||||
| 场景 | 必须观察到的结果 | 对应 |
|
||||
|---|---|---|
|
||||
| 同 requestId 并发/网络超时后重试 | 一个逻辑请求和同一 run，不重做已经确认的副作用 | R3/U3/U5 |
|
||||
| 两实例同会话不同请求 | 仅一个主执行；另一个排队或明确冲突，子代理不受错误唯一约束阻断 | R3/R4/U5 |
|
||||
| 多项目并行、热点会话、满额度父子派生 | 公平、有界；等待父 run 不阻塞子 run 获得许可，所有任务能前进或得到有界拒绝 | R1/R8/U3/U7 |
|
||||
| 并发修改同卡/设置 | 成功与冲突可辨认，无最后写入静默覆盖 | R3/U3 |
|
||||
| 在 B 提交 A 所有 run 的取消/HITL，消费前换 owner | 命令持久、唯一消费；取消随逻辑 run 生效，HITL 重验 gate 版本，卡片与 run 最终一致 | R4/U5 |
|
||||
| Worker 崩溃/暂停超过租约后恢复 | 新 owner 可受控接管；旧 epoch 不能提交；不明副作用不自动重放 | R4/R7/U5 |
|
||||
| PG 断连/提交响应丢失 | 依赖不可用有界失败；恢复按幂等记录核对，不自动切 SQLite | R2/R3/U3 |
|
||||
| Redis 断连/INCR 后崩溃 | 不改变业务事实；昂贵任务仍受硬预算；恢复无永久计数键错误 | R8/U3 |
|
||||
| 批事件/断开 LISTEN/通知丢失 | 所有已提交事件按连续 cursor 追赶，重放不跳洞 | R5/U6 |
|
||||
| 撤销成员权限/跨 owner 猜测 ID | 新请求、流后续事件与下载/检索/工具均不泄漏 | R6/U3/U5/U6 |
|
||||
| 多模型向量/过滤后 top-k | 不混模型，权限正确，召回/延迟达批准阈值 | R9/U6 |
|
||||
| 迁移崩溃/坏文件/未知 owner | 阻止切换；重试不重复导入，不隐式公开历史数据 | R7/U4 |
|
||||
| 磁盘满/备份恢复/整机失效 | 清楚拒绝写入和报警；在约定故障模型与 RPO/RTO 下恢复 | R7/U4/U7 |
|
||||
|
||||
## 8. 工具、观测与交付
|
||||
|
||||
本轮未安装软件、修改配置、运行迁移、重启服务或压测。brew 已有三项服务软件，当前瓶颈主要是接线与一致性机制，暂不重复安装。未来压测可通过 [brew 安装 k6](https://formulae.brew.sh/formula/k6)；PgBouncer 只在连接测量证明有必要后安装。安装授权不等于对共享数据库升级、创建扩展或变更服务的授权；执行前核对目标、版本与既有占用。
|
||||
|
||||
必需观测：API P95/P99与预期/非预期错误，DB pool wait/连接数/慢查询/锁等待，队列长度/最老年龄，run 租约/过期写拒绝/未知副作用，SSE cursor lag/补查次数，Redis 错误与降级，检索耗时/召回抽样，备份时间与恢复结果。日志只记录 request/run/owner 的安全标识，不记录 DSN、密钥或文档正文。
|
||||
|
||||
当前交付仅为 r1 方案与 SELF 调查记录。需求人数已确认；容量阈值、正式数据/部署目标、迁移窗口、灾难恢复等级和实施阶段尚待人工评审。没有业务测试 PASS、独立 REPLAY、CI GATE 或已部署声明。
|
||||
|
||||
方案静态审阅及修订处置见[审阅记录](../records/2026-10-11-collaboration-storage-plan-review.md)。Agent 审阅不替代人工批准或实现验收。
|
||||
|
||||
首选下一增量是 **U1 + U2 的详细实施与测试合同**：固定目标实例与 PG 测试环境，解决团队档、迁移原子性和真实数据库测试门禁。U6 的事件正确性修复可在单独授权后并行；不要先增加应用副本。各实现任务启动前复核在途 PR 与依赖 SHA，再按 Dev 的 evidence/task-sync/组合验证流程交付。
|
||||
@@ -6,12 +6,17 @@
|
||||
|
||||
## 先看哪一份
|
||||
|
||||
新增方向（2026-10-11 用户已裁定关键取舍）：[Generative UI 调研与插件方案 r1](2026-10-10-generative-ui-plugin.md)。
|
||||
首试点为对话内完整分析页，交付采用可信编译插件；U1 试验限 MiniMax M3 + M2.7-highspeed、合成或脱敏材料、费用上限 ¥200，作为独立任务另行评审启动。
|
||||
此记录独立于下方历史核验快照，不改写历史方案/PR 数量或验收结论。
|
||||
|
||||
| 要回答的问题 | 主记录导航 | 规划中的阶段 | 原文负责人 |
|
||||
|---|---|---|---|
|
||||
| 通用系统的原始边界与架构是什么 | [系统骨架](2026-09-29-system-skeleton-design-and-plan.md)，结合下表专题修订 | 骨架 P0–P5；D1–D16 | weichen |
|
||||
| 基座与下游如何分工，如何申请扩展 | [基座路线图](2026-10-01-base-extension-roadmap.md)，配套插件契约与兼容规则 | 公开扩展面、插件 v2、质量回路、工程基座 | weichen |
|
||||
| 三个智能体库如何继续演进 | [Agent 栈总案](2026-10-02-agent-stack-completion.md)，阶段细化见 N1/Q1/I1、N2、N3、Q2/Q3 | R0/R1/D1、N1–N3、Q1–Q3、I1–I2、阶段评测 | weichen |
|
||||
| RDM 下游的大目标和消费者里程碑是什么 | [RDM 阶段总案](2026-10-07-rdm-phase-plan.md) | P0–P4，对应 MS0'、MS1–MS4及发布前置 | weichen |
|
||||
| 10–100 人协作与未来分布式如何演进 | [协作存储与分布式方案](2026-10-11-collaboration-storage-and-distribution.md) | 团队 PG 档 → 迁移恢复 → 多实例执行与故障验收；r1 已批准（2026-10-11），实施自 U1+U2 启动 | 需求：weichen；实施/运维待指定 |
|
||||
|
||||
以上是依据文内显式范围和引用形成的阅读入口，不是新增优先级或批准结论。N2 阶段案未单列 owner，
|
||||
应由负责人补齐；不能仅凭任务创建人推断全部规划的负责人。
|
||||
@@ -77,7 +82,7 @@ Dev 链接均指向对应任务 PR，可从其任务卡继续追溯组件 PR；
|
||||
| [智能体工作流质量改进](2026-10-09-agent-quality-improvement-plan.md) | 直连主路径质量：诊断→六项裁定→P0–P5 分期 + 模型 A/B；推翻 fs 工具默认关闭裁定 | 已获实施授权（2026-10-09 六项裁定）；首个增量 feature/agent-quality-phase01 | 随本提案 PR；诊断 SELF（真实运行转录）；基线报告见任务卡 |
|
||||
| [EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md) | RDM 多人共享契约的基座最小扩展申请（EXT-6…EXT-12）：身份停用/受管配置/授权适配器/索引发布/分发守卫/Host 工厂/投影过滤 | proposed；需求依据=RDM U0 主记录（D1–D9 裁定，2026-10-08 合入） | 随本提案 PR；每条现状证据为 SELF·源码级（Dev 34a2bbe/backend fe7c245），运行态 NOT_RUN；受理后逐条另立实现任务 |
|
||||
| [EXT 申请包 G1](2026-10-09-ext-g1-b1-b3-exec-backend.md) | EXT-13…16：回合内共享检索、命令即工具、项目列表共享、执行后端接口 | proposed；需求依据=RDM 方案 V1.1 §3.3/§3.4/§5.3（2026-10-09 批复） | Documents [#52](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/52) 已合入；EXT-16 已实施（Dev #285，见其任务卡），其余受理评审待定。本行由本次索引维护补充 |
|
||||
| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录：委派契约与角色路由方案（E1–E5 增量）+ 任务工作区沙箱设计（仅记录不实施）；修正 overlay≠快照等三处假设 | proposed（2026-10-10）；E1 已完成（Agent-Native #42/#43/#44、Backend #127、Dev 任务卡 feature/agent-e1-parallel-fixes，2026-10-10）；E2–E5/S0 待授权 | 随本提案 PR；现状核查与启动延迟为 SELF（任务卡 evidence）；外部来源 URL 全量随任务卡 |
|
||||
| [子代理分工、模型分级路由与任务沙箱](2026-10-10-agent-delegation-routing-sandbox.md) | 方向主记录：委派契约与角色路由方案（E1–E5 增量）+ 任务工作区沙箱设计（仅记录不实施）；修正 overlay≠快照等三处假设 | proposed（2026-10-10）；E1、E3、E4(R4+账本)、E5(R3)、S0-1 已完成（E4：Dev #315；S0-1：Backend #135/#136、Dev #318，2026-10-11）；E2 暂缓（模型指示）、S0-2 待授权 | 随本提案 PR；现状核查与启动延迟为 SELF（任务卡 evidence）；外部来源 URL 全量随任务卡 |
|
||||
|
||||
原查询的 19 份原文中，14 份显式标注 owner 为 weichen。双档存储、启动配置面、跨会话读取、文件预览和
|
||||
N2 实施案这五份未单列 owner，其中预览案仅写“作者：weichen + Agent”。同步新增的 N3 与 Q2/Q3 案页首也未单列 owner。
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,31 @@
|
||||
# 协作存储方案 r1 静态审阅记录
|
||||
|
||||
对象：[方案 r1](../proposals/2026-10-11-collaboration-storage-and-distribution.md)。
|
||||
日期：2026-10-11（Asia/Shanghai）。来源：SELF，Agent 辅助静态审阅。
|
||||
三个 Agent 分别兼任两个视角：coherence/scope-guardian、feasibility/adversarial、security/product。
|
||||
同一 Agent 的两个视角不互相独立；没有跨模型审阅、独立测试重放、CI GATE 或人工批准。
|
||||
使用 ce-doc-review 的检查视角，覆盖与边界以本记录为准，不声称已运行额外外部模型审阅。
|
||||
|
||||
## 发现与处置
|
||||
|
||||
| 发现 | 原方案后果 | 修订处置 | 复核 |
|
||||
|---|---|---|---|
|
||||
| 正式导入与非空目标拒绝冲突 | 预演后可能无法最终导入，或放宽规则混入其他快照 | U4/§6 分开预演与正式空目标；migration_id+快照身份，只有同快照可续传，验证完成后切入口 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 恢复隔离晚于首期切换 | 现有 ResumeInterruptedChildren 可能自动重派未知副作用任务 | U3 前移持久 recovery hold，启动续跑跳过，U7 放行前验证 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 命令只绑定旧 epoch | owner 切换后取消或审批意图可能丢失 | KTD5 区分逻辑 run 取消、gate/version 审批与按 epoch 验证的执行结果 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 父子共享额度可能互等 | 父 run 占满许可并等待不能启动的子 run | §3/U3 区分接纳数与执行许可，等待父 run 让出许可但保留会话所有权 | 原审阅 Agent 已确认文本闭合 |
|
||||
| U6 先于 outbox 依赖 | 提前声明事务投递机制完成或重复建设 | U6 分追赶修复、outbox、向量三个切片并分别列前置 | 原审阅 Agent 已确认文本闭合 |
|
||||
| P0 权限检查落到后期 | 首期团队版可能未验证 SSE/检索/工具撤权 | U7 单实例放行前验证完整现有 R6 入口矩阵；新增跨机能力另验 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 过渡期本地权威未说清 | 尚未迁移的 checkpoint/续跑文件可能被当缓存清除 | KTD2 增加首期与多实例期归属表，联合备份，U5 前禁止跨机接管 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 只读适配器不足以判断写入/审批 | 可能把共享可读扩大成可写 | KTD13/U3 指定动作授权矩阵、版本化兼容与默认拒绝，不新建成员权威 | 原审阅 Agent 已确认文本闭合 |
|
||||
| 迁移/备份敏感副本保护未列 | 源库秘密可能经备份旁路暴露 | KTD14 指定访问、加密、密钥分离、保留与恢复验证；正式导出前缺项阻塞 | 原审阅 Agent 已确认文本闭合 |
|
||||
|
||||
主编另依据 PostgreSQL 官方 PITR 文档修正备份描述：pg_dump 是逻辑备份，不能作为 WAL 回放基础；PITR 使用物理基础备份加连续 WAL。未改变用户确认的规模与未来分布式方向。
|
||||
|
||||
## 剩余决策与验证边界
|
||||
|
||||
- 10–100 人、多项目、多会话及未来多服务分布式：用户已确认需求方向。
|
||||
- 量化容量/恢复目标、正式实例和数据归属、迁移窗口、资源与实施阶段：待人工评审。
|
||||
- 本记录只说明文档中的九项问题已经改写并由原 Agent 复读，不说明实现缺陷已修复。
|
||||
- 实施、真实 PG/Redis 测试、压测、故障注入、数据迁移、恢复演练与部署：全部 NOT_RUN。
|
||||
- 方案正文与调查收据的字节摘要由文档检查命令写入 Dev 任务卡，作为本次候选身份；本文件不手写命令结果。
|
||||
Reference in New Issue
Block a user