devgo.cn核心观点
- 团队为 Kubernetes 运维构建了自主 SRE Agent：主动巡检 + 按需调查两级结构，目标是缩短分诊与补救时间、减轻值班工程师的认知负担。
- 安全模型是硬约束：Agent 能读整个集群但默认改不了任何东西——所有写操作（扩缩容、重启 rollout、修改 HPA）集中在唯一的 change-executor 子 Agent 里，每个写工具都由 human-in-the-loop 拦截，Slack 里批准。
- 成本设计是量级级的：定时巡检绕开完整 Agent，纯 Python 采集集群状态 + 一次 Haiku 调用，每轮检查成本砍掉 95%-99% 且不漏问题。
- 架构主线的取舍清晰：窄任务子 Agent 而非全能提示词、Sonnet 负责思考 / Haiku 负责规模、写工具保持「可读懂」而非追求强大。
内容精讲
Kubernetes 对值班工程师来说是一个信号瀑布：pod 阶段、重启次数、HPA 状态、节点条件、告警事件、部署就绪度，散布在几十个 namespace 里，几乎没有合成。值班要回答三个问题：现在坏了吗（崩溃循环、OOM、零就绪端点）；快坏了吗（HPA 顶满、单副本服务、:latest 镜像）；该怎么办。回答这些问题需要判断力，但 90% 的工作是机械化的分诊，而且大部分时候结论是「一切正常」。这种 toil 会把人烧干，还会训练人无意中跳过重要告警。
**两级结构。** 主动监控：调度器每 N 分钟检查一次健康，不唤醒完整 Agent——用 Kubernetes Python 客户端采集原始集群状态（零 LLM token），再做一次 Claude Haiku 调用（强制工具使用）产出按严重度排序的结构化健康报告，投递到 Slack。按需调查：当问题需要诊断时，编排器并行派出专用子 Agent——pod-inspector、scaling-analyzer、performance-analyzer、log-analyzer、security-auditor、reliability-auditor 等，各自独立读集群后再综合成一份优先级报告。
**安全模型：读自由，写被门禁。** 这是整套设计里最值得抄的部分。Agent 可以读整个集群，但改不了任何东西：所有写操作都生活在唯一一个 change-executor 子 Agent 里，每个写工具都被 HITL 中断门禁——Agent 提出补救方案，人从 Slack 消息里批准、拒绝或修改。这种读写分离是结构性强制执行的：读工具和写工具分属不同模块，写工具只存在于 change-executor 子 Agent 内部且在中断门后，编排器根本接触不到写工具。集群内 RBAC 镜像同样拆分——集群级只读、严格限定的写。
**四个值得注意的工程决策。** 第一，用 Deep Agents 而非裸循环：在 LangGraph 上叠 create_deep_agent()，白拿规划循环（write_todos）、一等子 Agent 和内置 HITL 中断，这些手写都要时间；原则是「选不跟你的工作流作对的最高层框架」。第二，窄子 Agent 而非全知提示词：专业 Agent 各管集群一片，换来并行、更紧的上下文（更少幻觉），还能在范围明确的子任务上用便宜模型。第三，模型分档：编排器用 Claude Sonnet 思考，只读子 Agent 和定时检查用 Claude Haiku——只在需要智能的地方花钱。第四，写工具刻意「窄而可读」：把 deployment 扩到 3 个副本一眼能看懂，但 helm upgrade 一次点击会重写几十个资源、人在批准框里根本看不见——所以这类高爆炸半径的工具被故意留在了工具箱外，哪怕它有用。
**部署形态同样克制。** Kubernetes 客户端自动检测集群内/本地运行（镜像里没有 kubectl），Slack 走 Socket Mode（出站 WebSocket），批准流程不需要任何入站端点；容器非 root、根文件系统只读。贯穿始终的原则是：只在能改善被管理基础设施结果的地方花 token、模型算力和网络面——这让 Agent 便宜到可以每几分钟跑一次，安全到可以指向生产。
阅读价值
对 SRE 与平台工程师，这套「读自动/写门禁」的安全模型和 95%+ 成本削减的巡检设计可直接复刻；对 Agent 架构设计者，窄子 Agent、模型分档、可读审批三个取舍是生产级 Agent 的成熟范本。
内容与图片版权归原作者所有 · 原文: https://www.langchain.com/blog/how-we-build-an-autonomous-sre-agent-for-kubernetes-deployments