MCP 最近很热。
它让 AI Agent 可以用统一协议连接外部工具和数据源。以前 Agent 调工具常常是各写各的，现在 MCP 把工具调用抽象成一个更标准的方式。
但真正做工程时会发现，协议只是第一步。工具怎么运行、怎么隔离、怎么升级、怎么复现，才是落地时会不断遇到的问题。
Docker 推 MCP Catalog and Toolkit，就是在解决这个方向：把 MCP Server 容器化，让工具的发现、运行和隔离更标准。
这也意味着一个新问题会出现：AI Agent 的工具分发，会越来越像容器镜像分发。
一个 Agent 工具链会拉多少镜像
假设我们搭一个企业内部 Agent 平台，可能包含：
- Web UI；
- MCP Server；
- 浏览器自动化；
- 文档解析；
- 向量数据库；
- Redis / Postgres；
- 代码执行沙箱；
- Prometheus / Grafana；
- K8s 或 Docker Compose 编排。
这些组件里，很多来自不同 registry。
docker pull ghcr.1ms.run/open-webui/open-webui:main
docker pull docker.1ms.run/redis:7-alpine
docker pull docker.1ms.run/postgres:16-alpine
docker pull quay.1ms.run/prometheus/prometheus:latest
crictl pull k8s.1ms.run/pause:3.9
如果团队只处理 Docker Hub，GHCR、Quay、K8s 官方镜像仍然可能卡住。
为什么 MCP 更适合容器化
MCP Server 本质上是 Agent 可以调用的工具服务。
如果直接把工具安装到宿主机上，会遇到几个问题：
- 依赖冲突：不同工具需要不同版本的 Python、Node、系统库；
- 权限边界不清晰：工具可能访问文件、网络、数据库；
- 升级不可控：一个工具升级可能影响整个宿主机；
- 复现困难：本地能跑，服务器不一定能跑。
容器能把工具环境封装起来，降低这些问题。但容器化之后，镜像拉取就变成部署第一关。
用毫秒镜像统一处理 Agent 工具镜像
毫秒镜像（1ms.run）支持 Docker Hub、GHCR、GCR、K8s、Quay、NVIDIA、Microsoft、Elastic 等常见源，适合 Agent/MCP 工具链这种多源镜像场景。
Docker 可以配置：
{
"registry-mirrors": ["https://docker.1ms.run"]
}
也可以把镜像地址显式写进 Compose：
services:
webui:
image: ghcr.1ms.run/open-webui/open-webui:main
redis:
image: docker.1ms.run/redis:7-alpine
postgres:
image: docker.1ms.run/postgres:16-alpine
prometheus:
image: quay.1ms.run/prometheus/prometheus:latest
如果使用 K8s，节点初始化时先验证：
crictl pull k8s.1ms.run/pause:3.9
crictl pull k8s.1ms.run/coredns/coredns:v1.10.1
什么时候必须提前处理镜像
以下场景不建议临时拉镜像：
- Agent 平台要给多个团队共用；
- MCP 工具数量持续增加；
- 工具服务跑在 K8s 上；
- Runner 或节点经常扩容；
- 需要浏览器自动化、OCR、代码执行器等重依赖工具；
- 部署环境在国内服务器或边缘节点。
这些场景里，镜像源不稳定会让每次初始化都变成碰运气。
总结
MCP 解决了 Agent 如何连接工具的问题，Docker MCP 让工具容器化变得更自然。
但工具容器化以后，镜像分发会成为新的基础设施问题。对企业 Agent 平台来说，提前处理 Docker Hub、GHCR、Quay、K8s 等多源镜像，比部署时临时排查更可靠。
毫秒镜像适合放在这个位置：不改变 Agent 架构，只把工具链启动前的镜像拉取问题先稳定下来。
官网：1ms.run
开源工具：cnb.cool/mliev/1ms.r…
