MCP Agent 生产化：Docker + Kubernetes + 可观测性完整方案

在本地构建 AI Agent

在开发者的机器上构建 AI Agent 是令人兴奋的第一步。但在生产环境中可靠地运行同一个 Agent 是一个不同的挑战。

一旦真实用户和外部服务参与其中，应用需要的不仅仅是能正常工作的代码。它需要可重复的部署、安全的配置、健康检查、监控、受控的更新，以及清晰的恢复流程。

本文是我的 MCP 系列的一部分。如果你对这个话题还不熟悉，可以先阅读我的第一篇文章：Model Context Protocol (MCP) Servers Explained: A Complete Beginner's Guide。

在本文中，我将概述一个实用的架构，用于将基于 Model Context Protocol（MCP）的 AI Agent 从本地开发环境部署到 Kubernetes。

这是一个生产架构蓝图。具体的实现将取决于应用所使用的 AI 提供商、MCP 服务器、云平台和安全要求。

什么是基于 MCP 的 AI Agent？

Model Context Protocol 为 AI 应用提供了一种标准化的方式来连接外部工具、服务和数据源。

一个基于 MCP 的 Agent 可能会与以下内容进行交互：

• 业务应用
• 自定义自动化工具

一个基础的实现在开发者的机器上可能运行得很好。但在生产环境中，每个依赖都引入了运维问题：

• 应用将如何部署？
• 凭据将存储在何处？
• 如何检测失败的请求？
• 服务能处理额外流量吗？
• 如何回滚损坏的发布？
• 当 MCP 服务器变得不可用时会发生什么？

这些是熟悉的 DevOps 和 Site Reliability Engineering 问题，应用于一种新类型的工作负载。

一个实用的交付流程可能如下所示：

Developer
    ↓
GitHub Repository
    ↓
GitHub Actions
    ↓
Container Registry
    ↓
Kubernetes Cluster
    ↓
MCP Servers and External Services
    ↓
Logs, Metrics, Traces, and Alerts

每个组件都有明确的责任：

• GitHub 存储应用代码和部署配置
• GitHub Actions 测试应用并构建容器镜像
• 容器注册表存储版本化的镜像
• Kubernetes 运行和扩展 Agent
• 密钥管理保护 API 密钥和凭据
• 可观测性工具提供对可靠性和性能的可见性

步骤 1：将 Agent 容器化

容器化为应用在开发、测试和生产环境中提供一致的运行时。

一个简单的基于 Python 的 Agent 可以使用以下 Dockerfile：

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

RUN useradd --create-home appuser
USER appuser

EXPOSE 8000

CMD ["python", "app.py"]

这个例子遵循了几个有用的实践：

• 使用轻量级基础镜像
• 在复制源代码之前安装依赖
• 以非 root 用户身份运行应用
• 仅公开所需的应用端口
• 将运行时配置保留在镜像外部

容器镜像不应包含 API 密钥、访问令牌或特定于环境的凭据。

步骤 2：将 Agent 部署到 Kubernetes

Kubernetes 提供了一致的方式来部署、重启、扩展和更新服务。

一个简化的部署可能如下所示：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-agent
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mcp-agent
  template:
    metadata:
      labels:
        app: mcp-agent
    spec:
      containers:
        - name: mcp-agent
          image: registry.example.com/mcp-agent:1.0.0
          ports:
            - containerPort: 8000
          envFrom:
            - secretRef:
                name: mcp-agent-secrets
          readinessProbe:
            httpGet:
              path: /ready
              port: 8000
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

这个配置引入了几个生产控制：

• 多个副本提高可用性
• 就绪探针防止流量到达未准备好的容器
• 存活探针允许 Kubernetes 重启不健康的容器
• 资源请求支持可靠的调度
• 资源限制降低了一个工作负载消耗过多集群容量的风险

这些值应该在观察应用实际资源使用情况后进行调整。

步骤 3：安全地管理密钥

AI Agent 可能需要模型提供商、MCP 服务器、数据库或外部 API 的凭据。

这些值永远不应该被提交到 Git 或嵌入到容器镜像中。

Kubernetes Secrets 提供了应用代码和敏感配置之间的基本分离。为了获得更强的生产安全性，集群可以与专门的密钥平台集成，例如：

• Google Cloud Secret Manager

访问应该遵循最小权限原则。Agent 应该仅接收它所需的权限，凭据应该有明确的轮换流程。

步骤 4：构建 CI/CD 管道

可靠的 CI/CD 管道应在部署前验证应用。

一个典型的管道可能包括：

• 单元测试和集成测试
• 依赖和容器安全扫描
• 容器镜像创建
• 使用唯一版本发布镜像
• 部署到非生产环境
• 健康检查和冒烟测试
• 带有批准控制的生产部署
• 验证失败时的自动回滚

一个简化的 GitHub Actions 工作流可能如下所示：

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Run tests
        run: |
          pip install -r requirements.txt
          pytest

      - name: Build container image
        run: |
          docker build -t mcp-agent:${{ github.sha }} .

生产管道应使用固定的 action 版本、受保护的环境、安全身份验证和不可变的镜像标签。

使用 Git 提交 SHA 作为镜像标签也使得更容易识别确切哪个代码版本正在运行。

步骤 5：添加可观测性

传统的基础设施指标很重要，但对于 AI Agent 来说还不够。

一个有用的可观测性策略应该同时覆盖平台和应用：

• CPU 和内存利用率
• 模型请求延迟
• MCP 工具执行时间
• 工具成功和失败率
• 外部 API 可用性
• 被速率限制拒绝的请求
• 每个请求的估计成本

结构化日志应包含以下字段：

• 请求或关联 ID

敏感的提示、凭据、个人信息和完整的模型响应不应该在没有适当控制的情况下写入日志。

分布式追踪可以帮助跟踪请求跨越：

User Request → Agent → Model Provider → MCP Server → External Service

当总响应时间取决于多个外部系统时，这变得特别有价值。

步骤 6：为故障设计

MCP 服务器或外部 API 最终会变得缓慢、不可用或受到速率限制。Agent 应该在不引起更广泛服务故障的情况下处理这些情况。

有用的可靠性控制包括：

• 带有指数退避的有限重试
• 优雅的回退响应
• 用于长运行任务的基于队列的处理
• Pod 中断预算
• 经过测试的回滚程序

重试应该谨慎使用。重复不安全或非幂等的操作可能会创建重复记录或多次触发相同的操作。

步骤 7：基于有意义的信号进行扩展

Kubernetes 可以水平扩展副本，但 CPU 使用率可能并不总是反映 AI 应用的真实负载。

根据架构，扩展决策可以考虑：

• 工具执行的数量
• 模型提供商速率限制

扩展 Agent 并不会自动扩展其依赖。更多数量的 Agent 副本可能会给数据库、MCP 服务器和第三方 API 施加额外的压力。

因此，容量规划应该考虑完整的请求路径。

安全考虑

生产 AI 系统引入的风险超出了常规应用安全的范围。

重要的控制包括：

• 对 Agent 的请求进行身份验证
• 授权每个 MCP 工具操作
• 限制服务之间的网络访问
• 为不同的工作负载使用不同的身份
• 扫描应用依赖和容器镜像
• 记录与安全相关的操作以供审计
• 防止不可信的输入绕过工具权限
• 避免通过提示、日志或错误消息暴露密钥

Agent 仅仅因为它能使用 MCP 工具就不应该获得广泛的基础设施或业务系统访问权限。每个操作仍然应该通过明确的身份验证和授权控制。

实用的生产检查清单

在发布基于 MCP 的 Agent 之前，请确认：

• 应用被打包为可重复的容器镜像
• 镜像被扫描并进行了版本控制
• 凭据被存储在代码库外
• 健康和就绪端点可用
• 资源请求和限制已配置
• 日志是结构化的且可搜索的
• 指标和告警同时覆盖平台和 MCP 行为
• 外部调用具有超时
• 重试是有限的且安全的
• 访问遵循最小权限原则
• 回滚程序已被测试
• 运维文档可用

结论

构建 AI Agent 演示了应用功能。将其投入生产演示了工程成熟度。

Docker 提供一致的运行时。Kubernetes 管理可用性和扩展性。CI/CD 启用受控的发布。可观测性展示系统如何表现。安全和可靠性控制确定服务是否可信任于真实环境。

MCP 可能引入了一个新的集成模型，但生产原则仍然是熟悉的：自动化交付、减少不必要的访问、观察每个依赖、预期故障，并使恢复成为设计的一部分。

你将如何在你的环境中方法扩展和监控基于 MCP 的 Agent？

如需进一步的行动，你可能会考虑屏蔽此人和/或报告滥用行为