Docker把AI Agent装进容器

Docker近日推出 Docker Agent，把AI Agent的定义、组装和运行纳入开发者已经熟悉的容器工作流。根据Docker公开的官方代码仓库，Docker Agent被定位为面向AI Agent的构建器与运行时，重点不是再造一个聊天机器人，而是让开发者以配置驱动的方式组织模型、工具、提示词和多个Agent，并将其接入Docker Compose、沙箱、MCP与模型运行环境。

**Docker Agent是一个用于构建和运行单Agent及多Agent系统的工具。**它试图解决的问题，是Agent原型容易搭、生产环境难落地：模型只是其中一环，真正进入业务后，还需要文件系统、网络、命令行、凭据、工具权限、状态管理和部署环境，而这些恰好都是Docker过去十多年一直在处理的问题。

截至2026年10月8日，Docker Agent仍处在快速演进阶段，官方仓库的代码、文档和行为都有继续调整的可能。开发者现在更应该把它视为Docker AI平台的一块基础拼图，而不是一个已经完全定型、能够包办所有Agent需求的企业级平台。

Docker做的不是Agent框架，而是Agent运行底座

**Docker Agent最值得关注的地方，是它把Agent当成一种需要被部署和治理的软件工作负载。**过去两年，LangGraph、CrewAI、AutoGen和各家Agents SDK主要在解决Agent如何思考、调用工具和相互协作；Docker更关心另一个问题：这些Agent究竟在哪里运行、能访问什么、出错后如何复现，以及从开发机搬到服务器时会不会变成另一套系统。

传统Agent项目通常由几类组件拼成：一个模型接口、一组工具函数、若干提示词、一个状态存储，再加上能执行Shell或读写文件的环境。原型阶段，这些东西可以全部塞进一个Python进程；进入生产后，权限边界、依赖冲突和运行环境差异会迅速暴露。

Docker Agent给出的方向可以概括为下面这条链路：

Agent定义
  ↓
模型 + 提示词 + 工具 + MCP服务
  ↓
Docker Agent运行时
  ↓
Docker Sandboxes / 容器权限边界
  ↓
Docker Compose编排
  ↓
本地、远程Docker Engine或云端环境

**这种设计的核心价值是环境一致性。**开发者在本地定义的Agent、工具服务和依赖，可以沿着现有Docker工作流进入测试与部署环境，不必在原型完成后重新设计一套运行系统。对于已经使用Dockerfile、镜像仓库、Compose和CI/CD的团队，这比引入一套完全独立的Agent基础设施更容易被接受。

不过，Docker Agent并不等于“给Agent套一个容器”。简单容器化只能隔离进程和依赖，而一个真正可控的Agent运行时还需要处理模型选择、工具发现、多Agent委派、执行审批、凭据注入、网络访问和生命周期管理。Docker正在尝试把这些能力组合到同一套产品叙事中。

Compose正在从“启动服务”变成“组装Agent团队”

**Docker Compose是用声明式文件定义和运行多容器应用的工具。**在传统项目中，Compose文件描述数据库、后端、缓存和消息队列；在Agent应用中，它还可以承担模型服务、MCP服务器、向量数据库、浏览器环境和沙箱等组件的装配工作。

Docker希望开发者继续使用熟悉的“声明依赖—启动服务—查看日志—停止环境”路径，而不是为Agent重新学习一套部署语言。一个研究型Agent可能需要网页抓取服务、文档解析器、模型推理端和结果数据库；一个编程Agent则可能需要Git仓库、终端、构建工具和隔离文件系统。Compose适合把这些组件明确列出来，并建立可复现的启动关系。

**Compose在Agent场景中的优势不是让模型变聪明，而是让系统变得可重复。**同一个Agent今天能在开发者电脑上完成任务，明天却因为服务器缺少浏览器依赖、系统包版本不同或工具端口变化而失败，这类问题本质上仍是环境管理问题，而不是推理能力问题。

Compose也不是大规模Agent调度器。它适合开发、测试以及结构相对清晰的服务组合，但当企业需要跨集群调度、弹性伸缩、队列削峰、长任务恢复和复杂租户隔离时，仍然需要Kubernetes、工作流引擎或专门的任务系统。Docker Agent降低的是Agent进入容器体系的门槛，并没有消灭生产编排本身的复杂度。

MCP解决工具连接，容器解决工具边界

**MCP，即Model Context Protocol，是一种让模型客户端以统一方式发现和调用外部工具、资源与提示模板的协议。**它减少了每个Agent都为GitHub、数据库、浏览器和内部系统单独编写适配层的工作，但MCP只解决了“如何连接”，没有自动解决“是否应该连接”和“允许做什么”。

Docker Agent与Docker的MCP Gateway、容器网络和沙箱能力组合后，意图形成两层控制：MCP负责统一工具接口，Docker负责限制工具运行环境。Agent可以知道某个工具存在，但工具是否能访问宿主机目录、内网地址或敏感凭据，仍应由运行时权限决定。

**这一区分对安全至关重要。**如果一个Agent能读取任意文件、执行任意Shell命令并访问所有网络资源，那么提示词注入就不再只是“回答错误”，而可能变成代码执行、凭据泄露或供应链污染。模型层面的安全提示无法替代操作系统与容器层面的硬边界。

Docker还在推动基于OCI思路的Agent权限规范，并将相关Sandbox Kit Spec带向CNCF。其方向是让Agent权限描述成为中立、可移植的基础规范，而不是锁定在某一家模型或Agent框架中。OCI是开放容器标准体系，Docker若能让Agent权限也具备类似镜像规范的可移植性，长期影响会比单独发布一个Agent框架更大。

Docker Agent、Gordon和Docker AI不是同一个东西

**Docker Agent是供开发者构建Agent应用的运行时，Gordon则是Docker面向容器工作流提供的官方AI助手。**两者都带有“Agent”属性，但产品角色不同：前者偏基础设施和开发平台，后者偏终端用户产品。

Gordon可以通过Docker Desktop侧边栏或终端中的docker ai使用，能够结合文件系统、Shell和Docker CLI处理容器化、排错及DevSecOps任务。它执行命令、修改文件或进行Docker操作前会展示动作并请求用户批准。Gordon曾在Docker Desktop 4.61中以测试状态更新，Docker后续资料则将4.74及以上版本列为可用范围，这也说明Docker的AI产品线仍在快速迭代。

Docker Model Runner是本地运行模型的组件，Docker Offload是把本地Docker体验连接到远程计算资源及GPU的能力，MCP Gateway是集中管理多个MCP服务器的统一入口，Docker Sandboxes则提供隔离执行环境。Docker Agent把这些组件串成Agent开发链路，但并不要求所有项目都只能使用Docker自家的模型服务。

| 产品或项目 | 核心定位 | 主要解决的问题 | 与Docker Agent的关系 | 成本结构 | |---|---|---|---|---| | Docker Agent | Agent构建器与运行时 | 定义、组合和执行单Agent或多Agent系统 | 核心运行层 | 工具本身以官方仓库发布；模型、GPU和云资源另计 | | Gordon | Docker工作流AI助手 | 容器化、排错、命令执行与Docker操作 | Docker自用Agent能力的产品化示例 | 随Docker Desktop版本与相关服务政策而定 | | Docker Compose | 声明式多服务编排 | 统一启动Agent、工具、存储和模型组件 | 应用装配与开发到部署的桥梁 | Compose软件无单独模型费用，基础设施另计 | | Docker Sandboxes | 隔离执行环境 | 限制Agent对文件、进程和系统资源的访问 | 提供执行边界 | 取决于本地或远程运行资源 | | MCP Gateway | MCP统一入口 | 集中连接和管理多个MCP服务器 | 提供工具控制面 | 外部服务费用独立计算 | | Model Runner | 本地模型运行 | 在Docker工作流中运行模型 | 可作为Agent的模型后端之一 | 本地硬件、电力及模型许可成本 | | Docker Offload | 远程Docker计算 | 在本地操作远程引擎和GPU | 为重计算Agent提供远程资源 | 远程算力费用另计 |

Docker与主流Agent框架并非完全正面竞争

**Docker Agent与LangGraph、CrewAI、AutoGen等项目存在交集，但竞争层级并不完全相同。**Agent框架通常把重点放在状态图、任务委派、角色协作和推理循环上；Docker的优势则在镜像、进程、网络、文件系统和交付链路。

| 方案 | 强项 | 主要抽象 | 部署与隔离能力 | 更适合的场景 | |---|---|---|---|---| | Docker Agent | 环境一致性、容器生态、工具隔离 | Agent配置与运行时 | 原生贴近容器、Compose和沙箱 | 已采用Docker、希望统一开发与生产环境的团队 | | LangGraph | 有状态流程、分支与人工介入 | 图与节点 | 通常需要另配容器和基础设施 | 复杂工作流、可恢复的长流程Agent | | CrewAI | 角色与任务协作 | Crew、Agent和Task | 依赖外部部署方案 | 快速搭建角色分工明确的多Agent原型 | | AutoGen | 多Agent对话与协作模式 | 会话Agent | 需要额外运行环境治理 | 研究和多Agent交互实验 | | OpenAI Agents SDK等厂商SDK | 与特定模型平台集成紧密 | Agent、工具调用、追踪 | 云端能力较完整，但平台耦合更强 | 主要使用单一模型厂商能力的应用 |

**Docker Agent真正的竞争对手可能不是某个Agent SDK，而是团队自己拼出的基础设施。**不少公司已经用Python框架加Kubernetes Job、队列、临时容器和权限系统实现Agent执行；Docker需要证明的是，一套更集成的开发体验能否减少这些胶水代码，同时又不牺牲可观察性和平台自由度。

Docker目前没有公开一组足以横向比较的标准性能数据，例如单次任务启动延迟、并发Agent数量、沙箱创建时间或相对裸进程的资源开销。因此，现阶段不宜用“性能领先”评价Docker Agent，它的卖点主要是工作流整合、可移植性和权限边界，而非某项推理跑分。

真正难点仍是状态、评估和权限设计

**Docker Agent能够规范运行环境，但无法自动解决Agent可靠性。**一个任务失败，可能是模型推理错误、工具返回异常、上下文过长、权限不足或外部服务超时；容器可以让失败更容易复现，却不能直接判断究竟哪一步在语义上出了错。

生产团队仍需要自行补齐至少五项能力：

1. **状态持久化。**长任务不能只依赖进程内存，重启后需要从检查点恢复。
2. **可观察性。**每次模型请求、工具调用、权限决策和文件变更都应留下可关联记录。
3. **评估体系。**Agent版本更新后，需要用固定任务集衡量成功率、成本、耗时和副作用。
4. **预算控制。**多Agent互相调用很容易放大Token消耗和工具执行次数，必须设置上限。
5. **最小权限。**浏览代码不等于允许提交代码，读取数据库也不等于允许执行写操作。

**Agent权限不能只用“允许”或“拒绝”两个按钮表达。**更实用的策略应区分只读与写入、一次性授权与持续授权、项目目录与宿主机目录、公开网络与企业内网，以及低风险命令与破坏性命令。Docker在容器、Seccomp、Capabilities、网络和挂载方面已有积累，但如何把这些底层机制转化为普通Agent开发者能理解的策略，仍是产品成败的关键。

对开发者而言，它什么时候有用

**Docker Agent最适合工具多、依赖重且需要隔离执行的Agent应用。**例如编程Agent需要克隆仓库、安装依赖和运行测试；数据Agent需要访问数据库、执行脚本并生成文件；运维Agent需要查看日志、调用Docker CLI但不能无限制接触宿主机。这些场景都比纯聊天应用更需要稳定的运行时边界。

以下三类团队可以优先试用：

• 已经把Docker和Compose作为默认开发环境，希望Agent沿用现有CI/CD链路的团队；
• 正在构建代码执行、浏览器自动化或数据处理Agent，需要限制文件和网络权限的团队；
• 同时使用本地模型、云端模型和多个MCP服务，希望减少环境配置差异的团队。

以下两类项目则没有必要为了追逐概念立即迁移：

• 只有一次模型调用和少量无状态工具的轻量应用，引入完整运行时可能增加复杂度；
• 已经在Kubernetes、工作流引擎和内部沙箱平台上建立成熟治理体系的大型团队，迁移收益需要单独测算。

Docker在争夺Agent时代的默认入口

**Docker Agent的战略意义大于它当前的功能完整度。**容器时代，Docker成功把“打包并运行软件”变成统一动作；Agent时代，它希望进一步把模型、工具、权限和执行环境也装进同一条工作流。

这条路线具备现实优势。Docker拥有庞大的开发者安装基础，Compose已经是很多项目的本地编排入口，镜像和容器也天然适合交付Agent工具环境。相比从零建立生态的Agent基础设施创业公司，Docker不需要重新教育开发者什么是镜像、挂载、端口和服务依赖。

这条路线也存在明显风险。Agent应用比传统Web服务更动态，模型可能在运行中选择不同工具、创建子任务并修改环境；如果Docker只是给现有Compose工作流增加几层配置，而没有提供足够好的状态管理、审计和评估能力，开发者最终仍会回到专门的Agent框架与云平台。

**我们的判断是，Docker Agent值得关注，但现在更像基础设施方向的占位，而不是Agent开发的终局答案。**它最有价值的部分不是多Agent对话，而是把Agent执行重新拉回软件工程常识：环境应该可复现，权限应该最小化，工具应该可治理，开发与生产不应该是两套系统。

如果Docker能够把Agent定义、OCI权限、Compose编排和沙箱运行真正做成稳定标准，它可能成为Agent时代的“默认运行层”；如果做不到，它也至少会迫使Agent框架更认真地处理部署和安全问题。无论哪种结果，Agent不再只是一个模型加几段提示词，而正在变成需要完整运行时支撑的软件系统。

参考来源

• Docker Agent官方GitHub仓库：Docker Agent的代码、说明文档与最新项目状态。
• Docker Agent Releases：用于查看版本发布记录、变更内容和可下载构建。
• Docker Agent Issues：用于跟踪已知问题、功能讨论与社区反馈。