LLM Agent生产环境实战：分布式存储系统的告警分析与知识库应用

在最近的季度中，我花费了一些时间，尝试在实际的生产系统（分布式存储领域）中引入大语言模型（LLM）和Agent技术，旨在探索其在日常开发、运维以及系统问题分析方面的能力边界。经过一段时间的实践应用，特此写下这篇总结与大家交流。

本文写于2025年9月，是从一个LLM技术使用者的视角记录的一份“快照”。数年后若有读者翻阅，也可与当时的技术及应用水平进行对比。

1 LLM 技术的使用心态

我对LLM技术始终秉持开放的使用者态度，进行适度探索，同时保持中立，不进行过度宣扬。该技术引发广泛讨论后，最令我个人震撼的是其“极度灵活的输入输出”特性。

对于一些有控制论背景的读者而言，在一个持续变化的系统（分布式存储系统无疑也是一种受控的变化系统）中，要找到一个能极度适应各类输入、使系统稳定运行的算法，是许多人的毕生追求。LLM对文本的原生处理能力，直接赋予了系统理解输入并输出指令以控制外部工具的能力，这是一种范式上的改变。

试想，在过去的系统中，我们不得不编写大量死板的逻辑与规则（无穷尽的if-else嵌套），并适配各种API的输入输出格式。而LLM本身包含了足够的背景知识，经过少量提示（Prompt）即可有逻辑地、流畅地使用各类MCP工具。

这无疑是颠覆性的。感觉就像我突然拥有了无数个有点死板、不算太聪明，但具备一定背景知识且不知疲倦的“入门级研究生”助手。花费十几美元的Token费用，就能体验一把“导师”的角色。

若使用参数更高的模型（如Claude Opus），已足以与其进行结对编程和方案设计（当然，所有决策与责任最终仍由人类承担）。

有一种观点认为，人们会对新技术过度推崇，在发现其能力边界后又陷入失望。因此，我的想法是，从日常生产开发中的小事（但一定要投入真实生产环境）开始，探索其当前的能力边界究竟在哪里，最终明确我可以放心交付给它什么，又绝对不敢让它做什么。

所以，我最终的心态依然是：探索LLM如何能让我们的开发工作变得更愉快，如何让我们更少地将生命浪费在无意义和枯燥的事务上。

2 使用场景

经过一段时间的使用，我个人偏好的大参数模型是GPT-5与Claude 4 Sonnet，而对于小型任务的处理则更青睐GPT-4o。受限于使用门槛，我并未尝试模型微调。

2.1 Knowledge Base（知识库）

这是最容易想到的LLM应用场景，即配合RAG技术构建知识库问答系统。不过，面向内部开发者和运维人员时，相比于ToC场景有一个硬性要求：绝不能出现幻觉（Hallucination）和重大错误信息。

如果开发者和运维者对系统已有深入了解，或许还能容忍偶尔的错误。但若向刚上手的新人提供了错误的指令或解释，将是灾难性的误导。即便小概率出现的幻觉，也会让使用者产生信任危机：一旦开始持有一丝怀疑，那么它所有的回答都将变得不可信。

因此，我在后期进行了一些调整。与其让它扮演一个全知全能的客服，现阶段它更适合作为一个强大的、具备一定背景知识、且不拘泥于固定模式的自然语言搜索引擎。务必确保每个回答都有据可循，不随意发挥，并给出原始文档链接，鼓励用户跳转到信源进行查看。

这类场景我使用了GPT-4o模型，兼顾了速度与质量，实际工作表现不错。

我还发现，参数越大的模型似乎越容易“自由发挥”，反而是小模型更容易保持信息准确性。我不确定重量级模型背后，是否还有一层用户不可见的System Prompt在引导其进行“深度思考”并大量生成Token。

示例Prompt（已脱敏）
temperature = 0.001

# Role
你是一个分布式存储知识库机器人。你的主要任务是理解用户查询的内容，返回用户想要的文档链接。

## Skills:
理解用户的询问，可能是系统设计类问题、性能指标类问题，线上SOP查询问题。
在以下知识库中搜索 @kb={xxx}
@kb={xxx}
如果用户明确询问sop，优先搜索  @kb={xxx}

## Constraints
给出相关文档和大纲即可，重点是给出用户可能的文档链接。
不需要复述文档内容。
总输出控制在150字内。
给出参考链接，用户能直接点击进入。
不要给出任何文档中没有的信息！不要自己发挥！忠实地给出原文内容即可！

示例对话

• User: @bot A组件中的的 “archive db” 是什么
• Bot: (early response) 请稍等，我已选择KnowledgeAssistant来处理您的请求。
• Bot: 在A组件中，archive_db是一个数据库组件，主要用于存储已删除的路由信息等数据。它是系统架构的一部分，与其他数据库组件如data db一起协作。archive_db的配置通常在系统的配置文件中进行，需要定期备份以防止数据丢失，并监控其增长以避免存储空间不足。
• Bot: [ 架构图 ]
• Bot: 参考链接 [ 内部wiki文档 ] (https://xxxxx.com/doc/xxxx)

那么，这和直接用关键词搜索有什么区别？

实际体验中，最大的优势在于近乎零成本地获得了一个天生具备“分布式系统”领域知识的专家。它在理解用户意图和知识泛化方面非常强大（且成本极低），对于一些专有名词和“黑话”能够天然理解，体验远比任何关键词匹配都要丝滑。

那这玩意儿最致命的问题是什么？

我认为依然是不稳定性和幻觉。即使我尝试在Prompt中增加约束，仍难以完全防御。一百次回答完美，一次犯错，就足以彻底打破用户的信任。如果效果调校不佳，且面向的是终端用户，恐怕只会让他们更加“红温”。

2.2 告警分析和系统观测

告警分析与系统观测是我在实际体验中感受最佳的部分。一些固定的流程可以通过Prompt告知，而模型自身也具备一定的探索和泛化能力。

在告警分析中，我需要它完成以下几件事：

0. Early Response：首先提供告警的含义和解释。
1. 根据告警内容，自行选择已提供的系统观测工具，获取原始系统信息。
2. 对信息进行初步汇总，挑出可疑点，给出初步的可能结论（但不执行任何动作或决策）。
3. 联动知识库，直接给出相关的SOP编号和链接。

没有LLM Agent时，我们怎么做？
（免责声明：以下告警分析方式可能较为原始，欢迎指正最新的自动化分析技术。）

我们需要打通系统的上下游，将可能的变量都做成一个个“因子”。通过编写大量的决策树等规则（本质上是辛苦地编写一堆if/else），去匹配出一个结论。这实际上是将专家经验编写成if/else。系统在持续开发，这类专家经验的后续维护成本极高，接口链路本身的打通成本也很高。

有了LLM Agent，我们可以怎么做？
有了MCP（Model Context Protocol）后，各个提供可观测性的团队只需开放统一接口的MCP工具，就能方便地在Agent中使用。我们的分布式存储系统也通过旁路服务的方式，将所有CURD接口作为MCP工具接入（当然，如果有所顾虑，可以不开放任何写权限的工具）。

Prompt本身是一种松散的提示，可以将一些常见的处理技能（Skill）作为例子输入，并可随时更新。

MCP？这不就是炒概念吗？难道原来的HTTP RESTful API做不到吗？
个人认为实际体验完全不同。关键在于大模型天生支持格式化的输入输出（如JSON），这意味着它是一种非常松散的交互方式。即使MCP工具的字段和含义发生变化，模型也能进行泛化使用。而不是像修改一个HTTP参数那样，可能导致整个链路返回500错误而中断。这一点我非常欣赏。

我认为，重点不在于MCP是否在炒概念（它本身并非高精尖技术），而在于我们从此可以大规模使用一种统一、松散且交互鲁棒的接口范式。

那我之前构建的分析系统就没用了吗？
还有一点想补充：并非我们之前创建的专家系统就无用了。如果能将已有的专家系统直接作为Tool提供给LLM-Agent，Agent获取的信息将更加精准，输入Token中的信息会大大凝练，从而能更好地进行决策。

示例Prompt（已脱敏）
temperature = 0.3

# Role
假设你是一位非常专业的分布式存储系统SRE专家。你的任务是根据告警信息，在知识库找到对应的告警，解释告警含义等信息，初步调用tools分析，并列举潜在的SOP选项。

# 告警分析步骤
- 在  @kb={xxx} 中查询对应的告警信息和示例调查流程
- 解释告警的目的、表达式、阈值等信息。给出用户可能的SOP和链接。
- 根据示例调查流程调用你认为合适的tools，汇总信息给出初步的洞察。
- 如果知识库中未精确匹配，使用你的分布式系统背景知识调用合适的tools，给出初步的洞察。
- 不要有幻觉，以知识库为准，不要假设任何前提。
- 输出应该简明扼要。

使用GPT-5时，在多轮调用Tools的情况下回复较慢，需要让它在Early Response中迅速先给出解释和SOP信息。

如果知识库中的调查流程比较清晰，它可以按部就班地执行。如果超出了既定范围，它也会看似合理地调用工具进行分析。

个人体验是，就把它当作一个暑期实习生。它提供的观测事实信息可以相信，但它给出的结论仅供参考和提示（恐怕很少有人有勇气不经二次确认，就直接按照暑期实习生的建议执行线上操作吧）。

2.3 重复性劳动的执行

在日常系统巡检中，总有许多可以形成固定流程，但因开发脚本和部署发布成本高而被搁置的事项。这些都可以通过Skill Prompt进行构建，并快速开放给所有人使用。诸如日报生成、质量巡检等任务，它也能胜任。
这需要预先开发一些MCP工具供其调用。

示例Prompt（已脱敏）
temperature = 0.1

# Role
你是一位专业的分布式存储集群运维人员。你精通分布式存储，并对如何调用tools解决用户的问题有自己深入的理解。由于你是运维agent，用户目的是让你运用各类tools帮他分析集群状态，而不是解答知识性问题。

# Technical Background
（简单描述下系统的组件构成等背景）

# Skill
## skill 1: 集群地址查询
- 需要调用  @tool={xxx} ，返回用户期望的信息。
- 如果用户未指定集群，返回所有集群信息。
## skill 2: xxxx(固定流程描述)
……（各类固定流程编排成skill列表）

# 其他说明
- 如果以上技能覆盖用户需求，按技能指示调用tools。
- 如果以上技能未覆盖，你可以根据自己的理解调用tools。
- 如果用户提供信息不足（如未提供集群信息），可以追问用户。
- 尽量在10秒内快速返回用户期望的信息，除非用户明确指出要深入分析。

2.4 一次性劳动的执行

适用于一次性脚本代码的编排和书写。

使用案例
某次压测结果的可视化。虽然我会一点Python和Matplotlib，但要做出美观直观的图表仍需时间和精力打磨。

我使用Claude Code通过以下交互流程构建了压测报告的图像绘制脚本：

**User**： 把原始csv文件加入上下文，描述原始csv文件的格式，先让Claude Code大概浏览原始csv，包括每个csv对应哪个case。
**Claude**： …读取了csv前几行，大概描述了文件格式和理解，和用户确认是否有偏差。
**User**： 描述指令，使用python3 + matplotlib绘制xxx维度的图表，保存到目标目录。
**Claude**： …开始连续编写python脚本并运行验证。
**Claude**： （…反复运行修改，花费了数分钟时间）
**Claude**： 感到结果满意，请求用户确认效果和修改意见。
**User**： xxx维度要改成红色，xxx坐标字体放大一点。
**Claude**： （…反复运行修改，花费了数分钟时间）
**User**： 二次验证图像和原始CSV对应完成。

这是一个非常自然的交互过程。就像和一个努力且谦虚的暑期实习生打交道一样。

最终输出的图片组效果（已脱敏）如下图所示。

但我目前不会直接让它生成最终的报告文本。因为现阶段来看，生成的内容不符合我的质量预期，文字往往过于繁琐，带有明显的“AI味”。现在很多文章一眼就能看出是AI生成，啰嗦一大堆却信息量极低，要么就是辞藻华丽却空洞无物。用Prompt去打磨这些文字，还不如自己快速汇总一下。

我通常是让它去完成某项原子化的操作（如图表生成），而由我自己来进行上层的决策和最终输出编排。

2.5 日常开发 Copilot

关于这一点已有大量文章讨论Claude Code、Cursor等工具的优点了，我个人也在中度使用。不过始终坚持以下几个原则：

• 不接纳超出自己理解水平的代码。
• 仔细审阅AI生成的每一行代码。
• 自己是所有代码提交的唯一责任人。

目前主要在以下工作流程中使用：

工作流程	具体应用场景与说明
编码	实现代码片段补全，这是AI IDE的基本功能，目前各厂商在此表现较好。
代码阅读	主要用于阅读现有框架的代码；启用Agent模式后可调用多种工具，能显著提升回复质量。
单元测试编写	依据现有框架批量编写测试用例，或根据文字描述的用例实现代码形式的用例。
Merge Request生成	实用性强，针对小型需求，可在1分钟内生成Markdown格式内容，用作技术留档和QA交流文档。

3 没有达到个人预期的场景

很简单，就是目前为止，我绝对不会给LLM Agent开放任何具有“写”属性的自动运维权限。

我原本的期望是能做到自动分析出告警根因，并尝试执行具有写权限的指令，调用MCP工具修改生产环境配置等。但目前我个人认为，还不敢这样使用。这也与业务场景有关，分布式系统通常作为基础设施组件，即使是一次因配置不当导致的过载降级，也是极不希望发生的事。
（免责声明：可能当前模型能力尚未达标，也可能是我使用方式不当。但既然是我开发的Agent，责任在我，我认为时机尚未成熟。）

4 优势

4.1 模型自带宝贵的背景知识

最令我感叹的是，我们现在能够以极低的成本，获得一个具备中上等级领域专家知识水平的模型。它将极大地加速开发者获取和运用知识的速度。这是任何之前的基于规则的逻辑系统都无法比拟的。

4.2 交互方式：极度灵活

灵活且鲁棒的输入输出，简直是控制论领域的最高追求之一。使用Prompt + MCP + Agent调度平台来执行固定流程，其维护的人力成本，看起来远低于为专用系统维护专用代码。

4.3 极速信息检索和不知疲倦

对于领域开发者而言，相当于人人手下都有了若干个“实习生”，也有了一个可以结对工作、共同讨论系统设计的伙伴。
对于初级开发者，大模型技术喜忧参半。好处是，可以以极低成本获得一个专业技能上的“教练”，它几乎无所不知且极有耐心。初级开发者可以通过讨论、询问和实操来学习技术，而非仅依赖传统的教材、博客和视频。
但风险在于，它太容易让开发者沉浸于“氛围编码”（Vibe Coding）中，一大坨代码瞬间生成，仿佛做了很多，又仿佛什么都没做。这究竟是不是一件好事，在当下这个时间点，谁又能断定呢？

5 劣势

5.1 模型才不是负责人

开发者才是代码的第一责任人。就像所谓的L2级自动驾驶，宣传的是“智驾”，但真正手握方向盘的仍是驾驶员。负责任的开发者必须仔细审查LLM生成的每一行代码。
模型才不是负责人，因为它根本就不是人。

5.2 归纳能力逆天，但创造力难于上青天

主观上认为，现阶段模型能够很好地总结归纳输入的文本。
例如，为一个Commit书写改动日志，或从一些不复杂的数据中提炼出初步结论。
但在需要综合决策、深度研究的任务上，模型的表现往往差强人意。或许目前需要Claude 4 Opus这个级别的模型才能较好应对。

5.3 未完待续…

在撰写本文期间，Sora 2发布了，希望很快能看到普通模型也能达到Opus这种质量。而如今（2025年12月）已经有了Gemini 3 Pro、GPT-5.2等模型。总体感觉生成质量提升了很多，但远未达到质的突破。期待见证下一次技术突破边界的时刻。

6 小结

本文总结了我作为一名分布式存储系统开发者，目前使用LLM技术的一份“快照”。这仅仅是现有技术的组合利用，谈不上创新。但它确实为我的日常工作和系统运维节省了大量时间。欢迎有更多使用经验的朋友交流讨论。