企业运维 AI Agent 落地实践：从 MVP 演示到稳定可控运行的运维Agent系统一、运维的痛与 Agent 的价值运维人的日常痛点 做运维的同学应该都有共鸣：On-Call 的代价。无论故障大小，运维团队基本处于随时待命的状态。哪怕出去旅游，领导也会要求带上电脑。凌晨 3 点被告警叫醒，排查半小时发现只是个 VPN 连不上的问题——这种事每周都在发生。排查费时费力，现网中的服务问题通常不是单点问题。应用运维说可能是数据库，数据库那边查了说没问题，可能是系统或网络——各团队互相扯皮，排查链路漫长， 重复工单堆积，权限申请、服务器扩容、防火墙变更，大量重复性 Case 堆积如山。老员工的排障经验无法有效沉淀，新人接手断层严重。AI Agent 能带来什么？这三个痛点在没有 AI 之前也能解决——堆人力、招 SRE 专家。但 AI 的出现提供了第二种选择：用更低的成本实现同样的效果。释放重复劳动：让 Agent 处理标准化 Case，运维专注高价值工作；7×24 极速响应：全天候无休，减少 On-Call 对工程师的消耗；降低人为失误：标准化执行，减少疏漏；跨系统自动联动：一句话触发，Agent 自动跨多个系统完成操作。 实际场景举例 ：场景一：零信任工单自动处理。传统方式需要登录 OA 看工单 → 切到零信任后台 → 查用户 → 建资源 → 配授权 → 回钉钉通知 → 回 OA 关工单，6 个系统 7 步操作。引入 Agent 后，工程师只需说一句"处理下 xx 的零信任工单"，Agent 自动跑完全流程。场景二：内核级深度问题定位。传统排查到应用层就停了——Connection Reset，重启试试。但 Agent 会继续往下挖：查 dmesg、查 syslog，发现 nf_conntrack table full。借助 LLM 广阔的知识图谱，Agent 具备跨越应用层、系统层到内核层的深度诊断能力。场景三：开发测试自助排障。以前开发同事反馈"测试环境 user-service 启动失败"，需要提工单等运维响应。现在直接问 Agent，Agent 自己去查日志、定位问题、给出建议。开发自助闭环，运维不用介入。 二、Agent 架构设计 ### 整体四层架。  我们的架构分为四层：1. 钉钉通道层：Agent 入口在钉钉，通过 Stream 长连接接收消息。包括消息回调、卡片交互、OAuth 认证、附件处理等。2. 消息路由层：身份认证、会话管理、Agent 路由。不同用户的消息会到达不同的 Agent——非技术员工走自助服务 Agent，运维人员走运维 Agent。3. Agent Harness 层：核心编排框架，包含 ReAct 推理引擎、上下文工程、多层记忆、工具调度、安全控制。4. 基础设施层：LLM 集群、Neo4j 图数据库、向量库、对象存储、JumpServer 等。Agent 不是一个模型，而是一个编排框架。模型只是其中的推理引擎，围绕它还有大量的工程设计。 三、工具能力封装演进- 共四个阶段。起步期：MCP 标准工具。按 MCP 标准封装每个运维原子能力。Schema 定义繁琐，大量适配代码，工具数量面临爆炸风险。觉醒期：脚本框架。发现命令执行通道是通用的——既然 Agent 能通过 JumpServer 执行命令，那各种运维脚本就是可以直接执行的能力。突破期：SOP 知识驱动。用"知识指引"替代"代码堆砌"。为 Agent 编写 SOP 文档，有效化解多云运维的庞大工作量。成熟期：Agent CLI 化。60+ 独立工具被压缩为单一 CLI 入口。工具元数据 Token 消耗从万级降至数百。 Agent CLI 工具全景CLI 化之后，Agent 只需要知道 `agent-cli <类别> --help` 就能自助查阅工具用法。上下文里只放一个能力速查表，详细参数按需获取。凭证托管：最关键的设计 Agent CLI 不只是工具封装，更重要的是**用户凭证的托管和权限控制。大模型不参与凭证处理，凭证在 CLI 层透明注入。不同用户、不同角色加载不同的凭证。 四、JumpServer 命令执行器这是运维场景最经典的工具——让 Agent 能登录数千台服务器和网络设备。 我们采用 SSH 自动化的方式，模拟人类登录 JumpServer 的过程。每轮给 Agent 一个随机结束符（cli_round_guard），确保复杂多行命令的准确提取。命令执行后的输出捕获是动态的：设置最大阈值，同时设置动态阈值（连续 2 秒无新输出则提前终止）。 五、SOP 知识体系SOP 是 Agent 的操作手册。Agent 不是靠 LLM 的通用知识做运维，而是先读 SOP 再执行——和人类工程师一样。 我们积累了 68 篇 SOP，覆盖各运维领域。新增一项运维能力，最低成本的方式就是写一篇 SOP 上传。Agent 下次遇到相关问题时会先读 SOP，然后按流程操作。不需要改任何代码。 六、多层记忆系统-四层记忆体系普通聊天机器人只有对话历史。但运维 Agent 面临不同的挑战：复杂排查需要 10+ 轮工具调用，早期发现会丢失；不同用户之间有协作关系；同一台服务器可能反复出问题。我们设计了四层记忆：短期记忆、事件记忆、协作记忆、长期记忆。 事件记忆：解决"马冬梅问题"Agent 在第一轮很清楚这是"马冬梅"，但过了两轮之后就变成了"马东什么"或"马什么梅"。前几轮推理过程中发现的关键信息，在后续循环中丢失了。解决方案：给 Agent 配两个"秘书"。S1 管理消息入口（新 Case 还是老 Case），S2 记录每轮的"会议纪要"（关键事实实时提取）。 协作记忆：跨会话感知A 让 Agent 转达消息给 B。传统做法是单向的——B 收到消息但不知道来龙去脉。我们把所有用户 Session 全量归档到 Neo4j 图数据库，协作类消息事件作为锚点，在两个 Session 之间建立连线。B 再次对话时，Agent 就知道背景。 长期记忆（Mem0）基于开源 Mem0 框架，提供跨 Case、跨时间的永久记忆。坦率说，在运维场景中长期记忆并不是最重要的——运维 Case 处理更多依赖 SOP 和实时状态查询。但作为记忆体系的补充，我们还是引入了。记忆优先级 四层记忆有时会冲突。优先级：短期记忆 > 事件记忆 > 协作记忆 > 长期记忆。 七、安全基石：AI 审批与凭证隔离AI 审批：拒绝"先斩后奏"在 ReAct 循环的工具解析节点插入 AI 审批判断。引入 Flash 级别的小模型，2 秒内判断这个命令是否需要用户二次确认。高风险操作通过钉钉卡片让用户确认。AI 审批比硬规则更智能。Agent 第一次删除用户因没加 sudo 失败，第二次加了 sudo 重试。AI 审批能看到上下文——这是刚才已经审批过的同意图命令，不需要重复审批。 凭证隔离：千人千面全员可用的 Agent 服务，但每人只能操作权限范围内的资产。凭证在 CLI 层托管，不暴露给模型，也不暴露给用户。 八、实战表现：阿里云网络变更 一个真实案例：把一个 /16 的 VPC 拆成两个 /17 的 VPC，重新规划 CIDR。Agent 自动读 SOP、查询现有配置、逐个清理资源、重建 VPC 和交换机。最后一次经历了 30 轮循环，把整个变更做完了。OA 自动化与数据查询 财务同事看费控数据、运营同事看外呼数据，都能通过 Agent 自助查询并生成图表。OA 工单的查询、审批、提交也已全面覆盖。 九、未来方向1. 运维知识图谱：从扁平 SOP 文档升级为关系图谱，让 Agent 能做影响分析和根因推荐；2. Agent 间协作：用户的自助 Agent 向运维 Agent 发起求助，经人工审批后由运维 Agent 执行；3. 用户运行时沙箱：基于 K8S 为每个用户提供隔离容器，支持个人脚本和定时任务；4. Agent 安全：IM 入口让安全边界前置到钉钉消息层面，需要更完善的身份确认和攻击防护 。 Q&A 精选Q：用的是什么模型？A：主要用先进模型（Claude Opus 4.6 等）。运维 Agent 这种主动式任务处理，消耗的 Token 并不多，每月不到 200 美元。真正消耗大的是循环型任务和 AI Coding。 **Q：这个是基于 OpenClaw 做的吗？** A：不是，我们是从去年 9 月开始自研的，基于 LangGraph 框架。如果现在要快速落地，可以考虑拿 OpenClaw 或 Claude Code 二次开发。但如果追求深度定制，自研更灵活。Q：如何处理没有 API 的老旧系统？A：我们遇到过只有 Web 管理页面的语音 SBC 设备。通过逆向 HTTP 调用、提取 Cookie，甚至用图像理解模型识别验证码来实现自动化。做起来有点复杂，但可行。Q：Agent 的准确性如何保证？A：模型幻觉依然存在，这是事实。我们通过 SOP 约束、AI 审批二次确认、用户凭证隔离三层保障来兜底。即使 Agent 的指令遵循不是 100% 准确，用户二次确认可以帮它兜底。 欢迎更多小伙伴跟帖提问~