docs: 重构仓库文档目录并迁移训练素材
按当前架构重组 docs 目录，统一中文命名与目录分层，并将训练原材料迁移到独立目录以保持架构文档边界清晰。
This commit is contained in:
eaiadmin
@@ -0,0 +1,751 @@
|
||||
# SY22 — Expert / Skill / App 统一任务架构
|
||||
|
||||
> 状态：总架构扩展确认稿
|
||||
> 日期：2026-09-16
|
||||
> 关联文档：
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY17_工作台界面线框稿.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY20_角色卡与轻量本体架构.md`
|
||||
> - `SY21_统一角色技能动作架构.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 这份文档要解决什么问题
|
||||
|
||||
在 `SY21` 中，平台已经正式收敛为六层架构，并明确了：
|
||||
|
||||
- 对外暴露 `专家 / 技能 / 连接器`
|
||||
- 对内运行 `expert / skill / action / connector / policy`
|
||||
- 不再继续扩张 `tool` 概念
|
||||
|
||||
但随着工作台进一步向 WorkBuddy 类产品演进，系统需要新增一种与专家、技能并列的一级对象。
|
||||
|
||||
**这类对象就是 App。**
|
||||
|
||||
它具备以下特征：
|
||||
|
||||
- 不是以对话为主交互
|
||||
- 有自己长期存在的主界面
|
||||
- 有结构化状态、表单、题卡、看板、画布等交互
|
||||
- 启动后应成为一个长程任务实例
|
||||
- 可挂载右栏 AI、可调用技能、可沉淀业务产物
|
||||
|
||||
因此，这份文档正式确认：
|
||||
|
||||
> **平台需要第三类一级对象：App。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 最终结论
|
||||
|
||||
## 2.1 六层总架构继续成立，但第五层升级
|
||||
|
||||
`SY21` 的六层架构继续有效：
|
||||
|
||||
1. 外部连接层
|
||||
2. 本体与语义上下文层
|
||||
3. 总线与编排层
|
||||
4. 能力层
|
||||
5. 对象层
|
||||
6. 工作台与运行治理层
|
||||
|
||||
本次变化是在保留六层架构的前提下，把第五层正式升级为：
|
||||
|
||||
> **对象层（Expert / Skill / App）**
|
||||
|
||||
## 2.2 App 是一级对象，承接长程任务运行壳
|
||||
|
||||
App 的准确定义是：
|
||||
|
||||
> **面向某类长程任务的状态化运行壳。**
|
||||
|
||||
它与 Skill 的区别在于：
|
||||
|
||||
- `skill` 解决“做什么”
|
||||
- `app` 解决“这类工作如何持续运行、展示、交互、留痕”
|
||||
|
||||
它与 Expert 的区别在于：
|
||||
|
||||
- `expert` 解决“谁在与你协作”
|
||||
- `app` 解决“这项工作在什么界面和状态机里被推进”
|
||||
|
||||
## 2.3 任务不再等于对话
|
||||
|
||||
平台后续的统一定义应为：
|
||||
|
||||
> **任务 = 一个工作实例容器**
|
||||
|
||||
这个容器里可以挂载：
|
||||
|
||||
- 一个主 `app`
|
||||
- 一个右栏 `expert`
|
||||
- 多个后台 `skill`
|
||||
- 若干 `connector`
|
||||
|
||||
因此：
|
||||
|
||||
- 对话是任务中的一种交互轨迹
|
||||
- 消息流是部分任务的主界面形态
|
||||
|
||||
## 2.4 长程APP是一级导航，但一级导航必须完整描述
|
||||
|
||||
`app` 升格后，不能只补一句“新增长程APP”，否则会把整个一级导航重新说乱。
|
||||
|
||||
一级导航不再是同质栏目，而应明确分成四类：
|
||||
|
||||
1. 工作入口
|
||||
2. 对象目录
|
||||
3. 组织知识入口
|
||||
4. 治理与个人入口
|
||||
|
||||
推荐的一级导航全景应为：
|
||||
|
||||
1. `新建任务`
|
||||
- 对话驱动任务的默认入口
|
||||
- 负责创建以 `expert` 为主对象的任务
|
||||
2. `项目`
|
||||
- 任务容器与聚合视图
|
||||
- 用于组织多个长程任务与对话任务
|
||||
3. `专家 · 技能 · 连接器`
|
||||
- 对象目录与配置浏览入口
|
||||
- 这里看的是定义，不是运行时
|
||||
4. `长程APP`
|
||||
- `app` 定义卡片入口
|
||||
- 这里展示的是可启动的长程 App，不是历史任务
|
||||
5. `知识库`
|
||||
- 组织级默认内建 App 的直达入口
|
||||
- 承载组织专有知识、素材、题库、结果记录等核心资产
|
||||
- 是 Expert 与 App 共同消费的知识底座
|
||||
6. `后台管理`
|
||||
- 工坊、系统配置、对象治理、权限治理
|
||||
- 是平台治理入口，不是业务运行入口
|
||||
7. `我的`
|
||||
- 个人总览、我的资料、个人偏好与个人工作视角
|
||||
|
||||
这里最重要的边界是：
|
||||
|
||||
- `专家 · 技能 · 连接器` 看的是对象定义与配置
|
||||
- `长程APP` 看的是可运行的 `app`
|
||||
- `项目` 看的是任务集合
|
||||
- `知识库` 看的是组织级知识底座与其内建 App 运行面
|
||||
|
||||
这里需要明确一个特例：
|
||||
|
||||
> **知识库本身也是 `app`，并作为组织级默认必须存在的内建 App。**
|
||||
|
||||
原因是：
|
||||
|
||||
- 平台服务的是单一组织而不是开放公域
|
||||
- 没有组织专有知识，很多 Expert 与 App 无法稳定运行
|
||||
- 知识库不仅提供资料查看，还承担沉淀、审批、引用、题库与知识资产治理
|
||||
|
||||
因此在产品层，知识库同时具有两种身份：
|
||||
|
||||
1. 在对象模型里，它属于 `app.knowledge_hub`
|
||||
2. 在一级导航里，它拥有保留的直达入口，不必埋进“长程APP”卡片列表
|
||||
|
||||
点击 `长程APP` 里的卡片后，标准动作应为：
|
||||
|
||||
1. 创建任务实例
|
||||
2. 挂载主 `app`
|
||||
3. 进入该 `app` 的运行界面
|
||||
4. 同时进入统一任务列表
|
||||
|
||||
当前像 `AI考试` 这种已经长出独立业务界面的主导航，在架构上属于**过渡态专题入口**。
|
||||
后续收敛路径为：
|
||||
|
||||
- `长程APP -> app.training_exam`
|
||||
|
||||
---
|
||||
|
||||
## 3. 三类一级对象的边界
|
||||
|
||||
## 3.1 Expert
|
||||
|
||||
`expert` 是面向用户协作的交互外壳。
|
||||
|
||||
核心职责：
|
||||
|
||||
- 理解意图
|
||||
- 引导开场
|
||||
- 陪伴推进
|
||||
- 解释状态
|
||||
- 调度技能
|
||||
|
||||
典型交互：
|
||||
|
||||
- 对话主导
|
||||
- 欢迎语
|
||||
- starter prompts
|
||||
- 右栏 AI 助手
|
||||
|
||||
## 3.2 Skill
|
||||
|
||||
`skill` 是面向任务复用的能力包。
|
||||
|
||||
核心职责：
|
||||
|
||||
- 封装某类能力
|
||||
- 编排 `action`
|
||||
- 规范输入输出
|
||||
- 生成产物
|
||||
|
||||
典型交互：
|
||||
|
||||
- 被角色调用
|
||||
- 被 App 调用
|
||||
- 被工作流调用
|
||||
|
||||
## 3.3 App
|
||||
|
||||
`app` 是面向场景化长程任务或组织级运行面的运行壳。
|
||||
|
||||
核心职责：
|
||||
|
||||
- 承载主界面
|
||||
- 驱动状态机
|
||||
- 管理结构化数据
|
||||
- 组织多步骤交互
|
||||
- 沉淀长程产物
|
||||
|
||||
典型交互：
|
||||
|
||||
- 菜单
|
||||
- 表单
|
||||
- 按钮
|
||||
- 题卡
|
||||
- 看板
|
||||
- 画布
|
||||
|
||||
其中应区分两类 App：
|
||||
|
||||
1. **任务型 App**
|
||||
- 进入后通常创建 `app_task`
|
||||
- 例如培训考试、审批、数据分析、流程编排
|
||||
2. **底座型 App**
|
||||
- 组织级长期存在，默认安装
|
||||
- 例如知识库
|
||||
- 它既提供独立运行面，也为其他任务提供知识支撑
|
||||
|
||||
AI 在 App 中通常位于：
|
||||
|
||||
- 右栏副驾驶位
|
||||
- 辅助填表
|
||||
- 规则解释
|
||||
- 状态总结
|
||||
- 自然语言触发复杂动作
|
||||
|
||||
---
|
||||
|
||||
## 4. 六层架构回溯后的新定义
|
||||
|
||||
## 4.1 第一层：外部连接层
|
||||
|
||||
这一层继续负责连接真实世界与外部系统。
|
||||
|
||||
包括：
|
||||
|
||||
- 本地文件系统
|
||||
- 企业业务系统
|
||||
- 工业系统
|
||||
- 培训 / 考试 / OA / ERP / MES / CRM / LMS
|
||||
- 模型服务
|
||||
- API / Webhook / MQ
|
||||
|
||||
这一层回答的是：
|
||||
|
||||
**数据从哪里来，动作往哪里去。**
|
||||
|
||||
## 4.2 第二层：本体与语义上下文层
|
||||
|
||||
这一层需要从行业对象语义继续扩展到工作对象语义。
|
||||
|
||||
除了原有：
|
||||
|
||||
- device
|
||||
- alarm
|
||||
- work_order
|
||||
- report
|
||||
|
||||
还应补充：
|
||||
|
||||
- task
|
||||
- stage
|
||||
- expert
|
||||
- skill
|
||||
- app
|
||||
- artifact
|
||||
- form
|
||||
- workflow
|
||||
- record
|
||||
|
||||
对于 `app`，这一层必须支持：
|
||||
|
||||
- App 处理的业务对象类型
|
||||
- App 允许的阶段类型
|
||||
- App 产物类型
|
||||
- App 与 Expert / Skill 的可挂载关系
|
||||
|
||||
这一层回答的是：
|
||||
|
||||
**平台到底在处理哪些业务对象、工作对象和它们之间的关系。**
|
||||
|
||||
## 4.3 第三层：总线与编排层
|
||||
|
||||
这一层继续承担流转职责，但要正式接纳 `app` 作为任务主对象。
|
||||
|
||||
至少应包含：
|
||||
|
||||
1. 任务总线
|
||||
2. 事件总线
|
||||
3. 对象挂载总线
|
||||
4. 能力编排总线
|
||||
|
||||
新职责包括：
|
||||
|
||||
- 任务创建后挂载主 `app`
|
||||
- 根据 `app` 状态切换工作台界面
|
||||
- 允许右栏 `expert` 感知当前 `app` 上下文
|
||||
- 允许 `app` 调度 `skill`
|
||||
- 允许人工接管与审批节点插入
|
||||
|
||||
这一层回答的是：
|
||||
|
||||
**任务如何创建，对象如何挂载，状态如何推进，能力如何协作。**
|
||||
|
||||
## 4.4 第四层：能力层
|
||||
|
||||
这一层继续保持：
|
||||
|
||||
- `skill`
|
||||
- `action`
|
||||
- `policy`
|
||||
|
||||
但要明确一个边界：
|
||||
|
||||
> **App 不进入能力层。**
|
||||
|
||||
原因是：
|
||||
|
||||
- `skill` 是能力包
|
||||
- `action` 是原子动作
|
||||
- `app` 是运行壳
|
||||
|
||||
App 可以调用 Skill，但不替代 Skill。
|
||||
|
||||
## 4.5 第五层：对象层
|
||||
|
||||
这一层正式收敛为：
|
||||
|
||||
- `expert`
|
||||
- `skill`
|
||||
- `app`
|
||||
|
||||
并且三者都应该具备：
|
||||
|
||||
- 对象定义
|
||||
- 版本信息
|
||||
- 生命周期状态
|
||||
- 权限边界
|
||||
- 可挂载关系
|
||||
|
||||
这一层回答的是：
|
||||
|
||||
**平台有哪些可被用户使用、可被任务挂载、可被版本化治理的一等对象。**
|
||||
|
||||
## 4.6 第六层：工作台与运行治理层
|
||||
|
||||
这一层不再只有单一对话工作台，而应明确分成两类运行现场：
|
||||
|
||||
### A. 对话工作台
|
||||
|
||||
- 以专家为主
|
||||
- 适合模糊任务、探索任务、咨询任务
|
||||
- 中央区域以消息流为主
|
||||
|
||||
### B. 长程APP
|
||||
|
||||
- 以 App 为主
|
||||
- 适合强状态、强结构、长周期任务
|
||||
- 中央区域以业务界面为主
|
||||
- AI 位于右栏
|
||||
|
||||
两者统一纳入：
|
||||
|
||||
- 同一任务列表
|
||||
- 同一运行治理体系
|
||||
- 同一审计和产物体系
|
||||
|
||||
---
|
||||
|
||||
## 5. 统一任务模型
|
||||
|
||||
## 5.1 任务是工作实例容器
|
||||
|
||||
新的任务定义应为：
|
||||
|
||||
> **task = 一次完整工作实例**
|
||||
|
||||
它负责统一承载：
|
||||
|
||||
- 当前主对象
|
||||
- 当前阶段
|
||||
- 当前参与对象
|
||||
- 当前运行状态
|
||||
- 当前产物集合
|
||||
|
||||
## 5.2 一个任务可挂多个对象实例
|
||||
|
||||
建议使用如下运行模型：
|
||||
|
||||
- 主挂载：`app` 或 `expert`
|
||||
- 右栏挂载：`expert`
|
||||
- 后台挂载：`skill`
|
||||
|
||||
例如一个培训考试任务可以是：
|
||||
|
||||
- 主对象：`app.training_exam`
|
||||
- 右栏对象：`expert.learning_coach`
|
||||
- 后台能力：`skill.auto_grading`
|
||||
- 后台能力：`skill.study_plan_generation`
|
||||
|
||||
## 5.3 会话只是任务的一部分
|
||||
|
||||
以后应避免继续把任务状态写死在消息流里。
|
||||
|
||||
更准确的关系是：
|
||||
|
||||
- `task`：工作容器
|
||||
- `task_message`：对话轨迹
|
||||
- `app_state`：App 主状态
|
||||
- `artifact`：产物
|
||||
- `event`：运行轨迹
|
||||
|
||||
---
|
||||
|
||||
## 6. 存储架构建议
|
||||
|
||||
## 6.1 对象定义层
|
||||
|
||||
建议继续使用统一根定义：
|
||||
|
||||
- `object_definition`
|
||||
- `object_version`
|
||||
|
||||
关键字段建议：
|
||||
|
||||
- `object_id`
|
||||
- `object_type`：`expert | skill | app`
|
||||
- `code`
|
||||
- `key`
|
||||
- `label`
|
||||
- `status`
|
||||
- `manifest`
|
||||
- `schema_version`
|
||||
|
||||
其中 `app.manifest` 至少应包含：
|
||||
|
||||
- `object_entry_route`
|
||||
- `layout_type`
|
||||
- `supported_views`
|
||||
- `default_sidebar_expert`
|
||||
- `allowed_skills`
|
||||
- `state_schema`
|
||||
- `artifact_schema`
|
||||
- `permission_model`
|
||||
|
||||
为避免与 AI 路由和普通页面导航混同，当前项目统一采用三类命名：
|
||||
|
||||
- `ai_route_*`：AI 模型路由
|
||||
- `object_entry_route`：专家 / 技能 / APP 这类业务对象的进入入口
|
||||
- `page_route`：普通页面导航路径
|
||||
|
||||
## 6.2 任务与挂载层
|
||||
|
||||
建议新增或统一为：
|
||||
|
||||
- `task`
|
||||
- `task_object_instance`
|
||||
|
||||
`task` 核心字段建议：
|
||||
|
||||
- `task_id`
|
||||
- `task_type`：`conversation_task | app_task`
|
||||
- `title`
|
||||
- `status`
|
||||
- `source_object_type`
|
||||
- `source_object_id`
|
||||
- `current_stage`
|
||||
- `started_at`
|
||||
- `completed_at`
|
||||
|
||||
`task_object_instance` 核心字段建议：
|
||||
|
||||
- `task_object_instance_id`
|
||||
- `task_id`
|
||||
- `object_id`
|
||||
- `object_version_id`
|
||||
- `object_type`
|
||||
- `mount_slot`：`main | right_sidebar | background`
|
||||
- `instance_role`：`primary | assistant | worker`
|
||||
|
||||
## 6.3 运行轨迹层
|
||||
|
||||
建议使用：
|
||||
|
||||
- `object_run`
|
||||
- `task_message`
|
||||
|
||||
其中：
|
||||
|
||||
- `object_run` 记录对象执行、阶段推进、技能调用、人工确认
|
||||
- `task_message` 仅记录对话内容和消息元数据
|
||||
|
||||
需要明确：
|
||||
|
||||
> **`task_message` 不再承担 App 主状态存储责任。**
|
||||
|
||||
## 6.4 App 状态层
|
||||
|
||||
建议为 `app` 单独引入运行时状态存储：
|
||||
|
||||
- `app_instance_state`
|
||||
- `app_event`
|
||||
- `app_artifact`
|
||||
|
||||
`app_instance_state` 建议存：
|
||||
|
||||
- `task_id`
|
||||
- `task_object_instance_id`
|
||||
- `workflow_state`
|
||||
- `ui_state`
|
||||
- `form_state`
|
||||
- `selected_record_id`
|
||||
- `snapshot_version`
|
||||
|
||||
`app_event` 建议存：
|
||||
|
||||
- `event_type`
|
||||
- `payload`
|
||||
- `operator`
|
||||
- `created_at`
|
||||
|
||||
`app_artifact` 建议存：
|
||||
|
||||
- `artifact_type`
|
||||
- `artifact_uri`
|
||||
- `artifact_meta`
|
||||
- `produced_by`
|
||||
- `created_at`
|
||||
|
||||
## 6.5 领域数据层
|
||||
|
||||
对于复杂 App，不应把所有业务数据都塞进 `app_instance_state.payload_json`。
|
||||
|
||||
必须允许按领域建模。
|
||||
|
||||
例如培训考试 App 可拥有独立领域表：
|
||||
|
||||
- `training_plan`
|
||||
- `course_module`
|
||||
- `exam_paper`
|
||||
- `exam_question`
|
||||
- `exam_attempt`
|
||||
- `exam_answer`
|
||||
- `exam_score`
|
||||
|
||||
因此存储应分为：
|
||||
|
||||
- 通用运行表：承载平台运行
|
||||
- 领域业务表：承载业务事实
|
||||
|
||||
---
|
||||
|
||||
## 7. 前端与交互层含义
|
||||
|
||||
## 7.1 一级导航升级
|
||||
|
||||
前端一级导航不能只补“长程APP”这一项，而应整体升级为完整的信息架构。
|
||||
|
||||
建议目标态如下：
|
||||
|
||||
1. `新建任务`
|
||||
- 默认进入对话工作台
|
||||
- 主对象通常为 `expert`
|
||||
2. `项目`
|
||||
- 承载项目列表与项目详情
|
||||
- 用于聚合任务、产物与阶段
|
||||
3. `专家 · 技能 · 连接器`
|
||||
- 展示 `expert / skill / connector` 的定义目录
|
||||
- 负责浏览、筛选、配置、安装态查看
|
||||
4. `长程APP`
|
||||
- 展示 `app` 定义卡片
|
||||
- 负责启动 `app_task`
|
||||
5. `知识库`
|
||||
- 作为默认必须存在的内建 App 直接出现在一级导航
|
||||
- 承载组织知识、素材、题库、记录与知识治理
|
||||
- 是任务运行的公共知识面
|
||||
6. `后台管理`
|
||||
- 承载工坊、系统配置、组织与治理能力
|
||||
7. `我的`
|
||||
- 承载个人总览、个人资料与个人入口
|
||||
|
||||
因此，一级导航里实际并存四种不同语义：
|
||||
|
||||
- 工作启动入口：`新建任务`
|
||||
- 工作组织入口：`项目`
|
||||
- 对象目录入口：`专家 · 技能 · 连接器`、`长程APP`
|
||||
- 组织知识与治理入口：`知识库`、`后台管理`、`我的`
|
||||
|
||||
### 7.1.1 为什么必须这样写全
|
||||
|
||||
如果只写：
|
||||
|
||||
- 专家
|
||||
- 技能
|
||||
- 长程APP
|
||||
|
||||
会遗漏三件事：
|
||||
|
||||
1. `项目` 其实是统一任务系统的重要容器，不是普通页面
|
||||
2. `知识库` 是组织级默认内建 App，也是 Expert 和 App 的共用知识底座，不是边角内容
|
||||
3. `后台管理 / 我的` 分别承担治理与个人视角，不应被误解为附属页
|
||||
|
||||
### 7.1.2 当前专题主导航的收敛原则
|
||||
|
||||
凡是已经长成“非对话式、强结构、强状态”的专题栏目，例如：
|
||||
|
||||
- 培训考试
|
||||
- 审批中心
|
||||
- 数据分析台
|
||||
- 流程编排台
|
||||
|
||||
在目标架构中都应优先判断为 `app`，最终收敛进：
|
||||
|
||||
- `长程APP`
|
||||
|
||||
而不是继续无限增长新的专题型一级导航。
|
||||
|
||||
唯一应保留一级直达入口的 App，是像 `知识库` 这种**组织级默认必装底座 App**。
|
||||
|
||||
## 7.2 进入 App 的标准动作是“创建任务”
|
||||
|
||||
点击 App 卡片后的标准动作应为：
|
||||
|
||||
1. 创建 `task`
|
||||
2. 创建主 `task_object_instance(app)`
|
||||
3. 自动挂载右栏 `expert`
|
||||
4. 进入 `app runtime`
|
||||
|
||||
## 7.3 App 运行界面不再强制对话居中
|
||||
|
||||
App 主界面应由业务形态决定，例如：
|
||||
|
||||
- 培训考试：课程目录、题卡、成绩面板
|
||||
- 审批：表单、节点、操作栏
|
||||
- 数据分析：图表、筛选器、表格
|
||||
- 流程编排：画布、节点、日志
|
||||
|
||||
AI 对话框在 App 中退居右栏能力区。
|
||||
|
||||
---
|
||||
|
||||
## 8. 样板场景：培训考试 App
|
||||
|
||||
## 8.1 对象组合
|
||||
|
||||
- 主对象：`app.training_exam`
|
||||
- 右栏对象：`expert.learning_coach`
|
||||
- 调用技能：`skill.generate_study_plan`
|
||||
- 调用技能：`skill.auto_grade_exam`
|
||||
|
||||
## 8.2 任务阶段
|
||||
|
||||
建议阶段至少包括：
|
||||
|
||||
1. 待建档
|
||||
2. 培训中
|
||||
3. 练习中
|
||||
4. 待模拟考
|
||||
5. 模拟考完成
|
||||
6. 待正式考试
|
||||
7. 正式考试中
|
||||
8. 待复盘
|
||||
9. 待补训
|
||||
10. 已结业
|
||||
|
||||
## 8.3 交互形态
|
||||
|
||||
- 培训中：课程目录 + 内容区 + 右栏 AI 教练
|
||||
- 练习中：题目区 + 即时讲解
|
||||
- 正式考试中：题卡 + 倒计时 + 受控作答区
|
||||
- 复盘中：错题分析 + 补训计划 + 证书面板
|
||||
|
||||
这个样板说明：
|
||||
|
||||
> **同一个任务实例中，对话、结构化界面、技能执行、产物沉淀可以长期共存。**
|
||||
|
||||
---
|
||||
|
||||
## 9. 迁移指导
|
||||
|
||||
## 9.1 术语迁移
|
||||
|
||||
对外：
|
||||
|
||||
- 专家
|
||||
- 技能
|
||||
- 长程APP
|
||||
|
||||
一级导航目标态：
|
||||
|
||||
- 新建任务
|
||||
- 项目
|
||||
- 专家 · 技能 · 连接器
|
||||
- 长程APP
|
||||
- 知识库
|
||||
- 后台管理
|
||||
- 我的
|
||||
|
||||
对内：
|
||||
|
||||
- `expert`
|
||||
- `skill`
|
||||
- `app`
|
||||
- `action`
|
||||
- `connector`
|
||||
- `policy`
|
||||
|
||||
## 9.2 后端迁移重点
|
||||
|
||||
1. 从“任务 = 对话”迁移到“任务 = 工作实例”
|
||||
2. 新增 `app` 对象定义与版本机制
|
||||
3. 新增 `task_object_instance`
|
||||
4. 新增 `app_state / app_event / app_artifact`
|
||||
5. 把消息表从主状态中心降级为对话轨迹层
|
||||
|
||||
## 9.3 前端迁移重点
|
||||
|
||||
1. 把一级导航整理为“新建任务 / 项目 / 专家 · 技能 · 连接器 / 长程APP / 知识库 / 后台管理 / 我的”
|
||||
2. 新增“长程APP”并以对象定义驱动 App 卡片列表与详情页
|
||||
3. 将现有专题型一级导航逐步收敛为 `app`，避免继续平铺新的业务主栏目；`知识库` 作为默认必装底座 App 保留一级直达入口
|
||||
4. 统一任务列表兼容 `conversation_task` 和 `app_task`
|
||||
5. App Runtime 布局支持“主业务区 + 右栏 AI”
|
||||
|
||||
---
|
||||
|
||||
## 10. 最终定义
|
||||
|
||||
这次架构升级后的平台可以正式定义为：
|
||||
|
||||
> **一个以统一任务系统为核心、同时承载 Expert / Skill / App 三类一级对象的工业智能体操作平台。**
|
||||
|
||||
其中：
|
||||
|
||||
- `Expert` 负责协作
|
||||
- `Skill` 负责能力
|
||||
- `App` 负责长程任务运行壳
|
||||
- `Task` 负责统一承载工作实例
|
||||
|
||||
这意味着平台当前采用以下运行形态：
|
||||
|
||||
> **对话工作台与长程APP并存，但统一运行、统一治理、统一沉淀。**
|
||||
Reference in New Issue
Block a user