如果你正准备往大模型方向转《我用运维经验做了次 AI 项目最先失效的是旧方法》这类问题别只看热度。更重要的是判断自己该补哪块能力以及怎么证明你真的会。摘要上周联调完一个 AIOps Agent运维同学信心满满地演示告警归因模型一口气调了三个工具、查了四张表最后返回结果完美。第二天接入生产环境直接炸了——权限不够、日志对不上、关键 API 返回 403。团队盯着报错懵了半小时才发现 Demo 里用的测试账号和生产账号根本不是一回事。这件事让我意识到从运维转大模型真正卡脖子的不是调 API而是权限、日志、可观测这三件事。很多同行以为学会了 LangChain 或者能搭出一个能跑的 Agent 就算入门实际上那只是热身。真正决定项目能不能上线、面试能不能拿 offer 的是你能不能把 Agent 放进真实环境里跑稳。---目录运维能力的迁移日志分析告警归因自动处置 Agent安全与审批总结运维能力的迁移我做运维十年最早写 Shell 脚本处理告警后来用 Ansible 做批量部署再后来转向 SRE搞可观测性和容量规划。转大模型的时候我其实没从头学 Python 或者算法而是把运维经验平移过去。迁移的核心是思维转变以前你写脚本逻辑是确定性的输入 A 必然输出 B现在你写 Agent逻辑是概率性的模型会自己规划路径你只能约束边界。比如以前告警来了你写个脚本查 CPU、查磁盘、查进程逻辑写在代码里现在告警来了你让 Agent 自己决定查什么、怎么查、查到异常后怎么办。你的工作从写逻辑变成定义边界。这个转变很多人没转过弯。我见过不少转大模型的运维还在用写脚本的方式写 Prompt试图让模型一步一步执行结果模型经常跑偏。实际上好的 Agent 设计应该是定义目标、提供工具、设置约束、事后复盘。---日志分析Demo 阶段日志分析很简单——模型调一个日志查询接口返回几条记录你看着没问题就过了。生产环境里日志量是 Demo 的几百倍模型要么查不到、要么查错、要么超时。我们当时的问题是Agent 调日志接口时没有加时间范围约束直接查最近一小时结果日志服务返回了空结果模型误判为系统正常告警被错误归因为网络抖动。排查路径是这样的先看 Agent 的工具调用链发现日志接口确实被调用了再看接口返回是空数组再查模型推理发现 Prompt 里没有强制要求模型验证返回结果是否合理最后加了一个后置校验逻辑要求模型在得出结论前必须确认日志有实际内容。async def analyze_logs(alert: Alert) - AnalysisResult: # 第一步模型决定查询参数 query_params await agent.decide_query_params(alert) # 第二步执行查询带超时和结果校验 logs await query_logs( servicequery_params.service, time_rangequery_params.time_range, limit100, timeout5.0 ) # 第三步后置校验空结果必须触发二次查询或人工介入 if not logs or len(logs) 0: return AnalysisResult( statusinsufficient_data, actionescalate_to_human, reason日志为空无法归因 ) # 第四步模型基于实际日志推理 conclusion await agent.reason_with_logs(logs, alert) return conclusion这段代码的关键不是模型推理部分而是第三步的后置校验。运维经验在这里很有用——你知道什么情况下日志会为空知道什么时候应该放弃自动分析转人工。这个判断逻辑模型学不会必须你写进去。---告警归因告警归因是 Agent 最有价值的场景之一也是最容易翻车的场景。我们当时遇到的问题是模型把数据库连接池耗尽归因为应用代码bug因为日志里确实有连接超时的报错。但实际上根因是数据库侧的慢查询导致的。这个错误的根因是Agent 只看了应用层日志没看数据库层指标。模型在工具调用时没有主动去查数据库侧的数据因为 Prompt 里没有明确要求它跨层归因。解决方式是给 Agent 加了一个归因检查清单ATTRIBUTION_CHECKLIST [ {layer: application, check: 应用日志是否有异常}, {layer: database, check: 数据库慢查询和连接池状态}, {layer: network, check: 网络延迟和丢包率}, {layer: infrastructure, check: CPU、内存、磁盘 IO}, ] async def attribution_workflow(alert: Alert) - AttributionResult: findings [] for check in ATTRIBUTION_CHECKLIST: result await check_layer(alert, check[layer]) findings.append(result) # 如果当前层已经找到明确根因可以提前终止 if result.confidence 0.9: break return AttributionResult(findingsfindings)这里体现的运维思维是归因不是让模型自由发挥而是用检查清单约束它的搜索路径。清单由你来设计基于你对系统架构的理解。模型负责执行和推理你负责定义边界。---自动处置 Agent自动处置是 Agent 最危险也最有价值的部分。处置对了MTTR 大幅下降处置错了可能引发更大事故。我们当时设计了一个自动重启服务的 Agent逻辑是告警触发→检查服务状态→确认异常→执行重启→验证恢复。Demo 阶段跑得很顺生产环境却出了问题模型在确认异常这一步判断失误把一个正常的健康检查超时当成了服务故障触发了不必要的重启导致业务中断。问题的根源在于模型对异常的判断阈值太宽松。Demo 阶段的测试数据都是明确异常模型没见过边界情况。解决方案是加了一个双人确认机制对于高风险操作重启、扩容、删数据Agent 必须经过人工审批才能执行HIGH_RISK_ACTIONS {restart_service, scale_down, delete_data} async def execute_action(action: Action, context: Context) - ExecutionResult: if action.type in HIGH_RISK_ACTIONS: # 高风险操作必须人工审批 approval await request_human_approval(action, context) if not approval.approved: return ExecutionResult(statusrejected, reasonapproval.reason) # 执行前再次校验上下文 pre_check await validate_context(context) if not pre_check.passed: return ExecutionResult(statusblocked, reasonpre_check.reason) result await action.execute() return result这里的运维经验 again 发挥作用你知道哪些操作是高风险的知道审批流程应该怎么设计。模型不懂这些你必须定义清楚。---安全与审批这是 Demo 到生产最容易被忽视的部分。我们当时犯的一个错误是Agent 的 API 调用权限和运维同学的账号权限是同一套导致模型可以调用一些不该调用的接口。比如一个只读性质的日志分析 Agent实际却有权执行重启操作。修复方式是做了权限隔离Agent 运行在一个独立的 service account 下权限最小化。只读操作用一个账号写操作用另一个账号写操作必须经过审批流程。# 权限分级配置 PERMISSION_LEVELS { readonly: [query_logs, get_metrics, describe_service], write: [restart_service, scale_up], admin: [delete_data, modify_config], } async def check_permission(agent_action: Action, user_context: UserContext) - bool: required_level PERMISSION_LEVELS.get(agent_action.type, readonly) return user_context.permission_level required_level这个设计背后是运维的老习惯最小权限原则。模型再聪明也不能给它超出需要的权限。---总结从运维转大模型很多人以为难点在学新技术实际上难点在思维转变。你以前写脚本逻辑是你写的结果是你控制的现在你写 Agent逻辑是模型自己规划的结果是你约束的。你的价值从写代码变成定义边界。权限、日志、可观测这三件事是 Demo 到生产最大的门槛。模型调得再溜这三件事没搞定项目照样上线就崩。面试的时候企业真正想听的不是你搭了一个什么炫酷的 Agent而是你遇到了什么问题、怎么排查的、最后怎么解决的。权限日志这些无聊的事反而是区分 Demo 工程师和生产工程师的分水岭。运维经验没有白费只是换了个形式发挥作用。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。