从你的 Kubernetes 集群中驱逐 MCP tool calls
Source: Dev.to
概览
模型上下文协议（MCP）已经在自行摇摆一段时间了（相关链接），它阐明了我们许多在代理领域的从业者感受到却未量化的挫败感：
大语言模型是出色的代码生成器，但却是糟糕的状态机。
业界对代理的标准做法是 ReAct 模式（Reason + Act），本质上把你的 LLM 变成一个伪运行时。模型决定使用哪种工具，调用 API，等待网络响应，解析 JSON 结果，然后重复。该方法在当今的 LLM 上并不高效：你让一个概率引擎去处理确定性的控制流，导致幻觉、快速的上下文窗口污染以及脆弱的状态管理。
我尝试在 Kubernetes 诊断中实现 Code Mode（参考链接）模式。与其暴露原子工具（list、get、log 等）让 LLM 逐个编排，不如提供一个带运行时的沙箱。LLM 编写程序，代理执行它。结果不仅“更好”，而且代表了代理与基础设施交互方式的根本转变。
在真实的调试会话中，传统任务工作流（从日志中定位失败 pod 的问题）在 8–10 次工具调用中可能消耗约 100 万 token。而在 Code Mode 中，同样的调查只需要 10–20 万 token——约 2–10 倍的降低，对于上下文占用大的任务甚至可节省 90% 以上的 token。
上下文的经济性
在生产环境的 Kubernetes 工作流（日志量大）中，标准的“告诉我 pod 为什么会坏掉”工作流通常在 8–10 轮对话中消耗 1 M+ token。每一次工具调用都会把中间的 JSON 加入上下文，扩大幻觉的产生面。
传统的 MCP 工具调用链同样 不利于提示缓存，因为每一次交互都会根本性地改变对话上下文（Claude 提示缓存文档）。
切换到 Code Mode 后，模型只收到一次提示，写出单个代码块，然后得到最终的精炼答案。这消除了不必要的工具调用，极大降低了 token 使用量、延迟以及幻觉率。Anthropic 最近的 基准测试（链接）显示工作流从 150 k token 降至约 2 k token（节省 98% 上下文）。在我们自己的 Kubernetes 场景中也观察到类似的下降（最高 90%）。
- 传统工具使用： ~1 M token / 8‑10+ 次往返。
- Code Mode： ~100‑200 k token / 4‑6+ 次往返。
为什么有效
Code Mode 使架构与训练数据保持一致。前沿的 LLM 在有效、可执行的代码上进行大量预训练，能够隐式理解控制流、错误处理和数据过滤。
相反，交互式工具调用范式迫使 LLM：
- 在无状态的 HTTP 请求之间管理循环状态。
- 解析冗长的 JSON，同时忽略前一次调用的噪声。
将执行逻辑迁移到确定性的沙箱中，能够把严格的逻辑——循环、过滤、条件等待——交给专为此设计的运行时。LLM 实际上只会写出类似下面的脚本：
“遍历所有 pod；如果某个 pod 重启次数 > 5，获取其日志，grep ‘Error’，并返回结果。”
沙箱在毫秒级完成该循环。LLM 永远看不到 500 个健康 pod 的原始列表，只会看到最终的根本原因。中间结果在沙箱内部处理，而不是污染上下文窗口，正如 Anthropic 所指出的那样，这是导致代理性能下降的常见原因（链接）。
根据 Anthropic 的内部测试（链接），Code Mode 还能显著提升准确性。这与更广泛的研究相吻合：当模型被迫把代码包装在 JSON 中返回时，表现会下降——Aider 的基准测试（链接）发现模型在确保 JSON 格式有效的同时，生成的代码质量更低。
高阶 Kubernetes 诊断
这种转变使得之前因上下文限制而成本高昂或技术上不可行的工作流成为可能。
1. “集群健康扫描”场景
旧方式： 代理列出所有 pod，然后通过多次工具调用逐个描述，快速触达速率或上下文限制。
新方式： 代理编写循环。
// Execution inside the sandbox
const pods = tools.kubernetes.list({ namespace: 'default' });
const problems = pods
.filter(p => p.status === 'CrashLoopBackOff')
.map(p => {
const logs = tools.kubernetes.logs({ name: p.metadata.name });
return analyze(logs);
});
return problems;整个扫描在主 LLM 对话链之外完成。
2. 配置漂移与审计
代理可以拉取 Helm 发布清单（tools.helm.get）和实时的 Kubernetes 对象（tools.kubernetes.get），在沙箱内内存中进行差异比较，只返回漂移部分。如果使用传统工具调用，则需要把两个巨大的 YAML 文件粘贴进上下文窗口。
3. 事件驱动调试
因为沙箱提供了真实的运行时，代理可以编写轮询逻辑。它可以检查部署状态，等待 5 秒，再次检查，而无需在“等待”状态上消耗任何 token。这使得原子化的“滚动发布并验证”操作看起来像魔法，远胜于聊天式代理的卡顿步骤。
4. PII 数据获取
Code Mode 与 MCP 为 Kubernetes 环境提供了关键的安全优势：敏感数据永远不会进入 LLM 的上下文窗口。在传统工具调用中，代理检索 API 凭证、数据库密码或 ServiceAccount Token 等 Kubernetes Secret 时，这些值会流向云模型提供商的网络。而使用 Code Mode，沙箱在内部处理这些机密，仅返回已清理的结果给 LLM。