中文精炼导读
核心观点
- LangChain 的 Deployed Engineer 团队构建了一个自主 SRE Agent 来守护内部自托管的 Kubernetes 集群，目标是把"分诊时间"和"修复时间"降下来、降低团队认知负荷——它自动分诊集群健康、提出修复建议，只在需要集群或基础设施变更时才把人拉进来。
- 核心安全模型是"读全自主、写必须人工把关"：agent 可以读取整个集群但无法自己改动任何东西，所有写入（扩缩容、重启 rollout、修改 HPA）都封装在唯一的 change-executor 子代理里，每个写工具都被人机协同（HITL）中断拦截。
- 架构遵循"只在有收益处花钱"的原则：主动健康检查用纯 Python 收集状态 + 一次 Claude Haiku 调用，比原来跑完整 orchestrator（约 20 次模型调用）的成本削减 95%–99%，且不漏任何问题。
- 子代理采用"窄而专"而非"一个全知 prompt"：pod-inspector、scaling-analyzer、log-analyzer 等各管一摊，换来并行性、更紧凑的上下文（更少幻觉），并允许把界定良好的任务跑在更便宜的模型上。
- LangSmith Engine 把"发现问题→修复→防复发"的改进循环自动化：聚类 trace 成问题、写 prompt/代码改动并开 PR、建议在线评估器，甚至主动发现并修复了健康检查漏采利用率数据这个他们自己都没提出的问题。
内容精讲
文章的动机来自作者 Eric Johanson 的真实工作状态：作为 LangChain 的 Deployed Engineer，他维护内部自托管集群、还帮客户搭建和升级自托管环境，这需要对一个"活着的集群"建立足够深的心智模型——集群挂了要能读懂架构、找到故障、修好它。在全职工作之外持续做这件事非常耗人，而基础设施从业者都有同样的痛点。Kubernetes 会发射海量信号（pod 阶段、重启次数、HPA 状态、节点状况、警告事件、跨几十个命名空间的部署就绪度），却几乎没有综合。值班工程师用这些信号回答三个问题：现在有没有东西坏了（crash loop、OOM kill、零就绪端点）？有没有东西要坏（HPA 顶满、单副本服务、:latest 镜像标签）？我们该怎么办？回答好这些问题需要判断力，通常落在基础设施工程师或专家身上，但 90% 是"大多检查后一切正常"的机械分诊——这种 toil 让人精疲力竭，还会让人不自觉地开始略过重要告警。
他们构建的系统分两部分。主动监控：一个调度器每 N 分钟检查一次健康，不唤醒完整 agent；它通过 Kubernetes Python client 收集原始集群状态（零 LLM token），然后做一次 Claude Haiku 调用（强制工具使用）生成按严重程度排序的结构化健康报告发到 Slack。按需调查：当问题需要诊断时，orchestrator 并行扇出到专门的子代理——pod-inspector、scaling-analyzer、performance-analyzer、log-analyzer、security-auditor、reliability-auditor 等，每个都独立读取集群，最后综合成一份优先排序的报告。
安全模型是整篇的骨架。agent 可以读整个集群，但无法自己改变任何东西：每个写入（扩缩容部署、重启 rollout、打 HPA 补丁）都住在唯一的 change-executor 子代理里，每个写工具都由 HITL 中断把关。agent 提出修复方案，人从 Slack 消息里直接批准、拒绝或编辑。读取是自主的，写入始终由 HITL 把关——这在结构上强制实施，并由集群内 RBAC 镜像（集群范围读、严格受限写）。特别值得注意的设计是"给人类一个他们真能读懂的审批"：把部署扩到 3 个副本一眼可读，而一次 helm upgrade 会改写几十个你看不到的资源；所以他们刻意让写工具保持窄而可读，并故意不提供粗粒度、高爆炸半径的工具——即使它们有用。这个闸门只有在人类能真正判断他们在批准什么时才保护生产。
构建选择上有几个"明显路径与正确路径分叉"的决策点。用 Deep Agents 而非裸循环：他们基于 create_deep_agent() 而非 LangGraph 手写，获得规划循环（write_todos）、一等公民的子代理和内置的 HITL 中断。窄子代理而非一个全知 prompt：每个专家 agent 只拥有集群的一块，换来并行性、更紧凑的上下文和用便宜模型跑界定良好任务的机会。Sonnet 负责思考、Haiku 负责规模：综合 orchestrator 跑 Claude Sonnet，只读子代理和定时检查跑 Claude Haiku——只在需要的地方为智能付费。调度器绕过 agent：状态收集用纯 Python，一次 Haiku 调用就完成。运行在任何地方且无公网入口：Kubernetes client 自动探测 in-cluster 与本地（镜像里没有 kubectl），Slack 走 Socket Mode 出站 WebSocket，因此审批流不需要暴露任何入站端点；容器是非 root 且根文件系统只读。贯穿始终的主线是"尽量简单和低成本"——只在能改善被管理基础设施的 agent 产出时才花 token、算力和扩大网络面。
LangSmith 在整个改进过程中扮演了关键角色。每个决策都作为 trace 运行：定时 Haiku 检查、每个子代理调查、每次读取和提议的写入。trace 抓出了几类问题：约 20 次调用的定时检查是 LLM 浪费（每运行成本拆分显示"一切正常"的检查悄悄扇出到约 20 次跨子代理的 Sonnet 调用，这直接催生了单 Haiku 调用的重写）；失控循环在 trace 里一目了然（某 agent 卡在文件系统 grep/read_file 的紧循环里烧掉约 5 美元，trace 里同一个工具调用在一趟运行里堆了几十次，于是加了硬递归/模型调用/单工具限制和 prompt caching）；误报变成可识别的模式（scaling-analyzer 总把故意单副本的服务标成 CRITICAL，trace 展示了子代理看到的确切快照和推理路径，一次基于直接证据的 prompt 修改就修好了）；每次 HITL 编辑都是带标签的数据（"提议 10 副本，人类改成 4"成为 agent 最高风险调用的带标注样本）。
这些带标签的运行构成了评估套件的骨干：被误分类的 pod 或漏掉的 OOM 会被提升为 LangSmith 数据集（附上正确答案），此后每次 prompt 或模型调整都要用 LLM-as-judge 和基于代码的评估器跑一遍——回归会显示为红色数字从而无法合并；单副本误报成了评估套件的永久测试用例。而 LangSmith Engine 更进一步，把"靠人注意到问题、找到 trace、提升为数据集"这个繁琐循环自动化：Detect 阶段把相关 trace 聚类成排好序的问题（把跨六个命名空间的四十条 trace 归并成一个问题）；Fix 阶段总结失败、写出 prompt 或代码改动、开一个带 diff 和解释的 GitHub PR；Prevent 阶段建议在线评估器和数据集示例防止复发。Engine 还发现了一个他们自己没提过的问题：定时健康检查根本没收集利用率数据——收集器查了节点、pod、警告事件、HPA 和部署，但分析步骤是一次没有工具可用的强制工具调用，模型无法取回收集器跳过的东西，于是每小时的报告都会抛出一个它结构上无法回答的容量问题。Engine 提议把 pod/node 指标接进收集器（复用已有代码而非发明新逻辑），把改动限定在收集器内，保持零 token 属性不变——以 PR 形式到来，经评审、加入数据集、测试防止回归、合并。
文章结尾给出下一步：让 HITL 状态持久化、让监控循环变成有状态（记住近期报告过的事件）；项目开源在 github.com/langchain-samples/sre-agent，欢迎试用、贡献和反馈。
阅读价值
适合 SRE、平台工程师和正在生产环境跑 agent 的团队：这篇文章是一个完整的"用 agent 治理基础设施"实战案例——从安全模型（读自主/写 HITL、RBAC 镜像）到成本设计（调度器绕过 agent、Haiku/Sonnet 分工），再到用可观测性和自动改进循环（Engine 开 PR）持续优化；即使不用 LangChain 生态，其中的架构决策也极具参考价值。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.langchain.com/blog/how-we-build-an-autonomous-sre-agent-for-kubernetes-deployments