作者： Eric Johanson 日期： 2026 年 8 月 5 日 阅读时间： 9 分钟
作者是 LangChain 的一名 Deployed 工程师，工作内容与 Kubernetes 息息相关。他维护着一个内部自托管集群——用于测试新功能——同时协助客户搭建他们自己的自托管环境。当集群出现故障时，他需要在脑海中建立一份关于线上集群的清晰"心智模型"，才能定位并修复问题。要在本职工作之外持续维护这种认知，令人疲惫不堪。为了缩短故障排查与修复时间、提升可靠性并降低认知负担，团队构建了一个自主 SRE Agent，用于评估 Kubernetes 的健康状态并提出修复建议，只在确需变更时才引入人工介入。
Kubernetes 会产生海量原始数据（例如重启次数、HPA 状态、节点状况等），但几乎没有做任何聚合与归纳。值班工程师需要分析这些信号，以判断：
- 是否有东西正在出问题（例如 OOM 被杀、崩溃循环）。
- 是否有东西即将达到临界点（例如单副本服务、HPA 已拉满）。
- 需要哪些步骤来解决当前状况。
由于回答这些问题需要判断力，这项任务通常会落到基础设施工程师头上。然而其中大部分工作只是例行排查，大多数情况下结论都是"一切正常"。这种繁琐的手工劳动容易导致倦怠，也会让工程师错过关键告警。
主动监控： 一个调度器会按固定间隔检查集群健康状态，但不会触发完整的 Agent。它通过 Kubernetes Python 客户端采集原始集群状态（不消耗任何 LLM token），再执行一次 Claude Haiku 调用。这会生成一份按严重程度排序的结构化健康报告，并发布到 Slack。
按需调查： 对于需要诊断的问题，编排器会并行部署若干专门的子 Agent（pod-inspector、scaling-analyzer、log-analyzer 等）。每个子 Agent 独立评估集群，随后将各自的发现汇总成一份按优先级排序的报告。
安全模型： Agent 拥有完整的读权限，但不能独立修改任何东西。所有写操作都被限制在一个特定的 change-executor 子 Agent 中，并受到人工介入（Human-in-the-Loop，HITL）中断的保护。Agent 先提出修复方案，再由人工通过 Slack 批准、拒绝或修改。这种结构化的读写分离，在集群内的 RBAC 上也得到了对应映射。
团队做了若干刻意的架构决策：
- 选择 Deep Agents 而非裸循环： 系统基于 LangGraph 之上的 Deep Agents，使用
create_deep_agent()函数。它自带规划循环、子 Agent 和内置的 HITL 中断，无需手写定制代码。 - 窄域子 Agent： 每个专家 Agent 只负责特定的集群切片。这使得并行处理成为可能，限制了上下文以降低幻觉风险，并允许在定向任务上使用更便宜的模型。
- 策略性的模型使用： 负责汇总的编排器运行在 Claude Sonnet 上，而只读子 Agent 和定期检查则使用 Claude Haiku，以优化成本。
- 调度器绕过 Agent： 对于例行的"全部健康"检查，调度器不再运行完整编排器（约 20 次模型调用），而是依赖纯 Python 数据采集加上一次 Haiku 调用。这使检查成本降低了 95% 到 99%。
- 清晰可读的人工审批： 所提议的变更保持清晰且范围狭窄（例如扩容某个 deployment）。那些粗粒度、爆炸半径较大的操作被刻意排除在外，让人工能够准确评估自己究竟在批准什么。
- 结构化的读写分离： 读工具与写工具被隔离在不同的模块中。写工具只存在于 change-executor 子 Agent 内，并位于一个中断门之后。
- 无公网入口： 系统在不暴露公网端点的情况下安全运行。Kubernetes 客户端会自动识别集群内与本地配置，而 Slack 则通过 Socket Mode 经由出站 WebSocket 运行。
Agent 的每一个决策都会被记录为一条 LangSmith trace，包括定期检查、子 Agent 调查以及提议的写操作。
从 trace 中获得的洞察：
- 降低成本： trace 分析揭示，"全部健康"的检查不必要地扇出到了约 20 次 Sonnet 调用。这一洞察推动了"单次 Haiku 调用"调度器的重写。
- 防止循环： trace 曾捕捉到 Agent 陷入文件系统
grep循环、烧掉经费的情况。因此在递归、模型调用次数以及单个工具上都加上了硬性上限，并配合了 prompt 缓存。 - 解决误报： trace 暴露了一个反复出现的误报——scaling-analyzer 会把有意为之的单副本服务错误地标记为严重问题。这通过一次针对性的 prompt 修改得到修复。
- 为人工反馈打分： 每一次 HITL 的修改或拒绝都是有价值的标注数据，会被附在该运行的反馈上。
这些标注过的运行构成了一套回归测试集。被错误分类的场景会被提升为一个 LangSmith 数据集并附上正确答案，未来所有 prompt/模型的调整都会据此进行评估。
LangSmith Engine： 团队使用 LangSmith Engine 来自动化手工评估闭环。
- 检测（Detect）： 它在零数据保留的前提下，将相关 trace 组织成按优先级排序的问题。
- 修复（Fix）： 它起草 prompt 或代码修正，并开启一个带有 diff 和说明的 GitHub PR。
- 预防（Prevent）： 它建议在线评估器和数据集样例，以阻止未来出现回归。
例如，Engine 自主发现定期健康检查缺少利用率类数据能力（如 kubectl_top_pods 和 kubectl_top_nodes）。随后它提交了一个 PR，将 pod 和 node 的指标接入采集器，同时不打扰分析 prompt，也不破坏零 token 的特性。
LangChain 持续在内部使用这个 SRE Agent，并正在将其推广到 LangSmith 客户。未来的更新将引入面向 HITL 的持久化状态管理，以及面向监控循环的有状态记忆，用于追踪近期事件。该项目已开源，可在 GitHub 上获取：https://github.com/langchain-samples/sre-agent