OpenRig notification通知系统:从队列到Slack网关的完整消息旅程

发布时间:2026/10/2 8:16:17
OpenRig notification通知系统:从队列到Slack网关的完整消息旅程 OpenRig notification通知系统从队列到Slack网关的完整消息旅程【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一款多智能体协作框架能把 Claude Code 与 Codex 组成同一支队伍。它的 notification 通知系统负责一件关键的事当智能体需要人类拍板时把消息从内部队列一路送到你的手机 Slack——不漏、不重、还能根据你的在线状态决定多大声说话。本文将带你看懂这条消息旅程的完整路径。一、为什么多智能体团队需要通知系统OpenRig 的团队由多个座位seat组成lead 负责协调impl、qa、design 各司其职。人类并不可能一直盯着 TUI 拓扑图当某个 agent 遇到权限问题、需要你确认方案、或任务被阻塞时它会往队列里写入一条 qitem队列条目。问题就来了人不在电脑前怎么办消息太多会不会被淹没一条重要消息发失败了会丢吗OpenRig 的 notification 系统给出的答案是队列是唯一事实源Slack 网关负责可靠送达规则引擎负责音量控制。二、旅程第一站队列项qitem是消息载体所有跨智能体沟通都经由队列。qitem 记录了来源会话、目标会话、优先级、标签以及面向人类的字段ownerNotificationLevel通知级别、humanIntent是需要决策还是只是更新、evidenceRef截图等证据。路由入口queue.ts网关侧的读取投影queue-access.ts——只有状态为pending / in-progress / blocked且通知级别达标的 qitem 才被视为人类告警三、旅程第二站通知分发器监听事件守护进程内置一个事件总线分发器 notification-dispatcher.ts 订阅其中的协调事件默认只在必须触发的场景推送通知触发场景事件说明human-gate 队列条目到达必选queue.createdtier human-gate有事项等你拍板动词执行完成可选mission_control.action_executed需要显式开启分发器本身很薄查库取出 qitem → 生成标题与正文 → 交给通知适配器发送。适配器接口定义在 notification-adapter-types.ts目前内置两种实现ntfy默认notification-adapter-ntfy.ts —— 一次 HTTP POST 到 ntfy 主题即可推送到手机支持Click头点击直达 Mission Control 页面webhook投递到任意自定义端点值得注意的设计原则投递是尽力而为的——推送失败不会打断被通知的那个动作本身失败会发出mission_control.notification_failed事件留下审计痕迹notification-dispatcher.ts#L182-L191。四、旅程第三站投递规则引擎决定音量不是每条消息都值得 你。delivery-rules-engine.ts 是整条链路上唯一的决策点它根据三个输入算出四种结果之一你的通知档位A/B/C/D 注册表A 随时打断B 中心例外C/D 走摘要你的可用状态available / focus / away / off两条配置旋钮最低可发布级别、最低可打断级别结果行为interrupt立即 你notify发布但不 安静地进线程digest攒进 4 小时/每日摘要log只落库不发消息两个贴心的细节当你标记为away时升级类消息不会立刻吵你而是在30 分钟后延迟触发一次打断AWAY_ESCALATION_DEFER_MINUTES 30当你标记为off时任何升级都尊重你的静默但消息仍会落地发布并留下明确的终止记录——绝不悄悄丢弃。五、旅程第四站Slack 网关的可靠投递网关组装代码在 slack-subsystem.ts它把三块拼成一条线出站驱动器outbound-driver.ts每 30 秒扫描一次队列挑出既没发过、也还没在途的人类告警。发送成功后才把 qitem 标记为 seen——这就是至少一次语义的根基持久化缓冲决策在真正发送之前先落盘发送失败则保留决策下次启动自动重放重启不会丢消息投递器slack-delivery.ts把决策渲染成 Slack Block Kit 消息并chat.postMessage这里藏着最精巧的去重设计每条消息携带一个由decisionId生成的调和标记。重试前先在频道历史里搜索这个标记——找到了说明上一次的超时其实已送达就确认而不重发。正如代码注释所写宁可延迟不可重复打扰人类。此外新帖会注册到线程映射thread-seat-map.ts后续同一会话的通知都回复到同一线程保持上下文连续。六、回程Slack 里的回复如何变成任务消息旅程不是单向的。网关通过Socket Mode建立入站连接slack-subsystem.ts#L504-L545回复识别你在哪个线程下回复消息就路由回哪个座位——makeHumanReplyResolver 会把回复落成队列条目唤醒等待中的人类闸门文件入站你贴到 Slack 的截图会经认证下载、文件名消毒后保存到本地媒体目录绝不让 Slack URL 或 token 泄漏进队列行死信兜底无法处理的事件进入slack-inbound-deadletter.jsonl失败永远看得见七、上手与排查三条命令Slack 连接器的全部管理命令在 slack.tsrig slack manifest --url # 生成 Slack App 清单一键在你的工作区建应用 rig slack enable # 激活投递已有告警会被标记为历史不会补发 rig slack status # 查看配置摘要与入站/出站就绪状态一个诚实的设计未配置时网关是惰性的——它会明确拒绝投递并报出缺什么如SLACK_BOT_TOKEN unresolved而不是假装在工作。八、模块速查表环节模块路径通知分发器notification-dispatcher.ts适配器契约notification-adapter-types.tsntfy 适配器notification-adapter-ntfy.ts投递规则引擎delivery-rules-engine.tsSlack 网关组装slack-subsystem.ts出站驱动器outbound-driver.ts可靠投递slack-delivery.tsCLI 命令slack.ts总结OpenRig 的 notification 系统用一条清晰的路径回答如何让 AI 团队可靠地呼叫人类队列存事实 → 分发器听事件 → 规则引擎控音量 → Slack 网关保投递 → 入站路由收回复。每个环节都遵循同一条红线失败要大声重复不可接受人类的注意力是稀缺资源。下次当你的 Slack 弹出 human-gate qitem arrived 时你就知道——这背后是一条从 SQLite 队列出发、穿越规则引擎、最终稳稳落进你线程的消息旅程。【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考