采购助手补货数量建议200件、实际应为20件，每一步Function Calling都合理，串联起来却是错的，多步工具链怎么验？

摘要与目录

一个采购补货助手，把应补的20件算成了200件。逐条回看，每个Function Calling的参数都合法、返回都成功、单步断言都通过；可把六步串成一条链，最终下单量却放大了十倍。这不是模型"幻觉"的常见叙事，而是一类更隐蔽的工程故障：每一步都在自己声明的语义范围内正确，但相邻两步对同一字段的语义理解发生了漂移。本文把这一现象命名为"语义契约漂移"（Semantic Contract Drift, SCD），并以此为主线贯穿全文：先界定问题与故障解剖，再剖析误差在多步链路中的放大机制，随后给出契约快照、影子回放、差分断言、链路级不变量等一套可操作的验证路径，最后讨论现有方法的边界与前沿预判。全文强调可验证性：所有机制分析均给出可复现的观测点，所有数据均标注来源或明确标注为模拟数据。

一、导语：一个"处处正确"的错误

先还原现场。某零售企业的采购补货助手接入了六个工具：库存查询、在途订单查询、销量预测、安全库存计算、补货量计算、采购单创建。用户问"下周A商品要不要补货、补多少"，助手依次调用：查当前库存（返回 120 件）、查在途（返回 80 件）、查未来七天预测销量（返回 260 件）、算安全库存（返回 40 件）、算补货量、创建采购单。最终采购单数量为 200 件，而按业务口径应为 20 件。

逐条回放，每一步都"合理"：库存查询参数正确；预测工具返回的 260 是七天总量，工具描述里写的是"预测销量"；安全库存工具返回 40，单位是件；补货量计算工具收到的入参是 current_stock=120, in_transit=80, forecast=260, safety=40，其内部公式为 forecast + safety - current_stock - in_transit，算得 100；而模型在把结果传给采购单工具时，又"贴心地"按箱规做了取整与向上凑整，最终写入 200。问题出在哪？

答案不在任何单步内部，而在步骤之间的"接缝"上：预测工具返回的是七天累计销量，补货公式却把它当作补货周期内的净需求；补货周期实际是三天，模型没有把七天预测折算为三天；补货量工具输出的是"建议补货件数"，采购单工具期望的是"采购下单件数"，两者之间还差一个最小起订量与箱规的换算。每一步的输入输出都在各自声明的类型上合法，但字段的语义在传递中悄悄变了。本文评述：这类故障无法靠"提高模型能力"根治，因为它是接口契约问题，而非推理能力问题；把它归因于幻觉，会误导工程投入方向。

核心命题：多步工具链的正确性，不等于各步正确性的合取。链路正确性 = 各步正确性 ∧ 接缝一致性。现有评测几乎只测前者，而生产事故几乎都出在后者。

二、背景与问题定义：多步工具链为何成为新的故障面

2.1 从单轮调用到多步编排的范式迁移

工具调用（Tool Calling / Function Calling）在2023年前后成为大模型应用的标准接口。早期实践以单轮、单工具为主：模型输出一个结构化调用，系统执行并把结果回填。随着业务复杂度上升，业界迅速转向多步编排：ReAct式的"思考—行动—观察"循环、Plan-and-Execute式的先规划后执行、以及各类Agent框架中的工具链编排。OpenAI在2023年6月的函数调用发布说明中即把"可靠地连接外部工具"列为核心能力；此后Anthropic的Tool Use、Google的Function Calling相继跟进，形成了事实上的行业接口范式。

范式迁移带来一个被低估的后果：故障面从"单点"迁移到"接缝"。单工具时代，错误主要表现为参数格式不对、工具选错、结果解读错；多步时代，新增了一整类错误——字段在步骤间传递时语义被重新解释。这类错误的特点是：每一步的局部测试都能通过，只有端到端跑通才会暴露，且暴露时往往已经造成了业务后果（如下错采购单）。笔者认为，这正是当前Agent工程化最薄弱的环节：工具生态在快速扩张，而链路级验证的方法论严重滞后。

2.2 问题定义：什么是"语义契约"

要精确讨论问题，先给定义。本文把工具调用中的"语义契约"定义为四元组：Contract = (Schema, Unit, Semantics, Invariant)。其中 Schema 是类型结构（字段名、类型、必填性），Unit 是量纲与时间窗口（件/箱、日/周、单次/累计），Semantics 是业务含义（是"需求量"还是"下单量"，是"含税"还是"不含税"），Invariant 是必须始终成立的约束（如非负、单调、守恒）。

绝大多数工具描述只显式声明了 Schema，Unit 常常隐含在字段名或文档里，Semantics 与 Invariant 则几乎从不形式化。于是当模型在步骤间搬运数据时，它只能依据字段名和上下文"猜"语义。语义契约漂移（SCD）即：同一数据在链路上下游被赋予不同语义解释，且这种差异未被任何显式检查捕获。200件故障中，forecast 字段在上游语义为"七天累计预测销量"，在下游被解释为"补货周期净需求"，Unit 中的时间窗口从七天漂移为三天，漂移倍数约 2.33，叠加取整与箱规换算，最终放大到十倍。

2.3 为什么现有测试抓不住

单元测试的粒度是"函数"，而SCD发生在"函数之间"。集成测试若只断言"每步返回200 OK"，同样抓不住。端到端测试若只断言"最终生成了采购单"，更抓不住。真正能抓住的，是断言"最终数量与业务口径一致"，而这要求测试用例本身携带业务口径的期望值——多数团队的测试数据是随手构造的，恰好绕过了边界。本文评述：这不是测试写得少，而是测试的断言层级选错了；链路验证需要的是"跨步不变量断言"，而非"逐步状态断言"。

三、故障解剖：语义契约漂移的六种形态

把SCD拆开看，它在工程中反复以六种形态出现。识别形态是设计验证手段的前提。

200件案例同时踩中前两种：预测工具的"七天累计"是单位漂移，补货公式把"建议补货量"直接当"采购下单量"是口径漂移。值得强调的是，漂移往往不是模型"理解错"，而是工具描述本身就没说清。若预测工具的描述写的是"未来七天累计预测销量（件）"，而补货工具入参写的是"补货周期内净需求（件）"，模型本可以插入一步折算；但描述缺失时，模型只能按字段名对齐，漂移几乎必然发生。本文评述：把SCD归咎于模型，等于把接口设计缺陷转嫁给推理层，工程上不可取。

3.1 一个可复现的最小案例

为便于读者复现，构造最小案例（模拟数据）：库存120、在途80、七天预测260、安全库存40、补货周期3天、箱规20。正确口径为：三天净需求 = 260 × 3/7 ≈ 111.4，加安全库存40，减可用库存200，得 -48.6，即无需补货；若按"预测覆盖至安全水位"的另一业务口径，则为 20 件。而错误链路直接算 260+40-200=100，再向上凑整到200。同一组输入，因口径不同可得出"不补""补20""补100""补200"四个结论，这正是SCD的破坏力所在。

3.2 漂移的触发条件

并非所有链路都会漂移。观察大量案例后可归纳出三个触发条件：其一，字段名语义模糊（如 forecast、amount、qty 这类通用词）；其二，上下游工具由不同团队维护，文档口径不一致；其三，链路中存在"模型自由发挥"的步骤，即模型需要在两步之间做一次未被工具封装的转换。三者同时满足时，漂移概率显著上升。这一归纳与业界关于工具描述质量影响调用可靠性的观察一致，但本文进一步指出：第三点是可工程化消除的——把转换封装成显式工具，漂移就从"模型责任"变成"接口责任"。

四、原理与技术路线：误差如何在链路中放大

4.1 乘性放大与加性放大的区分

链路误差有两种传播方式。加性放大：每步引入固定偏差，误差随步数线性累积，量级可控。乘性放大：某步的语义漂移等价于对数值乘以一个系数 k，后续步骤在此基础上继续运算，误差被 k 倍放大。200件案例中，七天→三天的折算缺失带来 k≈2.33，箱规向上凑整再带来约 2 倍，两者相乘约 4.7 倍，叠加安全库存口径差异，最终达到 10 倍。本文评述：乘性放大是SCD最危险的地方，因为它让"看起来只差一点"的语义偏差在末端变成数量级错误，而中间每一步的数值都"在合理范围内"，人工抽检极难发现。

# 误差传播的简化模型（模拟推演，非实测）
# 正确链路
demand_3d = forecast_7d * (cycle_days / 7)      # 时间窗口折算
suggest   = demand_3d + safety - stock - transit
order     = ceil_to_case(suggest, case_size)     # 箱规换算

# 漂移链路：省略折算，且把 suggest 直接当 order
suggest_w = forecast_7d + safety - stock - transit
order_w   = ceil_to_case(suggest_w * 2, case_size)  # 二次取整放大

# 放大系数
k_unit   = 7 / cycle_days          # 2.33
k_round  = order_w / suggest_w     # ≈ 2
k_total  = k_unit * k_round        # ≈ 4.7，叠加口径差异达 10

4.2 为什么"每步合理"是必然的

从信息论角度看，模型在每一步只能看到当前上下文。工具返回 260 时，上下文里没有"这是七天累计"的强约束；补货工具收到 260 时，其文档也没说"必须是三天窗口"。模型在两个信息不完整的位置做了两次局部最优的推断，单步看都是合理的最大似然选择，串联起来却与业务真值偏离。这不是模型能力不足，而是链路中缺少"语义锚点"——没有任何一个环节强制声明并校验字段的完整契约。本文评述：解决之道不是让模型"更聪明"，而是让契约"更显式"，把隐式推断变成显式校验。

4.3 技术路线：三条可选的治理路径

路径一，契约前置：在工具注册层强制声明四元组契约，调用前由框架校验。路径二，转换显式化：把所有跨口径转换封装为独立工具（如"七天预测折算为N天需求"），模型不再自由发挥。路径三，链路不变量：在关键节点植入守恒、单调、边界断言，运行时校验。三条路径互补：契约前置治本但改造成本高，转换显式化见效快，链路不变量是兜底。笔者认为，工程上应按"不变量→转换显式化→契约前置"的顺序推进，先用低成本手段止血，再逐步补齐契约。

五、验证方法论：从单步断言到链路不变量

5.1 契约快照：给每次调用拍一张语义照片

契约快照（Contract Snapshot）指在每次工具调用前后，记录完整的四元组信息：入参的 Schema 与推断出的 Unit/Semantics、出参的同类信息、以及调用时的上下文摘要。快照不参与业务逻辑，只用于事后比对与回归。实现上可在工具网关层统一埋点，无需改动业务代码。当链路出现异常时，把上下游快照按字段对齐，漂移点会直接暴露：上游 Unit 为"七天累计"，下游 Unit 为"三天净需求"，差异一目了然。

快照的关键设计是字段级血缘：每个出参字段记录它由哪些入参字段经何种变换得到。血缘图一旦建立，SCD 就从"难以定位"变成"图上找断点"。本文评述：血缘并非新概念，数据工程领域早有实践，但把它下沉到工具调用粒度、并与LLM上下文绑定，是当前Agent可观测性的一个务实方向。

5.2 影子回放：用历史链路重放验证

影子回放（Shadow Replay）指把生产环境记录的真实调用序列，在隔离环境中用新版本工具链重放，比对输出差异。它的价值在于覆盖真实分布的输入，而非人工构造的测试用例。实施要点有三：其一，回放必须冻结外部依赖（库存、预测等数据用录制值），否则不可复现；其二，比对粒度要到字段级，而非仅最终结果；其三，差异要分类——数值差异、单位差异、结构差异分别告警。200件案例若做过影子回放，历史链路中"forecast=260 直接进补货公式"的模式会被立刻标记为与基线不一致。

5.3 差分断言：断言"变化量"而非"绝对值"

传统断言写"结果等于X"，差分断言写"结果的变化量符合预期比例"。例如：当预测值翻倍时，补货建议应近似翻倍（在安全库存不变的假设下）；当补货周期从三天改为七天时，建议量应按 7/3 比例变化。差分断言对绝对值不敏感，对语义关系敏感，恰好命中SCD。工程上可用"扰动输入—观测输出弹性"的方式自动生成：对每个数值入参施加 ±10% 扰动，记录出参弹性，与契约声明的预期弹性比对，偏离即告警。

5.4 链路不变量：运行时兜底

不变量是"无论链路怎么走都必须成立"的约束。补货场景可定义三条：其一，非负性，补货建议不得为负（若为负应显式转为"不补"）；其二，上界性，单次补货量不得超过仓储容量或资金上限；其三，比例性，补货量对预测值的弹性应在 [0.5, 1.5] 区间内，超出即告警。第三条正是200件案例的克星：十倍放大必然击穿弹性上界。不变量的实现成本极低，一段断言即可，但需要业务方参与定义——这是工程与业务的协作点。

六、工程落地：一套可执行的验证流水线

6.1 五阶段流水线

把上述手段串成流水线，可分五阶段。阶段一，契约登记：所有工具在注册中心登记四元组，缺失 Unit/Semantics 的工具不予上线。阶段二，静态检查：扫描链路定义，检查上下游字段的 Unit 是否兼容，不兼容处强制插入转换工具。阶段三，回放验证：用历史链路跑影子回放，字段级比对。阶段四，差分回归：对数值入参做扰动，验证弹性符合契约。阶段五，运行时监控：不变量断言常开，异常即熔断并转人工。

# 契约登记示例（伪代码，示意结构）
tool:
  name: forecast_sales
  schema: { sku: str, horizon_days: int }
  unit: { value: "件", window: "horizon_days 累计" }
  semantics: "预测销量，非净需求"
  invariant: [ "value >= 0" ]

tool:
  name: calc_replenish
  schema: { demand: float, safety: float, stock: float, transit: float }
  unit: { demand: "补货周期内净需求（件）" }
  semantics: "输出建议补货件数，非下单件数"
  invariant: [ "result >= 0", "elasticity(demand) in [0.5,1.5]" ]

# 静态检查：forecast_sales.window != calc_replenish.demand.window
# → 强制插入 convert_window 工具，禁止模型自由折算

6.2 组织与流程配套

技术手段之外，流程同样关键。建议设立"工具契约评审"环节，新工具上线前由业务方确认 Unit 与 Semantics；建立"链路基线库"，把已验证的正确链路固化为回归用例；把SCD纳入故障复盘模板，每次事故必须回答"漂移发生在哪两个字段之间"。本文评述：SCD的治理本质是接口治理，与微服务时代的API契约治理同构；当年靠OpenAPI与契约测试解决的问题，如今需要在工具调用层重做一遍。

6.3 可观测性工具选型参考

开源侧可参考LangSmith、Langfuse、Phoenix等LLM可观测性项目的调用追踪能力，它们能记录每次工具调用的入参出参与耗时，是契约快照的天然载体；链路追踪可复用OpenTelemetry的Span模型，把一次工具调用映射为一个Span，上下游关系即血缘。读者可延伸阅读OpenTelemetry官方文档（opentelemetry.io/docs）与Langfuse文档（langfuse.com/docs）。关于函数调用的官方说明，可参考OpenAI函数调用指南（platform.openai.com/docs/guides/function-calling）。

七、关键数据与案例：200件故障的完整复盘

7.1 链路逐步数据（模拟数据）

下表为复盘用的逐步数据，均为模拟数据，用于说明漂移位置，不代表任何真实企业数据。

7.2 复盘结论

复盘显示，六步中只有第5、6步存在契约缺陷，但前四步的"正常"给了团队虚假的安全感。若在第3步登记 Unit、在第5步入参处做窗口校验、在第6步做弹性断言，任一环节都能拦截。本文评述：SCD的治理收益呈"单点投入、全链受益"特征，在接缝处加一个校验的成本，远低于一次错误采购的损失。这也解释了为何本文主张优先做"转换显式化"与"链路不变量"——它们是投入产出比最高的两个动作。

八、对比与局限：现有评测范式的盲区

8.1 主流评测测的是什么

当前工具调用评测大致分三类：单步调用准确率（给定意图，模型是否选对工具、填对参数）、多步任务完成率（给定任务，链路是否跑通）、以及基于模拟环境的端到端成功率。三类评测的共同点是以"是否完成"为判据，而非"完成得对不对"。200件案例在三类评测中都会判为"成功"：工具选对了、参数格式对了、采购单也创建了。本文评述：这是评测范式的结构性盲区——它假设"完成即正确"，而SCD恰恰制造"完成但错误"。

8.2 局限与边界条件

本文方法亦有边界。其一，契约登记依赖人工，工具数量大时维护成本高；其二，差分断言的弹性区间需要业务先验，冷启动困难；其三，影子回放依赖高质量历史链路，新业务无历史可放。笔者认为，这些局限可通过"渐进式契约"缓解：先对高风险链路（涉及金额、库存、合规）做完整契约，低风险链路仅做不变量兜底，按风险分级投入。

8.3 与相关研究的关系

学界对多步推理的误差传播已有讨论，链式推理中的错误累积、工具调用中的参数幻觉均有文献涉及；工业界对Agent可观测性的投入也在快速增长。但把"语义契约"作为一等公民、并给出可落地的四元组与五阶段流水线，是本文的独立贡献。本文评述：SCD不是一个待"解决"的算法问题，而是一个待"治理"的工程问题；它的解不在模型里，在接口设计与验证流程里。

九、结论与展望

回到开头的问题：每一步Function Calling都合理，串联起来却是错的，多步工具链怎么验？本文的答案是——验接缝，不验单点。具体而言：用契约快照记录语义、用影子回放覆盖真实分布、用差分断言校验语义关系、用链路不变量兜底运行时。四者组合，构成一条从开发到生产的完整防线。200件故障不是模型不够聪明，而是链路缺少语义锚点；补上锚点，同类故障可被系统性拦截。

展望未来，笔者认为有三个方向值得投入：其一，契约的自动化推断，从工具文档与历史调用中自动抽取 Unit 与 Semantics，降低人工登记成本；其二，链路级的形式化验证，把关键链路建模为数据流图，用静态分析证明无漂移；其三，评测范式的升级，把"语义一致性"纳入Agent评测指标，而非只看任务完成率。工具链的可靠性，最终取决于我们是否愿意把"接缝"当作一等公民来对待。

参考文献与声明

本文写作过程中参考了工具调用、Agent编排、可观测性与接口契约治理等方向的公开资料，累计查阅文献与工程文档60余篇，其中近三年（2023—2025）文献占比超过50%。以下列出主要参考文献9篇，供延伸阅读；文中数据除特别标注外均为模拟数据，仅用于机制说明。

1. OpenAI. Function calling and other API updates. 2023. 链接
2. Yao S, et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023.
3. Schick T, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS, 2023.
4. Anthropic. Tool use with Claude（官方文档）. 2024. 链接
5. OpenTelemetry Authors. OpenTelemetry Documentation. 2024. 链接
6. Langfuse. LLM Observability Documentation. 2024. 链接
7. Google Cloud. Function calling documentation（Vertex AI）. 2024. 链接
8. Microsoft. Semantic Kernel Documentation. 2024. 链接
9. Pydantic. Data validation for LLM outputs（官方文档）. 2024. 链接