154 lines
5.5 KiB
Markdown
154 lines
5.5 KiB
Markdown
# 当前权威架构基线
|
||
|
||
**版本：** 2026-08-07 整合版
|
||
**主来源：** `01.当前有效设计/APP架构设计.md`、`01.当前有效设计/02.正式方案/*.md`
|
||
**补充来源：** `90.历史设计归档/` 中与当前实现不冲突的背景材料
|
||
|
||
## 1. 一句话结论
|
||
|
||
当前 LineUp 的权威架构基线应理解为：
|
||
|
||
**LineUp 是用户设备上的主应用；Runtime 是 LineUp App 内部的核心协调环境；MiniApp、Tool、Surface 和 Capability 都必须通过 Runtime 被管理，而不是各自直连服务端或 Agent。**
|
||
|
||
这一定义以当前有效设计区为准，比历史归档中的直连插件、早期 WebSocket 草案更接近今天的实际实现。
|
||
|
||
## 2. 当前产品结构
|
||
|
||
当前主线结构可以收敛为：
|
||
|
||
```text
|
||
LineUp App
|
||
├── App Shell / Host
|
||
│ ├── Tauri Desktop Host
|
||
│ └── Web Reference Host
|
||
├── LineUp Runtime
|
||
│ ├── 通信、会话、同步和 outbox
|
||
│ ├── App Registry、Instance、Focus、Lifecycle
|
||
│ ├── Tool Router、Inventory、Inbox
|
||
│ ├── Surface、Capability、Artifact、Audit
|
||
│ └── MiniApp SDK
|
||
└── MiniApps
|
||
├── Interact
|
||
├── Task Dashboard
|
||
├── Whiteboard
|
||
├── Pomodoro
|
||
└── 后续其他 MiniApp
|
||
```
|
||
|
||
## 3. 当前最重要的架构边界
|
||
|
||
### 3.1 App、Runtime、Host 三者分离
|
||
|
||
这是当前设计最关键的共识：
|
||
|
||
- `LineUp App` 是用户安装和使用的产品容器；
|
||
- `Runtime` 是 App 内部唯一拥有通信、可靠性、调度和安全决策的协调中心；
|
||
- `Host` 负责提供桌面或浏览器环境，但不能绕过 Runtime 直接把系统能力交给 App 或 Agent。
|
||
|
||
### 3.2 MiniApp 不能绕过 Runtime
|
||
|
||
所有 MiniApp 都必须通过 Runtime SDK 获得：
|
||
|
||
- 消息与 Inbox；
|
||
- Tool 调用；
|
||
- 生命周期；
|
||
- Surface；
|
||
- Capability；
|
||
- 受控状态投影。
|
||
|
||
它们不能：
|
||
|
||
- 直接连接 AppServer 或 Agent；
|
||
- 直接读写 Runtime Store、cursor、outbox；
|
||
- 直接调用 Host 特权或 Tauri 能力；
|
||
- 直接操控其他 MiniApp 或焦点栈。
|
||
|
||
### 3.3 Agent 只与 Runtime 通信
|
||
|
||
当前主线下，Agent 不应直接把某个 MiniApp 当作远端可执行对象，而是只能通过 Runtime 发布出来的受控 Tool / Inventory 与系统交互。
|
||
|
||
## 4. 当前 Host 基线
|
||
|
||
本轮整合后，当前唯一有效的客户端实现/验收基线是：
|
||
|
||
```text
|
||
Tauri 2 Desktop Host + Web Reference Host
|
||
```
|
||
|
||
这意味着：
|
||
|
||
- Web Host 是开发、联调和验证入口；
|
||
- Tauri Host 是正式桌面交付入口；
|
||
- 二者共享同一份 TypeScript Runtime 与 MiniApp 代码；
|
||
- 它们不是两套客户端。
|
||
|
||
与此冲突的早期判断，例如“当前以纯 Web 或未来移动端为主线”“局域网 App 直连 Agent 插件”，本轮都不再作为当前架构主结论保留。
|
||
|
||
## 5. 当前应用模型
|
||
|
||
### 5.1 Interact 是默认系统级入口
|
||
|
||
当前设计已经把“聊天页面”提升并重述为更高层的 `Interact`：
|
||
|
||
- 它是系统级 MiniApp；
|
||
- 当前默认模式是 IM；
|
||
- 后续可扩展 Voice / Video；
|
||
- 当前代码与作用域仍保留 `chat` 兼容命名，但概念上应理解为 `Interact`。
|
||
|
||
### 5.2 Runtime 管理实例、焦点和恢复
|
||
|
||
当前基线不再把 App 看成静态页面集合，而是 Runtime 管理的一组实例：
|
||
|
||
- 哪些 App 已注册；
|
||
- 哪些实例正在运行；
|
||
- 谁在前台；
|
||
- 谁被挂起；
|
||
- 如何恢复；
|
||
- 关闭或失败后如何回退到前一有效实例。
|
||
|
||
这也是后续工作区、Pomodoro、子会话、恢复与验收闭环成立的基础。
|
||
|
||
## 6. 当前 Tool 与 Inventory 模型
|
||
|
||
早期文档把工具分成 `app / toolset / action` 三类，这是有历史价值的草案；但当前主线已经收敛为：
|
||
|
||
- MiniApp 在受控声明中暴露可发布能力；
|
||
- Runtime 进行校验、裁剪和动态汇总；
|
||
- Agent 只能调用当前可见 Inventory 中的方法；
|
||
- Tool 的生命周期、可见性、风险和结果由 Runtime 裁决。
|
||
|
||
因此，今天更适合使用“Agent Tool / Inventory / Tool Call / 业务结果 / 协议回执”这套术语，而不是继续把早期三分法当作当前实现的主模型。
|
||
|
||
## 7. 当前 Surface 与 Capability 约束
|
||
|
||
这一层是从当前有效设计区的 `02.正式方案/` 中明显成熟起来的：
|
||
|
||
- 复杂交互不再靠不受控页面，而是放入受限 Surface；
|
||
- 系统能力不属于 MiniApp 自动拥有的权限，而是 Runtime/Host 保管的 Capability；
|
||
- Agent、MiniApp、Surface 都不能绕过 Runtime 直接获得系统动作执行权。
|
||
|
||
这比 `agent_ops/设计/` 早期协议文档中的能力模型更接近当前安全边界。
|
||
|
||
## 8. 本轮对旧设计的取舍
|
||
|
||
### 8.1 仍保留的背景价值
|
||
|
||
- 产品不是任务管理系统；
|
||
- 需要结构化消息与工具调用；
|
||
- Agent 与 UI 渲染要解耦；
|
||
- 工具、传输、连接需要分层思考。
|
||
|
||
### 8.2 不再作为当前权威基线的旧结论
|
||
|
||
- 局域网 WebSocket 直连是当前主线；
|
||
- 当前客户端基线是“Web / 未来移动端”；
|
||
- 工具协议可以脱离 Runtime 架构单独成立；
|
||
- 早期 `app / toolset / action` 三分法就是当前 Tool 模型本身。
|
||
|
||
## 9. 当前建议阅读顺序
|
||
|
||
1. 先看本文，建立当前架构全景；
|
||
2. 再看 [Agent工具与运行时边界](./03.Agent工具与运行时边界.md)；
|
||
3. 如需原始来源，再回看 `01.当前有效设计/APP架构设计.md` 与 `01.当前有效设计/02.正式方案/` 各细化文档；
|
||
4. `90.历史设计归档/` 仅用于追溯历史背景，不再作为当前设计入口。
|