最近在测试 AI Coding Agent 进入团队研发流程时，我发现真正容易卡住的地方并不是模型回答，而是工具链环境。
一个 Agent 想完成"读仓库、跑测试、打开浏览器、查数据库、看 K8s 日志"这些任务，背后通常需要 MCP Server、浏览器自动化、Node/Python 运行时、数据库客户端、K8s CLI 和容器沙箱。
如果这些工具来自不同镜像源，开发机、CI runner、K8s 节点又没有统一预检，就很容易在第一步卡住：
bash
docker compose pull常见错误：
text
TLS handshake timeout
context deadline exceeded
ImagePullBackOff
unauthorized本文记录一套 AI Coding Agent 工具链部署前的检查方法，重点覆盖 MCP Server、Docker MCP Gateway、镜像预检和常见错误定位。
1. 环境目标
本次目标不是搭一个完整生产平台，而是准备一个可复现的 Agent 工具链环境。
| 组件 | 用途 |
|---|---|
| Agent Runtime | 接收任务、调工具、执行计划 |
| MCP Server | 暴露 Git、数据库、浏览器、文件系统等工具 |
| Docker MCP Gateway | 管理和路由 MCP 工具服务 |
| Browser Tool | 页面复现、截图、E2E 验证 |
| CI Runner | 运行 lint、test、build |
| K8s 工具 | 查询 Pod、事件、日志和配置 |
核心要求：
- 开发机能复现。
- CI runner 能拉取工具镜像。
- K8s 节点能启动工具容器。
- 工具权限可控。
- 失败时能定位是镜像、网络、权限还是业务配置。
2. 先拆镜像来源
Agent 工具链里最容易被忽略的是镜像来源。
常见来源包括：
| 来源 | 典型组件 |
|---|---|
| Docker Hub | Node、Python、Nginx、Redis |
| GHCR | GitHub 生态工具、部分 MCP Server |
| MCR | Playwright、浏览器自动化相关镜像 |
| K8s Registry | pause、部分基础组件 |
| Quay | Prometheus、监控组件 |
不要只测一个 hello-world 或 nginx:alpine。工具链里只要有一个镜像来自不同上游，docker compose pull 就可能失败。
3. 镜像预检命令
企业环境里，我会先把常用工具镜像分组预检：
bash
docker pull docker.1ms.run/node:20-alpine
docker pull docker.1ms.run/python:3.11-slim
docker pull ghcr.1ms.run/github/github-mcp-server
docker pull mcr.1ms.run/playwright/mcp
docker pull k8s.1ms.run/pause:3.10这里的重点不是"用了哪个命令"，而是按上游来源分组。Docker Hub、GHCR、MCR、K8s 不是同一个问题。
如果团队使用毫秒镜像（1ms.run），可以把它作为多源镜像入口的预检层。它不替代 MCP Server，也不替代权限治理，只解决工具链镜像进入环境这一层的问题。
4. docker-compose.yml 示例
下面是一个简化示例：
yaml
services:
agent-tools:
image: docker.1ms.run/node:20-alpine
working_dir: /workspace
volumes:
- ./workspace:/workspace:ro
command: ["node", "--version"]
browser-mcp:
image: mcr.1ms.run/playwright/mcp
ports:
- "8931:8931"
github-mcp:
image: ghcr.1ms.run/github/github-mcp-server
environment:
- GITHUB_TOKEN=${GITHUB_TOKEN}启动前先校验配置：
bash
docker compose config
docker compose pull
docker compose up -d如果 docker compose pull 失败，不要直接改业务配置，先逐个拉镜像：
bash
docker pull docker.1ms.run/node:20-alpine
docker pull mcr.1ms.run/playwright/mcp
docker pull ghcr.1ms.run/github/github-mcp-server5. K8s 上的预检
如果工具链要进入 K8s，先看事件：
bash
kubectl describe pod <pod-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp常见问题：
| 现象 | 优先排查 |
|---|---|
ImagePullBackOff |
镜像地址、节点网络、镜像权限 |
ErrImagePull |
上游源、tag、认证 |
CrashLoopBackOff |
工具启动参数、环境变量、权限 |
Unauthorized |
私有镜像或 token |
context deadline exceeded |
网络超时或镜像层过大 |
Pod 示例：
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: browser-mcp
spec:
replicas: 1
selector:
matchLabels:
app: browser-mcp
template:
metadata:
labels:
app: browser-mcp
spec:
containers:
- name: browser-mcp
image: mcr.1ms.run/playwright/mcp
ports:
- containerPort: 89316. 权限边界
Agent 工具链能跑起来以后，下一步是权限。
建议默认从只读开始：
| 工具 | 默认权限 |
|---|---|
| Git 仓库 | 只读，必要时开 PR 权限 |
| 数据库 | 只读账号，脱敏样例库优先 |
| 浏览器 | 测试环境域名白名单 |
| K8s | 只读 namespace、日志和事件 |
| 文件系统 | 工作区目录，禁止访问宿主机敏感路径 |
这部分不建议后补。权限边界越早写清楚，团队越敢把 Agent 接入真实流程。
7. 日志与回滚
建议至少记录：
- Agent 调用了哪个工具。
- 工具镜像版本。
- MCP Server 启动参数。
- 输入输出摘要。
- 失败日志。
- 变更记录。
工具镜像也要固定 tag，避免今天能跑、明天变成另一个版本：
yaml
image: mcr.1ms.run/playwright/mcp:stable如果团队内部有制品仓库，可以把验证过的工具镜像同步进去，再统一从内部仓库发布。
8. 常见问题
只配置 Docker mirror 为什么还会拉取失败？
因为工具链可能不只来自 Docker Hub。GHCR、MCR、K8s、Quay 需要按来源分别处理。
MCP Server 能启动，Agent 还是调用失败怎么办？
先看 MCP Server 日志，再看工具权限、网络白名单、token 是否注入。
浏览器自动化镜像为什么最容易慢？
浏览器镜像通常较大，镜像层多，CI 或云服务器上更容易遇到超时。
K8s 里怎么看是镜像问题还是启动问题？
先看 Pod 事件。如果还没拉到镜像，就是拉取问题；如果已经 Started 后重启，才看启动参数和应用日志。
9. 总结
AI Coding Agent 进入团队，不只是"模型接进来"。
真正要准备的是：
- MCP Server 工具链。
- Docker / K8s 运行环境。
- 多源镜像预检。
- 工具权限边界。
- 日志和回滚。
工具链镜像能稳定进入环境，是 Agent 真正开始工作的第一步。