工具生态

工具栈是一组带版本的契约，不是框架清单。第 74 章 最后得到了一套经过验证的模型制品包。要让它真正可用，可能还需要训练器、转换工具、服务运行时、模型网关、智能体主机、能力服务器、沙箱、策略引擎与遥测系统。单凭产品名称，无法判断这些组件是否对文件格式、模式、默认值、权限、取消语义与故障恢复有一致理解。训练框架、服务引擎、智能体框架，以及帮助它们互操作的标准，仍然是工具生态的主要类别，但类别名称并不能定义它们之间的契约。

因此，真正有用的问题不是「哪个框架最好」，而是「每条边界在什么版本和工作负载下承诺什么，又如何发现承诺已经失效」。一个组件能否进入工具栈，取决于显式兼容性、故障隔离、可替换性，以及实际运行产生的证据。这些性质属于组合后的系统，不是某个品牌自带的性质。

先分平面，再看产品

三个问题会在每一层反复出现（图 75.1）：

• 执行平面负责执行调用。它加载检查点、调度词元、调用工具、运行代码或委托任务。
• 控制平面决定这次执行能否发生，以及应采用哪个版本、身份、预算、路由与策略。
• 证据平面记录实际发生了什么，包括最终解析得到的输入、决策、时间、输出状态、资源用量与实际影响。

同一个进程可以实现三个平面，但它们回答的仍是不同问题。工具成功返回，不代表调用获得了授权。授权决定通过，也不代表工具完成了预期操作。追踪记录不会强制落实任何一种性质，它只保留系统所观测事实的证据。

因此，每个控制点都必须明确且可以测试，执行、策略与证据仍应作为彼此独立的契约。

各层的边界也不相同：

这张表不是供应商职责划分图，而是一份接口审查清单。如果两个模块来自同一平台，仍要测试它们之间的边界。如果它们来自不同项目，就记录连接双方的适配器。

让兼容性成为可审查的主张

用以下契约表示组件 $i$：

$$C_i = (V_i, I_i, O_i, A_i, S_i, F_i, E_i).$$

其中，$T=(C_1,\ldots,C_n)$ 表示工具链，$w$ 表示工作负载。验收同时要求每个组件都已就绪，而且每条边都兼容：

$$\operatorname{accept}(T,w) = \bigwedge_{i=1}^{n}\operatorname{ready}(C_i,w) \;\land\; \bigwedge_{(i,j)\in E_T} \operatorname{compatible}(C_i,C_j,w).$$

每一项都有明确的运行含义：

其中：
  C_i            ：组件 i 的带版本契约
  i, j           ：从 1 到 n 的组件索引
  V_i            ：支持的版本与扩展集合
  I_i            ：接受的输入，包括格式与模式
  O_i            ：输出及其语义
  A_i            ：身份、同意与预算方面的权限要求
  S_i            ：持久化、重试与取消方面的状态语义
  F_i            ：故障语义、超时与恢复行为
  E_i            ：发出的证据，包括日志、追踪、指标与回执
  T              ：工具链中 n 份组件契约组成的有序集合
  n              ：T 中组件契约的数量
  w              ：已声明的工作负载与运行环境
  E_T            ：T 中有向集成边的集合
  (i, j)         ：从组件 i 的输出指向组件 j 的一条边
  ready(C_i, w)  ：组件 i 在工作负载 w 下满足自身契约时为真
  compatible     ：一条边在工作负载 w 下保留版本、模式、权限、
                   状态、故障与证据语义时为真
  bigwedge       ：所有列出组件或边之间的逻辑与
  land           ：两组必要检查之间的逻辑与

API 模式只是边兼容性的一部分。两个运行时可能接受同一种请求，却采用不同的对话模板、采样默认值、停止规则、工具调用编码、重试策略或取消语义。这些差异属于语义，而不是语法。应当用契约测试捕获它们，不能只在说明文字里宣称兼容。

发布记录至少应固定模型制品包摘要、运行时镜像摘要、精确配置、依赖与编译器版本、硬件与驱动类别、协议修订版与扩展、策略修订版，以及工作负载定义。容器摘要很有用，却不完整，因为它无法标识主机驱动、加速器、挂载配置或远端服务。

生态围绕不同边界逐步形成

几类主要工具并不是作为一套连贯的技术栈同时出现的。2019 年的 Megatron-LM 在其受评测的 PyTorch 配置中证明了张量并行训练的可行性。ZeRO 则先于 2019 年发布预印本，随后发表于 SC 2020，把普通数据并行会复制的状态拆分到不同设备 (Shoeybi et al. 2019; Rajbhandari et al. 2020)。这些机制属于 第 10 章。对工具生态而言，它们说明分布式布局与检查点状态已经成为训练程序和集群之间的显式接口。

服务系统形成了另一种接口。发表于 SOSP 2023 的 vLLM 系统使用 PagedAttention 管理键值缓存块，不要求物理内存连续 (Kwon et al. 2023)。论文报告的吞吐量提升属于完整的受评测系统、模型、工作负载与基线，并不是某个算法在所有环境中的普遍性质。第 31 章 与 第 32 章 解释了这一机制。本章关注的是它揭示的工具契约：运行时契约必须包含调度策略与工作负载。

智能体工具又暴露了第三种边界。ReAct 在 2023 年的问答和交互任务实验中交错执行模型推理与环境动作 (Yao et al. 2023)。它没有定义生产框架或安全模型，却把反复进行的模型、动作与观察循环变得具体。Anthropic 于 2024 年 11 月推出 MCP，后来将应用到能力服务器的接口标准化 (Anthropic 2024)。Google 于 2025 年 4 月推出 A2A，标准化由不同主体独立运行的智能体之间的消息与任务生命周期 (Google Cloud 2025)。这些历史彼此交叠，却并不构成一条成熟度阶梯。训练、服务、主机到工具的集成，以及对等委托，解决的是不同问题。

一旦共享边界得到明确，不跨越边界的实现选择就回到各层内部，由对应章节继续分析。

训练与服务暴露出可移植性的边界

训练检查点只有在目标加载器能够重建必要状态时才有用。PyTorch Distributed Checkpoint 支持加载时重新分片，包括改变训练器数量或并行布局。相同文档也明确表示，不保证状态字典在不同 PyTorch 版本之间向后兼容 (PyTorch Contributors 2026)。「可以重新分片」因此不等于「任何未来框架都能加载」。一份训练发布记录应包括：

• 规范模型与优化器状态，以及把它们映射到运行程序的代码；
• 为承诺的恢复形式所需的调度器、采样器、随机状态、数据位置与进度状态；
• 分布式布局与重新分片的假设；
• 框架、扩展、内核、编译器与检查点模式的版本；
• 经过测试的恢复流程，在目标拓扑上继续训练，并按已声明的容差比较后续步骤。

在服务系统中，识别模型格式与保持行为一致之间也有类似缺口。以 NVIDIA Triton 的模型仓库文档为例，TensorRT 计划与 CUDA 计算能力绑定，ONNX 支持取决于随软件提供的 ONNX Runtime 与算子集，TorchScript 兼容性则可能随 PyTorch 版本改变 (NVIDIA 2026)。文件名能被识别，不代表已经建立服务契约。

KServe V2 推理协议通过 HTTP 或 gRPC 标准化健康检查、元数据与推理操作。可选行为并不属于最低一致性要求 (KServe Contributors 2026)。通过线协议测试，不能证明分词、对话模板、流式数据块、采样默认值、结构化输出、工具调用、适配器或错误映射等语义等价。替换服务运行时之前，应使用锁定的语料库逐项测试这些语义。

性能主张也需要同样严格的边界。测试应采用接近生产环境的到达过程、提示与输出长度分布、并发量、加速器、运行时标志、故障条件和尾延迟。只有同时满足质量与延迟闸门的请求，才能计入有用吞吐量。在同一时刻发送全部请求的基准，回答的问题不同于突发式交互服务。每项结果都与具体工作负载相关。

智能体主机不是协议

智能体主机决定哪些内容进入上下文、何时运行模型、如何分派工具调用、保留哪些状态，以及何时必须由人批准实际影响。这就是 第 41 章 研究的运行框架，也是 第 38 章 展开的模型循环。协议只负责标准化主机某一条边上的消息。运行时或能力服务器则决定现实中可能产生哪些影响。把这些角色混在一起，会让协议支持看起来像安全保证或可移植性保证。

当调用方从应用变成智能体，风险也随之改变。模型生成的请求可能依赖不可信上下文，也可能在部分失败后被重复执行。主机仍然必须居中调解这些请求。

MCP 与 A2A 位于不同的边上（图 75.2）：

• 工具服务器向主机暴露操作或上下文。它的模式可以描述一个有边界的操作，但主机必须独立约束真实副作用。
• 对等智能体拥有独立的任务状态，也可能管理自己的模型、工具、策略与生命周期。把任务委托给它，会跨越普通函数调用所没有的问责边界。
• 智能体主机仍然负责应用状态、策略、上下文、审批，以及解释从任一协议收到的结果。

MCP：从应用主机到能力服务器

模型上下文协议（MCP） (Anthropic 2024) 常被称为连接模型与工具服务器的协议，更准确地说，它是一种主机、客户端与服务器协议。在当前的 2026-07-28 规范中，基础协议采用 JSON-RPC、保持无状态，并逐请求协商能力。主机拥有应用状态，一条打开的连接并不是协议层的对话或会话。服务器可以暴露工具、资源与提示，可选扩展则提供其他能力 (Model Context Protocol Contributors 2026)。

MCP 默认使用 JSON Schema 2020-12。模式验证只能检查结构，无法判断含义、副作用、发布者身份或陈述真伪。当前规范还明确指出，客户端与服务器的实现名称只是自报元数据，不能用于安全决策。因此，生产注册表应把经过认证的服务器来源或软件包摘要、工具名称、规范描述符摘要、协议修订版与获准能力集合绑定起来。如果发现过程报告描述符已经变化，就应将其隔离并重新审查。

发现工具不等于授予权限。MCP 的 HTTP 授权框架规定了受保护资源服务器与客户端如何使用 OAuth，本地 stdio 部署则通过运行环境取得凭据。上层应用仍然必须落实最小权限、明确同意、针对具体影响的审批与隔离。规范将工具描述和注解视为不可信内容，除非它们来自可信服务器；规范也指出，协议本身无法强制落实这些安全原则 (Model Context Protocol Contributors 2026; Model Context Protocol Contributors 2026)。

A2A：从客户端到独立智能体

A2A v1.0 描述的是生命周期更长的应用交互。A2A 服务器发布一张 Agent Card，声明接口、技能、媒体类型、能力与认证要求。A2A 客户端发送 Message，服务器可以创建有状态的 Task，任务状态随进度变化，结果则应作为 Artifacts 返回。每个请求通过 A2A-Version 指明协议版本 1.0，被追踪的任务最终会进入 completed、failed、canceled 或 rejected 等终态 (A2A Protocol Working Group 2026)。

这些结构让委托过程可以观测，却不能证明远端智能体正确、安全、诚实，或获准访问某项具体资源。Agent Card 描述的是其声称具备的技能。可选的卡片签名可以在给定信任策略下认证卡片字节，却无法验证能力。部署必须在每次操作时执行认证与授权。A2A 还允许至少一次推送交付，因此消费者必须对实际影响去重，不能假定一次通知只对应一次动作。

如果另一端只是在主机任务内执行一项定义明确的操作，就使用工具调用。如果另一端拥有独立的任务状态，可能要求补充输入，并返回可审查的制品，就使用 A2A。不要把每个函数都包装成智能体，也不要用工具标签掩盖一个独立智能体。多个对等智能体的组合方式由 第 43 章 继续讨论。

安全属于完整的组合路径

发现不等于授权。目录条目、MCP 描述符或 Agent Card 可以帮助调用方构造请求，执行点仍必须认证调用方与主体，检查准确的资源和动作，并把决定绑定到当前策略。第 56 章 中的控制适用于每一跳，包括模型网关、智能体主机、工具服务器、对等智能体、沙箱与下游 API。

最低限度应做到：

• 签发受众绑定的短期凭据，并遵循最小权限。MCP 授权指南禁止令牌透传，因为它会绕过资源服务器验证并削弱归属能力；
• 把每项服务商或下游秘密保留在模型可见的上下文、工具参数、工作区文件与日志之外；
• 隔离本地能力服务器与生成代码，限制文件系统和网络访问，并通过允许列表控制出站目的地；
• 把人的审批绑定到精确的工具身份与描述符摘要、规范化参数、目标资源或收件人、成本或影响上限，以及失效时间；
• 在执行时重新检查策略，因为一次审批并不授权已经改变的请求或更晚发生的重试；
• 验证结果与下游实际影响，而不只是输入，并从保留的证据中删除或遮蔽秘密与敏感内容。

协议元数据本身也能影响模型。归档的 MCPTox 研究从 45 组真实 MCP 服务器工具集中抽取 353 个真实工具，构造了 1,348 个恶意描述符案例，并测试了 20 种智能体设置 (Wang et al. 2026)。这是对描述符投毒的受控证据，并不能证明 45 台已部署服务器遭到入侵。AgentDojo 则另外评测了通过不可信环境与工具内容实施的间接提示注入，同时测量正常任务效用 (Debenedetti et al. 2024)。这些实验支持一项边界明确的结论：语法有效且可以互操作的内容仍可能带有对抗性，因此必须在准确的组合系统上同时测试效用与抗攻击能力。

建立跨越各条边的证据平面

一次请求可能依次经过网关、模型运行时、主机、沙箱、能力服务器与下游 API。应为同一逻辑操作分配一个追踪标识，并采用有文档说明的传播格式，保留各跳追踪跨度（span）之间的父子关系。W3C Trace Context 为此标准化了 traceparent 与 tracestate 请求头 (Kanzhelev et al. 2021)。追踪标识只能关联记录，不是身份凭据，绝不能用于授权调用。

对于每项特权操作，保留的证据至少要能重建：

• 行为者与主体身份、租户、委托权限和授权决定；
• 已解析的模型制品包与服务运行时、智能体主机版本、协议版本、服务器来源、工具或 Agent Card 模式摘要，以及策略修订版；
• 规范化参数摘要与目标，敏感内容应遮蔽，或置于单独的访问控制之下；
• 必要时使用的审批标识，以及预算预留与结算；
• 开始时间、截止时间、重试、幂等键、取消请求与确认、终态、返回制品摘要，以及观测到的下游实际影响；
• 延迟、词元与资源用量、成本和故障分类。

不能把「已经启用日志」等同于完整审计轨迹。完整性要求所有实际影响都经过中介、记录持久写入、标识稳定、时钟得到妥善处理，并有明确的保留期与访问控制。防篡改能力又是另一项性质。同样，遥测约定只是一套词汇，不能证明每个组件都发出了必要记录。第 87 章 将继续介绍消费这些证据的评测与可观测性闭环。

先验证可移植性，再依赖它

采用协议可以减少适配工作，但可移植性至少分为四层：

1. 线协议兼容性：消息能够解析，必需方法存在，版本与能力能够协商，错误响应格式符合预期。
2. 语义兼容性：默认值、工具产生的影响、流式传输、制品、取消、重试与状态，对应用具有相同含义。
3. 运行兼容性：替代组件满足当前工作负载对延迟、吞吐量、可用性、隔离与成本的要求。
4. 治理兼容性：身份、授权、审批、证据、保留与删除义务仍能落实。

一致性测试通常只能证明第一层的一部分。还需要增加应用语义契约测试、负向授权测试、畸形与对抗内容、故障注入、重试与幂等、取消、重启、回滚，以及符合工作负载形态的性能测试。如果缺失的行为很重要，就应拒绝静默回退到更旧的协议或更小的能力集合。

退出测试最能说明组件是否真正可替换。在预发布环境中，只通过公开契约与适配器替换组件，恢复状态，重放锁定的测试语料库，再恢复原有版本。记录过程中发现的每项未公开依赖。即使线协议保持不变，迁移工作、数据转换、重新测试、重新训练与运行经验的重新积累也都属于切换成本。

在把候选项当作直接替代品之前，可以先运行下面这份小型兼容性矩阵。它刻意检查精确值：更高版本的模式和缺失的生命周期保证，在完成审查前都不兼容。

requirements = {
    "artifact.bundle": "sha256:release-a",
    "serving.api": "chat.v2",
    "mcp.protocol": "2026-07-28",
    "tool.schema": "calendar.v3",
    "auth.audience": "calendar-service",
    "task.cancel": "required",
}

def evaluate(label, offered):
    for key, expected in requirements.items():
        actual = offered.get(key, "missing")
        if actual != expected:
            return f"{label}: rejected ({key}: expected {expected}, got {actual})"
    return f"{label}: compatible ({len(requirements)} contracts)"

candidate_a = dict(requirements)

candidate_schema_drift = dict(requirements)
candidate_schema_drift["tool.schema"] = "calendar.v4"

candidate_no_cancel = dict(requirements)
del candidate_no_cancel["task.cancel"]

print(evaluate("candidate-a", candidate_a))
print(evaluate("candidate-schema-drift", candidate_schema_drift))
print(evaluate("candidate-no-cancel", candidate_no_cancel))

预期输出：

candidate-a: compatible (6 contracts)
candidate-schema-drift: rejected (tool.schema: expected calendar.v3, got calendar.v4)
candidate-no-cancel: rejected (task.cancel: expected required, got missing)

经过隔离与准入采用新工具

把新框架、运行时、服务器、扩展或升级视为系统元组中尚未受信任的变化：

1. 盘点受影响的边。 列出每项输入、输出、状态存储、凭据、策略决定、副作用和证据消费者。
2. 固定候选项。 记录源代码或软件包修订版、镜像摘要、配置、依赖、协议版本、扩展与平台。
3. 建立兼容性矩阵。 将版本、格式、模式、默认值、权限、生命周期、故障与遥测，同每个相邻组件逐项比较。
4. 更新威胁模型。 视情况把发现元数据、工具输出、制品、回调、远端提示与对等消息列为不可信内容，并收紧沙箱与网络允许列表。
5. 执行一致性测试与契约测试。 覆盖畸形输入、负向授权、描述符变化、超时、重复交付、幂等、取消与恢复，以及依赖不可用。
6. 执行工作负载评测与对抗评测。 固定制品包与语料库，测量质量、服务行为、成本、正常效用与攻击成功率，并与获准组件比较。
7. 演练退出与回滚。 导出状态，切换到其他组件，恢复旧版本，并确认进行中和已结束的工作仍能得到一致解释。
8. 准入已锁定的系统元组。 签署或批准发布记录，渐进式部署并监控闸门，出现偏差时撤销或回滚。

从工具走向经济

工具链记录标识的不只是软件。它还标识工程人力、托管服务、加速器、存储、网络路径、可观测性，以及让每份契约持续有效所需的运行工作。这些成本和退出测试揭示的切换成本，将直接进入 第 76 章。后文的 第 88 章 会把相同契约组合成一套可部署的参考工具栈，第 89 章 则负责随时间推进准入与回滚。

协议让一条边变得清楚；只有测试与策略才能让组合系统获得准入。

延伸阅读