Skip to content
跳到项目内容
全部项目
商业系统/持续运行

飞书助手与 Flow 运维台

从聊天指令到授权审批、GPU 资源与云财务

Rust飞书 APIMCPsystemd
消息、审批与运维链路01 / 01

项目速览

业务背景

团队的日常操作集中在飞书:授权签发需要审批和留痕,GPU 机器和进程需要随时查看,云账单变化需要及时通知。项目从文件处理机器人起步,后来改为单一 Rust 服务,旧的项目与签发网页下线,授权能力改由 MCP 接入,后台成为 Flow 运维台。

负责范围
  • 飞书消息、卡片与扫码登录
  • 企业授权审批卡片与签发链路
  • GPU 机器资源与进程视图
  • 云财务采集与通知重试
  • 账号权限、受限只读 Agent 与操作流水
1 个服务

Rust 单进程

替换 Node 网关与 Python Worker,生产不依赖两者。

600 秒

采集间隔

机器与进程视图每 10 分钟后台采集,实测间隔 600 秒。

138 项

Rust 测试

财务补强版本发布时全部通过,覆盖采集、通知与 1/2/5/10 分钟有界重试。

01

核心业务

飞书是团队日常操作的入口:签发授权需要审批和留痕,GPU 机器与进程需要随时查看,云账单变化需要及时通知。项目起初是 Node 网关加 Python Worker 的文件处理机器人,2026-09 改为单一 Rust 服务,生产运行不再依赖 Node 或 Python。

2026-10-16 旧的项目、签发与结果网页下线,授权能力改由 MCP 接入,后台改为 Flow 运维台:飞书扫码登录、账号权限、4 台 H20 的资源与进程视图、受限只读 Agent、服务标记与操作流水、云财务通知和企业授权审批卡片。

01授权审批
企业授权申请以飞书卡片推送给审批人,批准后由签发链路完成签名、验签并提供下载。
02机器与进程
后台定时采集 GPU 机器资源与进程,人工为进程标记所属服务,操作写入流水。
03云财务
采集云账单变化并推送飞书通知,失败按退避有界重试。
04访问与权限
飞书扫码登录与账号权限;运维 Agent 只读且受限,不提供变更能力。
02

技术栈

服务
Rust单进程部署systemd
飞书
开放平台消息卡片扫码登录
运维数据
定时采集机器与进程视图云财务
接入
MCP受限只读 Agent操作流水
03

系统架构与部署

单一 Rust 服务承接飞书消息、卡片与扫码登录;审批卡片连到签发链路,定时采集驱动机器视图与云财务通知,授权能力经 MCP 对外提供。

服务

Rust / systemd

单进程承载飞书事件、运维台页面与定时任务,生产运行不依赖 Node 或 Python。

飞书

开放平台 / 消息卡片 / 扫码登录

审批卡片、通知与登录都使用飞书身份。

运维数据

定时采集 / 机器与进程视图 / 云账单

每 10 分钟采集一次机器资源与进程,财务变化单独通知。

接入

MCP / 受限只读 Agent

授权能力通过 MCP 提供;聊天侧 MCP 默认关闭,Agent 只读。

04

核心业务链路

企业授权从申请到下载

  1. 1企业申请
  2. 2飞书审批卡片
  3. 3批准
  4. 4签名与验签
  5. 5企业下载

审批人在卡片上点击批准,签发链路完成签名和验签后企业即可下载授权文件;重复点击按幂等处理。2026-10-16 由真人点击完成整条链路验证。

在飞书里看清一台 GPU 机器在做什么

  1. 1定时采集
  2. 2机器与进程视图
  3. 3服务标记
  4. 4操作流水

后台每 10 分钟采集一次(实测间隔 600 秒),列出 4 台 H20 的显存、进程与对应服务。人工为进程标记所属服务和用途,每次标记写入操作流水,排查时可以追溯谁在什么时候改过。

05

关键机制与取舍

01从两套运行时收敛到单一 Rust 服务

约束
Node 网关负责飞书交互、Python Worker 封装工具,两套运行时各自部署和升级,业务状态需要在两边同步。
做法
把消息、后台与工具调用合并进单一 Rust 服务;旧的项目与签发网页下线,授权能力改由 MCP 暴露给需要的客户端。
效果
生产只部署一个服务进程,授权、运维与财务共用同一套身份、权限和流水。

02财务通知:失败要补发,但不能刷屏

约束
云账单通知依赖外部接口和飞书推送,任何一侧暂时失败都会漏发。
做法
通知失败按 1、2、5、10 分钟退避重试,最多 5 次;财务补强版本发布时 138 项 Rust 测试全部通过,覆盖采集、通知与重试逻辑。
效果
短时故障可以自动补发;真实网络故障下的补发还没有专门验证。

03运维 Agent 只读

约束
在聊天里查询机器状态很方便,但让 Agent 直接改服务会引入新的变更通道。
做法
Agent 只读取机器、进程与服务标记,变更仍由人工在运维台执行并写入流水;聊天侧 MCP 默认关闭,模型更换执行器尚未接入。
效果
查询效率提升,变更仍然只有一条可追溯的路径。
06

AI 协作开发

版本发布、Rust 测试、多宽度浏览器回归和真实只读 API 检查由 Agent 执行,每次发布记录对应的提交哈希。

  • Agent 负责

    发布与回归

    每个版本跑 86–138 项 Rust 测试和五种宽度的浏览器回归;一个基于过期源码树的候选版本被自动回滚。

  • 安全约束

    MCP 只存变量名

    MCP 配置只保存环境变量名,不保存令牌;外部 MCP 必须使用 HTTPS 和白名单主机,本地命令必须位于固定目录且不能是软链接。

  • 主动发现

    发布前查出空的回调订阅

    在已同意发布的情况下,Agent 仍检查了卡片回调订阅,发现此前回调从未被真正验证,并把问题报告出来。

调试类调用需要管理员显式开启,默认关闭。

07

阶段成果

  • 飞书助手从文件处理机器人演进为授权审批、机器运维和云财务的统一入口。
  • 运行时收敛为单一 Rust 服务,旧网页入口下线,授权能力改由 MCP 提供。

继续浏览

飞书助手与 Flow 运维台 · 消息、审批与运维链路
100%
飞书助手与 Flow 运维台放大预览

消息、审批与运维链路

别急,先让缓存热一下。