※ “2 分钟、0 次”是 2026 年 11 月 12 日在开发环境中实测的结果。
运维的不安，在于依赖于人。
负责人离职、生病、休假，知识只在个人脑中，夜间和节假日的故障处理，写报告。运维 AI Bot 用机制消除对人的依赖。
BEFORE ── 由人承担的运维
- 夜间和节假日也要有人值班、被叫醒
- 读日志、修复、按手册发布
- 知识在负责人脑中，离职就带走
- 报告和交接资料由人来写
AFTER ── 交给运维 AI Bot 的运维
- AI 24 小时值守，检测后自己建工单
- 调查、修复、测试、PR 都由 AI 完成
- 原因、处理和团队约定记在系统里
- 计划、证据和结果留在工单里，不用另写报告
由 AI 承担运维保守的“作业”。
自己管理工单
从聊天消息、错误和 CI 失败中自动建单。编号、状态、经过、证据和 PR 全部保留。
在团队群里对话
不用 @ 也能捕捉请求和问题，能读图片、PDF 和日志，并在同一个群里回复受理编号和结果。
先出计划，确认后再改
对于变更需求先给出计划，得到同意后写测试、修复，并在专用分支提交 PR。
开发环境自动发布
只有 CI 全部通过的变更才经审批网关替换上线。失败时回退到上一版本。
生产环境由人审批
AI 只负责提案。审批网关确认审批人、提案人与审批人不同、计划一致后才执行。
用记忆防止遗漏
记住原因与处理、步骤和团队约定，用于下一次判断。不记个人信息。
只要写下来，AI 就会行动。
开发与测试期间
产品测试负责人、设计者、开发者和测试人员，只需在有运维 AI Bot 的聊天群（LINE、Teams、Slack）里留言，不需要 @。AI 会建成工单、给出计划，得到同意后修复和测试，发布到开发环境并汇报。决定事项和搁置事项也会完整记住。
上线之后
群里是客户的负责人、运维人员和运维 AI Bot。全年 24 小时，监控、检测、分析、修复和验证由 AI 完成，人只需“审批”，在手机上点一下。上线后的改进需求也按同样流程发布。
与工单管理工具的区别在于
谁来干活。
工单管理工具记录人的工作并使其可视化。运维 AI Bot 则由 AI 亲自完成工作。两者没有优劣之分，只是承担的范围不同。
| 传统运维管理工具 | 运维 AI Bot | |
|---|---|---|
| 谁来干活 | 人（AI 辅助做摘要、回复草稿） | AI（人负责方针、判断和审批） |
| 发现问题 | 人看监控通知 | AI 检测并建单 |
| 调查与修复 | 负责人读日志、修改 | AI 调查、修复、测试并提交 PR |
| 发布 | 人按手册操作 | 开发自动，生产由审批网关执行 |
| 汇报 | 人写报告 | 计划、证据和结果自动留在工单里 |
半夜发生一次故障时
AI 检测并建单（不叫醒任何人）
调查原因，修复并测试，准备好 PR
负责人早上用手机查看内容并审批
按固定流程发布，报告自动留存
负责判断的 AI，负责作业的 AI。
运维 AI Bot 是运行在与业务系统分开的服务器上的独立平台。对目标系统只读取日志、健康状态、仓库和 CI 状态；写入只限于向 Git 提交 PR 和已审批的发布。
6 个入口
聊天消息（含图片、PDF、日志）、错误日志、健康检查、CI 结果、Git 事件、定时触发。人的请求始终受理；AI 推断出的工作只处理符合团队规则的部分。
Router 与 Worker
Router 按目标常驻，负责受理、分派和回答（不能用 shell，也不能写文件）。Worker 按工单启动，在隔离的工作区里调查、修复、测试并提交 PR。
变更等级由程序决定
由程序而不是 AI，根据变更的路径和内容判定等级。涉及金额、权限、个人信息、数据库结构的变更需要额外确认。AI 不能放宽自己的规则。
生产密钥只在审批网关
审批网关是不调用 AI 的程序。确认审批人资格、提案人与审批人不同、计划与验证过的版本一致、冻结期之后才执行。
失败自动回退
开发环境发布后若健康状态没有恢复，自动回退到上一版本并通知人和 AI。目标服务器只接受固定命令（发布、回退、重启）。
模型可选
通过 OpenAI 兼容或 Anthropic 兼容的 API 连接，也可以使用企业自建的模型。Router 和 Worker 可以选用不同模型。
逐步扩大交给 AI 的范围。
| 等级 | AI 做的事 |
|---|---|
| L0 观察 | 只记录判断 |
| L1 分析 | 分析原因并汇报 |
| L2 修复方案 | 提交 PR（由人合并） |
| L3 开发自动 | 开发环境的合并、发布与回退 |
| L4 验证与提案 | 在验证环境确认后，提议生产发布 |
“自动修改生产环境”的等级，并不存在。
即使被操纵，也出不去。
与业务隔离
与业务系统分开的独立平台，不共享服务器、网络和机密信息。
AI 不持有密钥
AI 的执行环境里没有密钥和令牌，也不能访问外网。
全部留痕
判断、作业、审批和执行都记录在可检测篡改的审计日志里。
几分钟就失效的权限
Git 权限按仓库每次签发几分钟后失效的令牌。push 和 PR 由核心组件而不是 AI 执行。
不听从混入的指令
日志和消息里的指令一律当作不可信数据处理。规则和权限不会因文字而改变。
随时可以停
全部暂停、按期间冻结、降低自主等级、按工单停止。
导入所需条件
| 平台服务器 | 2 vCPU、内存 8 GiB、磁盘 64 GB 以上（Worker 并发多时增加）。Linux（已在 Ubuntu 24.04 LTS 验证）+ Docker Compose v2 |
| 部署位置 | 在客户的云或数据中心放一台专用服务器。已在 Azure 验证，其他云和本地机房也是同样构成 |
| 网络 | 入站 443、80。出站只到 AI 模型、GitHub 和聊天工具的 API（经白名单代理） |
| AI 模型 | OpenAI 兼容或 Anthropic 兼容的 API（合同与 API Key），企业自建模型也可 |
| 集成 | GitHub（仓库、CI）、运维群使用的聊天工具（LINE、Teams、Slack） |
| 目标系统 | 先从健康检查 URL 和日志读取入口开始。无需修改业务逻辑（需要追加设置） |
导入步骤 ── 从观察开始，边确认边扩大
事前诊断：确认目标、环境、CI 和发布方式，列出需要的设置
观察：接入后确认 AI 的判断与人一致
修复方案：接入聊天和 Git，确认 PR 质量
开发自动化：CI 通过的变更自动发布与回退
生产审批：发布计划由审批网关执行
提供状况（2026 年 11 月）
已提供
- 在聊天中提出请求、提问和审批
- 从工单管理到 PR
- 开发环境的自动发布与自动回退
- 审批网关、变更等级、自主等级
- 控制台、记忆、审计日志
陆续提供
- 验证环境与生产的发布计划运用
- 每日摘要自动推送
- 与 GitLab、Jira 等集成
- 一个平台管理多个系统
- SaaS 形式