Gateway & Web Monitor

后台事件驱动 AI 自动化

Gateway 与 Web Monitor 是 oh-my-feishu 从“飞书中调用 Claude Code”扩展到“后台事件驱动 AI 自动化”的核心模块。用户注册 Web 服务的 traceback 地址后，后台服务会定时轮询，发现新异常时自动触发 Claude Code 分析或修复，并把处理结果通过飞书卡片返回。

Files

1创建与管理监控服务

首先是用户如何把一个 Web 服务接入后台监控。入口可以是飞书卡片、自然语言，也可以是 CLI；最终都会写入服务注册表，形成后续轮询和修复所需的上下文。

飞书卡片管理在飞书中发送 /menu，进入自动化技能菜单，选择 Web 服务监控，通过卡片表单创建、查看和管理服务。适合移动端操作，不需要记命令。
自然语言管理用户可以直接让 Claude Code 查询或创建监控服务，Claude 通过 web-monitor-service-manager skill 执行 oh-my-feishu web-monitor 命令。
CLI 命令管理终端中使用 oh-my-feishu web-monitor，适合脚本化或 CI/CD 场景。CLI 最终进入 Gateway IPC 和 service-admin feature。

飞书卡片表单配置项

服务名称监控服务唯一标识

GitHub 仓库owner/repo 格式

Traceback URL日志或错误端点

自动 PR修复后是否自动创建 PR

PR 目标分支默认 main

PR 模式draft 或 ready

PR 分支前缀默认 oh-my-feishu/web-monitor

确认模式修复前是否等待人工确认

Traceback monitor

2Traceback 监控与去重

服务创建后，TracebackMonitor 会按配置轮询日志端点。它不把每次请求都交给 AI，而是先提取错误内容、计算 hash，并用基线和上一次 hash 控制触发频率。

多格式提取支持 JSON、文本和 HTML 内容格式。
首次建立基线第一次检查只记录状态，避免把历史错误当作新事件。
Hash 去重同一错误不重复触发，只有 traceback 变化时才进入下一步。
事件化输出新错误被转换成 traceback.detected，交给 Gateway feature 处理。

Repair modes

3分析与修复模式

Gateway 收到新 traceback 事件后，根据服务配置选择自动修复或修复前确认。这里的重点不是“让 AI 自动改一切”，而是把风险控制和协作确认放进流程里。

自动修复未开启确认时，直接调用 Claude Code 进入 auto-repair 工作流。
修复前确认先发送“发现新问题”卡片，用户点击后才进入只读分析。
二次确认分析完成后，再由用户决定是否执行实际代码修复。
Skill 约束PathGuard、DiffGuard、TestGuard、No Secrets、Git 安全、PR 控制控制路径、变更规模、验证和 Git 行为。

Directory session

4结果回传与继续协作

AI 处理完成后，结果不会停留在本地终端，而是回到飞书卡片。用户可以查看修复结果，也可以从监控详情页切换到该服务的目录会话，继续排查、补测试或做后续重构。

结构化结果分析结论、修复状态和后续动作以飞书卡片返回。
本地仓库上下文服务注册时保存本地路径，Claude Code 修复时进入真实项目目录。
目录会话监控详情页可以直接新建该目录下的 Claude Code 会话。
协作闭环发现问题、分析方案、确认修复、结果回传、继续协作都在飞书中完成。

Technical value

技术价值总结

Gateway 的价值在于把 Web 服务异常处理从人工复制日志、切换终端、手动同步结果，改造成飞书里的事件驱动闭环。

事件驱动TracebackMonitor 和 Gateway feature 把 traceback 变化转换成可执行事件。
上下文完整服务注册时记录本地仓库路径，Claude Code 修复时进入真实代码目录。
安全可控支持修复前确认，并在 skill 中约束修改范围、变更规模、验证命令和 PR 行为。
协作闭环发现问题、分析方案、确认修复、结果回传、继续目录会话都在飞书中完成。