解构Shippy：从动作、状态、后果模型到四大设计边界

1. 从“全拆”说起：为什么我们需要解构一个工具

最近在折腾一个叫 Shippy 的项目，这个名字听起来有点意思，像是和“运输”、“交付”有关。我拿到手的第一反应，不是急着去跑它的 Demo，而是想把它彻底“拆开”看看。这大概是我们这些老码农的职业病，看到一个封装好的工具，总想搞清楚它的内部构造、设计边界和潜在风险。毕竟，在项目里引入一个依赖，尤其是涉及构建、部署这类核心流程的工具，如果对其内部机制两眼一抹黑，那无异于给自己埋雷。

所以，这篇内容的核心，就是一次对 Shippy 的“全拆解”。这里的“拆”，不是物理破坏，而是逻辑上的解构。我会围绕标题里提到的“3个集合”和“4类边界”，一层层剥开它的设计。这“3个集合”指的是它的核心行为模型：动作、状态和后果。这听起来很抽象，但理解了这个模型，你就能明白 Shippy 是如何组织一次构建或部署任务的。而“4类边界”则定义了 Shippy 与外部世界交互的接口和限制，分别是：版本化行为、Typed API、CLI 和 Sandbox。这决定了你如何安全、可控地使用它。

为什么这种解构很重要？因为工具的价值不仅在于它能做什么，更在于它如何做，以及它的能力边界在哪里。直接看文档，你可能会知道“运行shippy deploy可以部署”，但你可能不知道它在背后创建了哪些临时资源、状态如何持久化、失败后如何回滚、以及它的插件机制会不会和你的现有流水线冲突。通过这次拆解，我希望你能获得的不只是 Shippy 的使用手册，而是一套分析类似工具的方法论。下次再遇到一个新的 DevOps 工具，你也能快速抓住它的设计核心，评估它是否适合你的技术栈和团队协作模式。

2. 核心行为模型：动作、状态与后果的三元组

任何自动化工具，尤其是像 Shippy 这样定位在“交付”领域的工具，其核心都是在管理一个有状态的过程。这个过程不是黑盒，我们可以将其清晰地拆解为三个相互关联的集合：动作（Action）、状态（State）和后果（Consequence）。理解这个三元组，是理解 Shippy 设计哲学的关键。

2.1 动作：触发状态变迁的原子操作

在 Shippy 的语境里，“动作”是最小的可执行单元。它不是一个模糊的“步骤”，而是一个定义明确、输入输出清晰、具有幂等性倾向的操作。例如：

• git.clone: 从仓库拉取代码。输入是仓库URL和分支，输出是本地工作目录。
• docker.build: 构建一个 Docker 镜像。输入是 Dockerfile 路径和构建参数，输出是镜像ID或标签。
• kubectl.apply: 向 Kubernetes 集群应用一个配置文件。输入是 YAML 文件内容，输出是创建或更新的资源列表。

这些动作通常对应一个具体的命令行工具或一个 SDK 的函数调用。Shippy 的设计精妙之处在于，它并不重新发明轮子去实现这些底层操作，而是将它们封装和标准化。它为每个动作定义了标准的接口：需要哪些参数（环境变量、文件）、产生哪些输出（标准输出、错误码、生成物路径）、以及预期的执行环境。这种封装使得“动作”成为了可组合、可替换的乐高积木。

注意：动作的幂等性是一个理想目标，但并非所有操作都能天然幂等。Shippy 框架层可能会通过一些机制（如检查点、状态判断）来辅助实现动作的“准幂等性”，这是评估其可靠性的一个重要维度。

2.2 状态：流程执行过程的快照

如果说动作是动词，那么状态就是名词。它代表了在某个时间点，整个交付流程所处的“位置”和“情况”。状态是分散的、多层次的：

1. 流程状态：整个 Pipeline 是成功、失败、运行中还是已暂停？当前执行到了哪个阶段（Stage）或哪个动作？
2. 环境状态：工作目录里有哪些文件？Docker 镜像是否已推送到仓库？Kubernetes 命名空间里现有的 Pod 是什么状态？
3. 数据状态：本次构建的版本号是多少？从上一个动作传递下来的元数据（如镜像标签、提交哈希）是什么？

Shippy 必须有能力感知、记录和追踪这些状态。这通常通过几种方式实现：

• 隐式状态：依赖于外部系统的状态，例如通过kubectl get pods来获取 Kubernetes 的实时状态。Shippy 需要调用查询动作来“感知”它。
• 显式状态：由 Shippy 自身维护的状态，例如一个内部的数据库或文件，记录当前 Pipeline 的执行进度和关键输出。这是实现断点续跑、状态查询和审计的基础。

状态的管理策略直接影响了系统的复杂度和可靠性。一个将所有状态都寄托于外部系统的 Shippy 实例会非常简单，但也非常脆弱，因为它无法在外部系统故障时知晓自己的进度。而一个维护了强一致内部状态的 Shippy，则要处理状态存储、同步和恢复等一系列分布式系统问题。

2.3 后果：动作执行后的外部影响与副作用

这是最容易被忽视，但也最危险的部分。“后果”是指一个动作执行后，对系统外部环境造成的、可能不可逆的改变。例如：

• docker.push动作的后果是：一个新的镜像被上传到远程仓库，覆盖了同标签的旧镜像。
• kubectl.apply动作的后果是：Kubernetes 集群中的实际资源被创建或更新，可能引发服务重启、IP 变更。
• 一个清理临时文件的动作，其后果是删除了磁盘上的数据。

后果是动作的“副作用”，但它正是我们使用自动化工具的目的——我们就是希望它去改变世界。然而，后果也带来了风险。因此，一个成熟的交付工具必须提供管理后果的能力：

• 后果的可观测性：Shippy 应该能清晰地报告每个动作产生了什么后果（例如：“已推送镜像myapp:v1.2.3至 registry.example.com”）。
• 后果的可控性：通过“Dry Run”模式，让用户预览动作可能产生的后果而不实际执行。
• 后果的可逆性（回滚）：提供机制来逆转某些动作的后果。但这非常复杂，因为不是所有后果都可逆（例如已发送的通知邮件）。Shippy 可能需要依赖动作本身提供的回滚能力，或维护一套反向操作指令。

三者的关系：一个动作的执行，会基于当前的状态，产生特定的后果，并推动系统进入一个新的状态。例如，当前状态是“代码已拉取”，执行docker.build动作，产生“生成了镜像文件”的后果，并进入“镜像已构建”的新状态。Shippy 的核心引擎，本质上就是在循环驱动这个“状态 -> 动作 -> 后果 -> 新状态”的变迁过程。

3. 第一类边界：版本化行为——稳定性的基石

当我们把 Shippy 集成到持续交付流水线中，最怕的就是“昨天还能跑，今天突然挂了”。而问题的根源，往往不是我们的代码，而是工具本身或其依赖的行为发生了意料之外的变化。这就是“版本化行为”边界要解决的问题。

3.1 什么是“行为版本化”？

它不仅仅指 Shippy 自身的版本号（如v1.5.0），而是指 Shippy 所封装的所有动作的底层行为，都需要有明确的、可追溯的版本约束。具体包括：

1. Shippy Core 版本：框架本身的 API、配置格式、状态机逻辑。
2. 动作实现版本：每个动作（如docker.build,aws.s3.sync）背后对应的具体工具或客户端版本。例如，docker.build动作依赖于 Docker CLI，那么是 Docker 20.10 还是 24.0 的行为？两者在构建参数、输出格式上可能有细微差别。
3. 运行时环境版本：执行动作的容器或沙箱内的系统库、语言运行时版本。

Shippy 如何管理这个边界？一个理想的设计是采用“声明式版本锁”。在你的项目配置文件（比如shippy.yaml）中，除了定义流程步骤，还应显式声明所依赖的行为版本：

apiVersion: shippy.dev/v1alpha2 kind: Pipeline metadata: name: my-app-deploy spec: runtime: shippyCore: "1.5.x" baseImage: "shippy/ubuntu-node-runner:2024-01" actions: - name: build-frontend uses: "action/npm-build@v3" with: nodeVersion: "18.18.x" - name: push-image uses: "action/docker-push@v2" with: dockerCLIVersion: "24.0.x"

通过这样的声明，无论 Shippy 主程序如何升级，只要它支持这套版本约束语法，它就应该保证在指定的版本环境下复现完全相同的动作行为。这本质上是将基础设施的“不可变部署”思想应用到了工具行为本身。

3.2 实践中的挑战与应对

然而，完美的版本化是困难的。你可能会遇到：

• 动作实现的向后兼容性破坏：一个动作的@v3版本修改了某个参数的语义，导致你的旧配置失败。这时，Shippy 应该提供清晰的错误信息，指出是哪个动作的哪个版本不兼容，而不是一个模糊的“执行失败”。
• 隐式依赖的版本漂移：你的动作运行在一个官方提供的ubuntu-runner镜像里，这个镜像每月更新。某次更新中，内置的git从 2.34 升级到了 2.40，而新版本的git对某些命令的输出格式做了调整，导致你依赖该输出格式的脚本解析失败。

应对策略：

• 锁定完整环境哈希：最严格的方式是不仅声明版本，更锁定具体的工作环境镜像的哈希值（如 Docker Image Digest）。这确保了二进制级别的完全一致。
• 依赖脆弱性权衡：完全锁定会导致无法自动获取安全更新。因此，Shippy 可能需要提供两套模式：一套用于“生产流水线”，严格锁定所有版本以保证绝对稳定；另一套用于“开发或测试流水线”，可以接受次要版本的自动更新，以便提前发现兼容性问题。
• 行为快照与回放：一些高级的 Shippy 实现可能会引入“行为快照”概念，不仅记录版本，还记录关键动作执行时的环境变量、文件树快照等，用于在独立环境中进行“回放”调试，精准定位是哪个环节的行为发生了变化。

4. 第二类边界：Typed API——契约优先的集成方式

CLI 适合人类交互，但当 Shippy 需要被其他系统（如你的 CI 平台、内部监控系统、审批系统）调用时，一个定义清晰、强类型的 API 就至关重要了。这就是“Typed API”边界。

4.1 超越 REST：类型安全的接口设计

Typed API 的核心思想是“契约优先”。在 Shippy 暴露任何 HTTP 端点之前，首先应该用一种接口定义语言（如 Protocol Buffers, GraphQL Schema, OpenAPI/Swagger）来定义它所能提供的所有服务、数据结构以及它们之间的关系。

例如，一个用于触发流水线的 API 可能被这样定义（使用 GraphQL 风格描述）：

type Mutation { triggerPipeline(input: TriggerPipelineInput!): PipelineExecution } input TriggerPipelineInput { pipelineRef: String! # 流水线标识 revision: String # 代码版本，如 git commit SHA parameters: [PipelineParameter!] # 覆盖参数 dryRun: Boolean = false } type PipelineExecution { id: ID! status: ExecutionStatus! createdAt: DateTime! steps: [ExecutionStep!]! } type ExecutionStep { name: String! action: String! state: StepState! startedAt: DateTime completedAt: DateTime logsUrl: String }

这样做的好处是巨大的：

1. 前后端解耦：API 提供者（Shippy）和消费者（其他系统）可以并行开发，只需基于这份契约。
2. 自动生成代码：可以从契约文件自动生成客户端 SDK（TypeScript、Go、Java 等），调用时享有完整的代码补全、类型检查和编译时错误提示，将许多运行时错误提前到编译期。
3. 自文档化：契约本身就是最新、最准确的 API 文档。任何字段的增减、类型的变化，都会在契约中体现，并强制影响所有消费者。
4. 版本管理清晰：API 的变更可以通过契约的版本（如shippy.api.v2alpha1）来管理，兼容性一目了然。

4.2 API 设计中的关键考量

在设计 Shippy 的 Typed API 时，有几个关键点需要仔细权衡：

• 同步 vs 异步：触发一个流水线执行，是应该立即返回执行结果（同步，适用于短任务），还是返回一个作业 ID 供后续查询（异步，适用于长任务）？Shippy 的 API 很可能需要同时支持两者，或者统一采用异步模式，通过 Webhook 或长轮询通知结果。
• 资源抽象层级：API 是直接暴露底层概念（如“动作”、“状态机”），还是提供更高阶的、业务相关的抽象（如“部署单”、“发布窗口”）？前者灵活，后者易用。一个成熟的 Shippy 可能需要提供多层 API。
• 认证与授权：API 调用如何认证（API Token, OAuth2）？如何授权（某个 Token 只能触发特定项目的流水线，或只能读不能写）？这需要与 Shippy 的整体权限模型深度集成。
• 可观测性端点：除了业务接口，Shippy 还应提供用于监控的健康检查端点（/healthz）、指标端点（/metrics， 暴露 Prometheus 格式的指标）和性能追踪集成（OpenTelemetry）。这些是 Shippy 作为生产级服务不可或缺的部分。

5. 第三类边界：CLI——开发者体验的第一线

对于大多数开发者而言，与 Shippy 交互的第一站甚至主要方式，就是命令行界面。一个设计良好的 CLI 能极大提升开发效率和幸福感，反之则让人望而却步。Shippy 的 CLI 设计需要在这几个方面下功夫：

5.1 符合直觉的命令结构与发现机制

命令的组织应该符合用户的心智模型。既然 Shippy 核心管理的是“流水线”或“交付任务”，那么命令树可以这样设计：

shippy # 根命令 ├── pipeline # 流水线管理 │ ├── ls # 列出可用流水线 │ ├── describe <name> # 查看流水线详情 │ ├── validate <file> # 验证配置文件 │ └── run <name> [flags] # 运行流水线 ├── execution # 执行实例管理 │ ├── ls # 列出历史执行 │ ├── logs <id> # 查看执行日志 │ ├── status <id> # 查看执行状态 │ └── stop <id> # 停止执行 ├── config # 配置管理 │ ├── view # 查看当前配置 │ └── set <key> <value> # 设置配置项 └── version # 版本信息

关键设计点：

• 子命令补全：通过shippy pipeline [TAB]能自动补全ls,describe等子命令。
• 上下文感知的帮助：shippy pipeline run --help应该展示针对该命令的详细参数说明，包括必选参数和示例。
• 一致性的标志：全局标志（如--config,--debug）和本地标志的命名、行为应保持一致。

5.2 丰富的输出格式与可编程性

CLI 的输出不仅要给人看，还要给机器读。

• 默认人性化输出：默认情况下，shippy execution ls可以输出一个格式美观的表格，包含 ID、状态、开始时间等。
• 支持结构化输出：通过-o或--output标志支持json,yaml,jsonpath等格式。例如shippy pipeline describe my-pipeline -o json，这便于其他脚本（如 Bash, Python）解析处理。
• 静默模式：-q或--quiet标志，只输出最核心的结果（如执行 ID），便于在脚本中赋值：EXECUTION_ID=$(shippy pipeline run my-pipeline -q)。

5.3 交互式体验与渐进式引导

对于复杂操作，CLI 可以提供交互式体验来降低认知负荷。

• 确认提示：对于删除、覆盖等危险操作，必须提供交互式确认提示（除非使用-f强制标志）。
• 参数引导：当运行shippy pipeline run而未指定必要参数时，可以进入交互式问答模式，逐步引导用户输入。
• 上下文配置：类似kubectl，Shippy 可以支持“上下文”，快速在不同项目、不同环境之间切换：shippy config use-context production。

5.4 错误信息的友好性与可操作性

这是 CLI 体验的“关键时刻”。一个糟糕的错误信息足以毁掉所有好感。

• 明确错误源：错误信息应明确指出是哪个组件、哪个步骤出了问题。对比“执行失败”和“动作 ‘docker.build’ 在步骤 ‘构建前端镜像’ 失败：Dockerfile 第 12 行语法错误”。
• 提供解决建议：在可能的情况下，给出下一步该做什么的建议。例如：“认证失败，请检查您的 SHIPPY_TOKEN 环境变量或运行shippy config login。”
• 关联文档：可以提供错误代码或指向详细故障排查文档的链接。
• 调试信息分级：在--debug模式下，输出详细的内部日志、网络请求和响应，便于深度排查。

6. 第四类边界：Sandbox——安全与隔离的生命线

这是 Shippy 设计中技术挑战最大、也最不容有失的部分。Shippy 要执行用户定义的、来自不可信来源（如 Git 仓库中的脚本）的动作。如果没有严格的沙箱隔离，一个恶意的或存在缺陷的构建脚本，就可能：

• 破坏宿主环境：删除服务器上的关键文件。
• 窃取敏感信息：读取其他项目的密钥、令牌。
• 发起网络攻击：以宿主机的身份对内网其他服务进行扫描或攻击。

因此，沙箱是 Shippy 安全模型的基石，它需要在多个层面建立隔离。

6.1 多层隔离策略

一个健壮的沙箱系统通常是多层防御的叠加：

1. 文件系统隔离：这是最基本的一层。每个动作（或整个流水线）应该在独立的、临时的目录中运行。这个目录是它的“根文件系统”，它无法访问该目录外的任何宿主文件。在 Linux 上，这可以通过chroot、pivot_root或命名空间（unshare）来实现。Shippy 需要确保工作目录的创建、绑定挂载（如需要访问缓存目录）和最终清理都正确无误。
2. 进程/网络隔离：动作运行的进程应该在自己的 PID 和网络命名空间里。这意味着它只能看到自己的子进程，并且拥有独立的网络栈（自己的 loopback 接口，独立的网络设备）。这可以防止动作窥探或杀死宿主上的其他进程，也限制了其网络访问能力（初始状态下可能只有 loopback）。Shippy 需要决定是否以及如何为动作提供网络访问（例如，通过一个白名单控制的代理）。
3. 资源限制：必须对动作可以使用的 CPU 时间、内存、进程数、文件描述符数量等进行硬性限制（通过cgroups）。防止一个失控的构建脚本耗尽整个服务器的资源，导致“吵闹的邻居”问题。
4. 用户权限隔离：动作进程不应该以 root 用户运行。Shippy 应该创建一个无特权的、唯一的用户 ID 和组 ID 来运行动作，并利用 Linux 的能力机制（Capabilities）进一步剥离其权限（例如，移除NET_RAW,SYS_ADMIN等危险能力）。

6.2 实现方式的选择与权衡

实现上述隔离，主要有几种技术路径，各有优劣：

• 容器化（Docker/containerd）：这是目前最主流、最成熟的方式。Shippy 可以将每个动作（或一组动作）打包进一个 Docker 容器中运行。容器天然提供了文件系统、进程、网络、资源的隔离，并且有丰富的镜像生态系统。优点是隔离性好、生态成熟、可移植性强。缺点是启动开销相对较大（虽然已经优化很多），并且需要管理容器运行时和镜像。
• 轻量级虚拟化（gVisor, Kata Containers）：比容器更强的隔离性（每个容器运行在一个独立的微型内核或虚拟机中），安全性更高，适合对多租户隔离要求极高的场景。缺点是性能开销更大，资源消耗更多。
• 系统调用拦截（seccomp-bpf, Landlock）：在 Linux 上，可以为核心进程配置 seccomp 过滤器，严格限制其可以调用的系统调用。Landlock 则可以限制文件系统访问。这可以作为容器隔离的补充，提供更深层的防御。但配置复杂，且需要深厚的系统知识。

对于 Shippy 这类工具，采用 Docker/containerd 作为默认的沙箱运行时是一个合理且务实的选择。它平衡了隔离性、性能、易用性和社区支持。Shippy 需要做的是安全地调用容器运行时 API，并管理好容器生命周期和资源。

6.3 沙箱内的安全实践

即使有了容器，内部的安全细节也至关重要：

• 镜像来源：动作使用的基础镜像必须是受信任的。Shippy 应支持从安全的私有仓库拉取镜像，或使用经过签名验证的镜像。
• 秘密管理：构建密钥、API Token 等绝不能以环境变量或命令行参数的形式明文传递到容器内（虽然常见，但有泄露风险）。应使用临时文件卷挂载（如 Kubernetes 的 Secret 卷）或运行时注入服务（如 HashiCorp Vault Agent Sidecar）的方式。
• 构建缓存安全：为了加速构建，通常会在宿主机上挂载 Docker 构建缓存卷。必须确保这个缓存卷在不同项目、不同用户之间是隔离的，防止通过缓存污染进行攻击。
• 出向网络控制：是否允许构建容器访问外网？如果允许，是否需要经过公司代理？是否需要域名白名单？这需要根据企业安全策略进行配置。

7. 边界交汇处：设计权衡与实战陷阱

当我们把“3个集合”和“4类边界”放在一起看时，它们之间会产生复杂的相互作用和设计权衡。这些交汇点往往是实际使用中最容易踩坑的地方。

7.1 状态持久化与沙箱的短暂性矛盾

沙箱（尤其是容器）是短暂的，任务结束即销毁。但“状态”需要持久化，以便在多个动作之间传递（如第一个动作生成的制品路径，需要告诉第二个动作），或者在任务失败后能够查询。

• 解决方案：Shippy 需要建立一个状态总线或上下文对象，这个对象存在于沙箱之外，由 Shippy 核心管理。每个动作启动时，Shippy 将当前所需的状态（以环境变量、配置文件或挂载卷的形式）注入沙箱。动作执行完毕后，Shippy 再从沙箱的特定输出位置（如约定的文件、标准输出中的特定格式）读取新的状态，更新到总线上。这个总线本身也需要持久化存储（数据库或文件），以实现任务的暂停、恢复和审计。

7.2 CLI/API 调用与异步执行的协调

用户通过 CLI 或 API 触发了一个耗时很长的流水线。CLI 是同步等待还是立即返回？API 是返回 202 Accepted 还是阻塞？

• 最佳实践：对于长任务，统一采用异步模型。CLI 命令在触发后，可以立即返回一个执行 ID，并提示用户使用shippy execution logs <id> -f来跟踪日志。API 则返回 202 状态码和执行 ID，并通过 Webhook 或让客户端轮询另一个状态端点来获取结果。这要求 Shippy 有一个可靠的任务队列和状态存储后端。

7.3 版本化行为在沙箱中的落实

你声明了使用node:18-bullseye镜像和npm@9。但如何确保沙箱内运行的确实是这个版本，而不是一个被篡改的镜像或通过apt-get意外升级的 npm？

• 深度锁定：除了声明镜像名，还应锁定镜像的摘要（Digest），确保二进制内容绝对一致。对于容器内的包管理器（npm, pip, apt），Shippy 的动作设计应避免在动作脚本中执行npm upgrade或apt-get update这类可能改变版本的操作。或者，更彻底的方式是使用完全自包含的、无网络访问的构建环境。

7.4 Typed API 与动态动作的兼容性

Shippy 支持用户自定义动作或插件。这些动态加载的动作，其参数和返回值如何反映到 Typed API 的契约中？API 如何触发一个参数结构未知的自定义动作？

• 设计模式：这需要一个灵活的、自描述的机制。一种方法是，自定义动作需要在注册时提供一个 JSON Schema 来描述其输入输出。Shippy 的 API 可以提供一个通用的executeAction端点，接受动作名和一个符合其 Schema 的 JSON 对象。更高级的设计是，Shippy 在启动时动态生成或更新 API 的 GraphQL Schema，将注册的动作作为可查询的字段或可调用的 mutation。这对框架的动态能力提出了很高要求。

8. 从设计到实践：构建你自己的“Shippy-like”系统

理解了 Shippy 的设计框架，我们甚至可以将其思想应用到构建自己的简易自动化工具中。这里以一个简单的、用于批量处理服务器配置的脚本管理器为例，看看如何应用这些概念。

假设我们有一个工具叫cfg-shipper，它负责将一批配置文件安全地分发到一组服务器并重启服务。

8.1 定义动作、状态、后果

• 动作：
  • validate-config: 本地验证配置语法。
  • secure-copy: 通过 SSH 将文件加密传输到目标服务器临时目录。
  • backup-remote: 在目标服务器上备份现有配置。
  • apply-config: 在目标服务器上移动新配置到正式位置。
  • reload-service: 在目标服务器上重载服务（如systemctl reload nginx）。
  • verify-service: 检查服务状态是否健康。
  • rollback: 如果验证失败，使用备份恢复配置并重载服务。
• 状态：我们需要维护一个状态文件（如 JSON），记录每台服务器当前处于哪个步骤（pending,copied,backed_up,applied,reloaded,verified,failed），以及备份文件的位置、临时文件的路径等。
• 后果：最关键的后果是服务器上配置文件的改变和服务重启。rollback动作就是专门为了逆转apply-config和reload-service的后果而设计的。

8.2 划定四大边界

• 版本化行为：在cfg-shipper的配置文件中，明确指定所使用的 SSH 客户端版本、目标服务器上命令的路径（如/usr/bin/systemctlvs/bin/systemctl），甚至目标服务的配置文件格式版本。
• Typed API：虽然可能不需要完整的 HTTP API，但我们可以为cfg-shipper设计一个强类型的配置文件 Schema（用 JSON Schema 或类似 Pydantic 的模型定义），并在代码内部用清晰的数据结构来传递参数和状态，这同样是“契约优先”思想的体现。
• CLI：设计直观的命令，如cfg-shipper plan ./configs（预览变更）、cfg-shipper apply --target web-servers（执行分发）、cfg-shipper status <job-id>（查看状态）。
• Sandbox：在这个场景下，“沙箱”的概念可以弱化，但“隔离”思想仍在。例如，secure-copy动作必须在独立的临时目录中进行，避免污染其他任务；执行远程命令时必须使用为此次任务专门创建的、权限受限的 SSH 会话和私钥。

通过这个例子可以看到，Shippy 所代表的“三元组模型”和“四类边界”是一种普适的设计模式，它不仅适用于复杂的云原生交付平台，也能指导我们设计出更健壮、更可维护的日常自动化脚本。下次当你再面对一个需要编排多个步骤的任务时，不妨先花点时间思考一下它的动作、状态、后果分别是什么，以及如何为它划定清晰的边界，这会让你的代码从一开始就走在正确的道路上。