运维转大模型：脚本经验能直接迁移？权限日志才是 Agent 上线的门槛

学习实战派

198人浏览 · 2026-08-08 12:56:09

学习实战派 · 2026-08-08 12:56:09 发布

聊《做过运维的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

做过运维的都知道，写脚本和建平台是两码事。

以前我们搞自动化，逻辑是线性的：if 告警A then 执行B。出了问题，看日志，找根因，手动或脚本恢复。整个过程是确定性的，权限也是明确的——用户有 sudo 权限，或者应用有特定的 API Token。

现在转做 AIOps Agent，很多人以为就是把这套逻辑换成 LLM 调用。我一开始也是这么想的，结果第一个 Demo 跑通后，真正让我头疼的不是模型选哪个，而是：谁授权了这个 Agent 执行命令？执行了什么？有没有审计？

这也是为什么最近行业风向变了——从比拼 Demo 的多功能，转向比拼权限控制、日志可观测和审批流程。对于运维背景的同学，这其实是你的主场。

运维能力的迁移：从“确定性脚本”到“概率性 Agent”

文章插图 1

运维转大模型，最大的优势不是会写 Python，而是对“系统稳定性”和“边界条件”的直觉。

在传统的 Ansible 或 Shell 脚本里，你很清楚每一步的输出是什么，失败会返回什么错误码。但 Agent 不同，它是基于概率的。你给 LLM 一个工具定义，它可能会：
1. 正确调用工具并解析结果。
2. 幻觉出一个不存在的工具。
3. 调用了正确的工具，但参数格式错误。
4. 成功执行，但返回的结果超出了你的预期范围。

我的观点：不要试图让 Agent 变得“聪明”，首先要让它变得“可控”。运维工程师的思维模型应该是：把 Agent 当作一个不可信的外部服务，通过严格的权限和日志来约束它。

日志分析：从“关键词匹配”到“语义归因”

文章插图 2

以前分析日志，我们靠 grep 关键字，或者 ELK 的可视化面板。现在，我们可以让 Agent 去读日志。

但这里有个坑：不要直接把整个日志文件丢给 LLM。生产环境的日志量是巨大的，既贵又慢，还容易超出上下文窗口。

实战建议：
1. 预过滤：先用传统规则（如 Promtail + Loki 的标签查询）缩小范围，只把最近 5 分钟的 ERROR 级别日志喂给模型。
2. 结构化输出：要求 Agent 返回 JSON 格式的分析结果，包括：异常类型、可能原因、建议操作。
3. 可观测性优先：在 Agent 内部埋点，记录“它读了什么日志”、“它得出了什么结论”。这比模型本身更重要，因为你需要复盘它的推理过程。


# 简单的日志分析 Agent 片段示例
def analyze_logs(log_entries: List[str], context: str) -> dict:
    # 1. 预过滤：只取 ERROR/WARN
    filtered = [l for l in log_entries if "ERROR" in l or "WARN" in l]

    # 2. 构造 Prompt，强调基于证据
    prompt = f"""
    请分析以下系统日志，找出根本原因。
    上下文：{context}
    日志片段：
    {filtered[-10:]}  # 只取最近10条

    请以 JSON 格式返回：
    {{
      "root_cause": "简要描述",
      "evidence": ["引用的日志行"],
      "confidence": "高/中/低"
    }}
    """
    return llm_call(prompt)

CSDN资料领取方式

告警归因：让 Agent 做“初级 SRE”

告警风暴是运维的噩梦。以前我们用 PagerDuty 或自研平台做告警聚合，现在可以让 Agent 参与归因。

关键取舍：

不要让 Agent 直接决定“是否抑制告警”。
要让 Agent 生成“归因报告”，由人或规则引擎做最终决策。

我见过一个案例，团队让 Agent 自动抑制重复告警，结果模型误判，把真正的 P0 故障当成了噪音，导致故障持续时间延长了 20 分钟。教训是：Agent 适合做“助手”，不适合做“守门员”，除非你有极强的兜底机制。

自动处置 Agent：最危险也最有价值的环节

这是运维转大模型最核心的战场。以前我们用脚本自动重启服务、扩容、回滚配置。现在，我们可以让 Agent 根据告警内容，自动执行处置流程。

但这里有一个巨大的鸿沟：Demo 能跑通，生产不敢用。

为什么？因为权限。

在 Demo 里，你可能给了 Agent sudo 权限，或者一个拥有所有资源写权限的 K8s ServiceAccount。在生产环境，你必须遵循最小权限原则。

我的实践：
1. 工具白名单：Agent 只能调用预定义的工具（如 restart_service, scale_pod），不能执行任意命令。
2. 权限隔离：每个工具对应一个独立的、权限最小的凭证。例如，重启服务的凭证只能重启特定命名空间下的 Pod。
3. 审批流程：对于高危操作（如删除资源、修改核心配置），Agent 必须触发人工审批。


# 工具定义示例：只允许重启，不允许删除
TOOLS = [
    {
        "name": "restart_service",
        "description": "重启指定服务",
        "parameters": {
            "service_name": {"type": "string", "enum": ["api-gateway", "user-service", "payment-service"]}
        },
        "permission": "revoke_on_failure"  # 失败后撤销权限
    },
    # 没有 delete_service 工具，防止模型幻觉执行删除
]

安全与审批：Agent 上线的生死线

这也是我最近踩坑最多的地方。

问题 1：Prompt 注入
如果 Agent 的输入来自用户（如运维工单），恶意用户可能通过 Prompt 注入，让 Agent 执行非预期操作。
对策：对用户输入进行严格过滤，使用系统提示词（System Prompt）明确边界，并记录所有输入输出。

问题 2：执行审计
Agent 执行了什么命令？谁授权的？结果如何？
对策：建立统一的审计日志平台，记录 Agent 的每一次工具调用、参数、返回值。这不仅是安全要求，也是故障复盘的依据。

问题 3：回滚机制
如果 Agent 执行错误，如何快速回滚？
对策：所有自动处置操作都必须有对应的回滚脚本或 API。Agent 执行后，必须触发一个“验证”步骤，确认系统状态正常。

总结

运维转大模型，不是从零开始，而是经验迁移。

你已有的运维知识——对系统稳定性的理解、对权限的敏感、对日志的可观测性要求——正是当前大模型应用从 Demo 走向生产所最缺的。

给想转型的同事几点建议：
1. 不要只学 LangChain/LlamaIndex，要深入理解权限模型和审计日志。
2. 从小场景入手，先做一个“只读”的日志分析 Agent，再逐步扩展到“受限执行”的处置 Agent。
3. 把安全当第一优先级，Demo 跑通只是开始，生产环境能稳定运行、可审计、可回滚，才是真正的能力。

大模型不会取代运维，但会用大模型且懂安全规范的运维，会取代只会写脚本的运维。

这趟路，我还在走，坑也还在踩。但方向是清晰的：从自动化脚本，走向可控的 AIOps Agent。