企业官网建设流程全解析

从零搭建自己的 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 一行代码。

三、组件选型

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

四、实战：三步搭起来

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

mkdir-p/opt/ai-gateway&&cd/opt/ai-gatewaycat>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 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_URL=http://<网关IP>:3000/v1\-eOPENAI_API_KEY=sk-你的网关令牌\hermes-agent:latest

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

配置里通常需要指定：

model:provider:openai-compatiblebase_url:http://<网关IP>:3000/v1name: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-checkschedule:"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，全部组件开源。