测试机上执行：

docker compose pull

结果 agent-ui 和 metrics 一直停在 Pulling，最后报 context deadline exceeded。这时还没有进入 Agent 业务日志，问题发生在镜像拉取阶段。

拆 compose 文件后发现，组件来源很分散：Agent UI 来自 GHCR，Redis/PostgreSQL 来自 Docker Hub，Prometheus 来自 Quay，K8s 节点还要准备 pause 和 CoreDNS。GPU 场景还会多出 CUDA runtime。

这篇按实际排查顺序来：先列镜像清单，再替换为毫秒镜像域名，最后做 Docker Compose 和 K8s 节点验证。

一、先列镜像清单

组件	作用	部署前检查
Agent UI	调试入口	版本固定
MCP Server	工具服务	独立登记
Redis	缓存/队列	拉取验证
PostgreSQL	状态存储	数据卷和版本
Prometheus	指标观测	Quay 类镜像
pause/CoreDNS	K8s 基础组件	新节点预拉取
CUDA runtime	GPU 运行时	GPU 节点验证

先列这张表，是为了避免把所有失败都归到 Agent 配置上。容器都没拉齐时，业务日志没有太多参考价值。

二、统一替换为毫秒镜像域名

毫秒镜像（1ms.run）适合处理这种多源镜像场景。先在测试机上执行：

docker pull docker.1ms.run/redis:7-alpine
docker pull docker.1ms.run/postgres:16-alpine
docker pull ghcr.1ms.run/open-webui/open-webui:main
docker pull quay.1ms.run/prometheus/prometheus:latest
docker pull k8s.1ms.run/pause:3.9
docker pull nvcr.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04

这组命令用于验证机器是否能稳定拉取 Docker Hub、GHCR、Quay、K8s、NVIDIA 等来源的替代镜像。

三、改 Docker Compose

不要只在命令行临时替换。内测环境应该把镜像地址写进 compose 文件：

services:
  agent-ui:
    image: ghcr.1ms.run/open-webui/open-webui:main
    ports:
      - "3000:8080"
    depends_on:
      - redis
      - postgres

  redis:
    image: docker.1ms.run/redis:7-alpine

  postgres:
    image: docker.1ms.run/postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pg-data:/var/lib/postgresql/data

  metrics:
    image: quay.1ms.run/prometheus/prometheus:latest
    ports:
      - "9090:9090"

volumes:
  pg-data:

启动顺序：

docker compose pull
docker compose up -d

这样排查路径更清晰：pull 失败先处理镜像链路，up 失败再看服务配置。

四、K8s 节点预检

上 Kubernetes 前，先在节点上执行：

crictl pull k8s.1ms.run/pause:3.9
crictl pull k8s.1ms.run/coredns/coredns:v1.10.1
crictl pull ghcr.1ms.run/open-webui/open-webui:main
crictl pull quay.1ms.run/prometheus/prometheus:latest

如果有预拉取需求，可以用 DaemonSet 做基础验证：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: agent-image-prepull
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: agent-image-prepull
  template:
    metadata:
      labels:
        app: agent-image-prepull
    spec:
      initContainers:
        - name: pull-agent-ui
          image: ghcr.1ms.run/open-webui/open-webui:main
          command: ["sh", "-c", "echo pulled"]
        - name: pull-prometheus
          image: quay.1ms.run/prometheus/prometheus:latest
          command: ["sh", "-c", "echo pulled"]
      containers:
        - name: hold
          image: k8s.1ms.run/pause:3.9

生产环境要按节点池、镜像大小和发布节奏拆分，这里只展示排查方法。

五、为什么这和 Agent 安全运行时有关

MCP 和 Agent Sandbox 让工具调用更标准，也让运行时边界更重要。权限、网络、文件系统隔离都需要在稳定环境里验证。

如果镜像源不稳定，团队就会临时换版本、换源、跳过预检。环境不可复现时，安全策略也很难验证。

所以建议顺序是：

1. 列镜像清单；
2. 固定镜像版本；
3. 统一镜像入口；
4. 节点预拉取；
5. 再验证 MCP Server 权限和 Agent 行为。

小结

MCP Agent 内测前，先不要急着调 prompt。把镜像拉取链路跑通，能减少大量无效排查。

毫秒镜像适合放在这个步骤里，用 docker.1ms.run、ghcr.1ms.run、quay.1ms.run、k8s.1ms.run、nvcr.1ms.run 统一处理多源镜像。

公开资源：

• 毫秒镜像：https://1ms.run
• 1ms-helper：https://cnb.cool/mliev/1ms.run/1ms-helper