从零搭建自己的 AI 运维助手Docker 多模型网关 飞书机器人全流程实战一个能帮你查日志、跑脚本、定时巡检、主动推告警的私人运维助理是怎么攒出来的。全程 Docker 部署单机可跑所有配置公开可复现。一、为什么要自己搭一个市面上 AI 助手不少但落到运维场景通用产品有三个绕不过去的问题够不着内网。你的服务、数据库、监控面板全在内网SaaS 助手碰不到。管不住成本。直连某一家大模型 API一旦调用量大账单不可控想换模型又要改代码。接不上工作流。你希望它在飞书/钉钉里回你消息、按 cron 巡检、发现异常主动推卡片——这些通用助手都做不到。所以正确的姿势是自己攒一个 Agent模型走自建网关交互走 IM 机器人。本文完整讲一遍搭建过程。二、整体架构┌─────────────┐ 消息/事件 ┌──────────────────┐ │ 飞书 / IM │ ────────────▶ │ Agent 框架 │ │ 机器人 │ ◀──────────── │ (Hermes Agent) │ └─────────────┘ 富文本卡片 └────────┬─────────┘ │ OpenAI 兼容协议 ▼ ┌──────────────────┐ │ 多模型网关 │ │ (new-api, Docker)│ └────────┬─────────┘ │ 统一路由/计费/故障转移 ┌──────────────┼──────────────┐ ▼ ▼ ▼ 模型渠道A 模型渠道B 模型渠道C核心思想Agent 只认OpenAI 兼容这一个协议剩下所有模型适配、密钥管理、故障转移、额度统计都交给中间的网关。好处是——换模型、加渠道、禁某个渠道全程不用动 Agent 一行代码。三、组件选型组件作用选它的理由new-api多模型网关开源、支持几乎所有主流模型协议、有 Web 管理台、支持多渠道负载与故障转移Hermes AgentAgent 运行时原生支持工具调用、cron 定时任务、多 IM 接入飞书自建应用交互入口消息卡片体验好、API 完善、机器人可进群硬件要求很低一台 4C8G 的小主机NUC / 旧笔记本 / 迷你主机都行足够。四、实战三步搭起来第一步Docker 部署多模型网关mkdir-p/opt/ai-gatewaycd/opt/ai-gatewaycatdocker-compose.ymlEOF services: new-api: image: calciumion/new-api:latest container_name: new-api restart: always ports: - 3000:3000 volumes: - ./data:/data environment: - TZAsia/Shanghai EOFdockercompose up-d起来后访问http://你的IP:3000默认账号root / 123456第一件事就是改密码。在管理台里加渠道把你有额度的模型 API比如某云的 GLM、某家的 DeepSeek、自建的本地模型逐个加进去填好 base_url 和 key。小技巧同一个模型可以配多个渠道网关会自动做负载均衡再给渠道设个体重把便宜/稳定的放前面贵的做托底。这样单一渠道挂了或限流请求会自动切到下一个Agent 侧完全无感。第二步部署 Agent 框架dockerrun-d\--namehermes\--restartalways\-v/opt/hermes:/root/.hermes\-eOPENAI_BASE_URLhttp://网关IP:3000/v1\-eOPENAI_API_KEYsk-你的网关令牌\hermes-agent:latest关键点Agent 的 base_url 指向你自己的网关而不是某家厂商的官方地址。这样你随时能在网关侧换模型Agent 不用动。配置里通常需要指定model:provider:openai-compatiblebase_url:http://网关IP:3000/v1name:DeepSeek-v4-Flash# 换成你网关里的任意模型第三步接入飞书机器人去飞书开放平台建一个自建应用拿到App ID和App Secret开通权限im:message、im:message.group_at_msg群消息需 才回复等事件订阅填 Agent 的 Webhook 地址把机器人拉进你的群 它就能对话。到这一步你已经可以在飞书里直接对 Agent 说“帮我看下服务器磁盘占用超过 80% 的列出来。”它会真的去执行命令、把结果整理成卡片回你。五、让它真正自动化定时巡检 主动告警光能对话还不够运维助手要能自己动手。Agent 框架一般内置 cron 能力可以配置定时任务cron:-name:disk-checkschedule:0 */6 * * *# 每 6 小时prompt:|检查所有主机磁盘使用率超过 85% 的整理成告警卡片 推送到运维群。正常情况下不要打扰我。deliver:feishu:ops-group配合 Docker 部署的 Prometheus Grafana就能做到磁盘/内存/服务状态定时巡检发现异常主动推飞书卡片而不是等你去看面板关键数字用大号彩色字体突出一眼看到重点。六、踩过的几个坑1. 上下文过长导致 Agent 变慢 / 报错模型上下文有限长会话一定要开自动压缩把历史对话摘要化并且给压缩单独配一个便宜快速的模型别用推理型大模型——后者又慢又贵。2. 主模型和压缩模型别共用同一个限流池如果两者走同一个渠道压缩请求一多就会触发限流然后主请求也超时形成死亡螺旋。让它们落在不同的配额池上。3. 群机器人默认收不到没 它的消息这是飞书平台机制未 的消息不推送事件不是 bug。想让它处理群里的所有消息得单独申请群消息敏感权限。4. 内网服务别裸奔到公网如果你需要外网访问走端口映射 HTTPS不要直接把管理面板尤其带数据库的暴露出去。开了公网的那一刻扫描器几分钟内就会到。七、效果搭完之后日常大概是这样早上到工位飞书里已经有昨晚的巡检卡片哪些服务正常、哪些异常想查什么直接在群里 它“昨天 23 点到今天 8 点XX 服务有没有报错”——它去翻日志给你结论新服务上线让它按模板生成部署脚本 / 配置比自己手搓快得多。真正省下的不是打字时间而是**切窗口、翻日志、拼命令的上下文切换成本。**八、总结这套方案的三个关键决策模型走自建网关—— 解耦 成本可控 不怕单点故障交互走 IM 机器人—— 用你本来就在用的工具零学习成本能力靠 cron 工具—— 让它主动干活而不是被动问答。整套东西单机 Docker 就能跑成本是一台小主机的电费。有兴趣的可以照着搭一遍有坑欢迎评论区交流。本文环境Ubuntu 22.04 Docker 24 new-api Hermes Agent全部组件开源。