Arthas Agent：当故障排查经验开始被“编译”
Arthas Agent 的出现，并非仅仅因为它对 Arthas 命令的熟悉，更重要的是它将 “排障经验系统化”。Skill 的本质是 “编码经验”，它使个人的 “手艺” 转变为 “可复用、可维护、可进化” 的资产。这种模式具备推广到更多场景的潜力，但前提是组织愿意为 “Skill 体系建设” 投入资源。将个人经验编写成 Skill 是一件值得去做的事情。Arthas Agent 的 Skill
从 Arthas Agent 看 Skill 驱动的 AI 运维
引言
近期阅读了阿里公众号文章《我们做了比你更懂 Java 的 AI - Agent – Arthas Agent》，作为长期使用 Arthas 进行故障排查的人员，这篇文章引发了我诸多思考。
在此先明确一点：需要说明的是，目前我尚未找到 Arthas Agent 的公开体验入口，因此本文并非基于实际使用体验，而是基于官方文章所引发的一些技术思考。所以本文更多是基于公众号描述所产生的启发式思考，并非产品评测。我更关注的是该产品背后 “Skill 驱动” 的模式，探讨其能否推广至更多场景。
目录
- Arthas Agent 做了什么？
- 这个模式的本质：Skill = 编码经验
- 我的困惑：速度 vs 安全的永恒权衡
- 拓展：这个思想能推广到哪些场景？
- 未来：Skill 体系的演进方向（假设性讨论）
- 挑战与思考
- 结语：这不是技术问题，是组织能力问题
一、Arthas Agent 做了什么？
1.1 痛点：Arthas 很强，但门槛也很高
Arthas 作为阿里开源的 Java 诊断工具，功能十分强大，几乎能在不重启应用的情况下实现诸多操作，如查看线程/CPU、反编译类、追踪方法耗时、观察入参返回值以及执行 OGNL 等，堪称 Java 线上故障排查的 “瑞士军刀”。
然而，在实际应用中，存在一些现实问题：
- 使用者需要清楚知晓该使用哪个命令，如
thread、dashboard、trace、watch、tt、vmtool、ognl、jad等。 - 不仅要知道命令参数如何编写，还要懂得如何拼接 OGNL 表达式，并知晓如何设置限量，避免在生产环境中输出过多信息造成刷屏。
- 还需掌握 “排障路径”，即先获取证据，再逐步收敛问题范围，最后进行验证，而不是盲目尝试各种命令。
实际上，真正耗费时间的并非 “敲命令”，而是 “经验成本”：
- 需要将实际问题转化为 “下一条该执行什么命令”。
- 读懂命令输出结果后，又要再次转化为 “下一条命令是什么”。
- 过程中要持续把控风险，例如设置限量、避免宽泛匹配。
- 同时，要在脑海中维护好上下文信息，如关键证据、时间点、线程 ID、类名等。
如此一来，故障排查工作就需要既 “会命令” 又 “理解问题” 的人员，缺少任何一方面都难以完成排查任务。
1.2 Arthas Agent 的核心能力
Arthas Agent 对故障排查方式进行了创新，让用户能够用自然语言表达需求，由 Agent 将意图转化为安全、可控且基于证据的 Arthas 操作。它具备以下核心能力：
Skill - first（技能优先）：
- 内置一套 “排障剧本”，优先匹配最相关的技能，然后依照剧本流程推进。
- 例如：
arthas - cpu - high（用于处理 CPU 飙高问题）、arthas - springcontext - issues - resolve（解决 Spring Context/Bean 相关问题）、arthas - eagleeye - traceid（获取 traceId）。
安全优先（Safety First）：
- 默认仅执行低风险、高信息量的操作。
- 若需要进行更深层次的操作，会先进行最少澄清或限量执行。
- 例如：每轮操作仅推进 1 - 2 个低风险步骤；对 OGNL 表达式强制使用单引号；禁止无锚点全量枚举类。
循证闭环（Evidence - based）：所有结论都必须依据工具返回的真实证据得出，绝不凭空猜测。
多 Agent 协作：
- 将 “长文本/日志/堆栈分析” 任务交给专门的 log_reader 子 Agent。
- 一个 Agent 负责 “运行工具获取证据”，另一个 Agent 负责 “读取证据并撰写结论”。
1.3 一个直观的例子
目标：获取正在运行的 Spring 版本号。
在没有 AI 辅助的情况下：
- 可能需要翻阅配置文件、查看启动参数，或者反编译 Spring 类来查找版本号。
- 还得清楚 Spring 版本号可能存储的位置，比如 ClassPath、Manifest 文件或者某个特定类中。
而有了 Arthas Agent 后：
- 用户只需表述 “获取 Spring 版本号”。
- Arthas Agent 便会自动匹配相应 Skill，执行一系列命令，最终返回结果。整个过程耗时不到 30 秒。
二、这个模式的本质：Skill = 编码经验
Skill 并非新生事物，但此次 Arthas Agent 在 Skill 的运用上做到了以下三点：
2.1 显式化：把"资深同学脑中的排障套路"变成可执行的剧本
例如，当应用启动卡住时，资深工程师脑海中的排查思路可能是：先查看 main 线程堆栈，接着检查 Spring Context，然后反编译关键类。在没有 Skill 之前，这条排查链路在人脑中是隐性的，难以直接复用。而通过 Skill，这些思路被明确地转化为可执行的剧本，实现了复用。
2.2 安全化：把"经验约束"变成"系统约束"
- 规定 OGNL 必须使用单引号，以此避免注入风险。
- 每轮操作仅推进 1 - 2 步，防止在生产环境中刷屏。
- 禁止无锚点全量枚举，避免系统过载。
这些原本依赖资深工程师个人经验的约束条件，如今转变为系统级别的规则，提高了操作的安全性。
2.3 可维护化：Skill 本身也是"代码"
- Skill 文档成为第一手资料，agent 在行动前先读取 Skill 文档。
- 这样做避免了无依据的盲目操作，降低风险。
核心观点：Skill 的本质是 “经验编码”，它将个人的 “手艺” 转化为团队可复用的 “资产”。
三、我的困惑：速度 vs 安全的永恒权衡
文章中未明确提及，但我对以下几个问题深感好奇：
3.1 速度真的够吗？
公众号所举例子中，“查 Spring 版本号” 用时不到 30 秒，这属于简单场景。然而，对于复杂的诊断任务，比如 CPU 高排查，如果每轮仅推进 1 - 2 步，是否会比经验丰富的工程师手动操作更慢呢？
这就引出了一个更深层次的问题：对于经验丰富的工程师而言，手动操作往往更加直接高效；而对于新手来说，虽然 Agent 可以降低学习门槛，但由于提问和迭代能力不足，可能需要多次尝试才能得到可用结果。。若 AI 的处理速度不及人工，那么该工具的实用价值就会大打折扣。因此，我认为它对于复杂且明确的问题更具实用意义。
3.2 谁在维护 Skill？
随着 Skill 的数量不断增加，如何防止 “技能腐化” 成为关键问题：
- 由谁来审核 Skill 的正确性？
- Skill 的版本管理、测试以及回滚机制是怎样的？
- 当业务发生变化时，旧的 Skill 是否仍然适用？
3.3 Skill 的粒度怎么控制？
- 是采用原子命令形式，例如 “获取 Spring 配置端口”？
- 还是以复杂流程的形式，如 “CPU 飙高排查”？
- 不同粒度的 Skill 又该如何进行组合？
我的看法：这些问题相较于 “技术实现” 更为重要，因为它们决定了 “Skill 体系” 是否能够长期稳定地存在。
四、拓展：这个思想能推广到哪些场景？
4.1 数据库排障（MCP 思路）
痛点：在进行慢查询分析、死锁诊断、锁冲突定位等操作时，都高度依赖经验。
可能的 Skill：
- 分析慢查询：使用
explain查看执行计划，进而找出索引问题。 - 诊断死锁：通过
show engine innodb status分析锁等待链。 - 定位热点表：借助
information_schema统计访问频率。
难点：不同数据库，如 MySQL、PG、Oracle，其对应的 Skill 差异较大，且依赖于具体数据库的 MCP（Management Control Protocol）。
4.2 运维自动化
痛点：每个团队中往往存在一些只有特定人员（如张三）才知晓如何操作的命令。
可能的 Skill：
- 容器健康检查：查看资源使用情况，检查日志，分析性能瓶颈。
- 配置中心验证：查询生效值，追溯配置来源，并与预期值进行对比。
- 依赖服务诊断：检查注册中心健康状况，确认网络连通性，查看超时配置。
价值：将个人经验转化为团队资产，便于团队成员共享和复用。
4.3 安全审计
痛点：合规检查需要遵循一长串的 checklist，操作繁琐。
可能的 Skill：
- 权限检查：审查用户角色、资源访问权限，并进行异常审计。
- 配置合规：依据安全策略，对比当前配置，分析差距。
优势：实现标准化、可追溯以及可复用，提高安全审计的效率和准确性。
4.4 一个有趣的观察：主流产品走的是"AIOps"路线
通过调研发现，在数据库排障、运维自动化、安全审计这三个方向上，主流产品（如 Datadog、Dynatrace Davis、阿里云 AIOps、Splunk AI）大多采用 “AIOps” 路线，其流程为：
监控数据 → AI 分析 → 异常告警/根因建议
而 Arthas Agent 则采用了不同的路线：
自然语言 → skill 匹配 → 工具命令序列 → 循证结论
出现这种差异可能有两个原因：
- 技术难度更大：Skill 的沉淀、安全约束的设置以及循证闭环的实现，每一步都颇具挑战。
- 市场验证不足：AIOps 专注于监控领域，已经实现商业化；而 Arthas Agent 所采用的 “Skill 驱动” 方向可能尚处于探索阶段。
也正因如此，Arthas Agent 更值得关注，它或许是 “Skill 驱动” 模式的一次重要实践。
五、未来：Skill 体系的演进方向（假设性讨论）
以下内容并非针对 Arthas Agent，而是对技术发展可能性的探讨。
5.1 自动沉淀
思考从哪些方面能够自动生成 Skill：
- 文档：包括官方文档、内部 wiki、issue 记录等。
- 对话历史：过往的故障排查对话内容。
- 代码：如注释、单元测试等。
技术路径：借助 RAG（Retrieval - Augmented Generation）与 LLM（Large Language Model）自动提取模式，生成 Skill 模板，再经过人工审核后持续优化。
5.2 组合能力
实现小 Skill 组合成大流程，类似函数式编程：
- 例如
cpu_high可以由dashboard+thread_top_n+trace_slow_method组合而成。 spring_port可由get_context+get_property构成。
并且能够根据具体问题动态选择 Skill 组合策略，以满足不同场景的需求。
5.3 反馈闭环
使用数据回流：
- 统计哪些 Skill 最为常用。
- 分析哪些 Skill 的失败率较高。
- 找出哪些 Skill 需要进行优化。
基于这些反馈，实现 Skill 的自我优化，如自动调整参数、收敛排查路径等。
5.4 版本管理
由于 Skill 本质上也是代码，因此：
- 需要采用 git 进行版本管理。
- 引入 code review 机制，确保 Skill 的质量。
- 建立 CI/CD 测试流程，在隔离环境中验证 Skill 的正确性。
通过这些措施，避免出现 “技能腐化” 的情况。
六、挑战与思考
这里原本按照我的写作习惯已经阐述完了心中的疑问，但后来阅读得物的一篇文章后又获得了一些新的思路（后续也会提及那篇文章），在此进行一些自问自答。
6.1 Skill 质量如何保证？
- 谁来写 Skill？：每一位工程师都可以参与编写。
- 谁来 review Skill？：需要既懂业务，又懂技术，还懂安全的人员，如架构师或经验更为丰富的工程师。
- 如何测试 Skill？：可以采用隔离环境、沙盒或者 A/B 测试等方式。
6.2 Skill 维护成本会越来越高吗？
- Skill 数量爆炸：Arthas 已有几十个命令，若将数据库、运维、安全等领域的 Skill 全部加起来，数量将极为庞大。
- Skill 依赖关系：若 A Skill 依赖 B Skill，B 发生更改时，A 是否会受到影响甚至崩溃？
- Skill 过期：业务发生变化后，旧的 Skill 是否还能继续使用？
6.3 人的角色会变化的
- 新手：从单纯 “学习命令” 转变为 “学会提出正确的问题”。
- 资深工程师：从凭借个人经验解决问题的 “手艺人”，转变为设计 Skill 的 “Skill 设计师”。
- 管理者：从依赖个人经验进行管理，转变为对 Skill 资产进行管理。
七、结语：这不是技术问题，是组织能力问题
7.1 我的核心观点
Arthas Agent 的出现，并非仅仅因为它对 Arthas 命令的熟悉，更重要的是它将 “排障经验系统化”。Skill 的本质是 “编码经验”，它使个人的 “手艺” 转变为 “可复用、可维护、可进化” 的资产。
这种模式具备推广到更多场景的潜力，但前提是组织愿意为 “Skill 体系建设” 投入资源。最大的挑战并非在于技术层面，而是如何让团队成员相信：将个人经验编写成 Skill 是一件值得去做的事情。
7.2 最后两个问题，留给读者、从业者
- Arthas Agent 的 Skill 是如何维护的？是否存在一套版本管理机制？
- 如何解决 “速度 vs 安全” 的权衡问题？是否有 “自适应” 的策略？
小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用
更多推荐
11
0- 0
已为社区贡献4条内容
所有评论(0)