LangChain 如何为 Kubernetes 构建自主 SRE 智能体

Kubernetes 集群会持续产生海量信号——Pod 状态、重启次数、HPA 伸缩状态、节点健康、部署就绪情况——却几乎不提供任何综合判断。值班工程师需要回答三个核心问题：当前是否有故障、是否有潜在风险、应该如何处置。这些判断需要深厚的领域经验，但其中 90% 的工作本质上是机械性分诊，最终结论往往是「一切正常」。这种重复性劳动不仅消耗精力，还会让工程师逐渐对真正重要的告警产生麻木感。

为解决这一问题，LangChain 团队构建了两种运行模式。其一是定时巡检：调度器每隔数分钟通过 Kubernetes Python 客户端采集集群原始状态（不消耗任何 LLM token），再用一次 Claude Haiku 调用生成结构化健康报告并按严重程度排序推送至 Slack。其二是按需深度调查：当问题需要诊断时，编排器会并行启动多个专职子智能体，包括 Pod 检查器、扩缩容分析器、性能分析器、日志分析器、安全审计器等，各自独立读取集群数据后汇总为一份优先级排序报告。

安全模型是整套系统的核心设计原则。智能体可以读取整个集群的状态，但无法自主执行任何变更。所有写操作——包括调整副本数、重启 Rollout、修改 HPA——都集中在单一的 change-executor 子智能体中，且每个写工具都设有人工审批中断点。工程师可以直接在 Slack 消息中批准、拒绝或修改变更方案。这一读写分离不仅体现在代码架构层面，也通过集群内 RBAC 权限策略在基础设施层面得到镜像强制执行。

在技术选型上，团队选择了 Deep Agents（create_deep_agent()）而非手写循环，原因是它开箱即提供规划循环、一等公民子智能体支持和内置 HITL 中断机制。模型使用策略上，编排器使用 Claude Sonnet 负责综合推理，只读子智能体和定时巡检使用 Claude Haiku 以控制成本。写工具被刻意设计得粒度细、可读性强，高影响范围的操作（如 helm upgrade）被主动排除在外，确保人工审批时能够真正理解自己在批准什么。

LangSmith 的全链路追踪在系统优化中发挥了关键作用。团队通过分析每次运行的 token 消耗和费用明细，发现定时巡检在结果为「全部健康」时仍会触发约 20 次 Sonnet 调用，造成大量浪费。这一发现直接推动了调度器的重构，将其改为纯 Python 采集加单次 Haiku 调用，成本降低 95% 至 99%。追踪还帮助团队识别出另一个智能体陷入工具调用死循环、单次运行烧掉约 5 美元的问题，促使团队为递归深度和模型调用次数设置了硬性上限。

从部署角度看，该智能体无需任何公网入口：Kubernetes 客户端自动识别集群内外环境，Slack 通过 Socket Mode 的出站 WebSocket 连接处理审批消息。容器以非 root 用户运行，根文件系统设为只读。整套架构的核心原则是：只在真正能改善运维结果的地方消耗 token、模型算力和网络资源，这使得智能体既能以极低成本每隔数分钟运行一次，又能安全地指向生产环境。

要点

• 读写权限的结构性分离是自主运维智能体安全上生产的关键：读操作完全自主，写操作必须经过人工审批，且这一边界在代码架构和 RBAC 两个层面同时强制执行
• 定时巡检与按需深度调查应采用不同的模型策略，将高成本推理模型保留给真正需要判断的场景，可将高频巡检成本降低 95% 至 99%
• 人工审批界面的可读性直接决定安全门控的实际效果，写工具应保持细粒度和高可读性，主动排除高影响范围的批量操作
• 全链路追踪工具（如 LangSmith）不仅用于调试，更是发现成本浪费和异常循环的核心手段，应覆盖所有模型调用包括直接 API 调用
• 专职子智能体并行架构相比单一全能提示词，能同时获得更低的幻觉率、更好的并行性和更灵活的模型成本分配