运维转大模型：团队协作中的使用边界-深圳市維司達科技有限公司

这篇我按“先跑起来、再讲取舍”的方式写《运维转大模型：团队协作中的使用边界》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

本文概述文章目标、核心观点和实践价值。

上周我们团队把那个跑了三年的 Python 批量部署脚本重构成了基于 LangChain 的 AIOps Agent。说实话，刚上线那周，我差点把服务器权限回收了。不是因为 Agent 太笨，而是因为它“太聪明”——它真的理解了我们的运维意图，甚至优化了执行路径，但它越过了几个我们原本定死的“红线”。

这次复盘，我不讲怎么调参，也不讲 Prompt 怎么写得更有文采。我想聊聊一个更现实的问题：**当运维工程师转向大模型应用开发时，如何界定团队协作中“自动化”与“人工干预”的边界？** 尤其是对于 SRE 和 DevOps 同学来说，从确定性极强的 Shell/Ansible 脚本，转向概率性极强的大模型 Agent，最大的挑战不是技术栈切换，而是信任机制的重构。

运维能力的迁移：从确定性到概率性的阵痛

很多运维兄弟转行做 AI 自动化平台时，第一反应是：“我要把所有 CronJob 都扔进 LLM 里让它自己干。”

这是误区。传统的运维脚本是确定性的：`if A then B`。只要环境一致，执行结果永远一致。而大模型 Agent 是概率性的：它基于上下文理解意图，然后生成动作。这意味着同样的报错日志，Agent 第一次可能推荐重启服务，第二次可能推荐扩容，第三次可能直接告诉你“不需要操作，这是预期行为”。

**我的取舍建议：**

1. **保留确定性环节**：涉及底层资源变更（如修改内核参数、调整防火墙规则）的操作，严禁完全由 LLM 自主决定。这部分逻辑必须保留在代码层的硬编码或策略引擎中。
2. **释放认知负荷环节**：将日志聚合、根因初步定位、文档检索交给 Agent。运维最累的不是敲命令，而是从几百页的监控图表和散落的日志里找线索。
3. **引入“影子模式”**：在灰度期，让 Agent 只输出建议（Plan），不执行动作（Act）。由人工确认后再通过 API 触发执行。这一步虽然增加了流程长度，但建立了团队对 AI 的信任基石。

日志分析：别让幻觉毁了你的 SLA

在日志分析场景中，最容易踩坑的就是“过度解读”。

举个例子，某次大促后，CPU 飙升 80%。传统告警只会告诉你“CPU 高”，不会告诉你原因。如果我们让 Agent 直接读日志并给出结论，它可能会说：“检测到大量 GC 日志，建议增加堆内存。”

听起来很合理，对吧？但如果实际情况是代码里有死循环导致的 CPU 占用，Agent 可能会因为看到了 GC 日志就产生误导。这就是大模型的幻觉风险——它倾向于给出一个“看起来正确”的解释，而不是“绝对正确”的真相。

**实战建议：**

不要直接让 Agent 输出诊断结论，而是让它输出**证据链**。

def analyze_log_with_evidence(log_text: str, context: dict) -> dict: """ 返回结构化证据而非直接结论 """ prompt = f""" 请分析以下日志片段，不要直接给出修复建议。 请按照以下格式返回： 1. 关键异常指标（时间戳、错误码、耗时） 2. 可能的关联事件（依赖服务的调用失败等） 3. 引用日志原文的具体行号 日志内容： {log_text} """ # 调用 LLM response = llm.chat(prompt) return parse_structured_response(response)

在后续的处理流程中，我们再根据这些证据，结合规则引擎（Rule Engine）来最终判定。这样，Agent 变成了你的“高级分析师”，而不是“决策者”。

告警归因：从“是什么”到“为什么”

告警风暴是运维的梦魇。传统的告警规则维护成本极高，阈值设置稍有偏差就会漏报或误报。

在引入大模型进行告警归因时，我发现最大的价值在于**语义关联**。之前的告警系统是孤立的事件流，现在我们可以把拓扑关系、变更历史、甚至是最近发布的代码 Commit 信息作为 Context 喂给 Agent。

**踩坑现场：**

有一次，Agent 成功地将“数据库慢查询”和“前端接口超时”关联了起来，并且指出了原因是昨天下午的一个热点 Key 变更。这非常棒。但是，它也错误地将“网络抖动”归因于“应用层 Bug”，导致开发人员浪费了半天时间在代码审查上，最后发现只是机房光纤松动。

**判断标准：**

**强关联场景**：代码变更引发的性能下降、配置错误导致的启动失败。这类场景上下文明确，Agent 表现优异。
**弱关联场景**：网络波动、第三方服务不可用、硬件故障。这类场景外部变量太多，LLM 很难通过日志推断出物理层面的问题。

**建议：** 在告警分组阶段，使用轻量级聚类算法做初筛，再让 Agent 对聚类后的组别进行语义解释。不要试图让 Agent 直接处理单条孤立的噪音告警。

自动处置 Agent：安全护栏比智能更重要

这是最关键的部分。当 Agent 被授权可以执行 `kubectl delete pod` 或 `ansible-playbook` 时，你必须构建多层安全护栏。

我在项目中设计了这样一个审批流：

1. **意图识别**：Agent 首先判断用户请求是否属于“危险操作”。如果是，强制进入人工审批队列。
2. **沙箱预演**：在执行前，Agent 需要在隔离环境中模拟执行过程，并返回预期的状态变化（Diff）。
3. **最小权限原则**：为 Agent 分配独立的 Service Account，该账号只能访问特定的命名空间和执行特定的命令。

# Kubernetes RBAC 示例：限制 Agent 只能查看特定命名空间的 Pod 状态 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production-ns name: agent-reader rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods/exec"] verbs: ["create"] # 注意：这里通常禁止，或者仅限特定命令

**切记：** 不要让 Agent 拥有 `ClusterRole` 级别的权限。即使是最简单的 Agent，也应该遵循“按需授权，用完即焚”的原则。

安全与审批：团队协作中的信任契约

技术上的边界清晰了，但团队协作中的边界更模糊。

当运维团队开始依赖 AI Agent 时，必然会产生责任划分的问题：如果 Agent 执行错误导致生产事故，谁负责？是写 Prompt 的开发，是训练模型的算法工程师，还是批准执行的运维负责人？

**我的经验是：**

**明确“人机协同”的责任主体**：Agent 是副驾驶（Co-pilot），人类是机长（Captain）。所有的自动化处置，必须有至少一名具备 Senior 资质的运维人员在岗确认，尤其是在初期。
**建立反馈闭环**：每次 Agent 被人工修正的操作，都要记录在案。这些数据不仅用于微调模型，更是优化 Prompt 和工具链的关键素材。
**透明化**：向业务方和其他团队成员展示 Agent 的决策逻辑。如果一个 Agent 连续三次做出相同的错误判断，必须立即下线并排查，而不是继续让它“学习”。