这篇不先堆名词。我们把《做过运维的人学大模型哪些经验可以直接迁移》拆成几级台阶看完至少知道下一步该学什么、该练什么。摘要 去年帮某金融客户做 AIOps Agent从日志分析到自动处置Demo 跑得好好的一上线就崩了。不是模型能力不够是权限没对齐、日志没留痕。运维人转大模型别只盯着 Prompt先过“权限与日志”这关。---目录运维能力其实没白扔日志分析从“看日志”到“让模型看日志”告警归因模型不是“猜”是“推理”自动处置 Agent能执行更要敢执行安全与审批别把“能力”当“信任”总结运维人转大模型不是换技术是换思维运维能力其实没白扔做运维那会儿天天跟日志、告警、自动化脚本打交道。那时候觉得不就是写个脚本自动重启服务、发个钉钉通知吗简单。现在回头看那些“简单”的事恰恰是 Agent 最需要的底座。大模型 Agent 本质上是“懂上下文 能执行”的系统。你之前用 Shell 脚本做自动化现在用 LLM 做决策只是决策主体变了底层逻辑没变你要知道系统状态日志、你要知道能做什么权限、你要知道结果如何可观测。我见过太多人上来就搞 Prompt 调优结果 Agent 能写诗、能写代码但一执行命令就报错——因为没权限或者执行了但没人知道它做了什么——因为没日志。这些不是模型的问题是工程问题。而运维人最擅长的就是工程。---日志分析从“看日志”到“让模型看日志”以前我们看日志是 grep、tail、awk靠经验定位问题。现在让模型看日志得先解决三个问题1. 日志结构化日志不是文本是事件。你得把日志转成 JSON 或结构化字段比如levelERROR,serviceorder-api,timestamp2026-07-30T10:00:00Z。不然模型会把“连接超时”和“内存溢出”当成同一种错误。2. 上下文对齐模型需要知道“什么时候发生了什么”。你不能只丢一段日志给模型得给时间窗口、服务依赖、历史告警。比如“过去10分钟order-api 有3次500关联的数据库连接池耗尽是否要自动扩容”3. 日志留存与审计Agent 执行了操作必须记日志。不是记“执行成功”而是记“谁在什么时间、基于什么条件、调用了哪个接口、返回了什么”。这是审计的基础也是故障回溯的关键。# 示例结构化日志 Agent 操作记录 import json from datetime import datetime log_entry { timestamp: datetime.utcnow().isoformat(), agent_id: aiops-agent-01, action: restart_service, service: order-api, condition: error_count 3 within 5m, result: success, details: { pid: 12345, restart_time: 2026-07-30T10:05:22Z, response: Service restarted, health check passed } } with open(/var/log/aioops/agent_actions.log, a) as f: f.write(json.dumps(log_entry) \n)这段代码不是炫技是底线。没有这个日志Agent 就是个黑盒谁敢让它动生产环境---告警归因模型不是“猜”是“推理”以前告警归因靠经验比如“内存高 CPU高 服务过载”现在让模型做得给它“推理框架”。你不能只丢一个告警给模型说“为什么出错”你得给告警内容如memory_usage 90%历史趋势过去1小时是否持续上升关联服务是否下游数据库慢最近变更是否有新部署然后让模型输出一个推理链比如 “内存高 CPU高 最近部署了新版本 → 可能是新代码有内存泄漏 → 建议回滚 检查 GC 日志”这个推理链要能解释、能追溯、能验证。否则模型就是个“黑盒推理”运维不敢信。我曾见过一个团队用模型做告警归因模型说“是数据库锁死”结果查日志发现是网络抖动。问题出在模型没拿到网络指标而不是模型能力不行。所以数据源的完整性比模型大小更重要。---自动处置 Agent能执行更要敢执行自动处置是 Agent 的“最后一公里”也是最危险的一步。以前我们写脚本加个if confirm yes就执行。现在模型做决策得加三层控制1. 权限隔离Agent 不能直接调用reboot或delete。要像运维权限体系一样分角色、分环境、分操作。比如“只读模式”、“测试环境可执行”、“生产环境需审批”。2. 审批兜底高风险操作如重启生产库、删除数据必须人工确认。可以加一个“审批队列”Agent 把操作推给人工确认后执行。3. 执行反馈闭环操作执行后必须回写日志、更新告警状态、通知相关人员。不然操作了没人知道系统状态不一致后续问题更难排查。# 示例带权限与审批的自动处置函数 def execute_action(agent_id, action, params, environmentprod): # 1. 权限检查 if not check_permission(agent_id, action, environment): log_error(f权限不足: {agent_id} 无法执行 {action}) return {status: denied, reason: permission_denied} # 2. 高风险操作需审批 if is_high_risk(action) and environment prod: if not await_approval(agent_id, action, params): log_info(f审批未通过: {action} by {agent_id}) return {status: pending_approval} # 3. 执行 try: result run_command(action, params) log_action(agent_id, action, params, result) return {status: success, result: result} except Exception as e: log_error(f执行失败: {e}) return {status: error, message: str(e)}这个函数不是完美方案但代表了思路执行前检查、执行中审批、执行后记录。没有这三步Agent 上线就是定时炸弹。---安全与审批别把“能力”当“信任”很多人觉得模型能写代码、能调 API那它就能做运维。错。模型是“推理引擎”不是“执行主体”。它的输出要经过“安全审查”才能执行。我们以前做运维有“变更管理”、“发布审批”、“回滚预案”。Agent 也得有。比如所有 Agent 操作必须记录在案支持审计。高风险操作必须走审批流程支持人工干预。每次执行后要验证系统状态是否恢复支持自动回滚。我见过一个团队Agent 自动扩容了数据库实例结果导致连接池耗尽业务挂了。因为没有“执行前评估”和“执行后验证”。模型“认为”能扩容但没考虑实际负载。所以Agent 不是要替代人而是要让人更专注决策把执行交给受控流程。---总结运维人转大模型不是换技术是换思维别总想着“模型多强”、“Prompt 多妙”。真正决定 Agent 能不能上线的不是模型能力而是日志是否结构化、可追溯权限是否隔离、可审计操作是否可审批、可回滚执行是否有反馈、可验证这些都是运维人最熟悉的领域。你不用学新语言、不用调新模型把以前的工程思维用到 Agent 上就是最大的优势。大模型不是要取代运维而是要让运维从“救火”变成“防火”。而防火的钥匙不在模型里在你写过的每一行脚本、看过的每一条日志、做过每一次审批里。所以别急着写 Prompt。先把你的日志系统、权限体系、审批流程重新整理一遍。让 Agent 在你的“老地基”上跑比从零造轮子靠谱得多。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。