发布背景：从 cagent 到 docker-agent
2026 年 10 月 7 日，Docker 以官方插件的形式发布了 docker-agent，一个用 Go 编写、Apache 2.0 许可的开源项目，定位是「AI Agent Builder and Runtime」。项目并非凭空出现：Docker 维护者在 Hacker News 讨论串中说明，它始于约两年前、内部名字叫「compose for agents」，此前的名字是 cagent——发布说明中的环境变量与部分 lint 规则里至今仍保留着旧名痕迹。正式发布当日同步释出 v1.149.0，项目发布当周登上 Hacker News 热榜（不同时间快照的得分数在 126 到 291 之间，社区热度口径以 Hacker News 页面为准）。
安装路径有三条：Docker Desktop 4.63 及以上版本预装该插件；独立环境可用 Homebrew 或 GitHub Releases 二进制；Windows 用户则经由 WSL 运行。项目官方文档称其目标是「创建和运行协作解决复杂问题的智能 AI 智能体，无需编写代码」——这句宣传语的关键词不是智能，而是无需编写代码。
值得注意的背景是，Docker 自己就是该项目的高强度用户：其贡献指南写明，docker-agent 团队构建 docker-agent 的方式就是运行 docker agent run ./golang_developer.yaml。用自研运行时撑起自研流程，这是一种比基准分数更实在的吃自家狗粮声明。
docker-agent 的赌注是：智能体的本质是打包问题，而打包问题 Docker 已经解决过一次。定义走 YAML，分发走 OCI 注册中心，运行走熟悉的 docker agent run——把智能体塞进开发者已有的工作流，而不是让他们再学一套平台。
声明式架构：一个 YAML 文件描述一个团队
docker-agent 的核心抽象极简：每个智能体是 YAML 文件里的一个块，包含模型、描述、指令与工具集四个要素。官方 README 的示例智能体使用 openai/gpt-5-mini，两行系统提示，加上一个经由 MCP 服务器提供的 DuckDuckGo 搜索工具——docker agent run agent.yaml 即可启动。
真正体现设计意图的是多智能体部分。一个 YAML 文件可以描述一个团队而非单个智能体：根智能体接收任务后，把子任务自动委派给更专业的子智能体，无需手写编排逻辑。这与多数智能体框架把编排写进 Python 或 TypeScript 代码的做法形成对照——docker-agent 把「接线」从代码移进了配置文件，智能体定义因此可以像基础设施即代码工件一样被版本管理、代码评审与共享。
| 组成要素 | YAML 中的角色 | 说明 |
|---|---|---|
| 模型 | 每个智能体块指定 provider/model | OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI 等，本地模型走 Docker Model Runner |
| 指令与描述 | 系统提示与智能体画像 | 描述用于委派时的任务匹配 |
| 工具集 | toolsets 列表 | 内置工具 + 任意 MCP 服务器（本地、远程或 Docker 容器） |
| 团队 | 同一文件的多个智能体块 | 根智能体自动向专业子智能体委派任务 |
模型无关是另一根支柱。README 列出的供应商覆盖主流闭源 API 与 Docker Model Runner 本地推理；clauday 的报道还提到一个容易忽略的工程细节——计费按 OpenAI 实际提供的服务档位而非请求档位计算，这种「诚实计费」只有在一天跑数千个智能体回合时才显得要紧。
工具与检索：MCP 生态加内置三件套
工具接入是 docker-agent 与容器生态咬合最紧的部分。任何 MCP 服务器都可以作为工具集挂载——本地进程、远程服务，或干脆以 Docker 容器形态运行；docker:duckduckgo 这样的引用写法可以直接接入 Docker 官方 MCP 目录。内置工具则覆盖智能体运行的常见刚需：think、todo、memory 三件套负责推理与状态，retrieval 层可插拔，BM25、embeddings、混合检索与重排序开箱即用。
发布前一周的版本迭代进一步补齐了工程面：v1.147 与 v1.148 加入了 hook 驱动的智能体路由、工具结果 50 KiB 上限（防止超大输出挤爆上下文压缩）以及 codemode 工具调用可见性；更早的 v1.145 则实现了跨 13 个 ACP 方法的 W3C traceparent 传播——分布式追踪开始成为智能体运行时的默认配置而非附加项。
OCI 分发：智能体成为注册中心里的一等公民
这是 docker-agent 最值得单独讨论的一步。因为智能体只是一个配置文件，它可以被 Git 版本管理，也可以被推送到任意 OCI 注册中心，再用 docker agent run myorg/agent:tag 从注册中心拉取运行——命令语法与 docker run 完全同构。
这个设计的含义超出便利性范畴。对已经在用 Docker 跑全部服务的团队来说，智能体从此与其调用的服务共享同一个注册中心、同一套 CLI、同一条构建与分发链路——运维心智模型不必为智能体另开一套。AI Weekly 的编辑评论把这一步概括为：Docker 在争夺让容器注册中心成为智能体分发层的地位，而不只是镜像分发层；对独立智能体运行时厂商而言，一个 Apache 许可、随每次 Docker Desktop 安装免费落地的竞争者已经进场。
当然，OCI 里推的仍是智能体的定义而非运行实例——模型密钥、工具可达性、沙箱环境依然是运行时问题。镜像化的智能体降低了「定义漂移」的风险（谁跑都是同一个 YAML），但不解决「运行环境漂移」。把这两件事分开看，才不会高估 OCI 路线的覆盖面。
评测、沙箱与发布节奏
v1.149.0 的三项更新里，两项与评测体系直接相关：skills 条目现在可以直接填公开 GitHub 仓库的 URL，运行时自动加载技能；评估器默认经由模型网关路由，OpenAI Decisions 成为原生评估后端，另有独立评估服务作为 LLM-as-judge 的替代。clauday 的分析指出，Docker 是最早把决策模型端点接进打分链路的框架之一，且是在该能力公开测试上线一天之内完成的集成。
运行形态上，docker-agent 支持 sandbox 模式（本地虚拟机或云端），提供 serve api 与 serve acp 两种服务形态——后者让智能体可以嵌进编辑器工作流；GitHub Action 支持把同一个智能体放进 CI 管线。遥测与隐私设置则默认倾向保守。
发布节奏本身就是信号：reveneau 统计其最后五个版本落在十二天窗口内；截至 10 月 8 日的多份快照显示 GitHub 星数在 3477 到 3793 之间快速爬升（时点数据，仅作热度参考）。对开源基础设施项目而言，这种迭代密度既是活跃度的证明，也是稳定性风险的来源——企业采用时需要对版本锚定策略有明确预期。
短板与适用边界
- 无质量基准：官方与第三方均未发布任何任务质量基准数据。资源占用、委派准确性、多智能体协作效率，全部没有可比较的数字——这与同期 LOOP 发布时自报内存对比数据（且已声明非质量测试）形成反差，docker-agent 连这个维度都没有给。
- 并非容器隔离的运行时：默认情况下智能体以普通进程运行，除非显式启用 sandbox 模式。把 docker-agent 理解为「智能体自动获得容器隔离」是常见误读。
- Windows 依赖 WSL：官方支持矩阵为 macOS 与 Linux，Windows 经由 WSL 路由——对纯 Windows 环境的企业是个前置成本。
- 声明式的表达力边界：YAML 适合描述「接线」，复杂控制流仍需下沉到工具与提示层。当编排逻辑超出声明式表达力时，团队要么拆分智能体，要么回到代码框架。
- 早期项目风险：v1.x 阶段、发布节奏极快，API 稳定性与长期维护承诺有待观察；旧名 cagent 的残留痕迹也提示迁移期的命名混乱可能。
路线对照与观察点
| 维度 | docker-agent | 代码框架（LangGraph 等） | 托管平台（云厂商智能体服务） |
|---|---|---|---|
| 定义方式 | YAML 声明式 | Python/TS 代码 | 控制台/API 配置 |
| 分发载体 | OCI 注册中心 | 代码仓库/包管理器 | 平台内市场 |
| 运维心智 | 复用容器工作流 | 需另建工程体系 | 托管但锁定 |
| 模型绑定 | 无关，含本地 Model Runner | 无关 | 常绑定自家模型 |
| 隔离能力 | sandbox 模式可选 | 自建 | 平台托管 |
| 质量基准 | 无 | 视项目而定 | 部分厂商自报 |
把 docker-agent 放回本站的分析脉络：R-TECH-17 提出的 Harness 工程范式把沙箱、权限、压缩、观测、状态列为运行层五原语；R-TECH-32 覆盖的 LOOP 则押注 Rust 单二进制与主权部署。docker-agent 的差异点在于分发——前两者解决「智能体怎么跑得好」，它解决「智能体怎么送得到」。三条路线并不互斥：一个团队完全可以在 OCI 里分发 docker-agent 定义、在虚拟机沙箱里跑敏感任务、用观测钩子接自己的监控栈。
三个值得跟踪的观察点：其一，OCI 智能体分发是否形成跨工具的事实标准——其他运行时若接受同一种 YAML/OCI 约定，这条路线的护城河会显著加深；其二，评测体系（网关路由 + OpenAI Decisions 后端）是否会沉淀出可公开比较的智能体质量数据；其三，Docker 是否会把 Agent 与 Model Runner、Sandbox 打成一条端到端产品线——那将意味着智能体基础设施的进一步「容器化收敛」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。