聊《我用运维经验做了次 AI 项目最先失效的是旧方法》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。上周复盘团队里两个做 AIOps Agent 的项目发现一个有意思的现象那些 Prompt 写得花里胡哨、能完美生成代码的 Demo上线第一天就崩了反而是两个 Prompt 平平无奇但在权限控制和日志追踪上死磕到底的项目稳稳扛住了第一次大促流量。我们这帮搞运维出身的人总有一种惯性思维——觉得自动化就是“脚本执行”。以前写 Shell 或 Python只要逻辑对跑起来就行。现在搞 LLM Agent大家第一反应是优化 System Prompt让模型更聪明。但在生产环境“聪明”不如“靠谱”。对于小团队或者资源有限的场景过度设计 Agent 的推理能力是陷阱把边界条件权限、审批、回滚和可观测性日志、审计做扎实才是从 Demo 走向生产的唯一路径。目录运维能力的迁移从“确定性”到“概率性”的控制日志分析不仅是搜索更是上下文构建自动处置 Agent敢让 AI 动手的前提是“后悔药”安全与审批小团队的“权限墙”总结回归工程本质运维能力的迁移从“确定性”到“概率性”的控制很多人觉得运维转大模型有天然优势因为我们都懂基础设施、懂网络、懂数据库。但这个优势是有代价的。运维的核心是确定性输入 A必须得到 B如果出错必须有明确的 Error Code。而大模型的本质是概率性同样的输入每次生成的内容可能微调甚至出现幻觉。我的第一个教训是不要试图用 Prompt 去解决所有逻辑问题。在一次尝试用 Agent 自动清理过期日志的任务中我最初让模型直接判断哪些文件该删。结果模型为了“节省空间”误删了一些正在被监控采集器读取的软链接。虽然没丢数据但告警响了半小时。后来我改了思路Agent 不做最终决策只做建议。1. Agent 扫描日志目录输出候选列表。2. 一个确定的 Python 脚本负责权限校验是否在生产环境是否被占用。3. 人类或审批流确认。4. 执行删除。这种“人机协同”或“LLM 确定性代码”的模式才是运维工程师最该掌握的。我们不是要取代过去的自动化脚本而是要把 LLM 作为一个强大的“意图理解器”把它的输出限制在我们的安全护栏内。日志分析不仅是搜索更是上下文构建在传统的 SRE 工作中我们看日志靠grep、awk或者 ELK/Kibana 的可视化。现在有了 LLM我们可以让模型做“初筛”和“聚合”。但这里有个巨大的坑Token 成本和上下文窗口。不要直接把几 GB 的原始日志扔给模型。你需要建立一套预处理机制。实战案例告警归因中的日志清洗假设我们要排查一个 CPU 飙升的告警。传统做法是导出最近 1 小时的所有日志人工看。现在我们的 Agent 流程是这样的1. 粗过滤用轻量级脚本提取关键字段时间、级别、模块压缩日志体积。2. 向量化检索将压缩后的日志片段存入向量库通过语义相似度召回相关片段。3. LLM 聚合将召回的片段发给 LLM让它找出共性模式。# 简化版日志处理管道 def prepare_logs_for_llm(raw_log_lines): 不要直接传 raw log 这里需要结合业务标签进行结构化 structured_data [] for line in raw_log_lines: # 假设我们有简单的正则提取 match parse_log_line(line) if match: structured_data.append({ timestamp: match.time, level: match.level, service: match.service, # 只保留关键异常堆栈忽略 DEBUG 信息 trace: match.exception_trace[:500] if match.exception else None }) return json.dumps(structured_data, ensure_asciiFalse) # 发送给 LLM 的内容经过严格裁剪 llm_context prepare_logs_for_llm(last_hour_logs) response llm_client.chat( system_prompt你是一个资深后端专家请分析以下日志中的异常模式..., messages[{role: user, content: llm_context}] )注意代码中的exception_trace[:500]。在实际生产中很多报错堆栈长达数千行全部传入不仅浪费 Token还会稀释模型对核心错误信息的注意力。做减法是运维工程师的本能也是 Agent 有效性的关键。自动处置 Agent敢让 AI 动手的前提是“后悔药”说到自动处置很多同行问我“能不能让 Agent 直接重启服务”我的回答是可以但必须加“熔断”和“审计”。在大模型应用中最危险的不是它做错了而是它不知道自己做错了并且没有留下痕迹。我们团队内部有一个硬性规定任何涉及写操作Write/Delete/Restart的 Agent 动作必须在数据库中记录一条“预执行审计日志”状态为 PENDING只有在人类确认或规则引擎放行后才能变更为 EXECUTED。这不仅是为了安全更是为了后续的可观测性。当 Agent 搞砸了我们需要知道1. 它当时看到了什么上下文2. 它做出的决策依据是什么Prompt 版本历史对话3. 它执行的命令参数是什么如果没有这些日志排查一次 AI 故障的成本可能比故障本身还高。安全与审批小团队的“权限墙”大厂有完善的 IAM 系统但小团队怎么办别指望 LLM 能懂复杂的企业级 RBAC 模型。最简单有效的办法是将权限校验逻辑外置。不要让 Agent 自己去判断“我能不能删这个库”。而是提供一个 API 接口Agent 调用这个接口时接口内部硬编码了权限校验逻辑。app.post(/execute-operation) async def execute_operation(op_type: str, params: dict): # 1. 验证用户身份JWT user verify_jwt(request.headers) # 2. 硬编码权限检查 - 这是 Agent 无法绕过的“墙” if op_type DELETE_DB and user.role ! DBA_ADMIN: raise PermissionDenied(No permission to delete database) # 3. 如果通过才允许 Agent 继续下一步 # 这里其实应该是一个审批流或者双人复核 await log_audit(user.id, op_type, params) # 4. 通知 Agent 可以继续执行 return {status: approved}这种设计看似笨拙但它确保了安全性不依赖于 LLM 的指令遵循能力。无论 Prompt 怎么变权限墙始终在那里。这对于快速迭代的 AI 项目来说是最稳妥的底线。总结回归工程本质从运维转大模型我们最大的误区是把 LLM 当成“魔法”。但实际上它只是一个更擅长处理模糊文本的组件。真正的竞争力不在于你能写出多复杂的 Prompt而在于你能否构建一个鲁棒的系统工程1. 日志先行在写 Agent 之前先设计好怎么记录它的每一次思考和行动。2. 权限隔离永远不要信任模型的自我约束用代码强制限制其能力边界。3. 小步快跑先从辅助分析做起再逐步放开自动处置的权限。当你不再纠结于“如何让模型更聪明”而是专注于“如何让系统更安全、更可观测”时你就真正完成了从运维到 AIOps 工程师的蜕变。Demo 跑得通只是热身能解释失败、能兜住风险才是生产环境的生存之道。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。