运维转大模型：脚本写得好，Agent 为什么还是上线就崩？

聊《别急着换赛道：运维经验在 AI 项目里到底值多少？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

做运维这些年，我写过不少自动化工具：从 Shell 脚本到 Ansible，再到自研的巡检平台，基本就是把"发现问题-定位问题-处理问题"这条链路固化下来。转做大模型项目后，我以为这些经验可以直接复用，结果第一次上线就把团队坑了。

不是模型不行，也不是 Agent 架构有问题，而是权限和日志没兜住。

最近行业里讨论大模型应用从 Demo 转向权限、日志和可观测，我觉得这是运维工程师转型的真正机会点。很多人以为转大模型就是学 Prompt 工程、调 LangChain，但真正卡住项目上线的，往往是这些"枯燥"的工程化能力。

目录

• 运维能力的迁移：别只盯着 Prompt 写
• 日志分析：从"能看"到"能查"
• 告警归因：让 Agent 学会"自己排查"
• 自动处置 Agent：从"能跑"到"敢跑"
• 安全与审批：运维的看家本领
• 总结：运维转型的真正价值

运维能力的迁移：别只盯着 Prompt 写

我见过太多运维转大模型的同学，上来就狂学 LLM API 调用、学 Agent 框架。但说实话，这些反而不是你的优势。

你的核心优势是什么？是对系统稳定性的敏感度。

做运维的人，天生就知道"什么情况下系统会崩"。这个直觉在大模型项目里同样值钱。比如：

• 你知道一个 Agent 调用外部工具时，如果超时没兜底，整个工作流会卡死
• 你知道日志打在哪里、怎么结构化，才能快速定位问题
• 你知道权限管控的底线在哪，哪些操作必须人工确认

这些经验，比你会写多少个 Prompt 模板都重要。

我当时的做法是，先把运维能力映射到大模型项目的关键环节：

| 运维能力 | 大模型项目对应 |
|---------|-------------|
| 日志采集与分析 | Agent 执行链路追踪 |
| 告警规则 | Agent 异常检测与熔断 |
| 自动处置脚本 | Tool Calling 与 Action 编排 |
| 权限管控 | Agent 操作边界与审批流 |
| 系统可观测 | 链路追踪与性能监控 |

看到没？你本来就会的东西，换个名字还是你的。

日志分析：从"能看"到"能查"

运维的日志分析，大多是结构化查询。但大模型项目的日志，往往是半结构化甚至非结构化的。

举个例子，我有一个 Agent 项目，每次调用都会输出 JSON 日志。表面上看很规范，但排查问题时才发现：

{
  "timestamp": "2026-08-01T10:23:45Z",
  "agent_id": "ops-agent-01",
  "step": "diagnose",
  "input": "服务器CPU使用率过高",
  "output": "建议重启服务",
  "tool_calls": [
    {"name": "get_cpu_usage", "args": {"host": "web-01"}, "result": "92%"},
    {"name": "check_logs", "args": {"host": "web-01", "time": "1h"}, "result": "..."}
  ],
  "latency_ms": 3200,
  "error": null
}

看起来没问题对吧？但实际排查时我发现：

1. output 字段是模型生成的，没有记录原始推理过程
2. tool_calls 的结果被截断了，关键错误信息丢失
3. 没有记录 token 消耗，无法评估成本

我后来加了一套完整的执行日志：

class AgentLogger:
    def __init__(self, agent_id: str):
        self.agent_id = agent_id
        self.trace_id = str(uuid.uuid4())
        self.start_time = time.time()
        self.steps = []

    def log_step(self, step_name: str, input_data: dict,
                 output_data: dict = None, error: str = None,
                 tools_used: list = None):
        self.steps.append({
            "step": step_name,
            "input": self._sanitize(input_data),
            "output": self._sanitize(output_data) if output_data else None,
            "error": error,
            "tools": tools_used or [],
            "latency_ms": round((time.time() - self.start_time) * 1000, 2)
        })

    def finish(self):
        return {
            "trace_id": self.trace_id,
            "agent_id": self.agent_id,
            "total_steps": len(self.steps),
            "total_latency_ms": round((time.time() - self.start_time) * 1000, 2),
            "steps": self.steps
        }

这段代码的核心不是技术多复杂，而是记录粒度。运维日志讲究"能复现"，大模型 Agent 日志也一样。你要能回溯每一步的输入输出，才能定位是模型问题、工具问题还是数据问题。

告警归因：让 Agent 学会"自己排查"

运维最值钱的能力之一是告警归因。一个成熟的 SRE 看到告警，能在几分钟内定位到根因。

这个能力迁移到 Agent 项目，就是让 Agent 具备自我诊断能力。

我做过一个实验：给 Agent 配置一套"自愈工作流"。当检测到异常时，Agent 不是直接报错，而是按以下步骤排查：

async def self_diagnose(agent_state: dict) -> str:
    """Agent 自我诊断工作流"""

    # 第一步：检查工具调用是否成功
    failed_tools = [t for t in agent_state['tool_history']
                    if t.get('status') == 'error']
    if failed_tools:
        return f"工具调用失败: {[t['name'] for t in failed_tools]}"

    # 第二步：检查模型输出是否合理
    last_output = agent_state['steps'][-1]['output']
    if not last_output or len(last_output) < 10:
        return "模型输出异常，可能触发安全过滤"

    # 第三步：检查外部依赖状态
    health = await check_dependencies(agent_state['deps'])
    if not health['all_ok']:
        return f"依赖异常: {health['failed_deps']}"

    return "无明显异常，建议人工复核"

这段代码的逻辑很简单，但背后是运维思维：分层排查，逐层收敛。

很多人做 Agent 时，遇到问题就说是"模型不准"。但实际排查下来，可能是工具调用失败、可能是权限不足、可能是输出被过滤。你的运维经验，能帮你在这些问题出现时快速定位。

自动处置 Agent：从"能跑"到"敢跑"

运维转大模型，最容易犯的错误是：把 Demo 当产品。

我有一个同事，做了个自动重启 Agent，Demo 跑得很顺。结果上线后，因为权限配置问题，Agent 在测试环境重启了生产数据库。

所以，自动处置 Agent 的设计，必须考虑三个问题：

1. 操作边界在哪里？

不是所有操作都能自动化。我总结了一个原则：

• 只读操作：可以全自动化
• 低风险写操作：需要审批流
• 高风险写操作：必须人工确认

class SafetyGate:
    """操作安全门控"""

    RISK_LEVELS = {
        'read': 'low',
        'write': 'medium',
        'delete': 'high',
        'restart': 'critical'
    }

    def check(self, action: str, context: dict) -> dict:
        risk = self.RISK_LEVELS.get(action, 'medium')

        if risk == 'low':
            return {"allowed": True, "reason": "只读操作"}

        if risk == 'medium':
            # 需要审批流
            return {
                "allowed": False,
                "need_approval": True,
                "reason": "写操作需要审批"
            }

        # high 和 critical 必须人工确认
        return {
            "allowed": False,
            "need_human_confirm": True,
            "reason": f"{risk}风险操作，必须人工确认"
        }

2. 执行过程可追溯

每个操作都要有完整的审计日志，包括：谁触发的、什么时间、什么参数、执行结果。

3. 失败有兜底

自动处置失败时，要有回滚机制或人工接管入口。

安全与审批：运维的看家本领

这部分可能是运维转型的最大优势。

大模型 Agent 的权限问题，和传统运维的权限管控逻辑是一样的：最小权限、分级审批、操作审计。

我见过太多 Agent 项目，因为权限配置不当，导致：

• Agent 能访问不该访问的数据
• Agent 能执行不该执行的操作
• 操作记录丢失，出问题后无法追责

我的建议是，把运维的权限管控经验直接迁移过来：

1. 建立 Agent 操作白名单：明确哪些操作可以自动化，哪些必须人工确认
2. 实施分级审批：根据操作风险等级，设置不同的审批流程
3. 完整审计日志：每个操作都要记录，支持事后追溯
4. 熔断机制：检测到异常行为时，自动暂停 Agent 执行

总结：运维转型的真正价值

写了这么多，我想说一个观点：运维转大模型，不是从零开始，而是能力迁移。

你的优势不在于学新技术快，而在于：

• 对系统稳定性的敏感度
• 对权限和安全的重视
• 对日志和可观测的理解
• 对自动化边界的把握

这些能力，在大模型项目从 Demo 走向生产的过程中，比会写 Prompt 值钱得多。

最后给想转型的运维同学几个建议：

1. 先补基础：了解 LLM 基本原理、Agent 架构，不用深入，知道边界在哪
2. 发挥优势：把权限、日志、可观测做成你的标签
3. 从小处切入：先做日志追踪、权限管控这类" boring but critical"的工作
4. 积累案例：把运维经验转化为大模型项目的实战案例

技术会迭代，但工程化思维不会过时。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。