当前位置：首页 > news >正文

运维转大模型：会写脚本不等于能造Agent，权限和日志才是硬通货

news 2026/8/4 16:52:56

这篇我按“先跑起来、再讲取舍”的方式写《别急着换赛道：运维经验在 AI 项目里到底值多少？》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

摘要：很多人以为运维转大模型就是换个工具写Prompt，结果做出来的Agent要么在Demo里跑得好好的，一上线就因为权限越界、日志缺失、审批失控翻车。这篇文章复盘我从自动化脚本到AIOps Agent的完整转型过程，重点讲清楚：你的运维经验到底值多少，取决于你能不能守住生产环境的权限和日志。

---

运维能力的迁移：你的脚本经验到底值多少
日志分析：从grep到语义检索，不是换个命令
告警归因：规则引擎和Agent的本质差异
自动处置Agent：工具调用只是冰山一角
安全与审批：Demo和生产的分水岭
总结：运维转大模型的真实护城河

---

运维能力的迁移

我先说一个反直觉的事实：会写Shell脚本、会配Ansible，在大模型项目里可能只值30%。

我带过一个团队，招了三个资深运维转做大模型Agent。第一个月大家信心满满，觉得不就是让AI调API吗？结果第二个月，三个项目全在上线前卡住了。问题不出在模型能力，而出在三个运维最熟悉的领域——权限、日志、审批。

运维的核心能力是什么？是对生产环境的敬畏。你知道什么能碰、什么不能碰、出了事怎么追溯。这个能力在大模型项目里不仅没贬值，反而更值钱。

但很多人卡在第一关：不知道怎么把运维思维翻译成Agent开发语言。

比如运维习惯先写脚本再跑，Agent开发要先设计权限边界再写工具调用。运维习惯告警来了先恢复再排查，Agent习惯先确认指令合法性再执行。这种思维转换，比学LangChain或Prompt Engineering难多了。

我的建议是：先把你的运维经验拆成三类——可自动化部分、需人工确认部分、绝对不能自动化的部分。这三类直接对应Agent的工具设计、审批流设计、安全红线。

---

日志分析

传统运维看日志靠grep、awk、elasticsearch查询。Agent时代，日志分析变成了语义检索+上下文关联。

我踩过的第一个坑：直接让大模型读原始日志，结果模型被噪声淹没，输出一堆正确的废话。后来加了三层过滤：

1. 先用向量检索找到相关日志片段
2. 再用规则过滤掉已知无害模式
3. 最后才把精简后的上下文交给模型分析

# 日志预处理管道示例 def preprocess_logs(raw_logs, service_name, time_window="1h"): # 第一步：向量检索召回相关日志 relevant_chunks = vector_search( query=f"{service_name} error anomaly", top_k=50, time_window=time_window ) # 第二步：规则过滤，去掉已知噪声 filtered = [] for chunk in relevant_chunks: if is_known_noise(chunk, service_name): continue if is_severity_high(chunk, threshold=3): filtered.append(chunk) # 第三步：压缩上下文，保留关键信息 compressed = compress_context(filtered, max_tokens=2000) return compressed

这个管道不是银弹，但解决了我80%的"模型读日志跑偏"问题。关键经验：不要相信模型能从原始日志里自动提取重点，你要先帮它过滤。

另一个容易被忽视的点：日志的可观测性。很多团队做了Agent日志系统，但日志本身缺少trace_id、缺少调用链、缺少决策依据。结果Agent出了问题，你连它为什么这么决策都查不到。

运维转大模型，第一件事应该是：把你的可观测性体系从"记录发生了什么"升级到"记录为什么这么做"。

---

告警归因

告警归因是运维最核心的价值之一。传统做法是规则引擎——CPU超阈值、磁盘超阈值、连接数异常。这些规则稳定但僵化，面对复杂故障经常误报或漏报。

Agent介入后的变化不是"替代规则"，而是"规则处理不了的交给Agent"。

我见过一个很典型的场景：某个服务延迟飙升，规则引擎报了20条告警，涵盖CPU、内存、网络、DB连接池。传统运维需要逐个排查，Agent的做法是：

1. 先聚合这20条告警，识别出这是同一个根因的连锁反应
2. 用向量检索找到历史相似案例
3. 结合当前变更事件（最近30分钟有发布）
4. 输出归因结论：可能是某次发布引入的性能回归

# 告警归因Agent核心逻辑 async def correlate_alerts(alerts: List[Alert], recent_changes: List[Change]): # 1. 告警聚类，找出关联组 alert_groups = cluster_alerts(alerts) # 2. 检索历史相似案例 similar_cases = await vector_search( query=build_query(alert_groups), top_k=5, filter={"time_range": "30d"} ) # 3. 结合变更事件 change_context = find_related_changes(alert_groups, recent_changes) # 4. 生成归因报告 report = await llm.generate( context={ "alert_groups": alert_groups, "similar_cases": similar_cases, "change_context": change_context }, prompt_template="alert_correlation_v2" ) return report

这里有个关键判断：Agent归因不是替代人工，而是把人工从"翻告警"变成"审结论"。好的Agent归因系统应该让你5分钟内知道"该不该信它"，而不是让你花30分钟验证它说的对不对。

我的经验是：归因结果必须附带置信度和证据链。没有这两样东西的Agent归因，等于在替你背锅——出了问题你甩不掉。

---

自动处置Agent

自动处置是运维转大模型最诱人的方向，也是最容易翻车的方向。

我见过一个案例：团队做了个数据库故障自动恢复Agent，Demo里跑得很顺——主库挂了，Agent自动切换从库、更新配置、通知相关人员。上线第一天，Agent把生产库的从库当成了主库切换对象，导致数据不一致。

问题出在哪？不是模型不够聪明，是工具调用的权限边界没锁死。

Agent的工具调用设计，我建议分成三层：

Layer 1: 只读操作（查询、日志、状态） └── 无需审批，Agent全权决定 Layer 2: 低风险写操作（重启服务、清理缓存、调整配置） └── 需要人工审批，审批通过后才执行 Layer 3: 高风险操作（删库、改核心配置、跨环境操作） └── 完全禁止Agent执行，只能建议+人工操作

# 工具调用权限分级示例 TOOL_PERMISSION = { "query_metrics": {"level": 1, "requires_approval": False}, "get_logs": {"level": 1, "requires_approval": False}, "restart_service": {"level": 2, "requires_approval": True, "approver_role": "senior_sre"}, "clear_cache": {"level": 2, "requires_approval": True, "approver_role": "senior_sre"}, "execute_sql": {"level": 3, "requires_approval": True, "approver_role": "dba", "audit": True}, "modify_config": {"level": 3, "requires_approval": True, "approver_role": "tech_lead", "audit": True}, }

这个分级不是技术难点，是组织协作难点。运维转大模型，最大的挑战不是学新技术，而是推动团队接受"AI可以干活，但必须在你的规则里干活"。

另一个实战经验：给Agent加"后悔药"。任何自动处置操作，都要支持回滚。我见过太多团队只设计了"执行"路径，没设计"撤销"路径，结果Agent跑偏了只能人工救火。

---

安全与审批

这是Demo和生产环境之间最宽的鸿沟。

我接触过的团队，90%在Demo阶段忽略了两件事：操作审计和权限最小化。

Demo里，Agent用你的账号跑，你当然不担心权限。生产里，Agent的权限应该比你个人的权限小得多。这是原则，不是建议。

我见过一个很典型的翻车场景：Agent被授权查询所有服务的日志，结果它把某条敏感错误日志里的用户信息当成了"上下文"输出给模型，模型把这段内容带进了生成结果。数据安全团队发现的时候，已经过了4小时。

教训：Agent的输入输出都要过安全扫描，不要相信"这只是内部日志"。

审批流的设计也有讲究。我见过两种极端：

极端A：所有操作都要审批，结果审批变成形式主义，Agent效率不如脚本
极端B：Agent全自动，结果出事找不到责任人

我的建议是：按风险分级审批，高风险双人确认，低风险自动通过但强制审计。

# 审批流设计示例 async def execute_with_approval(tool_call: ToolCall, user_context: UserContext): permission = TOOL_PERMISSION.get(tool_call.tool_name) if permission["level"] == 1: # 只读操作，直接执行 return await execute_tool(tool_call) elif permission["level"] == 2: # 低风险写操作，单人审批 approver = await find_approver(user_context, permission["approver_role"]) approval = await request_approval(approver, tool_call) if approval.approved: return await execute_tool(tool_call) else: raise ApprovalDenied(f"Rejected by {approver.user_id}") elif permission["level"] == 3: # 高风险操作，双人确认+强制审计 approvers = await find_approvers(user_context, permission["approver_role"], count=2) approvals = await request_dual_approval(approvers, tool_call) if all(a.approved for a in approvals): # 记录完整审计日志 audit_log = { "tool": tool_call.tool_name, "params": tool_call.params, "requester": user_context.user_id, "approvers": [a.user_id for a in approvers], "timestamp": datetime.utcnow(), "action": "executed" } await log_audit(audit_log) return await execute_tool(tool_call) else: raise ApprovalDenied("Dual approval required")

这个审批流不是银弹，但它解决了两个核心问题：责任可追溯和权限可收敛。

---