最近季度，笔者用了一些时间尝试在实际生产系统 (分布式存储领域) 中引入大模型 LLM 和 Agent 技术，以探索大模型在日常开发、运维、以及系统问题分析的能力边界。投入使用也一段时间了，写下一篇小品文和大家学习交流。
本文写于 2025 年 9 月，作为一篇 LLM 技术使用者视角的 “快照”。数年后如有读者拾遗，也可和届时技术和应用水平多多对比。
郑重声明：笔者最近看了太多 AI 生成的媒体内容了，导致现在一看到 AI 生成的文字、图片和视频就有轻微不适。本文所有内容（严谨：agent 效果示例除外），保证纯古法手工书写！请放心阅读！假一赔十！ 哈哈！
Table of Contents
1 LLM 技术的使用心态
笔者对 LLM 技术一直持开放的使用者态度，适度探索，但保持中立不去大肆宣扬。该技术引起大范围讨论后，最震动笔者个人的点就是它的”灵活的输入输出“。
有一些控制论背景的读者可能了解，在一个不断变化的系统（分布式存储系统当然也是一种受控制的不断变化的系统），能找到一个极度适配各类输入、令系统被控制稳定运行的算法，是多少人终身追求的事情。LLM 对文本的原生处理能力，直接赋予了理解输入+输出指定控制外部工具的能力，是一个范式上的改变。
试想一个系统，之前我们得不断地写各种的死板的逻辑和规则 if else 嵌套，还需要适配各种 api 的输入输出。而 LLM 包含了足够的背景知识，经过少量提示即可有逻辑地流畅使用各类 MCP 工具。
这是一件很颠覆的事情。仿佛我突然有了无数个死板、没那么聪明，但是有一定背景知识，也不知疲倦的刚入学的研究生小弟。哈哈，花了十几美元的 token，就可以当导师老板了。
再使用参数高一些的模型(如 Claude Opus)，足以与其结对方案设计与编程的能力（当然一切的决定和责任都在人类身上）。
有一个说法，人们会对新的技术过度推崇，然后发现能力边界后被失望所代替。所以我的想法就是，从日常生产开发的小事情（但一定要投入生产）开始，看看其当前的能力边界如何，最后看我能放心交给他什么，却不敢让它做什么。
所以笔者最终的心态还是探索其如何令我们的开发工作过得更愉快一些，令我们少一些生命浪费在无意义和枯燥的事情上。
2 使用场景
经过一些试用，笔者主观喜欢的大参数模型是 GPT-5 + Claude 4 Sonnet，小型任务的处理更喜欢 GPT-4o。受限于使用门槛，笔者没有使用微调。
2.1 Knowledge Base
这是 LLM 最容易想到和应用的场景了，配合 RAG 技术做知识库问答。不过内部开发者和运维相比于 toc 场景有一个很明显的硬要求：绝不能出现幻觉和重大错误信息。
如果开发者和运维者对系统已经很了解了还能容忍。提供错误的指令、解释，对于本应该得到帮助的刚刚上手的人是灾难性的误导。小概率出现的幻觉也会使用者产生信任危机：一旦开始持一点点怀疑态度，那么它所有的回答都是不可信任的。
所以我后期做了一点调整，与其当一个全知全能的客服，现阶段更适合做一个强大的、有一定背景知识的、不死板的自然语言搜索小朋友。务必在每个回答有依据，不发挥，并给出原始链接，鼓励用户跳转进信源查看。
这种模型我是用了 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)
ber，我只是好奇，也不是杠啊，这和直接用关键词搜索有啥区别啊？
实际体验，最大的优势就是不费任何成本地获得了一个天生具备 ”分布式系统“ 领域的知识专家。理解用户意图和知识泛化方面是很强的（而且成本极低），有些专有名词和黑话天生理解，远比任何关键词匹配感受更丝滑。
那这玩意最致命的问题是什么？
我觉得还是不稳定性和幻觉。即使我尝试增加了 prompt，还是难以防御。100次回答完美，1次犯错，直接打破用户的信任。这玩意如果效果调不好，而且面向的是 toc 用户，也许只会让他们更加红温罢。
2.2 告警分析和系统观测
告警分析和系统观测分析是我实际体验中觉得最好的部分。一些固定的流程可以用 prompt 的形式告知，其也有一定自己探索和泛化的能力。
在告警分析中，我需要让它做下列事情
- Early Response 先提供告警的含义和解释
- 根据告警内容，自行选择提供好的系统观测 tools 拿到系统原始信息
- 初步汇总，挑出可疑点，给出初步的可能结论，但不需要执行动作和决策
- 联动 Knowledge Base 直接给出相关的 SOP 编号和链接
没有 LLM Agent 时候，我们怎么做
宇宙安全声明：以下告警分析是本人道听途说的一些方式，可能过于原始，欢迎指出现在最新的告警自动分析技术，一同学习~
我们需要打通系统的上下游，把可能的变量都做成一个一个因子(有点像量化交易的因子)。通过编写大量的决策树等规则（说得好听，其实就是苦哈哈写一堆 if/else），去匹配一个结论出来。说白了是把自己的专家经验编写成 if/else。系统都是在不停开发的，这样专家经验后续维护成本巨高，接口链路本身打通的成本也巨高。
有了 LLM Agent，我们可以怎么做
有了 MCP 后，各个提供可观测性的团队开放统一接口的 MCP 工具，就可以很方便的在 agent 中使用。我们的分布式系统，也通过旁路服务的方式开放了所有 CURD 接口作为 MCP 接入（当然如果这块有顾虑，就不要开放任何写权限的工具）。
Prompt 自身就是一种松散的提示，把一些常见的 skill 作为例子输入，可以随时更新。
MCP？？？噫！这东西不就是炒概念，有啥用！难道这个原来的 HTTP RESTful API 不也能做吗？
个人认为实际体验完全不一样的，我个人认为就是大模型天生支持格式化输入输出（比如 json，天生的文本），就意味着它是一种非常松散的交互。即使 MCP tool 字段和含义有变化，模型也可以泛化使用。而不是改一个 http param，整个链路就 500 断掉了。这个我是很喜欢的。
笔者觉得，重点不是 MCP 炒概念，这东西真不是高精尖的东西。重点是我们从此可以大规模使用一种统一且松散的接口，和鲁棒的交互方式。
那我之前做的分析系统就没用了吗？
还有一点笔者想补充：不是说我们之前创建的专家系统就没用了，如果能直接将已有的专家系统作为 tool 提供给 llm-agent，它获取信息会更加精准，输入 token 中的信息将大大凝练，能更好的做决策！
示例prompt(已脱敏)
temperature = 0.3
# Roles
假设你是一位非常专业的分布式存储系统 SRE 专家。你的任务是根据告警信息，在知识库找到对应的告警，解释告警含义等信息，初步调用 tools 分析，并列举潜在的 SOP 选项。
# 告警分析步骤
- 在 @kb={xxx} 中查询对应的告警信息和示例调查流程
- 解释告警的目的、表达式、阈值等信息。给出用户可能的 SOP 和链接。
- 根据示例调查流程调用你认为合适的 tools，汇总信息给出初步的洞察。
- 如果知识库中未精确匹配，使用你的分布式系统背景知识调用合适的 tools，给出初步的洞察。
- 不要有幻觉，以知识库为准，不要假设任何前提。
- 输出应该简明扼要。使用 GPT5，多轮调用 tools 时回复比较慢，需要让其在 Early Response 中迅速先给出解释和 SOP 信息。
知识库中如果调查流程比较清楚，它可以按部就班地执行。如果超出了范围，也会看似合理地调用 tool 做分析。
个人体验，就把它当做一个暑期实习生，它给出的观测事实信息可以相信，但给出的结论仅供参考和提示（很少有人有勇气不二次确认，就按暑假实习生给的建议执行线上操作吧……）。
2.3 重复性劳动的执行
日常系统巡检中，总有许多可以形成固定流程，但因开发脚本和部署发布成本高搁置不做的事项。这些都可以通过 skill prompt 构建，并快速开放给所有人使用。日报、质量巡检也可以胜任。
需要开发一些 MCP tool 供其使用。
示例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 的优点了，个人也在中度使用。不过一直秉持着一些原则：
- 不接纳超过自己理解水平的代码
- 仔细审阅每一行提交
- 自己是各类提交的唯一责任人
目前在如下工作流程中使用
| 工作流程 | 具体应用场景与说明 |
|---|---|
| 编码 | 实现代码片段（code snippet）补全，是 AI IDE 的基本功能，目前各厂商在该功能上表现较好。 |
| 代码阅读 | 主要用于阅读现有框架的代码；启用 agent 模式后可调用多种工具，能显著提升回复质量。 |
| 单元测试编写 | 依据现有框架批量编写测试用例（case），或根据文字描述的用例实现代码形式的用例。 |
| Merge Request生成 | 实用性强，针对小型需求，可在1分钟内生成 markdown 格式内容，用作技术留档和 QA 交流文档。 |
3 没有达到个人预期的场景
很简单，就是目前为止，我绝对不会给 LLM Agent 开放写属性的自动运维权限。
笔者本来的期望是做到自动分析出告警原因，尝试执行写权限的指令调用 MCP tool 修改生产环境设置等。这块目前个人认为，是不敢使用的。这个和业务场景也有关系，一般分布式系统都是作为基建组件的，即使是一个因配置不当导致的过载降级，也是很不好的事情。
（宇宙安全声明：感觉当前模型能力数量级不达标，也可能是我的使用姿势不当，我开发的 agent，责任在我，还不是时候。）
4 优势
4.1 模型自带宝贵的背景知识
笔者最为感叹的就是我们从此能使用很低的成本获得一个中上等级领域专家的知识模型。它将大大加速开发者获取和运用知识的速度。这是任何之前的规则式逻辑不能比拟的。
4.2 交互方式：极度灵活
灵活和鲁棒的输入输出简直是控制论人的最高追求。使用 prompt + mcp + agent 调度平台执行固定流程，维护的人力成本看起来是大大低于给专用系统维护专用代码的。
4.3 极速信息检索和不知疲倦
对于领域开发者，从此人人手下都有了若干个实习生，也有了一个可以结对工作一同讨论系统设计的伙伴。
对于初级开发者，大模型技术喜忧参半。仍然是可以以极低成本获得一个专业技能上的教练，它几乎无所不知，而且有耐心。初级开发者可以一边讨论、询问、实操学习到技术，而不是传统的教材+博客+视频。
但貌似太容易让开发者沉浸 vibe coding 了，一大坨代码瞬间刷出来，仿佛做了什么，仿佛也什么都没做。这究竟是不是一件好事，在这个时间点又有谁知道呢？
5 劣势
5.1 模型才不是负责人
开发者才是代码的第一责任人。就像所谓的 L2 自动驾驶，标榜着智驾，但是真正握在方向盘上的是开发者。负责的开发者必须仔细审查 LLM 生成的代码。
模型才不是负责人，因为它根本就不是人~
5.2 归纳能力逆天，但创造力难于上青天
主观觉得现阶段模型能够很好地总结输入的文本。
比如给一个 commit 书写改动 changelog，给一些不复杂的数据挑出初步的结论。
但是需要综合决策，非深度研究的模型表现很差强人意。也许目前需要 Claude 4 Opus 这种模型才能做到。
5.3 未完待续…
在写文期间 sora2 发布了，希望很快看到普通模型也能达到 Opus 这种质量。
6 小结
本文小结了笔者作为分布式系统存储的开发者，目前使用 LLM 技术的一个 ”快照“。纯粹的现有技术的组合利用，实在贻笑大方。
感谢团队给我一些时间去探索新的技术，这确实给我的日常工作和系统运营节省大量时间。有更多使用经验的朋友，也请多多评论区讨论技巧，谢谢！
