从零搭建自己的 AI 运维助手：Docker + 多模型网关 + 飞书机器人全流程实战

一个能帮你查日志、跑脚本、定时巡检、主动推告警的"私人运维助理"是怎么攒出来的。
全程 Docker 部署，单机可跑，所有配置公开可复现。

一、为什么要自己搭一个

市面上 AI 助手不少，但落到运维场景，通用产品有三个绕不过去的问题：

1. 够不着内网。你的服务、数据库、监控面板全在内网，SaaS 助手碰不到。
2. 管不住成本。直连某一家大模型 API，一旦调用量大，账单不可控；想换模型又要改代码。
3. 接不上工作流。你希望它在飞书/钉钉里回你消息、按 cron 巡检、发现异常主动推卡片——这些通用助手都做不到。

所以正确的姿势是：自己攒一个 Agent，模型走自建网关，交互走 IM 机器人。

本文完整讲一遍搭建过程。

二、整体架构

┌─────────────┐   消息/事件    ┌──────────────────┐
│  飞书 / IM   │ ────────────▶ │   Agent 框架      │
│  机器人      │ ◀──────────── │  (Hermes Agent)   │
└─────────────┘   富文本卡片   └────────┬─────────┘
                                       │ OpenAI 兼容协议
                                       ▼
                              ┌──────────────────┐
                              │  多模型网关        │
                              │  (new-api, Docker)│
                              └────────┬─────────┘
                                       │ 统一路由/计费/故障转移
                        ┌──────────────┼──────────────┐
                        ▼              ▼              ▼
                   模型渠道A       模型渠道B       模型渠道C

核心思想：Agent 只认"OpenAI 兼容"这一个协议，剩下所有模型适配、密钥管理、故障转移、额度统计都交给中间的网关。

好处是——换模型、加渠道、禁某个渠道，全程不用动 Agent 一行代码。

三、组件选型

组件	作用	选它的理由
new-api	多模型网关	开源、支持几乎所有主流模型协议、有 Web 管理台、支持多渠道负载与故障转移
Hermes Agent	Agent 运行时	原生支持工具调用、cron 定时任务、多 IM 接入
飞书自建应用	交互入口	消息卡片体验好、API 完善、机器人可进群

硬件要求很低：一台 4C8G 的小主机（NUC / 旧笔记本 / 迷你主机都行）足够。

四、实战：三步搭起来

第一步：Docker 部署多模型网关

mkdir -p /opt/ai-gateway && cd /opt/ai-gateway

cat > docker-compose.yml <<'EOF'
services:
  new-api:
    image: calciumion/new-api:latest
    container_name: new-api
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - ./data:/data
    environment:
      - TZ=Asia/Shanghai
EOF

docker compose up -d

起来后访问 http://<你的IP>:3000，默认账号 root / 123456（第一件事就是改密码）。

在管理台里加渠道：把你有额度的模型 API（比如某云的 GLM、某家的 DeepSeek、自建的本地模型）逐个加进去，填好 base_url 和 key。

小技巧：同一个模型可以配多个渠道，网关会自动做负载均衡；再给渠道设个体重，把便宜/稳定的放前面，贵的做托底。这样单一渠道挂了或限流，请求会自动切到下一个，Agent 侧完全无感。

第二步：部署 Agent 框架

docker run -d \
  --name hermes \
  --restart always \
  -v /opt/hermes:/root/.hermes \
  -e OPENAI_BASE_URL=http://<网关IP>:3000/v1 \
  -e OPENAI_API_KEY=sk-你的网关令牌 \
  hermes-agent:latest

关键点：Agent 的 base_url 指向你自己的网关，而不是某家厂商的官方地址。这样你随时能在网关侧换模型，Agent 不用动。

配置里通常需要指定：

model:
  provider: openai-compatible
  base_url: http://<网关IP>:3000/v1
  name: DeepSeek-v4-Flash     # 换成你网关里的任意模型

第三步：接入飞书机器人

1. 去飞书开放平台建一个自建应用，拿到 App ID 和 App Secret；
2. 开通权限：im:message、im:message.group_at_msg（群消息需 @ 才回复）等；
3. 事件订阅填 Agent 的 Webhook 地址；
4. 把机器人拉进你的群，@ 它就能对话。

到这一步，你已经可以在飞书里直接对 Agent 说：

“帮我看下服务器磁盘占用，超过 80% 的列出来。”

它会真的去执行命令、把结果整理成卡片回你。

五、让它真正"自动化"：定时巡检 + 主动告警

光能对话还不够，运维助手要能自己动手。

Agent 框架一般内置 cron 能力，可以配置定时任务：

cron:
  - name: disk-check
    schedule: "0 */6 * * *"     # 每 6 小时
    prompt: |
      检查所有主机磁盘使用率，超过 85% 的整理成告警卡片，
      推送到运维群。正常情况下不要打扰我。
    deliver: feishu:ops-group

配合 Docker 部署的 Prometheus + Grafana，就能做到：

• 磁盘/内存/服务状态定时巡检；
• 发现异常主动推飞书卡片（而不是等你去看面板）；
• 关键数字用大号彩色字体突出，一眼看到重点。

六、踩过的几个坑

1. 上下文过长导致 Agent 变慢 / 报错
模型上下文有限，长会话一定要开自动压缩（把历史对话摘要化），并且给压缩单独配一个便宜快速的模型，别用推理型大模型——后者又慢又贵。

2. 主模型和压缩模型别共用同一个限流池
如果两者走同一个渠道，压缩请求一多就会触发限流，然后主请求也超时，形成"死亡螺旋"。让它们落在不同的配额池上。

3. 群机器人默认收不到没 @ 它的消息
这是飞书平台机制（未 @ 的消息不推送事件），不是 bug。想让它处理群里的所有消息，得单独申请"群消息"敏感权限。

4. 内网服务别裸奔到公网
如果你需要外网访问，走端口映射 + HTTPS，不要直接把管理面板（尤其带数据库的）暴露出去。开了公网的那一刻，扫描器几分钟内就会到。

七、效果

搭完之后，日常大概是这样：

• 早上到工位，飞书里已经有昨晚的巡检卡片：哪些服务正常、哪些异常；
• 想查什么，直接在群里 @ 它：“昨天 23 点到今天 8 点，XX 服务有没有报错？”——它去翻日志给你结论；
• 新服务上线，让它按模板生成部署脚本 / 配置，比自己手搓快得多。

真正省下的不是"打字时间"，而是**"切窗口、翻日志、拼命令"的上下文切换成本。**

八、总结

这套方案的三个关键决策：

1. 模型走自建网关 —— 解耦 + 成本可控 + 不怕单点故障；
2. 交互走 IM 机器人 —— 用你本来就在用的工具，零学习成本；
3. 能力靠 cron + 工具 —— 让它主动干活，而不是被动问答。

整套东西单机 Docker 就能跑，成本是一台小主机的电费。有兴趣的可以照着搭一遍，有坑欢迎评论区交流。

---

本文环境：Ubuntu 22.04 + Docker 24+ + new-api + Hermes Agent，全部组件开源。