架构设计 on Jiangwan's Blog

容器化替代方案：Docker 与 Podman 核心架构差异分析

Thu, 02 Apr 2026 00:00:00 +0000

一、背景

　　在近期的开发学习与实践中，我发现无论是做常规的后端开发，还是目前正在探索的 Agent 应用开发，复杂的环境隔离与部署都是绕不开的环节。容器化技术作为现代软件开发的基础设施，其重要性不言而喻。

　　提到容器化，绝大多数开发者的第一反应必然是 Docker。Docker 确实凭借其优秀的生态定义了现代容器的标准工作流。但在长期的企业级应用中，其底层架构设计也暴露出了一些难以规避的安全与稳定性痛点。这也正是近年来由 Red Hat 主导开发的 Podman 开始频繁进入开发者视野，并被视为最佳替代品的原因。

二、核心架构差异

1. 运行机制

　　Docker 采用的是一种强中心化的守护进程架构。我们在终端敲下的所有命令，都会发送给一个常驻后台的守护进程来进行统一调度与执行。这种设计的隐患在于单点故障风险。如果该守护进程意外崩溃或进行版本升级，它所接管的所有运行中的容器进程都会受到波及。

　　Podman 则采用了无守护进程架构。在执行容器启动命令时，Podman 会直接启动一个独立的容器进程作为当前命令的子进程。这种设计去除了中心化的管理节点，各个容器之间相互独立。一个容器的异常终止不会影响其他容器，更符合操作系统原生进程的管理逻辑，显著提升了系统的整体稳定性。

2. 权限与安全

　　Docker 的中心守护进程默认需要宿主机的最高权限才能正常运作。这意味着所有容器实际上是在最高权限下被调度的。一旦发生容器逃逸漏洞，恶意攻击者极有可能顺藤摸瓜，直接获取宿主机服务器的控制权，这在生产环境中是极其危险的。

　　Podman 在设计之初就将安全性作为核心考量，默认支持非特权模式。开发者完全可以使用普通系统用户的身份去运行容器。即使容器内部被攻破，攻击者能获取的最高权限也仅仅局限于该普通用户，无法对宿主机系统造成毁灭性打击，极大收窄了安全攻击面。

3. 镜像标准兼容性

　　虽然两者的底层架构截然不同，但在日常使用中却能做到高度互通。这得益于开放容器倡议（OCI）标准的约束。Docker 与 Podman 均严格遵守该规范，因此它们构建的镜像文件在数据结构上是完全一致的。我们在 Docker Hub 上拉取的绝大多数镜像，都可以无缝切换到 Podman 中直接运行，这为技术栈的平滑迁移提供了底层保障。

三、日常开发与迁移体验

1. 命令行平滑过渡

　　为了降低用户的迁移成本，Podman 在命令行接口设计上刻意保持了与 Docker 的高度一致。在绝大多数日常操作中，开发者甚至可以在系统配置文件中设置别名，直接用现有的操作习惯来驱动 Podman。基本操作如镜像拉取、容器启动与日志查看，体验上没有任何割裂感。

2. 容器编排工具差异

　　在多容器编排场景下，Docker 深度绑定了自家的 Docker Compose 工具。而 Podman 则提供了 Podman Compose 作为对等替代方案。需要注意的是，虽然两者在基础的编排文件语法上兼容，但在处理某些复杂的网络自定义和存储卷挂载逻辑时，Podman Compose 可能会出现部分行为不一致的情况。在迁移复杂编排项目时，需要进行针对性的测试。

四、选型建议

1. 继续使用 Docker 的场景

　　对于强依赖 Windows 或 macOS 图形化界面的开发者，Docker Desktop 依然提供了目前最完善的一体化开发体验。如果团队的现有项目深度依赖 Docker Swarm，或者使用了极其复杂的 Docker Compose 编排脚本，为了保证业务的绝对稳定，暂时留在 Docker 生态是更务实的选择。

2. 推荐切换 Podman 的场景

　　如果项目主要运行在 Linux 服务器环境，且对系统安全性有严格的合规要求，Podman 的非特权模式是毋庸置疑的首选。此外，在构建 CI/CD 自动化流水线时，Podman 的无守护进程特性可以避免流水线节点上的权限冲突问题，更适合现代的云原生部署流程。

五、总结

　　技术选型本质上是权衡的艺术。Docker 依然是极其优秀的容器化启蒙与开发工具，但 Podman 通过架构层面的革新，确实解决了容器运行时的许多顽疾。作为开发者，理解它们底层的差异，根据具体的业务场景、安全需求以及部署环境来灵活选择，才是掌握这两项技术的正确姿态。

Agent 基础设施演进：Tools、Skills 与 MCP 的工程边界

Wed, 01 Apr 2026 00:00:00 +0000

　　2025 到 2026 年的 Agent 开发历程，最显著的变化是底层基础设施从碎片化走向收敛。在早期，开发者通常直接使用模型厂商提供的 Function Calling 接口。这种模式导致了 M×N 的集成困境：如果系统接入了 M 个不同的大模型，同时需要使用 N 种外部能力，开发者就需要编写大量重复的胶水代码进行格式转换与适配。

　　随着 Agent 应用向深水区演进，系统需要解耦模型本身与外部执行逻辑，标准化协议与能力分层成为架构演进的必然结果。目前，现代 Agent 架构中主要沉淀了三个核心概念：Tools、Skills 与 MCP。厘清这三者的边界，是构建高可复用 Agent 系统的首要前提。

一、概念重塑：Tools、Skills 与 MCP 的边界

　　虽然这三个词语在日常交流中常被混用，但在工程实现上，它们处于完全不同的架构抽象层级。

1. Tools：原子执行单元

　　Tools 是系统中最底层的执行模块。它本质上是具体的代码函数，负责完成单一的、无状态的操作。

特征定义：Tools 只关心输入与输出，不包含任何复杂的业务决策机制。查询数据库、发送 HTTP 请求、读取本地文件均属于 Tools 的范畴。
设计原则：在设计 Tools 时，应当追求极致的单一职责与高内聚。一个合格的 Tool 应当具备明确的 Schema 定义，确保任何外部调用者都能准确识别其所需的参数列表与返回值格式。

2. Skills：场景化的业务编排

　　Skills 建立在 Tools 之上，是面向特定业务场景的能力封装。

特征定义：如果说 Tool 是“执行一条 SQL 语句”，那么 Skill 就是“分析上季度营收数据并生成报告”。Skill 内部通常组合了多个 Tools，并包含了特定的执行流控制、Prompt 模板或上下文状态管理。
价值体现：Skill 的核心价值在于降低大模型在复杂任务中的推理负担。将固定的业务逻辑下沉到 Skill 层执行，可以大幅减少 Token 消耗，并提高输出结果的确定性。

3. MCP：底层的标准化通信机制

　　MCP 全称 Model Context Protocol，它既不是工具也不是技能，而是一套标准化的通信规范。

核心作用：MCP 统一了 Agent 客户端与外部数据、工具服务端之间的双向交互协议。它规定了客户端应如何向服务端请求工具列表，以及服务端应如何将执行结果或上下文资源返回给客户端。
架构意义：引入 MCP 后，模型与工具之间实现了彻底的解耦。只要工具或技能封装为符合 MCP 规范的 Server，任何支持 MCP Client 的大模型或 Agent 框架都可以直接接入并使用，彻底消除了 M×N 的适配成本。

二、架构演进：从散装调用到标准协议

　　在现代的标准化架构下，一次完整的 Agent 任务执行链路呈现出清晰的分层特征。以下是基于 MCP 协议的系统协作架构图：

  sequenceDiagram
    participant LLM as Agent / LLM (MCP Client)
    participant Protocol as MCP 通信层
    participant Server as MCP Server
    participant Skill as Skill (业务编排)
    participant Tool as Tool (原子单元)
    participant API as 外部系统 (DB/API)

    LLM->>Protocol: 请求可用能力列表 (Discover)
    Protocol->>Server: 转发请求
    Server-->>Protocol: 返回 Skills 与 Tools 列表及 Schema
    Protocol-->>LLM: 同步给模型

    LLM->>Protocol: 决定调用特定 Skill (Call)
    Protocol->>Server: 传递 JSON 参数
    Server->>Skill: 触发业务流程
    Skill->>Tool: 按逻辑组合调用 Tool A
    Tool->>API: 执行底层交互 (如 SQL 查询)
    API-->>Tool: 返回原始数据
    Tool-->>Skill: 传递执行结果
    Skill->>Tool: 调用 Tool B (如数据清洗)
    Tool-->>Skill: 返回处理后数据
    Skill-->>Server: 汇总最终业务结果
    Server-->>Protocol: 按照 MCP 规范封装响应
    Protocol-->>LLM: 返回结果，供 LLM 继续推理

　　从上述链路可以看出，MCP Server 作为网关，屏蔽了后端所有复杂的业务实现。模型端（客户端）无需关心后端是简单的单体 Tool 还是复杂的串联 Skill，只需要按照统一的协议发送调用请求并等待标准响应即可。

三、实践思考

　　在实际开发中，理解概念只是第一步，更重要的是在工程实践中做出合理的选型。

1. 粒度划分：写 Tool 还是封装 Skill？

　　在系统构建初期，开发者容易倾向于把所有逻辑都写成巨大的单体 Tool，或者过度碎片化。合理的划分依据应基于“业务复用度”与“推理确定性”。

倾向于 Tool 的场景：当逻辑纯粹是数据获取或状态变更，且对各种上下文均适用时（如 send_email），应当保持其作为独立的 Tool。
倾向于 Skill 的场景：当某项任务需要固定的多步操作，且包含前置条件校验或数据中间态转换时（如 git_commit_and_push），应将其封装为 Skill。这不仅能减少大模型发生“幻觉”导致调用顺序错误的概率，也能提升系统的响应速度。

2. 接入 MCP 的工程折衷

引入成本：对于生命周期极短的单次脚本任务，强行引入 MCP 架构会增加不必要的网络通信开销与服务部署成本（如需要单独维护 MCP Server 进程）。
长期收益：但对于需要长期维护的个人知识库系统或跨应用调用的 Agent 矩阵，MCP 是不可或缺的基础设施。它保证了今天编写的业务能力，在明天切换底层大模型基座时，依然可以被无缝调用。

四、总结

　　从 2025 年到 2026 年初，Agent 技术栈完成了从“手写各类 API 适配器”到“基于标准协议构建基础设施”的蜕变。Tools 提供了手脚，Skills 沉淀了经验，而 MCP 则铺设了统一的轨道。理解并遵循这三者的架构边界，是我们在当下构建健壮、可扩展的 Agent 系统的必经之路。