运维转大模型：我用旧方法做 Agent，第一天上线就翻车

原创于 2026-08-30 22:08:33 发布 · 28 阅读

本内容遵循CC 4.0 BY-SA版权协议

聊《我用运维经验做了次 AI 项目，最先失效的是旧方法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

半年前我从 SRE 岗位转到大模型应用方向，接了一个自动告警处置的 Agent 项目。Demo 跑通得很顺，但接入生产环境第三天就崩了——不是模型不行，是权限设计、日志记录和审批流程三个运维老本行被我忽视了。这篇文章复盘那次翻车，以及后续怎么把 Agent 真正跑起来。如果你也带着自动化脚本的思维进 AI 方向，这篇应该能帮你省点时间。

运维能力的迁移：哪些真能用，哪些会误导人
真实案例：一个日志分析 Agent 的上线全过程
排查过程：Demo 能跑，生产为什么崩
代码解释：工具调用链的关键实现
失败原因：权限、日志、审批各踩了一次
适用边界：什么时候不该直接照搬
总结

---

运维能力的迁移：哪些真能用，哪些会误导人

文章插图 1

做运维的人转大模型方向，天然有几个优势：排障思路、对系统稳定性的敏感度、脚本能力。这三个在我后来的项目里确实帮了大忙。

但问题也出在这里。运维的习惯是"脚本能跑就行"，大模型工程的习惯是"要可观测、要可控、要留痕"。我第一次做 Agent 时，脑子里还停留在"搭个流程让它自动执行"的阶段，结果上线第一天就被运维同事拦住了——你这套东西谁负责？出了问题找谁？有没有审批记录？

我当时的表情你们可以想象。

真正有价值的迁移是排障逻辑：给定一个现象，怎么假设、怎么验证、怎么排除。写 Agent 的工作流本质上也是这个思路，只不过对象从"服务器故障"变成了"模型行为异常"。

---

真实案例：一个日志分析 Agent 的上线全过程

文章插图 2

项目背景是这样的：团队每天收到三四百条告警，其中大部分是重复或低优先级的。我们想做一个 Agent，能自动分析告警日志，判断根因，并决定是否执行预定义的处置动作。

输入：Kafka 里的告警消息，包含服务名、错误类型、时间戳、堆栈信息。
输出：处置建议 + 可选的自动执行动作（重启、回滚、扩容）。

整个流程分三阶段：

第一阶段（Demo）：用 LangChain 搭了一个简单的链，模型读取告警日志后直接输出 JSON 格式的处置建议。测试数据是离线日志，跑得挺顺。

第二阶段（联调）：接入真实 Kafka 数据流，加了工具调用——Agent 可以调用 check_service_status、get_metrics 两个函数来验证判断。这里第一次出问题：模型有时候会调用不存在的工具，因为 Demo 阶段的训练数据里没有覆盖这种情况。

第三阶段（上线）：正式接生产环境，加了权限校验和审批节点。这才发现之前完全没考虑的事情：谁来批准自动重启？日志存到哪里？处置结果怎么反馈给人？

---

排查过程：Demo 能跑，生产为什么崩

上线第三天出问题，现象是：Agent 连续触发了两次错误的自动回滚，导致两个核心服务被错误降级。

我的排查链路如下：

第一步：看日志
发现回滚请求的参数里，服务版本号和预期不一致。但 Agent 的输出日志里没有记录它读到了什么版本信息，无法还原决策路径。

第二步：查权限
原来回滚接口没有细粒度的权限控制，Agent 拿到 token 后就能调用任何服务的回滚接口。这是设计上最严重的问题——我当时只想着"让 Agent 能执行动作"，没想过"哪些动作它能做、哪些不能"。

第三步：验审批
回滚操作虽然走了审批节点，但审批节点是一个硬编码的超时逻辑：超过 10 分钟自动通过。第三天正好有人请假，审批卡在没人处理的队列里，10 分钟后自动放行。

第四步：定位根因
三个问题叠加：日志不全 → 无法快速定位；权限过大 → 错误动作能执行；审批虚设 → 无人复核。任何一个单独存在都不会造成那么严重的后果。

---

CSDN资料领取方式

代码解释：工具调用链的关键实现

这段代码是 Agent 的核心工具调用逻辑，我拆解一下关键点：

class AlertAgent:
    def __init__(self, model, tools, permission_layer):
        self.model = model
        self.tools = {t.name: t for t in tools}
        self.perm = permission_layer  # 权限校验层

    async def handle_alert(self, alert: AlertEvent) -> ActionDecision:
        # 第一步：权限预校验
        allowed_tools = self.perm.check(alert.service, alert.action_type)
        if not allowed_tools:
            return ActionDecision(reject=True, reason="无权限")

        # 第二步：构建上下文，注入历史日志
        context = await self._build_context(alert, allowed_tools)

        # 第三步：调用模型，解析工具调用
        response = await self.model.generate(
            messages=context,
            tools=[self.tools[t] for t in allowed_tools],
            tool_choice="auto"
        )

        # 第四步：执行工具并收集结果
        for tool_call in response.tool_calls:
            tool_fn = self.tools[tool_call.name]
            result = await tool_fn(**tool_call.arguments)
            context.append({"role": "tool", "content": result})

        # 第五步：生成最终决策，写入审计日志
        final = await self.model.generate(messages=context)
        await self._audit_log(alert, final)
        return parse_decision(final)

    async def _audit_log(self, alert, decision):
        # 关键：每次决策必须落盘，包含输入、工具调用、输出
        log_entry = {
            "alert_id": alert.id,
            "input": alert.raw,
            "tool_calls": decision.tool_calls,
            "output": decision.action,
            "timestamp": datetime.utcnow().isoformat()
        }
        await self.audit_queue.push(log_entry)

输入：一个 AlertEvent 对象，包含告警 ID、服务名、错误类型、原始消息。
核心逻辑：权限预校验 → 构建上下文 → 模型调用工具 → 收集结果 → 生成决策 → 审计日志。
输出：ActionDecision 对象，包含是否执行、执行什么、拒绝原因。
异常处理：工具调用失败不会中断流程，而是作为 error 消息追加到上下文，让模型有机会重新判断。但如果连续三次工具调用失败，会强制返回 reject 并告警人工介入。

这段代码里 _audit_log 是最容易被忽略的部分。Demo 阶段完全可以不写，但生产环境必须有。我当时就是漏了这一步，导致排障时找不到决策依据。

---