用 MCP 与代码编排串联故障排查

应用在上午 10:30 突然开始报 HTTP 500，指标、日志和 Kubernetes 状态都有，AI 却未必能把它们串成可靠结论。难点往往在于：先查什么、下一步查哪个时间段，以及哪些结果值得交给模型。

作者用一次假设的 5xx 故障调查，解释 MCP 与 Code Mode 的分工：前者统一工具接口，后者让模型写代码组织查询、处理数据。它值得读的地方，是把「接入更多工具」推进到了「怎样控制调查过程和上下文成本」，同时也留下了需要验证的工程前提。

MCP 管工具接入，Code Mode 管调查怎么执行

MCP 和 Code Mode 可以叠加使用，不是二选一。

Model Context Protocol（MCP）为 LLM 应用提供统一的工具发现与调用接口。Prometheus、Loki、Kubernetes、GitHub 各有接口和认证方式，MCP server 负责对接，向模型暴露 query_prometheus、query_loki、get_pod_status、get_recent_deployments 等能力。

统一接口不等于统一调查方法。模型知道怎样调用日志工具，并不代表它知道该查哪个时间窗口、怎样关联 pod 重启和数据库超时。

作者给出的 Python 接入示例，通过 pip install "mcp[cli]" httpx 安装依赖，从 mcp.server.fastmcp 导入 FastMCP，创建 FastMCP("sre-monitoring")，再用 @mcp.tool() 注册工具。它读取环境变量 PROMETHEUS_URL、PROMETHEUS_TOKEN，携带 Bearer 认证，以 httpx.AsyncClient(timeout=15) 请求 /api/v1/query，传入 params={"query": query}，最终返回 payload["data"]。服务通过 mcp.run(transport="streamable-http") 启动。

这解决了「能力如何暴露」，还没解决「能力如何组合」。

Code Mode 是一种架构模式：模型生成程序，由独立运行环境执行查询、条件判断、过滤和聚合，再把精简结果交回模型。底层仍然可以调用 MCP 工具。

原文特别说明，这套 Python 沙箱只是自定义架构示意，并非 Cloudflare Code Mode SDK 的官方 Python 实现。

同一次故障，差别在于谁处理过程数据

原文设定的场景是：checkout 应用在 10:30 左右，5xx 错误率从 0.5% 上升到 18%；Loki 出现数据库连接超时，Kubernetes 显示部分 pod 重启。

逐次调用工具时，模型先看指标，再读日志，再查 pod，最后关联证据。Code Mode 则把其中可程序化的步骤交给代码。

下面这段原文代码解决的是：先定位错误率异常，再缩小日志查询范围，最后只返回相关摘要。

async def investigate_5xx_incident(start, end):

    # 1. Query the error rate
    metrics = await tools.query_prometheus(
        query="""
        sum(rate(http_requests_total{
            status=~"5.."
        }[5m]))
        /
        sum(rate(http_requests_total[5m]))
        """,
        start=start,
        end=end,
    )

    # 2. Identify the first abnormal point
    first_bad_point = find_threshold_crossing(
        metrics,
        threshold=0.05,
    )

    if not first_bad_point:
        return {
            "status": "No significant increase detected"
        }

    # 3. Search logs around the abnormal time
    logs = await tools.query_loki(
        query='{namespace="production", app="checkout"} |= "ERROR"',
        start=first_bad_point["timestamp"] - 300,
        end=end,
    )

    # 4. Group and summarize errors
    error_summary = summarize_errors(logs)

    # 5. Check Kubernetes
    pods = await tools.get_pod_status(
        namespace="production",
        deployment="checkout",
    )

    # 6. Return only relevant findings
    return {
        "error_rate": first_bad_point,
        "log_summary": error_summary,
        "pod_status": summarize_pods(pods),
    }

重点看 threshold=0.05 和 timestamp - 300：前者把 5% 设为异常阈值，后者将日志起点向前推 300 秒。调查策略已经写进程序，不能当作适用于所有服务的默认答案。

这里还有一个接入缺口：前面的 MCP 示例只提供 instant query，签名是 query_prometheus(query: str)；调查代码却假设它支持 query_prometheus(query, start, end)。要查询历史区间，必须补上对应实现，不能直接拼起来运行。

tools 同样只是受控工具桥接的示意对象，并非 MCP Python SDK 自带 API。find_threshold_crossing、summarize_errors、summarize_pods 都需要自行实现、测试并约定输入输出。

原文的紧凑结果示例包含 4 个受影响 pod、检测到重启、疑似数据库连通性问题，置信度为 Medium。这些都是假设场景的输出，没有实测报告支撑。数据库超时与 pod 重启可以提供调查方向，却不足以确定谁先发生、谁导致谁。

节省上下文，靠的是先筛选再交给模型

上下文窗口按 token 计量。对话、工具描述、检索内容、工具结果和输出，都可能占用容量，具体取决于平台实现。

作者给了一组估算：500 个指标样本占 15,000 tokens，2,000 行 Loki 日志占 80,000，pod 信息占 15,000，近期部署信息占 10,000，工具定义占 5,000，提示与历史对话占 10,000，合计 135,000。对于 128K-token 窗口，这可能超出容量。

这些数值只是示意，格式、字段长度和分词方式都会改变实际用量，不能拿来当固定换算表。

Code Mode 的作用，是让大批过程数据留在运行环境里。例如，代码把 10:30 至 10:45 的 2,000 条错误归为三类：数据库连接超时 1,450 条、连接池耗尽 420 条、请求超时 130 条。模型收到分类和计数，就不必逐行阅读相似日志。原文还示意可以只返回前 5 项发现。

Code Mode 没有扩大上下文窗口，只是减少了进入窗口的过程数据。

生成的代码、工具描述和最终结果仍会消耗 token。它的收益来自减少噪声和重复处理，不是让调查天然更准确。

代价则是多维护一个执行层。作者建议将 MCP server 与代码运行环境分开，通过受控桥接访问获准工具。生产环境不能直接在 MCP server 进程中用不受限的 exec() 执行生成代码；还需要工具白名单、限定范围的凭证、尽可能短期的 token，以及执行时间、内存、查询和响应大小限制。

生成代码、工具调用、执行结果及责任会话也应记录，返回结果需要校验。涉及修改生产基础设施的操作，原文要求显式人工批准。

我的判断

我赞同作者把接入与编排分开的判断。查单个 pod、查当前 CPU、查部署版本，逐次调用 MCP 工具已经足够。只有任务包含多轮查询、条件分支、大量日志聚合时，增加执行环境才更有理由。

但这篇文章提供的是架构建议和示意代码，没有给出调用次数、调查耗时、token 成本或结论准确率的对照实验。不能据此断言 Code Mode 一定更快、更便宜。

传统工具调用也可以由服务端完成过滤、分页和聚合。若故障流程稳定，把它封装成固定调查工具，同样能减少上下文，还更容易测试。动态生成代码的优势，是临时组合已有能力；相应代价，是执行隔离、程序校验和排障成本。

另一个局限是摘要可能丢失少量关键证据。出现次数最多的错误未必最接近根因，首次异常的时间也受阈值和 [5m] 窗口影响。原文开头提到检查请求量、延迟和部署，但核心调查代码并没有覆盖这些检查。因此，「疑似数据库连通性问题」适合作为下一步假设，不适合作为调查终点。

能拿来做什么

• 给负责的 Node 或全栈服务接 AI 排障时，先暴露只读的指标、日志和 pod 查询工具，验证逐次调用能否解决常见问题，再决定是否增加代码运行环境。
• 检查现有 AI 调查记录，找到反复返回大量日志、指标样本的流程。先尝试限定服务与时间范围、服务端聚合；确实需要动态组合时，再引入 Code Mode。
• 落地示例前，补齐历史指标查询、工具桥接和摘要函数，明确阈值、时间戳单位及返回结构，并为摘要保留可回查的原始证据。
• 按作者建议记录工具调用次数、调查延迟和结论准确率，对比逐次调用与代码编排。只有收益覆盖新增复杂度，才值得扩大使用范围。