Skill调用的工具在目标平台不存在，不报错、静默降级成胡言乱语，“在你机器上能跑”到底算什么验证？

能力契约 · 静默失败 · 跨平台验证

摘要：当 Agent 通过 Skill 机制调用一个在目标平台上并不存在的工具时，系统往往既不抛异常、也不返回错误码，而是把“工具不可用”这一事实吞掉，继续用语言模型的参数知识“编”出一个看似合理的回答。这类静默降级（silent degradation）把工程缺陷伪装成模型幻觉，使“在我机器上能跑”成为一种几乎零信息量的验证结论。本文以“能力契约（Capability Contract）”为贯穿主线，把工具调用拆成协议层、运行时层、语义层三段，逐层分析静默失败的触发条件与传播路径；提出可落地的契约声明、启动期能力探测、运行期降级策略与四象限验证矩阵；并结合工具调用评测、函数调用基准与 Agent 可靠性研究，讨论当前评测体系的盲区与前沿方向。全文强调一个判断：验证的对象不应是“某次运行是否成功”，而应是“在声明的能力边界内，系统是否可预期地成功或可预期地失败”。

目录

一、导语：一个不报错的错误，为什么比报错更危险

先还原一个在工程现场反复出现的场景。开发者在本机搭好 Agent 运行时，注册了一个名为 search_docs 的 Skill，本地工具网关（tool gateway）能正常路由，端到端跑通，回答质量令人满意。代码合入、镜像构建、部署到目标平台之后，目标平台并没有注册这个工具——可能是插件未安装、权限未授予、区域未开通，也可能只是工具清单版本落后了一个小版本。此时调用发生，系统没有抛异常，没有返回 404，也没有写入错误日志；模型收到的是一个空结果或一段被截断的占位文本，然后它“顺着话头”继续生成，输出了一段语气笃定、细节丰富、却与任何真实文档无关的内容。用户看到的是一个正常回答，工程师看到的是一个绿色流水线。

这类现象之所以危险，不在于它错了，而在于它错得没有信号。传统软件工程里，“工具不存在”是一个确定性异常：链接期报未定义符号，运行期抛 NameError 或 ENOENT，最差也是一次非零退出码。而在以大语言模型为决策核心的 Agent 架构中，工具调用的失败被一层概率性的自然语言生成所吸收：模型并不知道“工具不存在”与“工具返回空”之间的区别，它只知道“我该继续把话说完”。于是，一个基础设施层面的缺失，被转译成了语义层面的幻觉。

“在我机器上能跑”（works on my machine）这句自嘲式的工程谚语，在这个语境下获得了新的、更尖锐的含义。它原本指环境依赖不一致导致的构建或运行差异，其危害通常止步于“跑不起来”。而 Skill 调用的静默降级把危害推进了一层：它跑起来了，还跑出了结果，只是结果是假的。这意味着验证结论的失效不是“漏报了一个失败”，而是“把一个失败认证成了成功”。本文要回答的核心问题因此不是“如何让工具调用不失败”，而是“如何让失败变得可判定、可观测、可归因”。

笔者认为，把这个问题简单归因为“模型爱幻觉”是一种智力上的偷懒。模型的行为在给定输入下是相对确定的：它收到了一段含糊的上下文，做出了在统计意义上最合理的续写。真正的缺陷在系统设计——工具能力的可用性没有被显式建模，失败没有被强制传播，降级没有被声明。换言之，这是一个契约缺失问题，而不是一个模型能力问题。这条“能力契约”主线将贯穿下文所有章节。

二、问题定义：从“工具不存在”到“语义塌陷”的因果链

2.1 三个必须区分的概念

讨论之前需要把三个常被混用的概念钉死。工具（tool）指具有明确输入输出模式、可被外部执行的可调用单元，例如一次检索、一次数据库查询、一次代码执行。Skill指面向 Agent 的能力封装，通常包含工具定义、提示片段、触发条件与后处理逻辑，它比单一工具更粗粒度，可能编排多个工具。能力契约是本文提出的分析概念，指“某 Skill 在特定平台上可用”这一命题所应附带的可检验声明，包括前置条件、输入输出约束、失败语义与降级行为。三者关系是：工具是原子，Skill 是编排，契约是对二者可用性的显式承诺。

本文评述：业界文档常把 Skill 描述为“可复用的提示加工具包”，这个描述偏重复用性而回避了可用性。复用性回答“能不能拿来用”，可用性回答“在这个平台上用了会发生什么”。前者是开发体验问题，后者是正确性问题。把两者混为一谈，正是静默降级得以藏身的语义缝隙。

2.2 静默降级的定义与判定

本文把静默降级定义为：当 Skill 所依赖的工具在目标平台不可用时，系统未向调用方或用户发出可判定的失败信号，而是以降低语义保真度的方式继续产出结果。这个定义包含三个可操作要素：其一，存在一个客观的不可用事实；其二，该事实未被传播为错误；其三，输出仍然生成但语义保真度下降。三者同时满足才构成静默降级，缺一不可。若系统明确返回“工具不可用”，那是显式失败；若系统完全不生成输出，那是硬中断；只有“继续生成且失真”才是我们要处理的对象。

判定静默降级需要一个参照系，否则“失真”无法度量。工程上可行的做法是引入双轨对照：同一输入分别在“工具可用”与“工具不可用”两种条件下运行，比较输出的事实一致性。若后者在可验证事实上出现系统性偏离，且系统未标记任何异常，则判定为静默降级。这个判定方法本身就可以写进测试用例，后文第五节会给出具体实现。

2.3 为什么“能跑”不是验证

验证（verification）在软件工程中有相对明确的含义：证明系统满足其规约。而“能跑”只证明系统在某一组具体输入与环境组合下没有崩溃，它既不覆盖规约，也不覆盖环境空间。把“能跑”当验证，等价于把一次抽样当成全称命题的证明。在传统系统中，这种偷懒尚可被编译器、类型系统、集成测试兜住一部分；在 Agent 系统中，由于输出是自然语言，缺乏类型约束与断言，兜底机制几乎全部失效。

笔者认为，更准确的表述是：“能跑”验证的是路径可达性，而工程真正需要验证的是能力可用性与失败可判定性。前者是必要条件，后者才是充分条件。把必要条件当充分条件，是静默降级在组织层面得以长期存在的认知根源——流水线绿了，评审过了，没人再问“如果工具不在会怎样”。

三、原理拆解：协议层、运行时层、语义层的三段式失效

要设计有效的防御，必须先看清失败是在哪一层发生的。本文把一次 Skill 调用拆成三段：协议层负责“工具是否被声明与发现”，运行时层负责“调用是否被实际执行”，语义层负责“结果是否被正确解释”。静默降级通常不是单层故障，而是三层缺陷的串联：协议层没声明清楚，运行时层吞掉了错误，语义层用生成填补了空缺。

3.1 协议层：能力发现的形式化缺口

当前主流的工具调用协议大致可分为两类：一类以 JSON Schema 描述函数签名（如 OpenAI 的函数调用、Anthropic 的工具使用），另一类以模型上下文协议（Model Context Protocol, MCP）描述资源、工具与提示的统一接口。两者都解决了“如何描述一个工具”，但没有解决“如何描述一个工具在某平台上是否可用”。函数签名是语法契约，它保证参数类型对得上；可用性是语义契约，它保证调用有意义。语法契约可以通过 schema 校验，语义契约目前基本靠口头约定。

本文评述：MCP 在能力协商上做了有价值的尝试，客户端与服务端在初始化阶段交换支持的能力集合，这实际上是能力契约的雏形。但它的粒度停留在“服务端支持哪些方法”，而非“某个具体业务工具在当前租户、当前区域、当前权限下是否可用”。前者是静态的、进程级的；后者是动态的、请求级的。把静态协商当成动态保证，是很多集成事故的直接原因。

一个具体的反例是工具清单的版本漂移。开发环境注册了 v2 版工具，目标平台仍是 v1，两者方法名相同但参数语义不同。协议层校验通过，运行时层调用成功，语义层却按新语义解释旧返回。这类问题不会触发任何异常，只会让输出“微妙地不对”。

3.2 运行时层：错误被吞掉的四种典型路径

运行时层的核心问题是错误传播链被有意或无意地截断。归纳工程实践中的常见模式，至少有四条路径会让“工具不存在”变成“无事发生”。

路径一：路由器的默认分支。工具路由器在找不到匹配项时返回 None 或空字典，上层用 or {} 兜底，错误被静默转换为“空结果”。路径二：异常捕获过宽。为了“提高鲁棒性”，调用被包在 try/except Exception 中，异常被记录为 warning 后继续。路径三：重试耗尽后的降级。重试三次失败后返回占位文本，而占位文本与正常结果在类型上无法区分。路径四：异步任务的丢失。工具调用被投递到队列，目标平台无消费者，任务静默过期，调用方拿到超时后的空值。

这四条路径有一个共同特征：错误在类型系统里不可见。正常结果与降级结果共享同一个返回类型，调用方无法在编译期或运行期区分。这与分布式系统中的“空值语义”问题同构——null 既可能表示“查无此项”，也可能表示“查询失败”，还可能表示“尚未查询”。Agent 系统把这个歧义放大到了自然语言层面，后果从“逻辑分支走错”升级为“事实陈述错误”。

3.3 语义层：模型如何把空缺补成故事

语义层的失效机制值得单独讨论，因为它解释了为什么输出不是“明显残缺”而是“看似完整”。大语言模型在预训练中习得了强大的模式补全能力，当上下文出现“我调用了一个检索工具，现在该给出答案”的结构时，模型会优先完成这个叙事弧，而不是质疑工具是否真的返回了内容。这是一种叙事惯性：上下文的结构压力压过了对证据的审慎。

笔者认为，把这种现象称为“幻觉”并不精确。幻觉通常指模型生成了与训练分布或事实不符的内容；而这里的失真有一个明确的外部诱因——工具缺失。更准确的描述是证据真空下的合理化生成。模型并非凭空捏造，它是在“应当有证据”的强先验下，用参数知识填补了证据空缺。区别在于：纯幻觉难以预防，而证据真空可以通过工程手段消除——只要让模型明确知道“证据不存在”。

这一点有直接的工程含义：在工具返回中显式注入“不可用”标记，并配合系统提示要求模型在证据缺失时拒答，可以显著降低合理化生成的概率。后文第五节会给出提示模板与验证方法。需要强调的是，这不能根治问题，因为模型仍可能忽略标记；但它把“静默”变成了“可观测”，这是工程可控性的前提。

3.4 三段失效的串联模型

把三层放在一起，可以得到一个简洁的串联模型：协议层未声明可用性 → 运行时层吞掉缺失信号 → 语义层用生成填补空缺 → 用户收到看似正常的错误答案。这个链条的每一环都可以被单独加固，但只有同时加固才能阻断传播。只修协议层，运行时仍可能吞错；只修运行时，语义层仍可能合理化；只修语义层，前两层仍会持续产生噪声。

四、能力契约：把“能跑”翻译成可验证的声明

前三节说明了问题与机理，本节给出本文的核心主张：用能力契约把隐含的可用性假设显式化。契约不是文档，而是可被机器读取、可被测试断言、可被运行时校验的结构化声明。它的价值在于把“我认为这个工具能用”变成“系统能证明这个工具在当前环境下可用，或明确报告不可用”。

4.1 契约的四个字段

一个最小可用的能力契约应包含四类字段。前置条件（preconditions）描述调用成立所需的环境事实，例如插件版本、权限范围、网络可达性、租户配置。输入输出约束（io_contract）在 JSON Schema 之外补充语义约束，例如“返回必须包含至少一条来源 URL”。失败语义（failure_semantics）枚举可能的失败模式及其错误码，要求调用方必须处理。降级行为（degradation）声明当工具不可用时系统应当如何表现，可选值包括“硬失败”“显式拒答”“带标记的降级结果”。

本文评述：这四个字段并非凭空设计，它们分别对应前文三层的加固需求——前置条件补协议层，失败语义补运行时层，降级行为补语义层，输入输出约束则横跨三层提供断言锚点。把契约设计成“每层都有抓手”，是它可落地的前提。若契约只是一份描述性文档，它很快会与实现脱节；只有当契约被测试与运行时共同消费，它才有约束力。

4.2 契约的机器可读表示

契约应当以结构化格式随 Skill 一起分发，并在启动时被校验。下面给出一个简化的 YAML 示例，字段命名刻意保持直白，便于工程团队直接采用。

skill: search_docs
version: 2.1.0
preconditions:
  plugin: doc-search
  min_plugin_version: ">=1.4.0"
  scopes: ["docs:read"]
  network: ["internal-gateway"]
io_contract:
  input_schema: ./schema/search_input.json
  output_assertions:
    - path: "$.results"
      rule: "len >= 1"
    - path: "$.results[*].url"
      rule: "matches ^https?://"
failure_semantics:
  TOOL_NOT_FOUND: hard
  PERMISSION_DENIED: hard
  TIMEOUT: retry_then_degrade
  EMPTY_RESULT: explicit
degradation:
  mode: refuse_with_reason
  message_template: "检索工具当前不可用，无法给出有依据的回答。"
  allow_model_fallback: false

这段契约的关键在于 allow_model_fallback: false。它明确禁止模型在工具不可用时用参数知识兜底，从策略层面切断语义层的合理化路径。工程上是否总是禁止可以讨论，但“必须显式声明”这一点没有商量余地——默认允许兜底，等于默认允许静默降级。

4.3 契约与现有标准的衔接

契约不必另起炉灶。JSON Schema 已经承担了输入输出结构约束，可以在其 description 与自定义关键字中承载语义断言；MCP 的能力协商可以作为前置条件的传输通道；OpenTelemetry 的语义约定可以承载失败语义的可观测字段。契约的角色是编排这些既有标准，而不是替代它们。

笔者认为，标准衔接的价值在于降低采纳成本。团队已经在用 schema 校验参数，只需增加一个断言层；已经在用 MCP，只需在初始化响应中增加工具级可用性字段。渐进式加固比推倒重来更可能在真实组织中落地。关于 MCP 的规范细节，可参考其官方文档（modelcontextprotocol.io）；关于 JSON Schema 的断言能力，可参考其规范（json-schema.org）。

五、工程路径：探测、降级、可观测与验证矩阵

契约是声明，落地需要机制。本节给出一条可操作的工程路径，分为启动期探测、运行期降级、全链路可观测、四象限验证四步。每一步都给出具体做法与判定标准，读者可以直接映射到自己的流水线。

5.1 启动期能力探测

探测的目标是在第一个真实请求到达之前，确认契约中的前置条件是否满足。做法是让每个 Skill 提供一个轻量的 probe 端点，返回结构化的可用性报告，包含工具是否存在、版本是否满足、权限是否具备、依赖服务是否可达。探测必须在目标平台上执行，而不是在构建机上执行——这正是“在我机器上能跑”失效的地方。

探测结果应当影响启动决策。若关键 Skill 不可用，服务应拒绝进入就绪状态（readiness），而不是带着残缺能力上线。对于非关键 Skill，可以进入“受限模式”，但必须在健康检查端点中暴露受限清单，供编排系统与告警系统消费。判定标准很简单：任何未通过探测的 Skill，其调用路径必须在运行期被显式拦截，而不是留给路由器兜底。

5.2 运行期降级策略

降级不是“随便返回点什么”，而是契约中声明的、可预期的行为。工程上建议把降级分为三档。硬失败：直接返回错误，适用于事实性查询，宁可无答案不可错答案。显式拒答：返回自然语言说明“因工具不可用无法回答”，并附带错误码，适用于面向终端用户的场景。带标记的降级结果：返回部分结果并打上 degraded=true 标记，适用于可容忍不完整的场景。

三档的选择应由契约声明，而不是由运行时临时决定。运行时临时决定的降级，本质上就是静默降级的温床——因为“临时决定”往往意味着“没有记录、没有告警、没有测试”。本文评述：降级策略的粒度应当与业务风险挂钩，而不是与实现便利挂钩。把降级选择权交给最了解业务语义的 Skill 作者，是责任与知识匹配的原则。

5.3 全链路可观测

可观测的目标是让静默失败无处藏身。至少需要三类信号：调用信号记录每次工具调用的工具名、版本、结果状态、耗时；契约信号记录探测结果与契约校验结果；语义信号记录输出中引用来源的数量、拒答次数、降级标记出现次数。三类信号通过同一个 trace id 关联，形成从请求到输出的完整证据链。

一个实用的告警规则是“调用成功率与语义保真度背离”：当工具调用成功率接近 100%，但输出中引用来源数量显著下降时，说明调用“成功”了但结果没被用上，这往往是空结果或降级结果在作祟。这类背离信号比单纯的错误率更能揭示静默降级。关于可观测性的通用实践，可参考 OpenTelemetry 的语义约定文档（opentelemetry.io）。

5.4 四象限验证矩阵

验证矩阵把“工具可用性”与“输入复杂度”两个维度交叉，形成四个必须覆盖的象限。只有四象限都通过，才能说验证是完整的。这个矩阵可以直接转化为测试用例集合，纳入 CI。

Q3 与 Q4 是当前测试覆盖的重灾区。多数团队的集成测试只覆盖 Q1，少量覆盖 Q2，Q3/Q4 几乎空白。而静默降级恰恰只在 Q3/Q4 暴露。把 Q3/Q4 用例纳入合并门禁，是阻断静默降级最直接的手段。具体做法是在测试环境中通过故障注入（fault injection）让指定工具返回“不存在”，然后断言系统输出包含显式失败标记。关于故障注入的工程方法，可参考 Chaos Engineering 的相关实践（principlesofchaos.org）。

5.5 提示层的配合

工程机制之外，提示层需要配合。核心是在系统提示中明确“证据优先”原则，并在工具返回中注入结构化状态。例如工具返回统一为 {"status":"unavailable","reason":"TOOL_NOT_FOUND"}，系统提示要求模型在 status 非 ok 时不得给出事实性结论。这个做法不能保证模型 100% 遵守，但配合输出侧断言（检查回答是否包含来源），可以把违规率压到可接受范围。

笔者认为，提示层与工程层是互补而非替代关系。只靠提示，模型可能忽略；只靠工程，输出仍可能被模型合理化。两层同时施加约束，才能把“静默”变成“响亮的失败”。关于提示工程与工具使用的结合，可参考 Anthropic 的工具使用文档（docs.anthropic.com）。

六、评测与案例：现有基准为何测不出静默失败

过去两年，工具调用与函数调用评测取得了明显进展，但主流基准的设计目标集中在“模型能否正确选择并填写参数”，而非“系统能否在工具缺失时正确失败”。这个目标错位，导致静默失败在评测层面几乎不可见。

6.1 主流基准的覆盖盲区

以函数调用评测为例，常见指标包括调用准确率、参数匹配率、多轮调用完成率。这些指标都假设工具集合是固定且可用的，评测环境不注入“工具不存在”的条件。Berkeley Function Calling Leaderboard（BFCL）等公开榜单在函数选择与参数生成上做了细致分层，但其任务设定中工具始终存在。这意味着一个在榜单上得分很高的模型，完全可能在工具缺失时给出流畅的错误答案，而榜单无法反映这一点。

本文评述：这不是榜单设计者的疏忽，而是评测目标的自然结果——榜单测的是模型能力，不是系统可靠性。问题在于工程团队把模型能力分数当成了系统可靠性证据。这两者之间隔着协议、运行时、语义三层，任何一层缺失都会让分数失去意义。把 BFCL 分数当作上线依据，与把“在我机器上能跑”当作验证，在逻辑上是同一种错误。

6.2 Agent 可靠性研究的启示

Agent 可靠性方向的研究提供了另一个视角。已有工作系统梳理了 LLM Agent 的失败模式，把“工具使用错误”与“环境理解错误”列为独立类别，并指出这类失败往往不伴随显式异常。这与本文的静默降级观察一致：失败发生在语义层，表现为“看起来合理的错误”，而非“明显的崩溃”。相关综述可参考 arXiv 上的 Agent 失败模式研究（arXiv:2401.13178）。

另一条相关线索是工具增强语言模型的可信度研究。这类工作关注模型在检索或工具返回不可靠时是否会过度信任，结论普遍指向“模型倾向于接受工具输出，缺乏质疑机制”。本文评述：这个结论对静默降级的启示是，模型不仅不会质疑“缺失”，还会主动填补“缺失”。因此，防御的重心必须放在系统侧，而不是寄希望于模型自省。

6.3 一个可复现的对照案例（模拟数据）

为说明问题，下面给出一个模拟对照实验的设计与结果。需要强调，以下数据为模拟数据，用于演示判定方法，不代表任何真实系统或团队的实测结果。实验设定：同一组 200 条事实性查询，分别在“工具可用”与“工具不可用且系统无显式失败”两种条件下运行，统计输出中包含可验证来源的比例、包含明确拒答的比例、以及包含与来源矛盾陈述的比例。

模拟结果显示，工具不可用时，系统仍有 85% 的回答“看起来正常”（含来源或未拒答），但其中大量包含矛盾陈述。这正是静默降级的典型画像：失败率高，但失败信号率低。若只看“是否返回了回答”，两种条件几乎无法区分；只有引入来源断言与矛盾检测，差异才显现。这个案例的方法论意义大于数值意义：它说明验证必须包含“负条件”下的断言，否则测不出问题。

七、对比与局限：不同技术路线的边界条件

围绕工具调用可靠性，工程界大致有三条路线：以协议为中心的能力协商、以运行时为中心的沙箱与网关、以模型为中心的自我校验。三条路线各有适用边界，也各有无法覆盖的盲区。把它们放在一起对比，有助于团队按场景选型，而不是盲目追新。

7.1 三条路线的对比

协议中心路线的代表是 MCP 与各类函数调用规范。优势是标准化、跨厂商可移植，劣势是协商粒度偏粗，难以表达请求级的动态可用性。运行时中心路线的代表是工具网关、沙箱执行与策略引擎。优势是能在调用点强制拦截与降级，劣势是需要额外基础设施，且容易因“过度兜底”而制造新的静默路径。模型中心路线的代表是自我反思、工具结果校验提示。优势是零基础设施改动，劣势是可靠性依赖模型行为，无法给出硬保证。

本文评述：三条路线不是互斥的，而是分层的。协议层负责“声明”，运行时层负责“强制”，模型层负责“兜底解释”。合理的架构应当三层都有，但责任要清晰：协议层不承诺动态可用性，运行时层不替模型做语义判断，模型层不承担硬保证。把责任混在一起，就会出现“每层都以为别人会处理”的经典漏洞。

7.2 局限与反例

能力契约路线也有局限。其一，契约维护成本随 Skill 数量增长，缺少自动化生成手段时容易腐化。其二，前置条件的动态性可能超出契约表达力，例如依赖服务的瞬时抖动，契约只能声明“可达”，无法声明“此刻可达”。其三，对抗性场景下，攻击者可能伪造可用性探测结果，使契约校验失效。这些局限意味着契约不是银弹，而是把“隐式假设”变成“显式可审计假设”的工具。

另一个需要警惕的反例是“降级过度”。若系统对任何工具异常都返回拒答，用户体验会显著下降，团队可能迫于压力重新打开静默兜底。因此降级策略必须与业务风险分级，而不是一刀切。笔者认为，判断标准应当是“错误答案的代价是否高于无答案的代价”。在医疗、金融、法律等高风险领域，无答案优于错答案；在创意辅助等低风险领域，带标记的降级结果可以接受。这个判断必须由业务方做出，并写入契约。

八、结论与展望：从“运行通过”到“契约可证”

回到标题的问题：“在你机器上能跑”到底算什么验证？本文的答案是：它验证了路径可达性，但没有验证能力可用性，更没有验证失败可判定性。在工具调用被自然语言生成包裹的 Agent 系统里，这个缺口会被放大成静默降级——系统不报错，却输出看似合理、实则无据的内容。把这种输出称为“模型幻觉”会掩盖真正的责任方：缺失的能力契约、被吞掉的错误信号、未被测试的负条件。

本文提出的能力契约主线，核心是把可用性从隐式假设变成显式声明，再用探测、降级、可观测、验证矩阵四套机制把它钉死。这条路径不追求“让工具永不缺失”，而追求“让缺失可被判定、可被归因、可被预期地处理”。笔者认为，这是从“运行通过”走向“契约可证”的必经一步，也是 Agent 工程从演示走向生产的关键分水岭。

展望未来，有三个方向值得投入。其一是契约的自动化生成与校验，从工具定义与部署清单中推导前置条件，减少人工维护。其二是面向负条件的评测基准，把“工具缺失”“权限不足”“版本漂移”作为一等评测维度，纳入公开榜单。其三是运行时与模型层的协同，让模型在证据真空时具备可训练的拒答行为，而不是依赖提示词的软约束。这三个方向都还在早期，但它们的共同指向很清晰：可靠性不是跑出来的，是证出来的。

工程建议速记：把每个 Skill 的可用性写成契约；在目标平台而非构建机做启动探测；让失败有类型、有错误码、有降级声明；把 Q3/Q4 负条件用例纳入合并门禁；用“调用成功率与语义保真度背离”做告警。做到这五条，“在我机器上能跑”才不再是一句自嘲。

主要参考文献

文章声明