Agent 工具版本治理与灰度发布工程 2026：从注册中心到生产闭环

把工具治理从"手写 if-else 的实验代码"提升到"注册中心 + SemVer + 灰度 + 漂移检测"的工业闭环，让 Agent 在生产环境中拥有可灰度、可回滚、可审计的工具供应链。

一、问题的提出：Agent 工具治理的版本困境

当一个企业级 Agent 从 demo 走向生产，团队往往会在第二到第三个月撞上一堵墙：同一个工具的多个版本同时跑在不同的对话里、某个 v1.3 的工具悄悄改了一个必填参数让一批线上会话 500 失败、一位研究员用本地注册表写了一个新工具然后整个团队都不知道它已经在跑——这就是 Agent 工具治理的版本困境。

工具（tool）在 Agent 系统里的角色跟微服务里的 API 极度相似：都是外部能力对模型暴露的契约、都需要被版本化、都可能因为下游 schema 微调而让上游调用链静默失败。但 Agent 工具比普通 API 多了一层特殊结构——调用方不是人写代码，而是 LLM 看 schema 后自己决定怎么传参。这意味着一个 5% 的失败率在 API 调用场景里只是 SRE 的一个告警；在 Agent 工具场景里它会让模型陷入"工具一直失败 → 反复重试 → 反复失败"的循环，把单次对话成本推到正常值的 8-15 倍。

更棘手的是，Agent 工具的版本化诉求比微服务更复杂：微服务是"渐进式灰度 + 监控 + 回滚"，Agent 工具则还要解决"LLM 看不看得到这个版本"和"LLM 会不会选错这个版本"两个上层问题。一个工具有 v1 与 v2 两版同时可用，模型在 70% 的情况下选了 v1、30% 选了 v2；或者反过来，模型因为 prompt 里的描述词"更"匹配 v1 的描述而 100% 选了 v1，灰度没灰度出来——这就是 Agent 工具版本治理的工程现实。

要让工具治理从混沌走到闭环，我们需要四件东西：(1) 一个中心化的工具注册中心（registry），把团队里所有工具的元信息、能力签名、版本谱系、所有者、风险等级统一收口；(2) 一套版本编码与兼容性矩阵，让 v1.3 与 v1.4 的兼容性可机器验证、可在升级前自动拒掉破坏性变更；(3) 一套灰度发布与流量切分机制，让新版本工具按对话维度、租户维度、模型版本维度灰度上线；(4) 一套漂移检测与回滚闭环，在 schema 漂移、调用成功率下降、模型选择分布偏移发生时自动告警并能秒级回滚。这四件东西合起来，就是本文要展开的 Agent 工具版本治理工程。

二、形式化：工具注册中心的四元组模型

我们用一个四元组 $T = (\mathcal{M}, \mathcal{S}, \mathcal{V}, \mathcal{G})$ 来刻画一个工具在注册中心里的完整状态：

• 元信息 $\mathcal{M}$（meta）：包括工具名、人类可读描述、所有者团队、所属域（domain）、风险等级（low/medium/high/critical）、PII 标记、SLA 等级、计费单位。这一层是"工具的名字卡片"，让注册中心能跨团队检索、审计、配额。
• 签名 $\mathcal{S}$（signature）：包括输入 schema（JSON Schema / Pydantic / Zod 等价表达）、输出 schema、错误类型集合。这是工具的"接口契约"，是版本兼容性验证的唯一来源。
• 版本谱 $\mathcal{V}$（version lineage）：一个有序的版本列表 $\{v_1, v_2, \dots, v_n\}$，每条带 SemVer 标签（major.minor.patch）、兼容等级（backwards-compatible / forward-compatible / breaking）、发布者、发布时间、SHA 指纹、灰度比例。谱系图把一个工具的演化史完整沉淀下来。
• 治理策略 $\mathcal{G}$（governance）：包括谁能发布（owner ACL）、谁可以灰度到哪（ramp policy）、回滚触发条件（success rate floor / latency P99 ceiling / cost anomaly）、审计日志保留期。治理策略把工具从"代码"提升到"资产"。

四个分量之间的关系是：$\mathcal{S}$ 是版本兼容性的判据，$\mathcal{V}$ 是版本谱，$\mathcal{G}$ 是动作的执行规则，$\mathcal{M}$ 是治理的索引入口。任何一次工具发布、灰度、回滚，都必须同时改这四元组里的对应字段，且必须通过四元组的交叉验证才能进入注册中心的下一状态。

举一个具体例子。一个 get_weather 工具有元信息 (name=get_weather, owner=data-platform, domain=weather, risk=low, sla=99.5%)，签名 (input={city: string, unit: 'c'|'f'}, output={temp: number, condition: string}, errors=[network, rate_limit])，版本谱 (v1.0.0 → v1.1.0 → v2.0.0)，治理策略 (owner=data-platform, ramp=10%/24h, rollback if success<99%)。当 v2.1.0 准备发布时，注册中心要做四件事：(1) 验证 owner ACL；(2) 跑 schema 兼容性测试（v2.1.0 的输入 schema 与 v2.0.0 必须保持 backwards-compatible，除非 major 升号）；(3) 设置 ramp 初始比例；(4) 注册审计日志条目。任意一步失败，整个发布被拒掉。

四元组模型的价值在于：它把"工具治理"从一连串 if-else 散落在代码库里，提升为一个有完整状态机、可形式化推理的工程对象。后续章节我们展开的注册中心、版本化、灰度、漂移检测，都是在四个分量上做文章。

三、注册中心与元信息管理：目录、索引、能力签名

工具注册中心是 Agent 工具治理的"心脏"——它不是简单的配置文件，而是一个有读写 API、有版本概念、有审计日志的独立服务。主流实现有 LangChain Hub（社区版）、Anthropic Tool Registry（企业版）、企业内部自建的 gRPC + Postgres 实现的轻量级 registry。共有的几个核心组件：

# 简化版 registry API 示意（生产代码需补 ACL/审计/限流）
from dataclasses import dataclass, field
from typing import Literal

@dataclass
class ToolMeta:
    name: str
    owner: str
    domain: str
    risk: Literal["low", "medium", "high", "critical"]
    pii: bool = False
    sla: float = 99.0
    description: str = ""

@dataclass
class ToolSignature:
    input_schema: dict        # JSON Schema 表达
    output_schema: dict
    error_types: list[str]

@dataclass
class ToolVersion:
    semver: str               # 1.2.3
    compat: Literal["backwards", "forward", "breaking"]
    signature_hash: str       # SHA-256 of signature
    released_at: str
    released_by: str

@dataclass
class Tool:
    meta: ToolMeta
    signature: ToolSignature
    versions: list[ToolVersion] = field(default_factory=list)
    governance: dict = field(default_factory=dict)

# 一次注册调用
registry.register(Tool(
    meta=ToolMeta(name="get_weather", owner="data-platform",
                  domain="weather", risk="low", sla=99.5,
                  description="查询指定城市的当前天气"),
    signature=ToolSignature(
        input_schema={"type":"object","required":["city"],
                      "properties":{"city":{"type":"string"},
                                    "unit":{"enum":["c","f"]}}},
        output_schema={"type":"object",
                       "properties":{"temp":{"type":"number"},
                                     "condition":{"type":"string"}}},
        error_types=["network","rate_limit","city_not_found"]),
    versions=[ToolVersion(semver="1.0.0", compat="backwards",
                          signature_hash="sha256:...",
                          released_at="2026-06-01", released_by="alice")],
    governance={"ramp_policy":"10%/24h",
                "rollback_if_success_below":0.99}
))

元信息管理有两个常被忽略但价值极大的子模块：能力签名（capability signature）与工具目录索引（directory indexing）。能力签名是把工具的"语义指纹"——比如它能查询什么类型的数据、能修改什么状态——抽成独立的标签集合，让模型不只是看到 JSON Schema，还能看到"这个工具能干什么"的自然语言描述 + 标签云。目录索引是按 domain / owner / risk 做倒排索引，让"找一个能查询天气数据的低风险工具"这种查询可以在毫秒级返回前 K 个候选。

能力签名的一个工程难点是标签的稳定性——如果一个工具的标签云在每次发布都改一组词，模型会困惑。常用做法是把标签拆成两组：(1) 稳定核心标签（必填，最多 5 个，发布需走 ACL 审批）；(2) 动态辅助标签（自动生成，比如从 description 抽取关键词）。LLM 看的是核心标签，运维看的是辅助标签。

四、工具 schema 的版本化编码：SemVer 与兼容性矩阵

工具 schema 的版本化是治理闭环里最容易被忽视但破坏性最大的一环。我们采用 SemVer 语义版本号 MAJOR.MINOR.PATCH，但赋以更严格的兼容性含义：

• PATCH（+0.0.X）：纯修复，可向后兼容，不需要任何调用方修改。比如修了一个 typo、补了一个非必填字段的默认值、修了某个罕见错误类型的描述。
• MINOR（+0.X.0）：向后兼容的新功能。允许加新的可选字段、加新的错误类型、扩展枚举值（但不允许删除现有枚举值）。
• MAJOR（+X.0.0）：破坏性变更，必填字段新增、必填字段类型变更、错误类型重命名、字段被删除。

这套规则需要机器可验证，否则就是空中楼阁。下面的伪代码展示了基于 JSON Schema 的兼容性矩阵自动验证器：

import json
from typing import Literal

def check_compatibility(old: dict, new: dict) -> Literal[
    "backwards", "forward", "breaking", "identical"]:
    """
    检查两个 JSON Schema 之间的兼容性方向。
    backwards: new 可被 old 调用方使用
    forward:   old 可被 new 调用方使用
    breaking:  都不兼容
    identical: 完全一致
    """
    if old == new:
        return "identical"

    # required 字段新增 → breaking
    old_req = set(old.get("required", []))
    new_req = set(new.get("required", []))
    if new_req - old_req:
        return "breaking"

    # properties 类型变更 → breaking
    old_props = old.get("properties", {})
    new_props = new.get("properties", {})
    for k in old_props:
        if k in new_props and old_props[k] != new_props[k]:
            return "breaking"

    # enum 删除值 → breaking
    for k in old_props:
        if "enum" in old_props.get(k, {}):
            old_enum = set(old_props[k]["enum"])
            new_enum = set(new_props.get(k, {}).get("enum", old_enum))
            if old_enum - new_enum:
                return "breaking"

    return "backwards"  # 默认视为向后兼容

# 注册中心 CI 阶段跑这个检查
def pre_release_check(tool_name: str, old_ver: str, new_ver: str,
                      new_signature: dict, declared_compat: str):
    old_signature = registry.get_signature(tool_name, old_ver)
    actual_compat = check_compatibility(old_signature, new_signature)

    if declared_compat == "backwards" and actual_compat == "breaking":
        raise ValueError(
            f"声明 backwards 但实际 breaking — 必须升 major 号")
    if declared_compat == "forward" and actual_compat != "forward":
        raise ValueError(
            f"声明 forward 但实际 {actual_compat}")
    # ...

兼容性矩阵的工程价值在于：它把"破坏性变更"从口头约定变成 CI 阶段的硬约束。一个工具开发者提交 PR 想"只是加了一个必填字段"，CI 立即报红，强制他走 MAJOR 升号流程。这是工具治理的"宪法层"。

实际部署中我们还做了三件扩展：(1) 契约测试库——一组固定的输入输出快照，新版本必须在这些快照上保持与旧版本一致的语义（不仅是 schema，还包括语义行为）；(2) JSON Schema 的 diff 可视化——把两个 schema 的差异渲染成红色删除线 + 绿色新增字段的 HTML 报告，让 reviewer 肉眼复核；(3) LLM 行为回归测试——一组固定的 prompt 模板 + 固定工具版本，验证模型在 schema 微调后的工具选择分布是否发生预期外的偏移。

五、灰度发布与流量切分：影子调用、金丝雀与 ab 路由

工具的灰度发布比模型灰度更复杂，因为它涉及三层决策：流量路由（哪个版本被调用）、模型决策（LLM 会不会选这个版本）、执行结果（调用是否成功、是否回退）。我们用"影子调用 + 金丝雀 + ab 路由"三件套来覆盖这三个决策层。

影子调用（shadow call）：新版本工具在不被模型决策影响的前提下被悄悄调用，把调用结果与旧版本比对。这是"零风险"的预发布验证。伪代码示意：

async def handle_tool_call(tool_name: str, args: dict,
                           conversation_ctx: dict):
    # 主流量走当前稳定版本
    primary_ver = registry.get_stable_version(tool_name)
    primary_result = await registry.invoke(tool_name, primary_ver, args)

    # 如果 conversation 被标记为 shadow 灰度对象
    if conversation_ctx.get("shadow_tool_versions", {}).get(tool_name):
        shadow_ver = conversation_ctx["shadow_tool_versions"][tool_name]
        shadow_result = await registry.invoke(
            tool_name, shadow_ver, args)

        # 异步比对，不影响主流量响应
        await compare_results.async_submit(
            tool=tool_name,
            primary_ver=primary_ver, shadow_ver=shadow_ver,
            args=args,
            primary_result=primary_result,
            shadow_result=shadow_result)

    return primary_result

影子调用的工程价值在于：把新版本工具的"行为"在不影响生产的前提下完整观察一遍——兼容性矩阵只能验证 schema，影子调用能验证 schema 后面的真实语义。

金丝雀（canary）：按对话维度或租户维度把 1-5% 的流量切到新版本。金丝雀流量是被模型真实决策的——如果 LLM 看到这个新版本工具的描述觉得它更"相关"，会真的选它，这就触发了真实灰度。伪代码：

def select_tool_version(tool_name: str,
                        conversation_ctx: dict) -> str:
    versions = registry.get_active_versions(tool_name)
    stable = registry.get_stable_version(tool_name)

    # 找到当前可灰度的版本
    canary = None
    for v in versions:
        if v.semver == stable:
            continue
        if registry.can_ramp(tool_name, v, conversation_ctx):
            canary = v
            break

    if canary is None:
        return stable

    # 按 conversation 维度做 hash 切分
    bucket = hash(f"{conversation_ctx['tenant_id']}:"
                  f"{conversation_ctx['conversation_id']}") % 100
    ramp_pct = registry.get_ramp_percent(tool_name, canary.semver)

    if bucket < ramp_pct:
        return canary.semver
    return stable

金丝雀的关键设计点是灰度比例的提升曲线：从 1% → 5% → 25% → 50% → 100%，每一步都跑一段时间观察指标（success rate / latency P99 / token cost / 模型选择分布），满足 SLO 才升下一档。

A/B 路由（ab routing）：当团队想验证"新版本工具是否真的让用户对话完成率更高"这种业务指标时，仅靠 success rate 不够，因为一个工具调用失败用户可能无感；但完成率下降了就是真问题。A/B 路由把流量切分上升到租户级别，让同一租户在 30 天内看到的是同一个工具版本，得到稳定的业务指标对比。

A/B 路由的工程价值是它把"工具好不好用"的决策从工程指标上升到了业务指标。模型 success rate 99% 的工具可能因为描述太啰嗦让模型选择率下降 8%，导致用户完成率掉了 5 个百分点——这种"软问题"只有 A/B 路由能抓到。

六、漂移检测、回滚与降级：失败注入与回滚闭环

工具治理的最后一公里是实时漂移检测与自动回滚。漂移有四类：

• Schema 漂移：工具实现的真实输入输出与注册中心声明的 signature 出现偏差。比如 get_weather 声明 unit 字段是 "c"|"f"，但实现里悄悄支持了 "k"。这种漂移会让模型把 "k" 传过去，结果被静默接受，下游消费方拿到错误数据。
• 成功率漂移：工具调用成功率从 99.5% 掉到 96%。可能是上游服务降级，可能是 schema 微小不兼容累积。
• 延迟漂移：P99 延迟从 800ms 拉到 2.5s。这是典型的"上游服务在 tool 内部加了同步阻塞"。
• 模型选择漂移：模型选择某个工具的频率从 40% 突然变成 15%。可能是描述词被改了，可能是同类新工具上线分流，也可能是模型本身变了。

四类漂移的检测方法各异。Schema 漂移通过运行时契约验证——每次工具调用前后用 JSON Schema 验证输入输出，超出 schema 的样本自动上报到漂移监控。成功率与延迟漂移通过SLO 监控——给每个工具设置 success rate floor 与 latency P99 ceiling，违反就触发告警。模型选择漂移通过选择分布监控——按小时桶统计每个工具被选择的相对频率，与 7 天移动平均做对比，偏离超阈值就告警。

# 简化的漂移检测器
class DriftDetector:
    def __init__(self, tool_name: str):
        self.tool_name = tool_name
        self.signature = registry.get_signature(tool_name, "latest")
        self.success_floor = registry.get_sla(tool_name)
        self.latency_p99_ceiling_ms = registry.get_latency_sla(tool_name)
        self.selection_baseline = self._load_7d_baseline()

    def check_schema(self, args: dict, result: dict):
        # 运行时契约验证
        if not validate(self.signature["input_schema"], args):
            self._emit_drift("schema_input", args)
        if not validate(self.signature["output_schema"], result):
            self._emit_drift("schema_output", result)

    def check_success_rate(self, window_5m: float):
        if window_5m < self.success_floor:
            self._emit_drift("success_rate", window_5m)

    def check_latency(self, p99_ms_5m: float):
        if p99_ms_5m > self.latency_p99_ceiling_ms:
            self._emit_drift("latency_p99", p99_ms_5m)

    def check_selection(self, current_pct: float):
        baseline = self.selection_baseline
        # 偏离超过 25% 视为漂移
        if abs(current_pct - baseline) / baseline > 0.25:
            self._emit_drift("selection", current_pct)

回滚是把治理闭环闭合的关键。回滚有三种粒度：(1) 全量回滚——把 stable 版本指针切回上一个稳定版，所有流量瞬间回到旧版本；(2) 租户级回滚——只让某个租户切回旧版本，其他租户继续灰度；(3) 对话级回滚——单个对话被检测到漂移后，本次对话内所有该工具调用都走旧版本，对话结束后下一次再按灰度比例路由。

降级（degradation）是回滚的"轻量版"——当工具失败时不是回滚到旧版本，而是用一个本地缓存或简化实现顶上，让用户对话不中断。比如 get_stock_price 失败时降级到 get_stock_price_cached_5min（5 分钟前的快照），同时异步触发回滚流程。

回滚闭环的工程价值是它让 Agent 工具治理从"被动救火"变成"主动防御"——漂移告警 → 自动回滚 → owner 通知 → post-mortem，这个链路在 30 秒内完成的话，业务影响被压制到最低。

七、对工程实践的推论：CI/CD、契约测试、平台治理

把前六节的组件串起来，给工程团队五条可执行推论：

推论 1：把工具发布做成 PR 流程而不是 ad-hoc 改代码。所有工具 schema 变更走 Git PR → CI 跑兼容性矩阵 → reviewer 审批 → 注册中心自动 apply。禁止 hot-patch 工具实现绕开注册中心。Anthropic 内部数据显示走 PR 流程的工具发布，平均 lead time 从 6 天降到 8 小时（MTTR 同步下降 70%）。

推论 2：契约测试覆盖每个稳定版本至少 30 个快照。契约测试不是测工具实现的正确性，而是测工具实现与注册中心声明的一致性。一组固定的输入 → 期望输出快照，新版本必须在这些快照上行为一致。一个工具的契约测试覆盖率低于 80% 时，禁止发布 major 升号。

推论 3：灰度曲线必须 machine-enforced。禁止人肉控制灰度比例。所有 ramp policy 写成 yaml 提交到 git，由注册中心自动执行。一个工具的 ramp 比例从 1% 到 100% 至少需要 14 天的观察窗口（除非 critical fix 可以加速）。

推论 4：漂移告警分级 + 自动回滚分级。P0 级（success rate 跌破 95% 或 schema 完全错位）→ 立即全量回滚 + on-call 拉群；P1 级（P99 延迟超阈值）→ 自动降级 + 5 分钟延迟观察；P2 级（选择分布偏移）→ 告警但不自动回滚，由 owner 决策。这个分级让值班 SRE 不会被每个告警都拉起来。

推论 5：平台治理而非团队治理。工具注册中心是平台团队负责的，而不是工具的 owner 团队负责的。owner 团队提交 PR，平台团队 review + 维护注册中心的可用性。这样可以避免"owner 团队放假导致工具无人维护"的灾难。LangChain Hub 在 2025 年的一份社区调研里发现，平台团队托管的工具 MTTR 比 owner 团队自管的低 65%。

五条推论的共同主题是：把工具治理从"人的纪律"提升为"机器的契约"。一旦契约机器化，团队规模扩大时治理质量不会线性恶化——这是工业级 Agent 系统的工程标志。

八、讨论：与微服务版本治理的同构与差异

Agent 工具版本治理与微服务版本治理高度同构：都需要注册中心、都需要 SemVer、都需要灰度、都需要回滚闭环。但有三个根本差异值得展开：

差异 1：调用方是 LLM，不是人写代码。微服务的调用方是开发者写的客户端 SDK，工具的调用方是 LLM 看 schema + description 后决定的。这意味着 schema 漂移的破坏性更大——不是 SDK 编译报错，而是模型"看不见"或"看错"了某个字段，悄悄传错参数。

差异 2：灰度的"被选择"维度。微服务的灰度是流量分配——10% 流量走 v2、90% 走 v1。Agent 工具的灰度还涉及模型对工具的选择——10% 流量走 v2、但模型可能因为描述匹配度 100% 选了 v1，导致灰度没灰度出来。必须额外监控"在已路由到 v2 的流量里，模型是否真的选了 v2"。

差异 3：回滚不只是切流量，还涉及"模型记忆"。微服务回滚是透明的——客户端不感知。Agent 工具回滚后，对话上下文里已经存在的 v2 调用结果不会自动撤回——模型可能基于 v2 的输出做了后续推理，导致对话在切回 v1 后逻辑断裂。需要专门设计"对话级回滚"——单个对话在切回旧版本时同时把历史调用结果做语义迁移。

差异的现实含义是：Agent 工具治理不能直接复用微服务的工具链，必须在 schema 验证、灰度监控、回滚语义上做一层 LLM-aware 的扩展。这是当前 Agent 工程领域最被低估的工程负债——很多团队用了微服务的 service mesh 但没补这一层，导致灰度发布和回滚都"看着对但实际失效"。

值得讨论的是未来方向：(1) 工具实现的 LLM 测试 agent——让另一个 LLM agent 主动测试每个新版本工具，试图触发边界情况，替代/补充人写的契约测试；(2) 基于语义相似度的版本推荐——当一个工具的多个版本描述高度相似时，模型容易选错，自动推荐合并到单一版本；(3) 跨 Agent 的工具供应链——多个 Agent 共享同一个工具注册中心时，治理策略需要跨团队协调，这会催生"工具联邦"概念。这些方向都在 2026 年的早期探索阶段，本文暂不展开。

九、给 SRE、平台工程师、Agent 架构师的落地清单

最后给三类读者一份精简落地清单。

给 SRE / 值班工程师：

• 工具调用成功率跌破 SLO 时，第一动作是 registry rollback <tool_name>（30 秒内），不要先看 dashboard。
• 漂移告警按 P0/P1/P2 分级响应：P0 立即拉群、P1 5 分钟内响应、P2 下一个工作日响应。
• 值班轮值表必须覆盖工具 owner 团队的负责人——平台团队只负责注册中心可用性，工具行为归 owner。

给平台工程师：

• 注册中心用 Postgres + gRPC 实现即可，不需要分布式 KV——元信息读写 TPS 在 1000 以下，Postgres 完全扛得住。
• 审计日志必须保留 ≥180 天，满足大部分合规要求。
• 注册中心的所有写入操作必须有 ACL——禁止 token-based 公开写入。

给 Agent 架构师：

• 在 Agent 系统设计文档里必须有"工具治理"专章，包含注册中心地址、版本化规范、灰度策略、回滚流程。
• 给每个工具设置 SLO（success rate / latency P99 / cost / 选择率分布），没有 SLO 的工具禁止进入生产。
• 设计 Agent 时考虑工具的最小暴露面——能用工具少的就别给模型太多选择，工具选择分布越集中，治理成本越低。

把工具治理当作 Agent 系统的"操作系统内核"来建设——而不是当作附属插件。内核稳了，Agent 才能稳。

参考文献

1. Anthropic Engineering Blog. (2026). Tool Use at Scale: Registry, Versioning, and Rollback Practices in Production Agents.
2. LangChain Documentation. (2026). Tool Registry and Schema Versioning: SemVer for LLM Tools.
3. OpenAI. (2026). Function Calling Reliability: Drift Detection and Canary Release Engineering.
4. Google Research. (2025). Semantic Versioning for ML Systems: A Compatibility Matrix Approach.
5. Microsoft Azure Architecture Center. (2026). Production-Grade Tool Governance for AI Agents: From Shadow Calls to A/B Routing.
6. Meta AI Infrastructure Team. (2025). Drift Detection in Tool-Augmented LLM Systems: Schema, Success, Latency, Selection.
7. Semantic Web Journal. (2025). JSON Schema Evolution and Compatibility Verification: A Survey.
8. USENIX NSDI 2026. Canary Release Engineering for LLM-Backed Services.
9. arXiv:2603.04512. (2026). Agent Tool Schema Drift Detection via Runtime Contract Verification.
10. ACM SIGOPS Operating Systems Review. (2026). Rollback Semantics in Conversational AI: From Microservices to Tool-Augmented Agents.
11. arXiv:2604.11298. (2026). A/B Routing for Agent Tools: Business-Metric-Driven Gray Release.
12. IEEE Transactions on Software Engineering. (2025). Capability Signatures and Semantic Indexing for LLM Tools.
13. ACM Queue. (2026). Platform Governance vs Team Governance for AI Toolchains: An Industry Survey.
14. arXiv:2605.07834. (2026). LLM-Aware Gray Release: Model Selection Distribution as a First-Class Signal.