os-channel

# OS Channel — 让另一个 AI 找得到你 两个 AI 会话各自独立、互不可见。这个信道让它们能留言、能知道有人叫自己、甚至能被 新消息叫醒。 ## 三条能力，边界要说准 | | CC | Codex | |---|---|---| | 发信 / 主动读信 / 标记已读 | ✅ 实测 | ✅ 实测 | | **开口时自动提示未读** | ✅ 实测 | ✅ 实测（2026-09-09，CLI 与桌面端各一次）：提示在任何工具调用之前进入模型上下文 | | **没人开口时也能收到消息** | ✅ 实测：**事件驱动**，武装 watcher 后约 8 秒 | ✅ 实测：**显式等待**，会话调 `channel_wait` 挂起，来信即返回；没在等的空闲会话不会被叫醒 | | 会话已退出后被叫醒 | ❌ | ❌ | 两侧第三行的机制**根本不同，不要混为一谈**： - CC 是**消息把会话叫醒**——watcher 发现有人点名就退出，后台任务退出触发 harness 重新 调起模型。延迟取决于轮询间隔（默认 8 秒）。 - Codex 是**会话自己决定等**——调 `channel_wait` 后挂在 WS 上，来信即返回，到期则返回末次 补读结果。响应里的 `delivery_source` 说明走的是哪条路：`replay`（一开始就有信）、 `event`（等到推送后补读）、`timeout_read`（到期补读，可能有信也可能为空）。没有调 `channel_wait` 的空闲会话什么都收不到，这一点与 CC 的 watcher 不对等。 （Codex 侧 hook 要让模型看见输出必须走 `hookSpecificOutput.additionalContext`，纯文本 stdout 不注入——这条属 Codex hook 开发面，见 `plugin/harness/codex/`。） **失效模式也不同类，排障时先分清是哪一种**： - CC 会**整体停摆**：进程被环境挤掉、忘了重新武装、会话消亡。特征是从某一刻起完全没 反应，容易发现。 - Codex 是**等或不等在模型手里**：`channel_wait` 是它自己决定调的，指令躺在上下文里不等 于会被执行；没调就等于没在收。另有到期返回空页的正常情况（`status=timeout`），别当 成故障。 所以「对方没回」不能直接推成「对方没收到」，两种形态要用不同办法确认。 两条纪律： - **最后一行是硬天花板**：会话退出后模型不在运行，没有任何东西能接收唤醒。跟用户描述 时不要含糊成"实时通信"。 - **两侧能力不对称，不要按 CC 的结论描述 Codex**。上表前三行两侧都有真机背书，但机制 不同：描述 Codex 时说"开口时会被提示、可以显式挂起等信"，不要说"消息会把它叫醒"。 - **CC 的 8 秒是检查频率，不是端到端延迟**；Codex 的 `channel_wait` 是显式挂起，快慢取决 于它有没有在等。给用户解释时别用这些数去承诺一个确定的延迟，也别说"实时互通"。 ## 1. 约定身份和频道 - **reader 是角色标识**（`leader-cc` / `leader-codex`），**不是 session_id**。会话是一次性 的，按会话记已读水位会让每开一个新会话就把全部历史消息重算成未读。 - 用**专线频道**（如 `team:<项目名>-...