Files

T

kyugao 10840909ab 初始化 agent_ops 文档治理体系

2026-08-07 16:56:51 +08:00

27 KiB

Raw Blame History

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。

因此，本方案作出以下正式决策：

LineUp 以唐僧叨叨作为成熟 IM 业务层基础，以 WuKongIM 作为通讯内核。 用户、联系人、群组、文件、工作台与现有多端客户端能力优先复用；仅在 LineUp 的产品需要超出现有能力时再扩展或替换。
LineUp 的正式 Agent 交互通道采用 增强后的 LineUp Client + WuKongIM 官方 SDK + LineUp 自定义消息协议。 该协议在唐僧叨叨的用户与业务体系内运行，不把 LineUp 限制为机器人文本对话。
LineUp Agent Adapter / Gateway 作为外部常驻服务运行，负责连接 Agent Runtime 与 LineUp 协议。 Hermes 是第一个适配目标，后续可接入其他 Agent Runtime。
唐僧叨叨 Robot Events API 是可复用的机器人接入能力。 它适合快速提供文本型 Hermes 入口、通知和兼容降级；结构化工具交互的正式主载体仍是 LineUp 自定义消息协议。
WuKongIM AI Plugin 不作为第一阶段核心依赖。 它保留为后续的服务端路由、低延迟流式输出和自动化处理能力；待确认当前部署版本的插件机制与唐僧叨叨配套版本兼容后再评估。
LineUp Client 是对唐僧叨叨客户端能力的面向 Agent 扩展，而不是孤立重造一个聊天客户端。 choice、confirm、canvas、artifact 等由 LineUp 模块实现，同时保留已有 IM 业务体验。

2. 产品目标与边界

2.1 产品目标

LineUp 让人和 Agent 在远程、跨设备、可恢复的 IM 会话中协作。交互不局限于文本问答，而是包含：

人与人：文本、图片、语音、文件与群组协作；
人与 Agent：自然语言、任务进度、状态、图像、文件和流式内容；
Agent 与用户端工具：选择、确认、表单、画板、文件预览、设备能力等；
Agent 与 Agent：在受控会话或频道中交换结构化协作消息；
用户对 Agent 的控制：继续、取消、修改指令、批准、拒绝和恢复。

2.2 关键体验目标

用户面对的不是一个只会输出文本的机器人，而是一个可呈现和操作工作内容的 Agent 会话。例如：

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. 总体架构

┌─────────────────────────────────────────────────────────────┐
│              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 三层分工

LineUp 交互协议层
  └─ 会话语义、Actor、设备能力、工具、状态、产物、取消与确认

WuKongIM 消息传输层
  └─ 文本、媒体、文件、自定义 Payload 的可靠投递与同步

WuKongIM 连接层
  └─ 认证、长连接、心跳、重连、离线恢复

LineUp 不重新实现下层 IM 可靠传输；WuKongIM 也不解释 LineUp 的工具和 UI 语义。

4.2 统一 LineUp 信封

所有自定义交互消息使用一个可演进的信封。基础媒体仍优先使用 IM 的原生媒体能力；信封保存其交互语义、引用关系或媒体元数据。

{
  "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 协议》。Surface 不是 Agent 在 Client 主进程执行任意代码的通道；它只能运行在受限容器中，并通过预定义 bridge 回传用户事件。任何上层 App / 原生能力必须经 app.call、用户确认和 capability registry 执行。

5. 用户端工具调用规范

5.1 工具注册

Client 在设备上线或能力变化后发布 tool.list。每个工具至少声明：

{
  "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 调用与返回

{
  "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，并且结果为可扩展对象，不长期限制为纯字符串：

{
  "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 的第一版枚举为：

completed | rejected | cancelled | expired | unsupported | failed

5.3 调用状态机

created
  → delivered
  → acknowledged_by_client
  → waiting_user
  → completed | rejected | cancelled | expired | failed

规则：

call_id 在 conversation_id 范围内唯一；
同一个 call_id 的重复 tool.call 必须幂等显示，不能重复执行本地副作用；
tool.result 必须幂等转交给 Agent，Gateway 需持久记录最终状态；
Client 离线时调用可等待到 expires_at，不得无限期阻塞 Agent；
用户、Agent 或系统取消后，旧调用及旧流输出不可覆盖新一代会话状态；
高风险工具没有显式用户授权时，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 权限原则

默认最小权限：Agent 只看得到被明确路由给它的会话；
设备能力显式声明：没有在 tool.list 声明的工具不可调用；
风险分级：display_only、user_confirmation、system_permission、restricted；
人类可取消：用户在任一 Agent 会话中必须可发出取消/中断；
群聊默认只响应明确提及或授权的 Agent；
Gateway 记录调用、确认、结果和取消的审计事件；
Agent Runtime 的本地终端、文件和浏览器权限不因 IM 通道自动扩大。

7. 可靠性、重连与用户插入指令

7.1 双层可靠性

WuKongIM
  └─ 连接、顺序、离线消息、重连与传输级可靠性

LineUp Gateway
  └─ 应用级 idempotency、call_id 状态、inbox/outbox、Agent 执行恢复

Gateway 维护持久 inbox/outbox。任何消息只有在成功落入 inbox 后才视为被应用层接收；任何对 Agent 或 Client 的关键发送都要记录投递状态和应用级消息 ID。

7.2 用户中断

用户的新指令不能因为旧 Agent 任务运行很久而被阻塞：

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 当前部署的使用方式

当前环境维持：

唐僧叨叨服务端 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。

工作项：

定义 lineup.v1 自定义 Payload 的编码、消息类型编号和最大体积；
使用两个测试账户，通过官方 SDK 收发并解码一条 LineUp 信封；
验证离线消息、多设备同步、顺序、重复投递与撤回等边界；
验证图片、文件与自定义交互消息的引用关系；
定义测试频道/Agent 身份命名规范；
记录 WuKongIM v2 的精确 SDK 与协议限制。

验收标准：

任一端离线重连后，lineup.v1.tool.call 不丢失且不重复执行；
自定义消息可以被测试 Client 正确识别；
不改变现有唐僧叨叨用户、消息和 Docker 命名卷。

Phase 1：LineUp 协议核心与最小 Gateway

目标： 打通 Client、Gateway 与一个模拟 Agent 的双向结构化交互。

工作项：

实现 LineUp 信封编解码库与 JSON Schema；
实现 Gateway 的 Actor、Device、Conversation 映射；
实现 SQLite 持久 inbox/outbox 与消息去重；
实现 device.hello、tool.list、tool.call、tool.result、tool.cancel；
实现 call_id 状态机、超时和审计；
使用模拟 Agent 发起 choice 与 confirm。

验收标准：

Client 断线、Gateway 重启后，待处理工具调用仍可恢复；
重复投递不导致工具执行两次；
不受支持工具返回 unsupported；
用户拒绝、取消、超时能精确回到对应 Agent 调用。

Phase 2：LineUp Client 最小交互面

目标： 从“聊天 UI”进入“Agent 交互 UI”。

工作项：

基于现有唐僧叨叨客户端能力建立 LineUp Client 扩展层或受控分叉，保留登录、联系人、聊天、媒体与文件基础；
接入并验证 WuKongIM SDK 的 LineUp 自定义 Payload；
实现文本、Agent 状态、进度、choice、confirm、input；
实现工具注册、风险提示、用户授权与结果回传；
实现会话列表中的 Agent 标识、运行状态与取消入口；
实现最小 Artifact 展示：图片与文件；
记录客户端能力及版本兼容策略。

验收标准：

用户可在手机上完成 Agent 发起的选择和确认；
Agent 能得到结构化而非文本猜测式的结果；
用户可在 Agent 工作期间中断并发送替代指令；
图片、文件与进度不会破坏普通人与人聊天。

Phase 3：Hermes 首个正式 Adapter

目标： Hermes 成为第一个完整支持 LineUp 协议的 Agent Runtime。

工作项：

实现 Hermes ↔ Gateway Adapter；
将 LineUp Conversation 映射到 Hermes session；
将用户新消息、取消和排队指令映射到 Hermes 原生会话控制；
将 Hermes 的工具等待映射为 tool.call / tool.result；
将 Hermes 进度、状态和产物映射为 LineUp 消息；
实现按用户/群组/Agent 的访问控制与审计。

验收标准：

Hermes 可以发起 choice / confirm 并等待手机端结果后继续；
任务中途的新指令能取消旧 run，旧输出不会污染新会话；
Gateway 或 Hermes 重启时不重复执行不可逆工具调用；
白名单外用户不能访问 Hermes 的本地执行能力。

Phase 4：富交互与机器人接入

目标： 扩展产品表达能力，同时保持现有唐僧客户端可用。

工作项：

实现 canvas.open/patch/close 与基础画板；
实现 Artifact 卡片、图片预览、文件产物和流式状态；
建立 lineup_hermes 唐僧机器人，提供文本入口、通知和不支持富交互时的安全降级；
Robot Events Adapter 将文本对话接入 Hermes；
对尚未安装 LineUp 扩展能力的客户端，发送安全的降级文本与 LineUp Client 跳转提示；
建立跨客户端能力协商策略。

验收标准：

LineUp Client 可以呈现至少一种非文本 Agent 交互（画板或结构化表单）；
唐僧客户端仍可完成文本对话和基础确认降级；
两种入口不会对同一会话产生重复 Agent 回复。

Phase 5：WuKongIM AI Plugin 评估与增强

前置条件： 仅在独立测试实例确认当前 WuKongIM 版本、插件协议、插件管理与唐僧叨叨兼容边界后启动。

目标： 评估服务端 Plugin 是否为 LineUp 带来明确收益。

评估项：

流式延迟与 Gateway 外部 SDK 通道的对比；
插件绑定是否能精确限定 Agent 频道；
插件崩溃、升级、滚动重启的影响；
Go Plugin 与 Hermes/Python 外部 Runtime 的超时、取消和恢复；
与唐僧叨叨 webhook 的消息所有权和重复处理风险；
安全审计、配置密钥和多租户隔离。

只有存在可量化收益时，才将 Plugin 用作 Gateway 的优化实现或服务端路由层。

10. 近期执行顺序

本方案确认后，近期工作的严格顺序如下：

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	判断服务端插件是否能在当前兼容边界内带来可量化收益	在确认版本、稳定性和收益后，决定是否加入低延迟流式与服务端路由增强层

依赖关系如下：

先证明 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 业务系统。

27 KiB Raw Blame History Unescape Escape

LineUp IM Agent 交互平台：历史方案与实施计划（已归档）

1. 决策摘要

2. 产品目标与边界

2.1 产品目标

2.2 关键体验目标

2.3 明确不承担的职责

3. 总体架构

3.1 组件职责

4. 协议分层与消息模型

4.1 三层分工

4.2 统一 LineUp 信封

4.3 第一批正式消息类型

5. 用户端工具调用规范

5.1 工具注册

5.2 调用与返回

5.3 调用状态机

6. 身份、会话、设备与权限

6.1 四种核心对象

6.2 权限原则

7. 可靠性、重连与用户插入指令

7.1 双层可靠性

7.2 用户中断

8. 技术选型与当前环境定位

8.1 主通道选择

8.2 当前部署的使用方式

9. 分阶段实施计划

Phase 0：协议与可行性基线

Phase 1：LineUp 协议核心与最小 Gateway

Phase 2：LineUp Client 最小交互面

Phase 3：Hermes 首个正式 Adapter

Phase 4：富交互与机器人接入

Phase 5：WuKongIM AI Plugin 评估与增强

10. 近期执行顺序

10.1 各阶段目标概览

11. 与既有文档的关系

27 KiB

Raw Blame History