578 lines
27 KiB
Markdown
578 lines
27 KiB
Markdown
# LineUp IM Agent 交互平台：历史方案与实施计划（已归档）
|
||
|
||
**版本：** 0.2（提案）
|
||
**状态：** 已归档；不作为当前技术路线
|
||
**日期：** 2026-07-30
|
||
**原决策范围：** LineUp 的 IM 基础、人与 Agent 的交互协议、首个 Hermes 接入，以及唐僧叨叨 / WuKongIM 在体系中的职责。
|
||
|
||
> 归档说明（2026-08-03）：本方案依赖唐僧叨叨业务服务与 WuKongIM v2 运行栈；该路线已经退役。当前项目使用 WuKongIM 3.0 官方源码 + LineUp AppServer，客户端与 Mini Runtime 路线见 `lineup-app/` 和 `设计/02.正式方案/`。本文仅保留作为历史决策与兼容性分析记录。
|
||
|
||
---
|
||
|
||
## 1. 决策摘要
|
||
|
||
LineUp 的定位是一个连接**人、人与人协作、人与智能体**的交互平台。它以即时通讯的可靠连接和消息能力为基础，但不把产品限制为传统的聊天窗口。
|
||
|
||
LineUp 的核心能力是：用户与 Agent 可以在同一个会话中交换文本、媒体、状态、产物和结构化交互；Agent 可在用户授权边界内调用用户端工具，用户端将结构化结果可靠返回给 Agent。
|
||
|
||
因此，本方案作出以下正式决策：
|
||
|
||
1. **LineUp 以唐僧叨叨作为成熟 IM 业务层基础，以 WuKongIM 作为通讯内核。** 用户、联系人、群组、文件、工作台与现有多端客户端能力优先复用；仅在 LineUp 的产品需要超出现有能力时再扩展或替换。
|
||
2. **LineUp 的正式 Agent 交互通道采用 `增强后的 LineUp Client + WuKongIM 官方 SDK + LineUp 自定义消息协议`。** 该协议在唐僧叨叨的用户与业务体系内运行，不把 LineUp 限制为机器人文本对话。
|
||
3. **LineUp Agent Adapter / Gateway 作为外部常驻服务运行，负责连接 Agent Runtime 与 LineUp 协议。** Hermes 是第一个适配目标，后续可接入其他 Agent Runtime。
|
||
4. **唐僧叨叨 Robot Events API 是可复用的机器人接入能力。** 它适合快速提供文本型 Hermes 入口、通知和兼容降级；结构化工具交互的正式主载体仍是 LineUp 自定义消息协议。
|
||
5. **WuKongIM AI Plugin 不作为第一阶段核心依赖。** 它保留为后续的服务端路由、低延迟流式输出和自动化处理能力；待确认当前部署版本的插件机制与唐僧叨叨配套版本兼容后再评估。
|
||
6. **LineUp Client 是对唐僧叨叨客户端能力的面向 Agent 扩展，而不是孤立重造一个聊天客户端。** choice、confirm、canvas、artifact 等由 LineUp 模块实现，同时保留已有 IM 业务体验。
|
||
|
||
---
|
||
|
||
## 2. 产品目标与边界
|
||
|
||
### 2.1 产品目标
|
||
|
||
LineUp 让人和 Agent 在远程、跨设备、可恢复的 IM 会话中协作。交互不局限于文本问答，而是包含：
|
||
|
||
- 人与人：文本、图片、语音、文件与群组协作；
|
||
- 人与 Agent：自然语言、任务进度、状态、图像、文件和流式内容；
|
||
- Agent 与用户端工具：选择、确认、表单、画板、文件预览、设备能力等；
|
||
- Agent 与 Agent：在受控会话或频道中交换结构化协作消息；
|
||
- 用户对 Agent 的控制：继续、取消、修改指令、批准、拒绝和恢复。
|
||
|
||
### 2.2 关键体验目标
|
||
|
||
用户面对的不是一个只会输出文本的机器人，而是一个可呈现和操作工作内容的 Agent 会话。例如：
|
||
|
||
```text
|
||
Agent：需要确认部署目标
|
||
└─ LineUp Client 渲染为 choice 卡片
|
||
|
||
用户：选择“预发布”
|
||
└─ Client 返回结构化 tool.result
|
||
|
||
Agent：开始执行，持续更新进度
|
||
└─ Client 渲染进度与状态，不强迫用户阅读多段文本
|
||
|
||
Agent：生成架构草图
|
||
└─ Client 打开画板，持续接收 canvas.patch
|
||
|
||
用户：点击“暂停”，修改颜色后继续
|
||
└─ Client 发送控制事件或 tool.result
|
||
```
|
||
|
||
### 2.3 明确不承担的职责
|
||
|
||
- LineUp 不取代 Agent Runtime 的任务规划、工具调用引擎或记忆系统；
|
||
- LineUp 不把 WuKongIM 替换为自研消息服务器；
|
||
- LineUp 不在第一阶段实现多 Agent 编排平台；
|
||
- LineUp 不默认授予 Agent 对用户设备、文件或系统操作的无限权限；
|
||
- LineUp 不把所有消息都交给服务端 AI 插件处理。
|
||
|
||
---
|
||
|
||
## 3. 总体架构
|
||
|
||
```text
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ LineUp Client（唐僧客户端能力 + 扩展） │
|
||
│ │
|
||
│ 会话 / 聊天 / 媒体 / 文件 │
|
||
│ Agent 状态 / 进度 / 产物 │
|
||
│ Tool Registry / Choice / Confirm / Form / Canvas │
|
||
│ LineUp 自定义消息渲染与本地授权 │
|
||
└───────────────────────┬─────────────────────────────────────┘
|
||
│
|
||
│ WuKongIM SDK 长连接
|
||
│ 原生消息 + LineUp 自定义 Payload
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ WuKongIM │
|
||
│ │
|
||
│ 认证后连接、频道、可靠投递、离线同步、重连、顺序、流消息 │
|
||
└───────────────────────┬─────────────────────────────────────┘
|
||
│
|
||
│ 指定 Agent 频道 / 绑定路由
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ LineUp Agent Adapter / Gateway │
|
||
│ │
|
||
│ Actor / Device / Conversation 映射 │
|
||
│ LineUp 信封编解码、去重、持久 inbox/outbox │
|
||
│ call_id 生命周期、超时、取消、恢复、权限校验 │
|
||
│ Hermes Adapter、未来其他 Runtime Adapter │
|
||
└───────────────────────┬─────────────────────────────────────┘
|
||
│
|
||
▼
|
||
Hermes / 其他 Agent Runtime 与其本地工具
|
||
|
||
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 唐僧叨叨业务层（复用与扩展） │
|
||
│ │
|
||
│ 用户与认证 / 联系人与群组 / 文件与对象存储 / 工作台 / 管理端 │
|
||
│ Android、Web、PC 基础 IM 能力 / Robot Events（可选接入） │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 3.1 组件职责
|
||
|
||
| 组件 | 负责 | 不负责 |
|
||
|---|---|---|
|
||
| WuKongIM | 长连接、消息投递、离线同步、频道与消息流 | LineUp 工具语义、设备授权、Agent 会话管理 |
|
||
| 唐僧叨叨 | LineUp 的 IM 业务基础：用户、认证、好友、群组、文件、工作台、管理端与既有多端客户端 | 替代 LineUp 的 Agent 交互协议与工具语义 |
|
||
| LineUp Client | 在唐僧叨叨客户端基础能力上增加交互 UI、工具注册、本地授权、协议显示与回传 | Agent 任务规划与执行 |
|
||
| LineUp Adapter / Gateway | 协议路由、可靠性、会话与调用映射、Agent 适配 | 直接替代 IM 服务 |
|
||
| Hermes | 理解用户意图、执行任务、调用其工具、请求用户交互 | 负责移动端 UI 渲染 |
|
||
| WuKongIM AI Plugin（后续可选） | 服务端高性能路由、流式和自动化 Hook | 定义 LineUp 协议或取代唐僧叨叨业务层与 Adapter |
|
||
|
||
---
|
||
|
||
## 4. 协议分层与消息模型
|
||
|
||
### 4.1 三层分工
|
||
|
||
```text
|
||
LineUp 交互协议层
|
||
└─ 会话语义、Actor、设备能力、工具、状态、产物、取消与确认
|
||
|
||
WuKongIM 消息传输层
|
||
└─ 文本、媒体、文件、自定义 Payload 的可靠投递与同步
|
||
|
||
WuKongIM 连接层
|
||
└─ 认证、长连接、心跳、重连、离线恢复
|
||
```
|
||
|
||
LineUp 不重新实现下层 IM 可靠传输；WuKongIM 也不解释 LineUp 的工具和 UI 语义。
|
||
|
||
### 4.2 统一 LineUp 信封
|
||
|
||
所有自定义交互消息使用一个可演进的信封。基础媒体仍优先使用 IM 的原生媒体能力；信封保存其交互语义、引用关系或媒体元数据。
|
||
|
||
```json
|
||
{
|
||
"v": 1,
|
||
"id": "msg_01J...",
|
||
"type": "lineup.v1.tool.call",
|
||
"conversation_id": "conv_01J...",
|
||
"sender": {
|
||
"kind": "agent",
|
||
"id": "agent_hermes_main"
|
||
},
|
||
"target": {
|
||
"kind": "device",
|
||
"id": "device_phone_01"
|
||
},
|
||
"timestamp": "2026-07-30T14:00:00+08:00",
|
||
"payload": {}
|
||
}
|
||
```
|
||
|
||
字段规则：
|
||
|
||
- `v`：协议主版本。未知主版本必须拒绝执行，只可按安全降级显示；
|
||
- `id`：全局唯一的应用级消息 ID，用于幂等去重；
|
||
- `type`：以 `lineup.v1.` 为命名空间，禁止与基础 IM 类型混淆；
|
||
- `conversation_id`：LineUp 会话 ID，不以某一个 IM message ID 代替；
|
||
- `sender` / `target`：显式描述人、Agent、设备或群组，而不只依赖底层频道；
|
||
- `payload`：仅由对应 `type` 的 schema 定义。
|
||
|
||
### 4.3 第一批正式消息类型
|
||
|
||
| 类型 | 方向 | 目的 |
|
||
|---|---|---|
|
||
| `lineup.v1.text` | 双向 | 与 Agent 相关的结构化文本元数据；普通 IM 文本仍可原生发送 |
|
||
| `lineup.v1.device.hello` | Client → Gateway | 设备注册、客户端版本、协议版本、能力摘要 |
|
||
| `lineup.v1.tool.list` | 双向 | 声明或查询可用工具与 schema |
|
||
| `lineup.v1.tool.call` | Agent → Client | 请求调用用户端工具 |
|
||
| `lineup.v1.tool.result` | Client → Agent | 返回工具结果、拒绝、取消或错误 |
|
||
| `lineup.v1.tool.cancel` | 双向 | 取消尚未完成的调用 |
|
||
| `lineup.v1.agent.status` | Agent → Client | idle / thinking / waiting_input / running / interrupted / failed |
|
||
| `lineup.v1.agent.progress` | Agent → Client | 可合并、可覆盖的进度状态 |
|
||
| `lineup.v1.artifact.offer` | Agent → Client | 声明图片、文件、网页、报告、画板等可展示产物 |
|
||
| `lineup.v1.canvas.open` | Agent → Client | 创建一个受控画板实例 |
|
||
| `lineup.v1.canvas.patch` | Agent → Client | 增量更新画板内容 |
|
||
| `lineup.v1.canvas.close` | Agent → Client | 关闭画板实例 |
|
||
| `lineup.v1.stream.start/delta/end` | Agent → Client | 流式文本、代码、图形或状态输出 |
|
||
| `lineup.v1.ui.open/patch/close/event` | 双向 | 受控 HTML/CSS/JS UI Surface 的生命周期与用户事件 |
|
||
| `lineup.v1.app.list/call/result` | 双向 | Client 上层应用能力的声明、授权调用与结构化结果 |
|
||
|
||
不在第一阶段实现的消息类型可以预留命名空间，但不得先发布无 schema 的行为。
|
||
|
||
UI Surface 与 App Capability 的完整隔离、生命周期和权限约束见[《LineUp UI Surface 与 App Capability 协议》](lineup-ui-surface-protocol.md)。Surface 不是 Agent 在 Client 主进程执行任意代码的通道；它只能运行在受限容器中，并通过预定义 bridge 回传用户事件。任何上层 App / 原生能力必须经 `app.call`、用户确认和 capability registry 执行。
|
||
|
||
---
|
||
|
||
## 5. 用户端工具调用规范
|
||
|
||
### 5.1 工具注册
|
||
|
||
Client 在设备上线或能力变化后发布 `tool.list`。每个工具至少声明：
|
||
|
||
```json
|
||
{
|
||
"name": "choice",
|
||
"version": "1.0",
|
||
"type": "action",
|
||
"description": "展示选项并返回用户选择",
|
||
"inputSchema": {},
|
||
"outputSchema": {},
|
||
"risk": "user_confirmation"
|
||
}
|
||
```
|
||
|
||
工具分为三类：
|
||
|
||
- `action`：一次性操作，如 `choice`、`confirm`、`input`；
|
||
- `toolset`：无状态工具集合，如计算器、文件选择器；
|
||
- `app`：有生命周期的交互应用，如 `canvas`，通过 `instance_id` 管理 `open → use → close`。
|
||
|
||
### 5.2 调用与返回
|
||
|
||
```json
|
||
{
|
||
"v": 1,
|
||
"id": "msg_01J_call",
|
||
"type": "lineup.v1.tool.call",
|
||
"conversation_id": "conv_01J",
|
||
"sender": { "kind": "agent", "id": "agent_hermes_main" },
|
||
"target": { "kind": "device", "id": "device_phone_01" },
|
||
"payload": {
|
||
"call_id": "call_01J",
|
||
"name": "choice",
|
||
"action": "select",
|
||
"expires_at": "2026-07-30T14:10:00+08:00",
|
||
"arguments": {
|
||
"question": "部署到哪个环境？",
|
||
"options": ["测试", "预发布", "生产"]
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
返回必须携带相同 `call_id`，并且结果为可扩展对象，不长期限制为纯字符串：
|
||
|
||
```json
|
||
{
|
||
"v": 1,
|
||
"id": "msg_01J_result",
|
||
"type": "lineup.v1.tool.result",
|
||
"conversation_id": "conv_01J",
|
||
"sender": { "kind": "human", "id": "user_01" },
|
||
"target": { "kind": "agent", "id": "agent_hermes_main" },
|
||
"payload": {
|
||
"call_id": "call_01J",
|
||
"status": "completed",
|
||
"result": {
|
||
"selected": "预发布"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
`status` 的第一版枚举为：
|
||
|
||
```text
|
||
completed | rejected | cancelled | expired | unsupported | failed
|
||
```
|
||
|
||
### 5.3 调用状态机
|
||
|
||
```text
|
||
created
|
||
→ delivered
|
||
→ acknowledged_by_client
|
||
→ waiting_user
|
||
→ completed | rejected | cancelled | expired | failed
|
||
```
|
||
|
||
规则：
|
||
|
||
1. `call_id` 在 `conversation_id` 范围内唯一；
|
||
2. 同一个 `call_id` 的重复 `tool.call` 必须幂等显示，不能重复执行本地副作用；
|
||
3. `tool.result` 必须幂等转交给 Agent，Gateway 需持久记录最终状态；
|
||
4. Client 离线时调用可等待到 `expires_at`，不得无限期阻塞 Agent；
|
||
5. 用户、Agent 或系统取消后，旧调用及旧流输出不可覆盖新一代会话状态；
|
||
6. 高风险工具没有显式用户授权时，Client 必须返回 `rejected`，而不是静默执行。
|
||
|
||
---
|
||
|
||
## 6. 身份、会话、设备与权限
|
||
|
||
### 6.1 四种核心对象
|
||
|
||
| 对象 | 说明 | 示例 |
|
||
|---|---|---|
|
||
| Human | 一个经过 IM 认证的人类用户 | `user_01` |
|
||
| Device | 某个具体 Client 实例 | `device_phone_01` |
|
||
| Agent | 一个可接收和处理 LineUp 消息的 Agent 实例 | `agent_hermes_main` |
|
||
| Conversation | 人、人群或 Agent 间的一段稳定上下文 | `conv_01J` |
|
||
|
||
底层 WuKongIM 频道负责投递，LineUp `conversation_id` 负责产品语义。一个 Conversation 可映射到单聊、群聊、主题或多个设备，但映射关系必须由 Gateway 显式维护。
|
||
|
||
### 6.2 权限原则
|
||
|
||
1. 默认最小权限：Agent 只看得到被明确路由给它的会话；
|
||
2. 设备能力显式声明：没有在 `tool.list` 声明的工具不可调用；
|
||
3. 风险分级：`display_only`、`user_confirmation`、`system_permission`、`restricted`；
|
||
4. 人类可取消：用户在任一 Agent 会话中必须可发出取消/中断；
|
||
5. 群聊默认只响应明确提及或授权的 Agent；
|
||
6. Gateway 记录调用、确认、结果和取消的审计事件；
|
||
7. Agent Runtime 的本地终端、文件和浏览器权限不因 IM 通道自动扩大。
|
||
|
||
---
|
||
|
||
## 7. 可靠性、重连与用户插入指令
|
||
|
||
### 7.1 双层可靠性
|
||
|
||
```text
|
||
WuKongIM
|
||
└─ 连接、顺序、离线消息、重连与传输级可靠性
|
||
|
||
LineUp Gateway
|
||
└─ 应用级 idempotency、call_id 状态、inbox/outbox、Agent 执行恢复
|
||
```
|
||
|
||
Gateway 维护持久 inbox/outbox。任何消息只有在成功落入 inbox 后才视为被应用层接收；任何对 Agent 或 Client 的关键发送都要记录投递状态和应用级消息 ID。
|
||
|
||
### 7.2 用户中断
|
||
|
||
用户的新指令不能因为旧 Agent 任务运行很久而被阻塞：
|
||
|
||
```text
|
||
Client 新消息
|
||
→ WuKongIM 实时送达 Gateway
|
||
→ Gateway 按 conversation_id 分发
|
||
→ Hermes Adapter 调用 Hermes 的会话中断/追加机制
|
||
→ 旧 run 标记为过期 generation
|
||
→ 旧 run 的迟到输出禁止回写 Client
|
||
→ 新指令立即开始或进入指定队列
|
||
```
|
||
|
||
第一版约定：
|
||
|
||
- 普通新文本：默认 `interrupt` 当前同会话 Agent run；
|
||
- `/stop` 或显式“停止”：取消当前 run 并通知用户；
|
||
- “完成后再……”：由 Client 或 Adapter 标记为 queued follow-up；
|
||
- 不同 Conversation：相互独立，可并发处理。
|
||
|
||
---
|
||
|
||
## 8. 技术选型与当前环境定位
|
||
|
||
### 8.1 主通道选择
|
||
|
||
| 方案 | 结论 | 原因 |
|
||
|---|---|---|
|
||
| 唐僧叨叨业务层 | 正式业务基础 | 已提供用户、认证、联系人、群组、文件、工作台、管理端及多端客户端基础；LineUp 优先在其上生长，而非在第一阶段重新建设这些通用 IM 业务能力 |
|
||
| 唐僧叨叨 Robot Events API | 机器人接入与兼容通道 | 具备事件队列、ACK、机器人身份，适合文本 Hermes 入口、通知和降级交互；当前发送能力不适合作为完整结构化工具协议的唯一主载体 |
|
||
| WuKongIM AI Plugin | 后续可选 | 适合低延迟和服务端 Hook；当前部署为唐僧叨叨配套 WuKongIM v2，插件协议和管理能力需单独验证，且不替代 Client/Gateway 的产品语义 |
|
||
| WuKongIM SDK + 外部 LineUp Gateway | 正式 Agent 交互通道 | 在唐僧叨叨业务体系内保留自定义消息、双向实时、客户端工具、多个 Agent Runtime 与独立演进能力 |
|
||
|
||
### 8.2 当前部署的使用方式
|
||
|
||
当前环境维持：
|
||
|
||
```text
|
||
唐僧叨叨服务端 v1.5 + WuKongIM v2 + MySQL + Redis + MinIO
|
||
监听：100.121.118.116（Tailscale）
|
||
```
|
||
|
||
该环境在本方案中的职责：
|
||
|
||
- 以唐僧叨叨作为 LineUp 的既有业务基础，继续提供用户、认证、联系人、群组、文件、工作台和管理能力；
|
||
- 以 WuKongIM 承担基础 IM 服务、长连接、离线同步和自定义消息传输；
|
||
- 以现有唐僧 Android / Web 作为可复用的客户端基础，并逐步加入 LineUp 交互渲染与工具模块；
|
||
- 用于验证 LineUp Client 的 SDK 连接、消息、离线和媒体行为；
|
||
- 为 LineUp Gateway 提供受控网络内的消息服务；
|
||
- 可选提供唐僧 Robot Events 文本机器人、通知和降级入口。
|
||
|
||
不得为了启用 AI Plugin 而直接将该稳定配套环境替换为 WuKongIM 主线版本；插件实验必须使用独立测试实例。
|
||
|
||
---
|
||
|
||
## 9. 分阶段实施计划
|
||
|
||
### Phase 0：协议与可行性基线
|
||
|
||
**目标：** 在不改变现有生产性 IM 数据的前提下，确认 WuKongIM v2 可以承载 LineUp 自定义 Payload。
|
||
|
||
**工作项：**
|
||
|
||
1. 定义 `lineup.v1` 自定义 Payload 的编码、消息类型编号和最大体积；
|
||
2. 使用两个测试账户，通过官方 SDK 收发并解码一条 LineUp 信封；
|
||
3. 验证离线消息、多设备同步、顺序、重复投递与撤回等边界；
|
||
4. 验证图片、文件与自定义交互消息的引用关系；
|
||
5. 定义测试频道/Agent 身份命名规范；
|
||
6. 记录 WuKongIM v2 的精确 SDK 与协议限制。
|
||
|
||
**验收标准：**
|
||
|
||
- 任一端离线重连后，`lineup.v1.tool.call` 不丢失且不重复执行；
|
||
- 自定义消息可以被测试 Client 正确识别；
|
||
- 不改变现有唐僧叨叨用户、消息和 Docker 命名卷。
|
||
|
||
### Phase 1：LineUp 协议核心与最小 Gateway
|
||
|
||
**目标：** 打通 Client、Gateway 与一个模拟 Agent 的双向结构化交互。
|
||
|
||
**工作项：**
|
||
|
||
1. 实现 LineUp 信封编解码库与 JSON Schema；
|
||
2. 实现 Gateway 的 Actor、Device、Conversation 映射；
|
||
3. 实现 SQLite 持久 inbox/outbox 与消息去重；
|
||
4. 实现 `device.hello`、`tool.list`、`tool.call`、`tool.result`、`tool.cancel`；
|
||
5. 实现 `call_id` 状态机、超时和审计；
|
||
6. 使用模拟 Agent 发起 `choice` 与 `confirm`。
|
||
|
||
**验收标准：**
|
||
|
||
- Client 断线、Gateway 重启后，待处理工具调用仍可恢复；
|
||
- 重复投递不导致工具执行两次；
|
||
- 不受支持工具返回 `unsupported`；
|
||
- 用户拒绝、取消、超时能精确回到对应 Agent 调用。
|
||
|
||
### Phase 2：LineUp Client 最小交互面
|
||
|
||
**目标：** 从“聊天 UI”进入“Agent 交互 UI”。
|
||
|
||
**工作项：**
|
||
|
||
1. 基于现有唐僧叨叨客户端能力建立 LineUp Client 扩展层或受控分叉，保留登录、联系人、聊天、媒体与文件基础；
|
||
2. 接入并验证 WuKongIM SDK 的 LineUp 自定义 Payload；
|
||
3. 实现文本、Agent 状态、进度、choice、confirm、input；
|
||
4. 实现工具注册、风险提示、用户授权与结果回传；
|
||
5. 实现会话列表中的 Agent 标识、运行状态与取消入口；
|
||
6. 实现最小 Artifact 展示：图片与文件；
|
||
7. 记录客户端能力及版本兼容策略。
|
||
|
||
**验收标准：**
|
||
|
||
- 用户可在手机上完成 Agent 发起的选择和确认；
|
||
- Agent 能得到结构化而非文本猜测式的结果；
|
||
- 用户可在 Agent 工作期间中断并发送替代指令；
|
||
- 图片、文件与进度不会破坏普通人与人聊天。
|
||
|
||
### Phase 3：Hermes 首个正式 Adapter
|
||
|
||
**目标：** Hermes 成为第一个完整支持 LineUp 协议的 Agent Runtime。
|
||
|
||
**工作项：**
|
||
|
||
1. 实现 Hermes ↔ Gateway Adapter；
|
||
2. 将 LineUp Conversation 映射到 Hermes session；
|
||
3. 将用户新消息、取消和排队指令映射到 Hermes 原生会话控制；
|
||
4. 将 Hermes 的工具等待映射为 `tool.call` / `tool.result`；
|
||
5. 将 Hermes 进度、状态和产物映射为 LineUp 消息；
|
||
6. 实现按用户/群组/Agent 的访问控制与审计。
|
||
|
||
**验收标准：**
|
||
|
||
- Hermes 可以发起 `choice` / `confirm` 并等待手机端结果后继续；
|
||
- 任务中途的新指令能取消旧 run，旧输出不会污染新会话；
|
||
- Gateway 或 Hermes 重启时不重复执行不可逆工具调用；
|
||
- 白名单外用户不能访问 Hermes 的本地执行能力。
|
||
|
||
### Phase 4：富交互与机器人接入
|
||
|
||
**目标：** 扩展产品表达能力，同时保持现有唐僧客户端可用。
|
||
|
||
**工作项：**
|
||
|
||
1. 实现 `canvas.open/patch/close` 与基础画板；
|
||
2. 实现 Artifact 卡片、图片预览、文件产物和流式状态；
|
||
3. 建立 `lineup_hermes` 唐僧机器人，提供文本入口、通知和不支持富交互时的安全降级；
|
||
4. Robot Events Adapter 将文本对话接入 Hermes；
|
||
5. 对尚未安装 LineUp 扩展能力的客户端，发送安全的降级文本与 LineUp Client 跳转提示；
|
||
6. 建立跨客户端能力协商策略。
|
||
|
||
**验收标准：**
|
||
|
||
- LineUp Client 可以呈现至少一种非文本 Agent 交互（画板或结构化表单）；
|
||
- 唐僧客户端仍可完成文本对话和基础确认降级；
|
||
- 两种入口不会对同一会话产生重复 Agent 回复。
|
||
|
||
### Phase 5：WuKongIM AI Plugin 评估与增强
|
||
|
||
**前置条件：** 仅在独立测试实例确认当前 WuKongIM 版本、插件协议、插件管理与唐僧叨叨兼容边界后启动。
|
||
|
||
**目标：** 评估服务端 Plugin 是否为 LineUp 带来明确收益。
|
||
|
||
**评估项：**
|
||
|
||
- 流式延迟与 Gateway 外部 SDK 通道的对比；
|
||
- 插件绑定是否能精确限定 Agent 频道；
|
||
- 插件崩溃、升级、滚动重启的影响；
|
||
- Go Plugin 与 Hermes/Python 外部 Runtime 的超时、取消和恢复；
|
||
- 与唐僧叨叨 webhook 的消息所有权和重复处理风险；
|
||
- 安全审计、配置密钥和多租户隔离。
|
||
|
||
只有存在可量化收益时，才将 Plugin 用作 Gateway 的优化实现或服务端路由层。
|
||
|
||
---
|
||
|
||
## 10. 近期执行顺序
|
||
|
||
本方案确认后，近期工作的严格顺序如下：
|
||
|
||
```text
|
||
1. Phase 0：验证 WuKongIM v2 自定义 Payload 与 SDK 行为
|
||
2. 固化 LineUp v1 消息 schema 与 call 状态机
|
||
3. 建立最小外部 LineUp Gateway（模拟 Agent）
|
||
4. 在唐僧叨叨客户端基础上实现 LineUp 最小交互：choice / confirm / input
|
||
5. 实现 Hermes 正式 Adapter
|
||
6. 补唐僧机器人作为文本、通知和降级入口
|
||
7. 最后才评估 WuKongIM AI Plugin
|
||
```
|
||
|
||
### 10.1 各阶段目标概览
|
||
|
||
| 阶段 | 阶段目标 | 完成后得到什么 |
|
||
|---|---|---|
|
||
| 1. 验证 WuKongIM 自定义消息能力 | 证明当前唐僧叨叨配套的 WuKongIM v2 能可靠传输 LineUp 自定义 Payload | 确认 IM 基础能够承载 `tool.call`、`tool.result` 等协议，而不是只能传普通文本 |
|
||
| 2. 固化 LineUp 协议 | 明确消息格式、类型、版本、会话、调用 ID、取消和错误语义 | Client、Gateway、Hermes 可遵循同一份可测试、可版本化的协议契约 |
|
||
| 3. 建立最小 Gateway | 建立 IM 和 Agent 之间的常驻中枢，负责收发、去重、会话映射与持久化 | 得到可靠的 LineUp 交换站，Client 或 Agent 重启时关键交互仍可恢复 |
|
||
| 4. 实现最小 LineUp Client | 在唐僧叨叨客户端基础上，让客户端从文本聊天界面进入可操作的 Agent 交互界面 | 用户可执行 choice、confirm、input 等结构化交互，而非回复编号或自然语言猜测 |
|
||
| 5. 接入 Hermes | 将真实 Hermes 会话映射为 LineUp 会话和工具调用 | 用户可远程操控 Hermes，Hermes 可请求确认、获得结果、展示状态并被中断 |
|
||
| 6. 提供唐僧叨叨机器人入口 | 在既有唐僧叨叨业务与客户端体系内提供 Hermes 文本、通知和降级交互 | 为尚未具备 LineUp 富交互能力的客户端提供可用入口；复杂操作安全降级为文本 |
|
||
| 7. 评估 WuKongIM AI Plugin | 判断服务端插件是否能在当前兼容边界内带来可量化收益 | 在确认版本、稳定性和收益后，决定是否加入低延迟流式与服务端路由增强层 |
|
||
|
||
依赖关系如下：
|
||
|
||
```text
|
||
先证明 IM 能传 LineUp 消息
|
||
↓
|
||
再规定 LineUp 消息、会话和工具调用的统一语义
|
||
↓
|
||
建立可靠的 Gateway
|
||
↓
|
||
让 Client 将结构化消息渲染为可操作 UI
|
||
↓
|
||
接入 Hermes，形成真实的人—Agent 协作闭环
|
||
↓
|
||
补充唐僧叨叨机器人文本、通知与降级入口
|
||
↓
|
||
最后按实际收益评估 WuKongIM AI Plugin
|
||
```
|
||
|
||
这保证产品核心先围绕“人和 Agent 的结构化协作”落地，而不是被某个现有 IM 客户端的文本机器人能力限制。
|
||
|
||
---
|
||
|
||
## 11. 与既有文档的关系
|
||
|
||
本方案继承早期文档中以下原则：
|
||
|
||
- 三层分离：连接层、消息传输层、工具/交互层；
|
||
- LineUp 协议只定义上层交互，不重复实现 IM 基础能力；
|
||
- `tool.call` / `tool.result` 使用结构化数据与 `call_id` 配对；
|
||
- Agent Runtime 插件化接入，避免将所有 Agent 逻辑写入客户端。
|
||
- 唐僧叨叨作为成熟 IM 业务层和客户端基础，优先复用并按 LineUp 实际需求扩展。
|
||
|
||
本方案替换或细化以下早期假设：
|
||
|
||
- 不再将“官方唐僧叨叨客户端上的文本机器人”视为 LineUp 的唯一体验；机器人是完整业务体系中的一种 Agent 接入形式；
|
||
- 不再将“基于某一个 Agent 的 WebSocket 插件”视为广域网交互的唯一架构；
|
||
- 正式引入 Client、Device、Agent、Conversation 与持久化 Gateway 的边界；
|
||
- 将自定义 IM Payload、客户端工具注册、调用状态机、取消与权限模型列为 MVP 基础，而不是后续附加能力；
|
||
- LineUp 的新增能力以唐僧叨叨已有用户、群组、文件、工作台和多端客户端能力为基础生长，不预设重造整套 IM 业务系统。
|