软件架构师罗小东，多年架构和平台产品设计经验，目前在 Agent 场景落地结合中。

概述

做平台型，一定会遇到运维管理的问题，通常少的可能面对的是10+人的技术团队，多的则面对100+人的技术团队。另外一个是项目型的，再小的项目，也涉及到运维的管理，大的项目涉及到的面就更加广。

在系统和平台级的运维层面来说，常常会遇到典型问题：

• • 告警风暴：告警太多像风暴，真问题被淹没，人工筛选累死人。
• • 故障定位慢：故障来了像破案，跨系统翻日志，全靠老师傅经验。
• • 数据孤岛：监控数据各管各的，像盲人摸象，拼不出故障全貌。
• • 被动响应：总是事后救火，没提前预警，业务受损才着急。
• • 自动化断层：AI分析出根因，但没法自动修复，还得人工接手。
• • 成本优化难：云资源用不用都花钱，缺乏智能调控，成本居高不下。
• • 合规压力大：合规检查靠人工，容易漏项出错，面临监管处罚风险。
• • 知识传承难：运维经验在老师傅脑子里，新人接不上，容易断层。
• • 信任缺失：AI给建议像黑盒，说不清原因，运维不敢放心用。
• • ......

原来的设计思路很多，也整合过ELK、Promethus之类的一套，比较难交出，普通人员很难接手，普及起来也会有一些难度，基于AgentOps来解决这个问题。

设计

这里目前针对于中小型项目和内部资源，基于Agent来过程来自动运维管理的落地实践，过程由Agent操作，管理员做核心确认。整个架构设计如下：

从上往下分四层，横向两条贯穿的竖栏不在流程里，而是压在流程上的约束和产出。

① 交互入口层，任务从这里进来。四种入口：对话提问、副驾目标、定时任务、过程溯源。对话里用 @ 定位数据对象、# 定位功能界面，这一层的作用是把"要干什么"讲清楚，不涉及怎么干。

② Agent 编排层（Harness），决定用谁去干。大模型可以换厂商、配调用策略，能力用 SKILL 挂、用 MCP 接，上下文里带上业务规范 SPEC 约束口径，实际执行放在沙箱里。这一层右上角单独立了一个卡口：建议出来以后要走"采纳并执行"，管理员确认了才继续。模型可换、能力可插、动作可控，说的就是这一层。

③ 连接器层，决定手伸到哪里。SSH、Kubernetes、GitLab、Jenkins、数据库、邮箱与 OSS，Agent 的可达范围由这一层划定，不在清单里的地方就到不了。跳板机在这一层统一收口，不直连服务器。

④ 资源台账与知识资产，是被管和被写的对象。服务器台账、中间件环境台账、部署文档、巡检报告、工单台账、仓库台账、人员台账、知识库、素材与密钥、业务功能分组。字段和分组都是动态可加的，结构化数据配字段，非结构化文档在线编辑，Agent 自己维护自己管的范围，这也是台账不至于过时的前提。

左边那条"安全与管控"贯穿四层：跳板机统一入口、操作权限范围、密钥加密存储、危险命令限制级、全程步骤溯源、Agent 行为准则。它不是某一层的子项，每一层都得过这道约束，红线内放行、越界即拦。右边那条"交付产出"也贯穿四层：Word 巡检报告、台账记录落库、部署文档生成、邮件与首页通知、问题清单、经验沉淀回写知识库。过程留痕是顺带产出的结果，不是额外补的作业。

读操作默认放开，写操作按危险等级分级，不可回退的动作必须人工确认。这条线划在哪，决定了这套东西敢不敢真用在生产上。

基础的资源管理，主要的管理如下：

• • 服务器台账： 针对于服务器资源和管理和维护，分组等，类似于CMDB；
• • 中间件台账： 针对于所有中间件的管理，包括消息、数据库、缓存、Ansible、反向代理、k8s等；
• • 部署文档管理： 过程中的所有部署文档材料还有留痕的文档；
• • 巡检文档管理： 针对于工单的处理还有过程归档，还有每一步的操作留痕；
• • 运维团队管理： 涉及到的开发人员、运维人员的管理，主要是用于发送邮箱通知汇报等；
• • Gitlab仓库台账： 涉及到的jenkins、git项目文档的管理；
• • 工单台账管理：业务部署还有业务组反馈的问题记录还有排查处理过程，解决过程等；
• • 知识库管理： 运维相当的知识库管理和相关的问答材料、管理材料、规范等；
• • ....

功能做成了动态添加，可以让Agent来管理和添加，自定义字段，比如可以添加运营管理的功能。

安全和管控如下：

• • 跳板机的管理： 统一的跳板机管理，而不是直连服务器资源 ；
• • 操作权限认证的管理： Agent操作的权限范围还有哪些需要人工介入的操作，可执行的操作的确认；
• • 密钥的管理： 中间件、服务器、三方平台的密钥管理，不能出现明文密钥等；
• • 连接器管理： SSH、Gitlab、Jenkins、Kubernetes、OSS（minio等，用于备份）
• • 回答过程溯源能力： 过程每一步执行的回答及所有步骤的溯源查看；
• • 危险命令的处理： 限制级命令和操作的处理，规避越界操作；

除了内部的原本能力以外，还添加了Agent智能体的行为准则，类似于机器人的行为准则【不能伤害人类】一样。每个架构师有自己的设计，我有我思。

集成效果

集成效果因不同的团队而异，集成效果如下：

• • 对话式管理所有的资源、服务器等
• • 对话式管理部署中间件和更新中间件，同时整理出部署文档，然后发给对应的人员
• • 对话式管理CICD和K8S发布运维管理
• • 对话式管理知识库和添加个人经验沉淀
• • 对话式每天运维管理和巡检，然后发送对应的人员
• • .....

下面拿几个典型场景做演示示例，每一个都是实际在跑的那一句提问。

示例一：一句话跑完一次K8S节点存活巡检

我早上一般只发一句话：给开发和测试那两台K8S节点做一次存活巡检，结果写成一条巡检报告记录。三分十四秒回来，Word报告生成好了，同时库里落了一条巡检记录。

报告的写法是结论先行。

第一章巡检概要，写清楚检查对象、走的哪条通道、本次是只读、给出的落库编号；

第二章直接下结论abnormal，附判定口径和今天需要我拍板的事项；

第三章把205和206两套集群按五类检查逐项并列，资源水位另外补了实测值；

第四章是测试集群问题清单，3个问题按对象、现象、根因、影响面、建议动作拆开列表，后面跟着13个异常Pod的明细；

第五章开发集群逐项实测，本次无异常；

第六章补充观察，比如两套独立集群待核台账、df -h有一次挂起、phase选择器漏抓CrashLoop；第七章数据来源与可信度，把所有取数命令原样列出来。

第七章是我认为最有价值的一章。

AI说的每一句话都能落到一条具体命令上，我要复核直接复制去跑就行。它不是"我觉得有问题"，是实测数据有问题，前面提到的信任缺失就是这么解掉的。

示例二：一条Kafka告警，跨台账把根因串起来

chs-sms-service报Kafka地址无法解析。放以前这套流程得走两个人：先问开发这个地址配在哪，再去中间件台账里翻kafka那条记录，然后登服务器看当前值和连通性。

现在就一句：bootstrap.servers配在哪里、现在还能连上吗。

Agent从中间件环境台账定位到那条记录，拿到配置的位置和当前值，再通过连接器到节点上实测一次连通性，最后把这个中间件被哪些服务在用一并带出来。一次提问替掉了三次转手，故障定位慢这件事，慢的地方本来就不是分析，是找信息和等人。

示例三：根分区用到81%，先给清单再动手

205根分区告到81%，我的问法是列出最占空间的目录和容器镜像。它把实测占用排出来，分清哪些是容器镜像、哪些日志能清、哪些挂着业务不能碰，再给建议动作。

这里有个边界我一直守着：它只出清单和建议，删除这类不可回退的操作必须我在会话里确认。磁盘治理这件事，误删一次的代价比多等一分钟大得多，这也是危险命令处理那一条存在的意义。

示例四：台账和文档跟着过程自己长

服务器台账现在25条记录，服务名称、环境、建设状态、单台CPU核数、内存、硬盘都是结构化字段，可以按名称模糊查、按环境筛。

关键在字段可配：想加一列不用改代码，要统计GPU或者信创标记，加个字段就完事。业务分组同样是动态的，现在挂着服务器管理、文档管理、代码仓库、项目组团队四组，下面是服务器台账、中间件环境台账、部署文档、巡检报告、Gitlab仓库台账、开发人员台账、SVN仓库台账这些功能，要接运营管理再新建一组。

CMDB最容易死在"导入那天就是最新的那天"。字段和分组能自己长，部署过程又能自动留痕成部署文档发给对应的人，台账才有人愿意维护下去。

示例五：把重复的巡检交给定时任务和副驾

重复的事交给时间。我挂了一个目标，每天9点30自动跑一次K8S存活巡检，单次最多交5条。到点它真的跑一次Agent任务去查数据、给建议，产出的规划按紧急度分了级：测试集群10个业务Pod持续崩溃算紧急，205根分区81%加负载12.8超标算重要，台账口径待修正算提示。需要我马上定的那几条顶在首页，其余按日期倒序留着翻旧账。

被动响应变成主动盯，靠的不是模型更聪明，是把巡检这件事变成一个到点就会执行的目标，并且把结论按我该先处理哪条排好序。

上面这些是对话式能覆盖的日常。还有很多能力，配上SKILL基本可以做横向扩展，还有MCP集成等，这些都基于当前的AgentOps进一步增强。

AgentOps能力演示

这里主要是设计的平台基础功能，还有管理能力。主要功能如下：

• • 智能体配置： 针对于Agent的配置，包括SKILL、大模型、MCP、上下文、定时任务、沙箱等Harness环境的管理；
• • 知识库管理： 知识库的CURD管理、还有分级分类管理；
• • 业务管理： 功能管理还有功能规范（类似于数据标准、业务本体）的管理；
• • 全局配置管理： 密钥、定时任务、素材文档的管理；
• • AI副驾管理： 自动化运行处理还有管理，类似于PersonAgent，不过在运维上不太建议；

全局配置：四类配置收在一个页面

平台的基础配置我不喜欢散在各个后台，这里收成一个页面，分全局、业务、知识库、智能体四类。

上半屏看全局配置这一组：组织配置管应用名称、logo和工作台服务入口，系统配置放全局能力开关与运行参数（当前跑的是CodeMode），密钥配置负责加密存储和权限管控，请求Token管数据访问且支持脱敏显示，素材文件管智能体任务的上传附件，定时任务按cron、固定间隔或一次性计划触发，监控服务看接口维度的7日与24小时调用量趋势。

智能体配置：模型能换、能力能插、账能算清

下半屏是智能体配置这一组，

这一组实际解决两件事。一是能力可插拔：换模型不动业务代码，要加一块新能力就挂个SKILL或者接个MCP，运维范围横向扩出去，平台本身不用改。二是账算得清：模型调用花了多少积分、哪条任务扣的，有流水可查，不至于问到成本只能靠估。

云资源之外的第二笔开销，就是这么管住的。

副驾：让AI主动盯，但不给它越界的口子

副驾是自动化那部分，界面上分三层。

这个界面里最关键的是那条边界：目标到点只是交出一次真实的Agent任务去查数据、给建议，只有我点"采纳并执行"，这条建议才变成一个要我确认的动作，高危写操作仍然走会话内的既有确认，副驾绕不过去。

运维最怕的是不敢用AI，这个卡口就是把信任做成界面的一部分，而不是写进制度文档里。代价也说得很明白：每一个目标到点都是一次真实任务和一笔模型额度，不能随便挂。

总结

这个是AgentOps上一些实践和当前的使用情况，效果相对来说，是相当不错的，类似于编写代码一样的，这一年以来的，基本上都没有登陆到服务器进行管理和操作，几乎都是对话式的管理。

在那么多年的基础平台环境管理上面，基本上解决掉了前期大部分问题，其它的问题不是无法处理，而是进一步的深入探索。