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

关注

原创最新推荐文章于 2026-09-05 13:52:56 发布 224 阅读 AI 写同款· GEO 优化 ›

【技术解析】华为智算中心：昇腾AI算力与无损网络如何驱动大模型训练本文深入解析了华为智算中心如何通过昇腾AI算力与超融合以太无损网络的协同，驱动千亿参数大模型的高效训练。昇腾NPU提供专用计算引擎，而基于RoCE的无损网络则通过PFC、ECN等技术确保万卡集群间的高带宽、零丢包通信，实现算力利用率最大化，解决大规模AI训练的核心瓶颈。阅读详情

聊《我用运维经验做了次 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 分钟后自动放行。

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

---

优快云资料领取方式

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

这段代码是 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 阶段完全可以不写，但生产环境必须有。我当时就是漏了这一步，导致排障时找不到决策依据。

---