研运一体化思想

为什么会有这个方案？

得益于 OpenClaw、Hermes 以及人工智能领域的高速发展，传统技能型人员正在面对一个很现实的问题：你的经验，如何和现在的 AI 大模型相比？你的排障速度，怎么可能一直比 AI 更快？

这句话可能有点刺耳，但这是现实。

过去运维、开发、测试，大家靠的是经验积累。谁见过的问题多，谁处理得快，谁就更有价值。但是现在不一样了，AI 本身具备极强的信息总结能力、模式识别能力、代码分析能力和知识迁移能力。一个普通技术人员，如果还是只靠自己一个人一点点翻日志、看指标、查链路、搜资料，那么在未来的故障响应场景里，效率一定会越来越低。

基于这种时代变化，我构想出了一个基于 AI-Agent 的方案：

研运一体化诊断系统。

这里说的研运一体化，不是传统意义上喊口号的 DevOps，也不是让运维去写业务代码、让开发去管服务器，更不是让 AI 直接接管生产环境。这个方案的第一阶段目标很明确：

只做诊断，不做生产变更。

也就是说，AI-Agent 不负责重启服务，不负责修改配置，不负责发版，不负责删除数据，不负责自动修复线上问题。它第一阶段只做一件事：

在故障发生后，尽可能快、尽可能准地完成故障分析、根因定位和解决方案建议。

准确率目标暂定为 80% 以上，但这里的 80% 不能简单理解成 AI 每次都能直接命中唯一根因，这不现实。更合理的目标应该是：AI 给出的 Top 3 怀疑方向中，能够覆盖最终真实根因的比例达到 80% 以上；核心组件级别，例如 Redis、MySQL、Kafka、JVM、网关、宿主机等，定位准确率达到 80% 以上。至于 Top 1 根因完全命中，可以作为后续优化目标。

为什么要这么做？

现代项目，大多以微服务为主。微服务时代最核心的三大观测指标就是 log、metric、trace，也就是日志、指标、链路。

但是在真实生产环境里，这三类数据往往是分散的。

日志在 ES 里，指标在 Prometheus 或 VictoriaMetrics 里，链路可能在 SkyWalking、OTEL、Jaeger，或者同样落到了 ES 里。服务发布记录在 Jenkins，代码在 Git，配置在 Nacos，进程状态可能在 Supervisor，容器状态可能在 Docker 或 K8s。每一类数据都能说明一部分问题，但很少有人能在故障第一时间把这些信息完整串起来。

现在大多数中小型公司排障，还是从用户反馈开始。

比如用户说：“系统变慢了。”

就这一句话，后面实际要做的事情非常多。

运维要看服务器 CPU、内存、磁盘、网络、连接数、负载，要看 Redis、MySQL、Kafka、Nacos、网关、中间件是否异常。开发要看服务日志、错误堆栈、接口耗时、业务调用逻辑，要看是不是最近上线代码引入的问题。然后大家再把各自看到的信息汇总到群里，一起判断到底哪里出了问题。

这个过程非常现实，也非常低效。

问题主要有几个：

（1）费时费力，第一时间定位问题能力弱。

（2）排查人员能力有限，发现现象之后不一定能定位根因。

（3）日志、指标、链路分散，关联性弱。

（4）技术人员对完整业务链路的熟悉程度不一定足够。

（5）系统级慢请求、局部中间件异常、部分服务受影响等问题，很难第一时间归因。

大厂可以靠高级人才、成熟平台、完整工具链去解决这些问题。但中小企业不一样。中小企业没有那么多人，也没有那么多预算，更没有那么完整的平台建设能力。可问题在于，小企业也罪不至死。业务出问题了，一样要有人排，一样要快速恢复。

所以这个方案的核心思路就是：

不要让 AI 替代人直接操作生产，而是让 AI 成为故障诊断中枢。

也就是说，人还是最终决策者，AI 负责把分散的信息收集起来，把历史经验调出来，把代码逻辑分析出来，把日志、指标、链路、发布记录、业务依赖关系串起来，然后给出一份尽可能可靠的诊断结论。

所谓的研运一体化，需要拆开来看。

首先是运维模块。

我对运维更熟悉，所以先讲运维。运维在故障排查里基本是中流砥柱。除非是非常明确的业务代码问题，否则绝大多数生产问题都会经过运维这一层。

运维面对的最大问题，不是没有数据，而是数据太多。服务器有数据，中间件有数据，监控系统有数据，日志系统有数据，链路系统有数据，Docker、Supervisor、K8s、Nginx、网关都有数据。真正难的是：如何在海量信息里，第一时间找到真正有价值的证据。

举个例子，用户反馈业务变慢。那运维该怎么排？

先看接口慢在哪里？看网关？看服务日志？看链路？看 Redis？看 MySQL？看 Kafka？看服务器负载？看网络连接？看最近有没有发布？

如果是 Redis 慢，那是连接数满了？CPU 单核打满了？慢查询？KEYS？SCAN？大 key？内存淘汰？网络问题？

如果是 MySQL 慢，那是慢 SQL？锁等待？连接数满？索引失效？磁盘 IO？主从延迟？

如果是 Kafka 慢，那是 broker 异常？consumer lag？生产端连接异常？topic 分区不合理？ISR 异常？磁盘压力？

如果是 JVM 服务慢，那是 Full GC？线程池满？连接池满？OOM 前兆？接口下游超时？

这些东西每一个方向都需要经验。问题在于，中小企业的运维不可能每个方向都非常精通。更现实的是，一个运维可能要同时管服务器、中间件、监控、发布、网络、备份、安全、容器、K8s、CI/CD，还要跟开发一起排业务问题。

这就是 AI-Agent 的价值点。

运维模块的核心，不是让 AI 随便 SSH 到服务器执行命令，而是让 AI 通过受控工具获取诊断信息。比如 Prometheus 指标查询、ES 日志查询、链路查询、中间件专项诊断脚本、主机只读巡检脚本等。

这里计划通过 MCP 来实现。

MCP 的定位不是让 AI 自由发挥，而是把复杂的数据查询能力封装成受控工具。AI 只能传入有限参数，例如服务名、时间范围、日志级别、关键字、实例地址、trace_id、topic、consumer group 等，然后 MCP 负责去 Prometheus、ES、链路数据、Jenkins、Git、宿主机诊断脚本里拿数据。

比如可以设计这些 MCP：

prom_query_mcp，用于查询 Prometheus 或 VictoriaMetrics 里的指标。

es_log_query_mcp，用于查询 ES 里的服务日志、错误日志、关键字日志。

trace_query_mcp，用于查询链路数据，比如接口耗时、span 耗时、trace_id 关联信息。

release_query_mcp，用于查询 Jenkins 发布记录、构建号、commit、发版时间。

code_search_mcp，用于在代码沙箱里搜索业务代码、调用逻辑、Redis / MySQL / Kafka 使用方式。

host_doctor_mcp，用于执行只读主机诊断脚本。

redis_doctor_mcp、mysql_doctor_mcp、kafka_doctor_mcp，用于执行中间件专项诊断。

jvm_doctor_mcp，用于分析 JVM 服务状态，例如线程、GC、内存、重启情况。

这里最重要的一点是，AI 不直接写 ES DSL，不直接自由执行 shell 命令，不直接改生产配置。AI 只是传参数，MCP 和脚本负责受控执行。

比如 ES 查询不能让 AI 直接写完整 DSL，而应该定义固定参数：

服务名是什么？

日志级别是什么？

查询时间范围是什么？

关键字是什么？

最多返回多少条？

是否需要聚合错误模式？

这样可以避免 AI 查询过重，也避免误查敏感数据。

同样，PromQL 可以开放模板化查询，但不建议一开始完全让 AI 自由写 PromQL。尤其是在生产环境里，任何查询都应该有边界，有时间范围，有结果限制。

另外，所有诊断脚本的输出都应该尽量结构化。不要只输出一大段自然语言，而是输出 JSON，至少包含 status、severity、evidence、suggestion、confidence 这些字段。

比如 Kafka 诊断脚本 Kdoctor，就不应该只是告诉人“可能有问题”，而是应该告诉 AI：

哪个 broker 有问题？

哪个 topic 有问题？

consumer lag 是多少？

ISR 是否正常？

磁盘是否接近阈值？

连接是否异常？

证据是什么？

建议下一步怎么查？

这样 AI 拿到的不是一堆杂乱文本，而是一组可分析、可关联、可归纳的结构化证据。

我之前写过一个 Kdoctor，它通过提供 Kafka broker 地址，就可以快速完成 Kafka 相关问题巡检。这个方向非常适合继续扩展。后续可以做 RedisDoctor、MySQLDoctor、HostDoctor、JVMDoctor，把很多原来依赖人工经验的排查步骤固化成脚本。

这样做的好处是：AI 不需要一步一步敲命令，它只需要知道什么时候调用哪个工具，然后拿到返回值进行分析。

strace 这类工具也可以纳入体系，但它不应该作为第一排查工具。strace 更适合疑难问题，比如进程卡住、网络连接异常、文件 IO 异常、系统调用异常等。常规问题还是应该优先从日志、指标、链路、中间件专项诊断入手。strace 可以做，但必须受控，不能让 AI 随便 attach 生产进程。

生产命令这一块，第一阶段暂时不打算让 AI 自由操作。AI 不应该自己执行 systemctl restart，不应该自己改 Nacos，不应该自己发版，不应该自己删 Kafka topic，不应该自己 kill 进程。即使是诊断脚本，也应该通过固定目录、固定用户、固定参数来执行。

比如可以在宿主机上创建 ai-diagnose 用户，只允许它执行 /opt/ai-diagnose/bin/ 目录下的只读脚本。sudoers 只开放必要脚本，不开放 shell，不开放任意命令。所有执行行为必须审计，记录谁触发、什么时候触发、执行哪个脚本、传入什么参数、返回什么结果、耗时多少、是否失败。

这样 AI 虽然参与了生产诊断，但没有生产变更权限。

再说开发模块。

我对开发的理解没有运维那么深，但从现在的趋势来看，开发侧的问题也很明显。现在越来越多代码基于 AI Coding 完成，开发效率确实提高了，但是代码量也会越来越大，业务迭代速度也会越来越快。

代码写得快，不代表代码质量一定高。很多问题在测试环境不一定能暴露，到了生产环境，随着真实数据量、真实流量、真实并发、真实依赖关系出现，问题才会爆发。

之前碰到过一个非常典型的问题：生产环境 Redis 被打满，后面发现业务代码里大量使用 KEYS 做模糊查询。第一次出问题后，把 KEYS 改成了 SCAN 10000，结果第二天还是顶不住，最后才改成精准 key 查询。这个问题本质上不是 Redis 本身的问题，而是业务代码使用 Redis 的方式有问题。

这类问题，如果只靠运维看指标，最多只能发现 Redis CPU 高、慢日志多、timeout 多。但是如果要定位到代码，就需要开发参与。如果开发不熟悉这块逻辑，或者代码量太大，定位速度依然会慢。

所以开发模块的核心是：

让 AI 能看懂业务代码，但不能让 AI 直接发版。

这里计划准备一个代码沙箱或容器。这个容器只存放代码，不连接生产环境，不存放敏感配置，不具备发版能力。Agent 可以通过 Git 感知代码变化，也可以根据生产服务版本 checkout 到对应 commit，然后分析对应版本的代码。

这里有一个关键点必须解决：

AI 分析的代码，必须是生产环境正在运行的代码版本。

不能生产跑的是旧版本，AI 分析的是最新 master。那样很容易误判。

所以需要建立一条链路：

生产服务实例，对应 Jenkins 构建号。

Jenkins 构建号，对应 Git commit。

Git commit，对应代码沙箱 checkout 的版本。

服务启动日志或构建产物里，最好能打印 build-info，比如服务名、版本号、commit id、构建时间、分支名。

如果能把服务名、运行环境、jar 包、构建号、commit、Nacos 配置版本关联起来，那么 AI 分析代码的准确性会高很多。

开发模块里还需要整理业务 Skills。比如服务之间的调用关系、核心业务流程、接口依赖、中间件依赖、开发规范、Redis 使用规范、MySQL 查询规范、Kafka 使用规范、异常处理规范等。这样当 AI 看到某个接口慢的时候，它不只是看一段日志，而是知道这个接口背后调用了哪些服务、依赖了哪些中间件、走了哪些业务逻辑。

这就是研运一体化真正有价值的地方。

不是让运维代替开发，也不是让开发代替运维，而是让 AI 作为中间层，把运维数据和开发代码连接起来。

再说 Skills 和 Memory。

Hermes 最让我感兴趣的地方，就是它的三层记忆能力：session、memory、skills。

session 是当前上下文，解决的是当前这一次对话或故障的信息承接。

memory 是历史经验，记录的是之前发生过什么问题、最后怎么解决、有哪些特殊环境约束。

skills 是能力沉淀，记录的是某类问题应该怎么分析、怎么判断、怎么看证据、怎么给建议。

这三层结构非常适合做故障诊断系统。

比如 Redis 曾经因为 KEYS / SCAN 导致 CPU 单核打满，那么这个问题解决后，不应该只是写一篇复盘文档放在那里，而是应该沉淀成 RedisSkill 下面的一个子 Skill。

比如：

RedisSkill
RedisHighCPUSkill
RedisKeysScanSkill
RedisTimeoutSkill
RedisConnectionSkill
RedisMemorySkill

MySQL 也可以类似：

MySQLSkill
MySQLSlowQuerySkill
MySQLLockWaitSkill
MySQLConnectionSkill
MySQLIndexMissSkill
MySQLDiskIOSkill

Kafka 也一样：

KafkaSkill
KafkaBrokerHealthSkill
KafkaConsumerLagSkill
KafkaISRSkill
KafkaDiskUsageSkill
KafkaConnectionSkill

每一次故障彻底解决后，AI 根据完整上下文生成一个子 Skill 草稿，记录问题现象、影响范围、关键证据、根因、解决方案、后续预防方式。但是这个 Skill 不能直接进入主 Skills，必须人工审核。因为 AI 可能误判，如果错误经验直接进入长期知识，后面会越用越偏。

所以 Skills 应该走 Git 管理，有版本，有审核，有回滚，有适用范围，有最后验证时间。

Memory 也不能乱写。

Memory 里适合记录历史故障摘要、已确认根因、已验证解决方案、业务系统依赖关系、特殊环境约束、历史误判记录。不适合记录密码、Token、大量原始日志、用户隐私数据、未经确认的猜测、临时性命令输出。

Memory 需要定期检查、清理、重塑。否则长期运行后，它一定会变脏。脏 Memory 会比没有 Memory 更危险，因为它会让 AI 带着错误经验去分析新问题。

所以 Memory 最好也分层：

临时 Memory，用于当前故障上下文，故障结束后清理。

故障 Memory，用于已经确认的故障案例，长期保存。

业务 Memory，用于服务依赖、架构约束、特殊配置，长期维护。

再说输出。

AI 最终不能只说一句“可能是 Redis 问题”。这种输出没有价值。

标准输出应该包含几个核心部分：

问题概述。

影响范围。

关键证据。

根因判断。

置信度。

建议解决方案。

下一步人工确认项。

是否需要升级处理。

是否建议沉淀为 Skill。

其中最重要的是关键证据和置信度。

比如一次 Redis 问题，AI 的输出应该类似：

问题概述：某业务接口在 14:05 后响应时间明显升高，主要集中在 gateway 到 order-service 的调用链路。

影响范围：当前影响部分依赖 Redis 的接口，暂未发现全站不可用。

关键证据：Redis CPU 单核持续接近 100%；服务日志集中出现 Redis timeout；commandstats 中 scan 调用速率异常升高；慢日志中存在 pattern scan；受影响接口均依赖同一 Redis 实例。

根因判断：高概率为业务代码触发高频 SCAN / KEYS 类查询，导致 Redis 单线程阻塞，引发接口超时。

置信度：0.86。

建议解决方案：确认最近上线服务是否存在 Redis 模糊 key 查询；临时限制相关接口流量；将模糊扫描改为精准 key 查询或索引集合查询；修复后观察 Redis CPU、slowlog、commandstats 是否恢复。

这样开发和运维才能知道 AI 为什么这么判断，而不是盲信 AI。

整个系统从架构上可以分成四层。

第一层是数据源层。

包括 Prometheus / VictoriaMetrics、ES 日志、ES 链路数据、Jenkins 发布记录、Git 代码仓库、Nacos 配置、Supervisor / Docker / K8s 状态、Redis / MySQL / Kafka 专项数据。

第二层是 MCP 工具层。

包括 prom_query_mcp、es_log_query_mcp、trace_query_mcp、release_query_mcp、code_search_mcp、host_doctor_mcp、redis_doctor_mcp、mysql_doctor_mcp、kafka_doctor_mcp、jvm_doctor_mcp。

第三层是知识层。

包括运维 Skills、业务 Skills、历史故障 Memory、服务依赖图、故障场景库、诊断规则库。

第四层是 Hermes Agent 分析层。

用户输入问题后，Hermes Agent 先拆解故障场景，再调用对应 MCP 工具，聚合指标、日志、链路、代码、历史经验，然后生成证据链，输出根因判断和解决方案。故障结束后，再根据上下文生成复盘 Skill 草稿，经过人工审核后沉淀进知识体系。

第一阶段不要贪大。

第一阶段应该只覆盖核心业务和最高频问题。结合实际生产环境，我认为优先做这几类：

（1）Redis 高 CPU、KEYS、SCAN、timeout。

（2）MySQL 慢 SQL、锁等待、连接数打满。

（3）Kafka consumer lag、broker 异常、连接异常。

（4）JVM OOM、Full GC、线程数异常、服务频繁重启。

（5）网关接口慢、下游服务超时、Nacos 配置异常。

每一类问题都要形成独立场景库。每个场景库里要定义输入数据、查询方式、判断规则、证据链、输出模板、解决建议、是否沉淀为 Skill。

比如 Redis 场景，输入包括 redis_exporter 指标、Redis commandstats、Redis slowlog、服务错误日志、Trace 中 Redis span 耗时、最近发布记录、代码中 Redis 查询方式。判断逻辑包括 Redis CPU 是否接近单核 100%，slowlog 是否增长，commandstats 中 KEYS / SCAN / HGETALL 是否异常，是否有 Redis timeout 日志，受影响服务是否依赖同一 Redis。输出则包括是否 Redis 问题、是否疑似代码误用、哪些服务受影响、哪些接口受影响、建议排查代码位置。

这就是一个最小闭环。

用户反馈问题。

人工输入服务名、接口名、时间范围。

Agent 查询指标、日志、链路、发布记录、代码沙箱、诊断脚本。

Agent 输出问题概述、证据链、根因判断、解决方案。

人工确认。

故障解决。

AI 生成复盘 Skill 草稿。

人工审核后沉淀。

下次类似问题，再次调用这个 Skill，排查速度继续提升。

这就是我想做的“越用越智能”。

但是这里的越用越智能，不是 AI 自己随便学习，而是在人类审核、规则约束、工具边界、权限控制下，把每一次真实故障转化成下一次可复用的经验。

从最终目标来看，这套方案不是为了炫技，也不是为了证明 AI 可以替代运维或开发。它真正想解决的是中小企业现实存在的问题：

人少，系统多。

经验有限，问题复杂。

工具分散，数据割裂。

业务发展快，代码变化快。

故障发生后，排查依赖个人能力。

而 AI-Agent 可以在这里扮演一个新的角色：

它不是生产执行者，而是故障诊断中枢。

它不是替代人，而是放大人的经验。

它不是直接修复问题，而是更快找到问题。

它不是单纯问答机器人，而是连接日志、指标、链路、代码、发布、历史经验的研运一体化分析入口。

所以这个方案的第一阶段，可以定义为：

基于 Hermes Agent、MCP、Skills、Memory、诊断脚本和代码沙箱，构建一个只读、受控、可审计、可沉淀的 AI 故障诊断系统。它通过聚合 Prometheus 指标、ES 日志、ES 链路、Jenkins 发布记录、Git 代码、历史故障经验和专项诊断脚本，实现对核心业务故障和高频中间件问题的快速分析，目标是将故障分析准确率提升到 80% 以上，并逐步形成企业自己的业务故障知识库。

这个方案不追求一步到位。

先不做自动修复。

先不做自动发版。

先不做自动重启。

先不让 AI 拥有生产变更权限。

第一步只做诊断，把诊断这件事做准、做稳、做成闭环。

等诊断稳定了，准确率达标了，Skills 和 Memory 体系成熟了，再考虑是否开放低风险操作，例如自动生成排查命令、自动生成修复建议、自动生成回滚方案、自动生成复盘文档。

真正高风险的生产变更，仍然应该由人确认。

这样，这个方案才不是一个危险的 AI 自动化运维系统，而是一个适合中小企业落地的 AI-Agent 研运一体化诊断方案。