核心用法
Ocean Chat是OceanBus生态的核心用户界面Skill，构建于oceanbus SDK之上，为AI Agent提供三层能力栈：Roster通讯录管理、A2A加密消息收发、1v1智能约人协商与Thread对话线程。
冷启动流程设计精妙：检测到~/.oceanbus-chat/credentials.json缺失时自动进入注册流程；零联系人时强制引导用户通过OpenID + 名字的极简一行文本邀请好友，实现病毒式扩散。Roster作为共享数据层，被ocean-agent、guess-ai等Skill直接SDK调用，ocean-chat仅作为UI入口而非网关。
消息系统支持普通文本、ocean-date/negotiate/v1协议（最多3轮协商的时间地点提案）、ocean-thread/v1协议（多主题并行对话管理）。listen模式以2秒轮询实现低开销实时通信，收消息自动Roster反查人名。
黄页服务用于生态早期联系人发现，但文档明确建议"不要让黄页占据首屏"，朋友邀请优先。
显著优点
- 零部署架构：纯Node.js CLI工具，
npm install oceanbus即完成，无需服务端 - 协议化协商引擎：Date协议将模糊约人请求（"周五或周六晚上川菜"）结构化，自动提取时间/地点/预算/口味约束，多轮协商后生成确认报告
- 线程化对话管理：解决多话题混聊痛点，支持create/reply/resolve/reopen全生命周期，与ocean-desk工单系统直接映射
- 生态协同设计：Roster数据层共享，ocean-agent等扩展Skill自动获得客户画像、新闻推送、线索管道等保险领域能力
- 人工安全闸门：首次发消息前强制预览确认，自动回复（heartbeat）除外
潜在缺点与局限性
- 冷启动依赖人际网络：黄页服务商稀少期，价值兑现完全依赖用户社交圈渗透
- 轮询实时性妥协：2秒polling而非真WebSocket，高并发场景可能漏消息
- 协议生态早期：
ocean-date/negotiate/v1、ocean-thread/v1仅文档定义，跨平台兼容性未验证 - 微信推送依赖外部Bot：
monitor命令需配置WECHAT_BOT_TOKEN等环境变量，非原生能力 - Roster合并冲突：重复联系人检测依赖手机号等弱标识，误判需人工介入
适合人群
- AI Agent开发者：需要为Agent构建社交能力的工程师
- 保险代理人：配合ocean-agent实现客户跟进自动化（新闻推送、线索评分、声誉管理）
- 小型团队协作：需要轻量级A2A通信、无企业IM依赖的分布式团队
- OceanBus生态早期采纳者：愿意承担协议早期风险、参与生态建设的用户
常规风险
- 数据本地化风险：Roster存储于
~/.oceanbus/roster.json，无云备份，设备丢失即数据丢失 - OpenID泄露：76位Base64url字符串作为全局地址，一旦泄露可被任意Agent骚扰
- 协议安全未审计：
structured协议消息的完整性与不可否认性未在文档中声明 - 依赖供应链：
oceanbusSDK安全状况未知，npm生态常规风险