OpenSRE 网关（Gateway）架构解析：Slack/Telegram 会话、存储与身份中间件-开发者社区

OpenSRE 网关（Gateway）架构解析：Slack/Telegram 会话、存储与身份中间件

【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensre

OpenSRE 是一个开源的 AI SRE（智能运维）工具包，它的Gateway（网关）模块是一个常驻进程，负责把Slack、Telegram、Discord 等聊天平台接入 AI 运维代理：你在 Slack 里 @ 一下机器人，或在 Telegram 里发一条私信，代理就会开始调查线上故障。本文带你从会话、存储、身份中间件三个维度，快速看懂 gateway/ 的架构设计。

🧭 先搞懂：OpenSRE 网关解决什么问题？

OpenSRE 有 3 种与代理对话的"界面（Surface）"：交互式 Shell、CLI 一次性命令、以及网关。网关是唯一常驻运行的界面——它持续监听聊天平台的消息，把"人 → 代理"的输入和"代理 → 人"的输出桥接起来。

关键设计只有一条：所有界面共用同一个核心。无论你从哪个平台发消息，最终都交给同一个回调（text, session, output, logger四参数），由TurnRunner驱动代理思考。网关只负责"如何收消息、如何回消息"，永远不改变代理本身如何推理。

各平台接入方式见官方文档：docs/messaging/slack.mdx、docs/messaging/telegram.mdx。

🚀 启动链路：一条命令如何拉起整个网关

执行opensre gateway start后，启动链路层层委托，职责清晰：

阶段	文件	职责
守护进程	gateway/core/process/supervision.py	pidfile + 子进程派生，支持`start/stop/status`
组合根	gateway/core/lifecycle/controller.py	`GatewayController`：构建唯一的`TurnRunner`，编排各表面
表面装配	gateway/startup.py	`start_gateway`：一次性启动 Web 表面 + 全部聊天传输
传输注册	gateway/transports/startup.py	`TRANSPORTS`注册表：Telegram / Slack / Discord / Buzz

其中 Web 表面是一个 FastAPI 应用（健康检查 + 告警接收，见 gateway/web/webapp.py）；网关进程还会顺带托管定时任务调度器——这是"平台组件"，不是聊天传输。

💬 Slack 与 Telegram：两种传输，同一核心

传输层位于 gateway/transports/，各平台是互不导入的对等包，每个传输自带固定的"五件套"：

Settings— 环境变量配置，缺失即报错；
Listener（监听器）— 接收消息，调用共享回调；
Inbound Security— 逐条消息鉴权 + 审计日志；
Turn Output— 实现流式状态与最终回复的投递；
Session Binding— 把平台会话键绑定到Session。

两种平台的差异只在"消息如何到达"：

Telegram：长轮询（long polling），无需公网地址，适合移动端值班场景；
Slack：默认Socket Mode（同样无需公网 URL），可选Events API HTTP（需要可达 URL 和签名密钥），每个 Slack 线程就是一个独立会话。

💡 出入站是独立的：Slack 既可以是入站聊天通道，也可以通过 webhook/bot token 工具出站发告警。

🗄️ 会话存储：一个对话如何变成稳定的 Session

聊天平台里的"一个对话"（Slack 线程、Telegram 私聊）与代理的Session之间，靠**绑定存储（Binding Store）**连接：

gateway/core/storage/session/resolver.py：SessionResolver负责"平台会话键 ↔ 会话 ID"的查找、创建、轮换，生命周期本身委托给SessionManager；
gateway/core/storage/postgres.py：配置DATABASE_URL后全进程共享一个已迁移的 Postgres 数据库，事件与反馈各有repository.py选择器——有 Postgres 走 Postgres，没有则退回进程本地实现；
安全审计日志由 gateway/core/storage/security_audit.py 承接。

值得注意的细节能体现多租户意识：绑定键是principal（组织 silo）+ actor（平台用户 ID）双维度的。首次运行时，解析器会把旧版"空 ID"的遗留绑定一次性采纳为带作用域的键并删除旧行，防止第二个用户意外继承别人的会话。

🛡️ 身份中间件：入站消息的三重防线

每条入站消息在到达代理之前，都要穿过 gateway/core/middleware/ 中的逐轮（per-turn）步骤——这些步骤是所有传输共享的，避免"同一个逻辑在 4 个平台各抄一份、互相漂移"：

中间件	文件	作用
入站决策	inbound_decision.py	统一编排：持久化策略变更 → 发送回复 → 拒绝即停 → 遇`/new`轮换会话
身份策略	identity_policy.py	从集成记录读写`MessagingIdentityPolicy`（入站开关 + 白名单），无记录时默认放行，首跑友好
会话锁	conversation_locks.py	每个会话一把锁，串行化同一会话的轮次；空闲锁有上限，自动清理
在途取消	active_turns.py	注册在途轮次的取消事件；`/stop`在锁外查找并触发，不会排队阻塞
工具审批	approvals.py	敏感工具调用前弹出确认（Slack 用 Block Kit、Telegram 用内联键盘）

配合opensre messaging allow -p slack -u U0123ABCD之类的白名单命令，未授权用户的消息会在第一层就被拦截并留下审计记录——这是"fail closed"（默认拒绝）的安全姿态。

⚖️ 并发控制：两层阀门，消息不打架

网关用两层不同的限流防止并发风暴：

进程级闸门process_turn_gate()：按OPENSRE_SIZE_PROFILE给出容量（SMALL=1、MEDIUM=2、LARGE=4 个并行轮次）。聊天消息采用"忙则丢弃"（回复 at-capacity 提示），而调度器任务采用"忙则排队"；
传输级并发*_GATEWAY_MAX_CONCURRENT：限制单个传输在触及共享TurnRunner之前可并行处理的消息数。

同一会话内轮次串行、不同会话间在闸门内并行——这就是为什么你可以同时和 Slack 线程、Telegram 私聊分别对话，互不干扰。

🔌 扩展指南：如何接入一个新聊天平台

得益于"核心唯一"设计，新增平台不需要碰代理、提示词或工具，只需提供一个包含上述"五件套"的包：

settings.py读取环境变量；
监听器收到消息后调用共享回调(text, session, output, logger)；
接入integrations/messaging_security做鉴权与审计；
实现TurnOutput（流式状态 + 最终答案投递）；
在SessionResolver中注册新的platform值完成会话绑定。

最后把新传输注册进 gateway/transports/registration.py 即可。完整入口清单见 gateway/AGENTS.md 与 gateway/README.md。

📚 小结：一张速查表

想了解的	去哪里看
启动与进程模型	gateway/core/lifecycle/controller.py
Slack 处理与分发	gateway/transports/slack/processing/dispatcher.py
Telegram 轮询与启动	gateway/transports/telegram/startup.py
会话绑定与存储	gateway/core/storage/session/resolver.py
身份/入站中间件	gateway/core/middleware/identity_policy.py
消息平台配置指南	docs/messaging/index.mdx