# 当前权威架构基线

**版本：** 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.历史设计归档/` 仅用于追溯历史背景，不再作为当前设计入口。