Docker 官方开源 Docker Agent：一个 YAML 文件定义一个 Agent，像跑容器一样跑起来

昨天，Docker 把"容器工作流"完整复制到了 Agent 世界

10 月 8 日，一个叫 Docker Agent 的项目被提交到 Hacker News。10 月 9 日，它出现在 HN 首页，时间戳显示 "1 day ago"，290 points、133 条评论。同一天，dev.to 的技术 digest 也收录了它——一天之内，开发者社区两个最重要的信息源同时把它推到了台前。

这不是又一个 Agent 包装器。这是 Docker 官方开源的 docker CLI 插件：用声明式 YAML（agent.yaml）定义 Agent，官方口号只有三个词——"no code required"。

一句话概括它在干什么：把定义、运行、分发 Agent 的整套动作，做成和容器一模一样的工作流。docker agent run agent.yaml 跑本地的 Agent 定义，docker agent run myorg/agent:tag 拉远端 registry 上的 Agent——语法和你用了十年的 docker run 几乎没有区别。对已经装了 Docker 的开发者来说，学习成本约等于零。

而这篇文章想说的是另一件事：Docker Agent 最重要的不是功能列表，是它第一次给了 Agent 世界一个像容器一样的"打包格式"。复现、分享、部署三位一体——这正是 2013 年容器解决的问题，也是 Agent 折腾了两年多一直没解决的问题。

它是什么：docker CLI 的官方插件

先把定位说清楚。Docker Agent 不是 Docker 投资的某个外部项目，也不是社区插件——它是 Docker 官方仓库（docker/docker-agent）里的 docker CLI 插件，Apache-2.0 协议开源。Docker Desktop 4.63 及以上版本直接预装，docker agent 开箱即用；不用 Desktop 的人也可以走 Homebrew 安装。

"官方插件"这四个字分量很重。过去两年 Agent 工具的典型剧本是：创业公司先做一个私有格式的 Agent 定义，攒用户，融一轮，然后被更大的平台收购或慢慢沉寂。Docker 反其道而行之：直接把 Agent 定义做成开放的 YAML，把"定义层"变成公共基础设施——这姿态不像是在做一个产品，更像是在铺一条赛道。

核心交互简单到有点反常识：写一个 agent.yaml，描述这个 Agent 是谁、用什么模型、能调哪些工具；然后 docker agent run agent.yaml，它就跑起来了。不需要写胶水代码，不需要搭服务框架，不需要理解 Agent 循环是怎么转的。YAML 即 Agent。

技术解剖：模型无关、MCP 原生、RAG 四件套

功能列表本身没有太多"黑科技"，但组合方式很老练——每一项都踩在 2026 年 Agent 工程的共识上：

• 模型无关。支持 OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI，外加 Docker 自己的 Model Runner，一共七家。换模型提供商不需要重写 Agent，只需要在 YAML 里改个配置。在模型价格和能力每个季度洗牌一次的今天，这个设计不是"功能"，是"生存策略"。
• 工具走原生 MCP。本地 MCP 服务器、远程 MCP 服务器、基于 Docker 的 MCP 服务器都能直接接。这是 2026 年最正确的押注之一：MCP 已经是 Agent 工具的事实标准，Docker 没有自己发明一套工具协议，而是直接站到了标准这一边。
• 内置 think、todo、memory 三个工具。Agent 的思考、任务拆解和记忆，不需要你自己从零实现。这三件套恰好是"能干活的 Agent"和"只会聊天的机器人"之间的分水岭。
• RAG 四件套一次给全：BM25、embeddings、混合检索、reranking。做过知识库 Agent 的人都知道，检索这块的坑最多，而 Docker Agent 把几种主流路线都做成了可选项，而不是替你做决定。
• 多 Agent 编排。README 里的原话是 "specialized agents that delegate tasks automatically"——专业分工的 Agent 之间自动委派任务。注意"自动"两个字：不是让你手写 DAG 编排，而是 Agent 自己判断某件事该交给更专业的 Agent，主动转交出去。

单看每一条，都不算首创；但把它们装进一个 docker agent run 里，意义就变了：过去搭一个能用的 Agent 是一项工程，现在它变成了一次配置。

最狠的一招：Agent 像镜像一样 push 和 pull

如果只说 YAML 定义和 docker agent run，Docker Agent 只是"又一个好用的 Agent 运行器"。真正让它和其他 Agent 工具拉开差距的，是这一句：Agent 可以 push/pull 到任意 OCI registry，像分发镜像一样分发。

做过 Docker 的人秒懂这意味着什么。容器世界的工作流和 Agent 世界的工作流，现在可以一一对应：

容器世界	Agent 世界（Docker Agent）
Dockerfile	agent.yaml
docker run nginx	docker agent run agent.yaml
docker pull myorg/app:tag	docker agent run myorg/agent:tag
docker push 到 registry	Agent push 到任意 OCI registry
Docker Hub / 私有 registry	任意 OCI registry（现成的全球分发网络）

这张表的每一行都是降维打击。想想看 Agent 分享在今天是什么样子：复制一段 prompt，贴到聊天框里，祈祷对面的人模型版本和你一样、工具配置和你一样。而 Docker Agent 的世界里，分享一个 Agent 是 docker agent run myorg/agent:tag——版本 pin 住，依赖（模型、MCP 工具、知识库配置）写在 YAML 里，拉下来就能跑。复现、分享、部署，三位一体，一次解决。

更深一层：agent.yaml 是文本文件，可以进 git，可以走 PR 评审，可以打 tag 做版本管理。以后"改 Agent 的行为"这件事，会变成提一个 PR，diff 里清清楚楚写着改了哪个工具的权限、换了哪个模型。评审 Agent 的改动，会像评审 Dockerfile 一样自然。这是 Agent 从"炼金术"走向"工程"的关键一步：一切可变的东西，都变成了可评审的制品。

为什么说这是"Agent 工程化"的标志性事件

先泼一盆理性的水：Agent 赛道在 2026 年已经挤到爆，几乎每周都有新的 Agent 框架、新的编排工具。为什么偏偏 Docker 这次值得单独写一篇？三个判断：

第一，Agent 缺的从来不是更聪明的模型，是工程化。过去两年，Agent 的定义散落在各家的私有格式里：换工具等于重写，分享靠复制粘贴 prompt，部署靠"我本地能跑"。Docker 在 2013 年解决容器的，恰好是同一类问题——"在我机器上能跑"到"在任何机器上都能跑"。Docker Agent 是把那套答案，原样搬到了 Agent 世界。历史不会重复，但会押韵。

第二，Docker 真正的武器不是技术，是分发。Docker Desktop 4.63+ 预装，意味着 docker agent 对海量开发者是开箱即用的；OCI registry 是现成的全球分发网络，不需要再建一个"Agent Hub"。当所有人都在卷 Agent 本体的能力时，Docker 直接占住了"定义层 + 分发层"。这个位置一旦坐实，后面所有的 Agent 工具都得来兼容 agent.yaml，而不是反过来。

第三，Apache-2.0 + 官方身份，等于在押注 agent.yaml 成为事实标准。Docker 没有把 Agent 定义做成私有护城河，而是开源、宽松协议、OCI 标准 registry 全兼容。这是在复制 Docker 当年最成功的一招：用开放换生态，用生态定标准。当年是 Dockerfile 和镜像格式，这次是 agent.yaml 和 Agent 分发。

反直觉的细节：它不是跟风之作

看到"Docker 官方 10 月开源 Agent 工具"，第一反应可能是：容器巨头终于忍不住来蹭 Agent 热度了。但仓库数据讲了另一个故事：

指标	数据
仓库创建时间	2025-09-01
Commits	10,735
Releases	263
Stars	4,284
Forks	498
开源协议	Apache-2.0

这个仓库 2025 年 9 月 1 日就创建了——比这次 HN 爆火早了整整一年多。10,735 个 commits、263 个 releases，这不是"为开源而开源"的快闪项目，而是一个闷头干了一年多的工程。HN 上的 290 points 和 133 条评论，与其说是"一夜爆火"，不如说是"一年慢工终于被看见了"。

这个时间线很说明问题：2025 年 9 月，Agent 话题远没有今天这么拥挤，MCP 协议也还在早期。Docker 在那个时间点开工，说明它不是看到风口才追，而是提前一年就判断"Agent 需要容器式的工程化"。在 2026 年这个时间点回看，这个判断准得有点可怕。

冷思考：YAML 的边界在哪里

吹完也要泼冷水。有几个问题，是 Docker Agent 必须回答、而目前还没有答案的：

• 声明式 YAML 能走多远？简单的 Agent 用 YAML 描述很优雅，但当 Agent 的行为复杂到一定程度——条件分支、动态工具选择、长链条的状态机——声明式会不会变成新的天花板？"no code required"的反面，可能是"no complex behavior supported"。当然，Dockerfile 当年也被问过同样的问题（"声明式能表达多复杂的构建？"），后来的答案是多阶段构建、分层缓存这些工程机制。Docker Agent 会不会走出同样的路，值得盯着看。
• 多 Agent 自动委派的调试体验。"specialized agents that delegate tasks automatically"听起来很美好，但一个 Agent 把任务转交给另一个 Agent、再转交给第三个——出了问题找谁？调用链的可观测性，是多 Agent 系统公认的硬骨头，YAML 本身解决不了这个。
• 生态位的战争才刚刚开始。Claude Code、Codex 这类强绑定的专有 Agent 工具，和 Docker Agent 这种开放的"定义层"，走的是两条路。前者赌的是"最好的模型+最深的集成"，后者赌的是"最开放的格式+最广的分发"。两条路不互斥，但开发者的注意力是有限的。

不过换个角度想：这些问题恰恰说明 Docker Agent 选对了战场——值得被挑剔的，才是值得认真对待的基础设施。没人会去挑剔一个玩具的调试体验。

对一人团队意味着什么

最后说回 VibeFix 的读者最关心的问题：这东西和我有什么关系？

如果你是一个人维护一个 vibe coding 项目，Docker Agent 的意义非常具体。权限和工具面被声明式收敛了：Agent 能用什么工具、能调什么模型、记忆怎么存，全写在一个 YAML 文件里，一眼看完，不用再去翻散落在各处的配置和胶水代码。

Agent 的改动第一次可以走 PR 流程。agent.yaml 进 git 仓库，给 Agent 加个工具、换个模型、调个 prompt，就是一次普通的 commit 和 PR。Code review 顺手就把 Agent 的变更审了——这对一人团队是质变：以前"调 Agent"是玄学，现在它是工程变更，有 diff、有历史、有回滚。

一人团队也能玩多 Agent 协作了。以前多 Agent 是"团队级"的工程复杂度：编排、委派、状态同步，每一项都要写代码。现在是一个 YAML 文件里定义几个 specialized agents，让它们自动委派。一个人的团队，可以第一次拥有"一个 Agent 团队"。

从 Dockerfile 到 agent.yaml，Docker 花了十三年。但这一次它想做的事情，和十三年的那次一模一样：把一种混乱的、不可复现的东西，变成一种人人会用、人人可分发的标准件。上一次，它改变了软件分发；这一次，它想改变 Agent 分发。HN 首页的 290 个赞，是开发者们用投票告诉 Docker：这条路，我们跟。