把 MCP 应用从本地 Demo 搬到公司生产环境

很多同事在写 MCP Server 的时候，习惯性地认为只要 Python 函数能跑通就万事大吉，但实际在公司工作流里，链路太长了：用户 → AI 客户端 → MCP Server → 具体 Tool → 外部 API/数据库。随便哪个环节点掉链子，整个 Agent 就会开始胡言乱语或者直接卡死。

为了不让产品上线后被用户骂死，我总结了一套在公司内部实操的测试和调试方案，建议打算把 MCP 规模化部署的同学参考。

一、 别只测正常路径，多写点单元测试

很多人的单元测试只写“输入正确 → 输出正确”，这在生产环境里根本不够。你要重点测那些能让程序崩溃的边缘 case。

比如一个天气查询工具，除了测能查到温度，更得测输入为空、城市名乱码、或者权限不足时，代码是否能优雅地抛出错误而不是直接 Crash。

import pytest

# 验证空输入是否能被正确拦截
def test_get_weather_rejects_empty_city():
    with pytest.raises(ValueError):
        get_weather("")

# 验证正常响应的结构是否符合预期
def test_get_weather_returns_result(mocker):
    mocker.patch(
        "weather_client.get", 
        return_value={"city": "Toronto", "temperature": 24}
    )
    result = get_weather("Toronto")
    assert result["city"] == "Toronto"
    assert result["temperature"] == 24

二、 强制使用 Mock 模拟外部服务

在公司环境下，你不能在每次跑测试时都真去请求一次第三方 API，那样不仅慢，还容易触发频率限制（Rate Limit），甚至产生不必要的费用。

用 Mock 模拟外部依赖是标准操作，但重点是：必须模拟失败场景。超时、401 鉴权失败、返回畸形 JSON，这些才是决定你应用鲁棒性的关键。

# 模拟 API 超时，看代码能不能接住这个异常
def test_customer_api_timeout(mocker):
    mocker.patch(
        "customer_api.get_customer", 
        side_effect=TimeoutError()
    )
    result = get_customer("cust-104")
    assert result["error"] == "service_unavailable"

三、 必须跑通集成测试

单元测试只能证明“零件”没问题，集成测试才能证明“机器”能转。

一个完整的集成测试链路应该是：客户端发起请求 → MCP Server 接收 → 匹配到对应的 Tool → 执行逻辑 → 返回结构化结果。如果中间任何一个环节的 JSON 格式对不上，或者模型选错了工具，那单元测试跑 100 遍也没用。

在实际部署中，建议把这些测试集成到 CI/CD 流水线里，确保每次代码提交都不会把之前的功能跑崩。