核心用法
Ocean Chat 是 OceanBus 生态的核心 UI 技能，为 AI Agent 提供类微信的通讯能力，包含三大模块：
1. Roster 智能通讯录
- 语义搜索：支持模糊匹配（"老王"→"王总"）、标签筛选（"喜欢川菜的"）、笔记内容检索
- 自动发现：从对话中提取人名，超过 3 次提及自动提示添加
- 重复合并：基于手机号/OpenID 自动检测重复联系人，支持一键合并
- 跨 Skill 共享：ocean-agent、guess-ai 等技能共用同一 Roster 数据源
2. Chat 加密消息
- A2A 直连：基于 OceanBus L0 协议的端到端加密消息管道
- 结构化协议：支持
ocean-date/negotiate/v1约人协议、ocean-thread/v1线程协议 - 实时监听：
listen模式 2 秒轮询，自动反查联系人名显示
3. Date 智能约人（v2.1）
- 意图解析：自动提取时间/地点/预算/口味等约束条件
- 协商引擎：最多 3 轮自动提案-反提案循环，支持对方 Agent 偏好读取
- 线程管理：多话题并行通过 Thread 协议隔离，避免消息混杂
4. Thread 对话线程（v1）
- 创建/回复/结束/重开线程，支持
payload字段透传业务上下文 - 与 ocean-desk 坐席系统直接映射，客户咨询=线程，工单关闭=resolve
5. Yellow Pages 黄页
- 发布/发现 Agent 身份，生态冷启动期核心获客渠道
---
显著优点
| 维度 | 优势 |
|------|------|
| **冷启动设计** | 独创「一行邀请」机制：A 转发 `<OpenID> <名字>` 给 B，B 粘贴给 AI 即双向建联，零配置 |
| **协议扩展性** | 结构化消息支持领域协议（保险约访、客服工单、游戏组队），非侵入式升级 |
| **生态协同** | 与 ocean-agent（保险）、ocean-desk（客服）、guess-ai（游戏）深度联动，Roster 全局共享 |
| **隐私架构** | 基于 OceanBus L0 的 OpenID 寻址，无中心服务器存储消息内容 |
| **低门槛** | `npm install oceanbus` 即运行，无需部署，环境变量全可选 |
---
潜在缺点与局限性
| 问题 | 说明 |
|------|------|
| **生态早期** | 黄页服务稀疏，冷启动依赖人际邀请，商户 Agent 覆盖不足 |
| **协议兼容** | 对方 Agent 需支持相同协议版本（如 `ocean-date/negotiate/v1`），否则降级为文本 |
| **实时性局限** | 默认 2 秒轮询，非真 WebSocket；高并发场景下 OceanBus L0 公共节点可能成为瓶颈 |
| **安全依赖** | 加密强度取决于 OceanBus 实现，本 Skill 未独立审计加密算法 |
| **Roster 单点** | `~/.oceanbus/roster.json` 本地存储，多设备同步需手动处理 |
| **LLM 幻觉风险** | 模糊搜索、意图解析依赖 LLM，可能出现「把王总当成老王」的消歧错误 |
---
适合人群
- 保险代理人：配合 ocean-agent 实现客户线索管理、新闻推送、智能跟进
- AI 应用开发者：需要为 Agent 添加通讯能力的 Builder
- 小团队/自由职业者：轻量级客户管理 + 约人协商，替代 CRM + 日历工具组合
- 多 Agent 用户：同时运行多个 AI 工具，需要统一通讯录和消息中心
---
常规风险
1. 身份冒充：OpenID 为 76 位 Base64url，视觉上难以校验，存在钓鱼复制风险（建议交叉验证）
2. 消息持久化：聊天记录本地存储，设备丢失无云端恢复机制
3. 协议锁定：深度绑定 OceanBus 生态，迁移成本高
4. 自动化边界：Date 协商的「确认即锁定」设计可能因 Agent 误解导致约定冲突，关键约会建议人工复核