资讯 · 改写稿
把 Agent 写成 YAML：Docker Agent 的声明式做法
结论先给：Docker Agent 把 Agent 的定义从代码里挪到 YAML 里——模型、指令、工具写成配置，一条命令跑起来，也能像镜像一样打包分享。声明式的好处是可版本化、可复用。
来源（Docker 的 docker-agent 仓库）是这样介绍自己的：用声明式 YAML 配置来构建、运行和分享 AI Agent，自带工具生态与多 Agent 编排，而且不需要写代码。它是一个 docker CLI 插件，用 docker agent 调用。
一个 Agent 长什么样
来源给出的示例很直白：在 YAML 里给一个 root 节点指定模型、说明和指令，再挂上一组工具（示例里是一个 MCP 工具），然后用 docker agent run agent.yaml 跑起来。也就是说，「这个 Agent 用什么模型、能干什么」这件事，从代码里挪到了配置里。
它提供的能力
- 多 Agent 架构：可以组建多个专职 Agent，让它们自动分派任务；
- 工具生态：内置工具，并支持任意 MCP 服务器（本地、远程或跑在 Docker 里）；
- 模型无关：来源列出的提供方包括 OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI 以及 Docker Model Runner 等；
- YAML 配置：可声明、可版本化、可分享；
- 内置推理工具：think、todo、memory；
- RAG：可插拔检索，支持 BM25、向量、混合检索与重排；
- 打包分享：可以把 Agent 推到任意 OCI 仓库。
本站实测——这套「一份声明式配置 + 一条命令跑完」的思路，本站的发布流水线也在用：全部发布动作收敛在一条 publish.sh 里，它会依次跑派生文件一致性、内容口径、结构骨架、部署前安全预检等门禁，全过才提交并部署。差别在于：本站的配置是脚本里的清单，Docker Agent 把它换成了可以单独分享的 YAML。
值得注意的一点
把 Agent 定义成 YAML 之后，它就和「代码」一样进入了版本管理：改了什么、谁改的、能不能回滚，都有据可查。来源还允许把 Agent 推到 OCI 仓库，等于把「一个能跑的 Agent」当成制品来分发——这是它和「把提示词散落在各个脚本里」最本质的区别。
声明式带来的两个直接好处
把 Agent 写成配置，最实际的好处是可审阅与可回滚：一份 YAML 摆在仓库里，谁改了模型、谁加了工具，diff 一眼可见；出问题直接回到上一个版本，不用在代码里翻找散落的提示词。其次是可复用——同一份配置换个模型或换个工具就能当新 Agent 用，也方便在团队之间分享。
把 Agent 定义散在代码里：改一处提示词要翻好几个文件，也没法 diff。
忽略工具来源：MCP 服务器可以是本地、远程或容器内的，权限边界要分清。
只看「不用写代码」：YAML 也是配置，写错了照样跑不起来。
自检清单
常见问题
Docker Agent 是什么？
来源称它是一个 docker CLI 插件：用声明式 YAML 配置来构建、运行和分享 AI Agent，支持多 Agent 编排与工具生态，并可用 docker agent 命令调用。
它支持哪些模型和工具？
来源称它模型无关，列出 OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI 与 Docker Model Runner 等；工具方面内置一批，并支持任意 MCP 服务器。
为什么用 YAML 而不是代码？
来源强调配置可声明、可版本化、可分享；把 Agent 定义从代码里挪到配置里，改动能被记录和复用。
它还能做什么？
来源称支持内置 think/todo/memory 工具、可插拔的 RAG（BM25、向量、混合检索与重排），并能把 Agent 推到任意 OCI 仓库分享。
来源参考
以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。
下一步：Agent 之间怎么分工，读 Agent 配置同步；给 Agent 划权限边界，见 执行容器。