把同一个智能体、同一个任务、同一份上下文跑两遍，结果会一样吗？这是 2026 年 4 月 arXiv 一篇被低估的论文《How Consistent Are LLM Agents?》正面回答的问题：在 19 个任务、6 个模型、1140 条轨迹上，智能体呈现出"结构稳、参数飘"的分裂态——工具调用序列几乎一致（TSS=0.87），但参数显著漂移（AC=0.69，d=0.75，p<10⁻¹³）。更关键的是，只有结构层（调了哪些工具、什么顺序）能预测任务成败，高 TSS 组正确率 90.2% 对低 TSS 组 61.2%，而参数飘动几乎无害。这把"确定性"从一句口号拆成了三层——采样层、训练层、基础设施层，每一层都有不同的税和不同的修法。本文围绕这条主线，叠加本地模型实测中的"并行-顺序悖论"和 BFCL 榜单不迁移现象，拆解工具调用确定性的真实工程账。

一、核心对比：结构层 vs 参数层

六款主力模型在工具调用确定性上的分化（每任务跑 10 次，温度 1.0，10 个确定性模拟工具，来源 arXiv:2605.28840）：

补一张本地栈（Q4_K_M，LM Studio v0.4.6，8 工具 40 用例，温度 0）的实测表，揭示"榜分"与"实分"的鸿沟：

两张表拼出一个反直觉结论：调对序的难度和填对参的难度，是两件事，模型选型对它们的影响方向不同。GPT-4.1-mini 是少数两项都高的；Claude Sonnet 4 在 AC 上反超 GPT-4.1，靠的是"策略会换但参数填得稳"；Llama 3.3 70B 是唯一在结构层明显掉链子的——它每 10 次会跑出 3.3 条不同序列，歧义任务上 TSS 直接跌到 0.54。

二、结构稳、参数飘：为什么工具序列稳如老狗

arXiv 论文最硬的发现是"结构一致性、参数方差"（Structural Consistency, Parametric Variance）模式。它把一条智能体轨迹拆成三层：结构层（工具名序列，"先查后发"的菜谱）、参数层（每步的实参，比如搜索词、日期格式）、输出层（最后那段自然语言）。三层稳定性逐级坍塌：TSS=0.87 → AC=0.69 → 输出精确匹配 <5%。

为什么会这样？论文给出的机制解释是训练信号的不对称。RLHF/SFT 对"调对工具、用对顺序"给出了更干净、更可奖励的信号——发邮件就是发邮件，先查后发的顺序基本固定；而"参数怎么填"在不同训练样本里天然分散（同一个人的名字有大小写、同一天有不同日期格式），强化学习很难给一个唯一正解。结果是模型学到了稳的过程性图式，却保留了飘的实例化细节。

度量本身是这个结论能否成立的命门，TSS 用的是工具名序列上的归一化编辑距离：

from itertools import combinations

def tss(traces):
    # traces: List[List[str]]，每个内层是某次运行的工具名序列
    sims = []
    for s1, s2 in combinations(traces, 2):
        d = levenshtein(s1, s2)          # 工具名 token 上的 Levenshtein
        sims.append(1 - d / max(len(s1), len(s2)))
    return sum(sims) / len(sims)          # [0,1]，1=完全同序

# 10 次跑同一个"找Alice邮件再发提醒"任务，tss≈0.9 是常态
# 哪怕 AC 只有 0.6（日期一会儿 03-02 一会儿 2026/3/2）

优缺点：这套度量的最大价值是"可对比、可监控、不依赖正确性标签"——TSS 只看工具名序列，不用知道任务对错。缺点是 AC 按步索引对齐，当两轨迹在某步调了不同工具时，键值集不相交直接记 0，会把一部分结构性分叉也算进参数飘动里，混了边界。变现评估：TSS/AC 这套指标可以直接打包成"智能体一致性体检"训练营模块——给企业算出每个任务类型在结构层和参数层的稳定度，比泛泛谈"AI 不稳定"具体得多，客单价和复购率都高于通用提示词课。

三、调序即成败：TSS 是不需要标签的可靠性代理

参数飘动扰人但不致命，结构飘动才是杀手。论文做了一次决定性的验证：把 1140 条轨迹按 TSS 中位数劈成两组，高 TSS 组（≥0.90）任务正确率 90.2%，低 TSS 组只有 61.2%，效应量 d=0.81（p<0.001）；而 AC 与正确性的相关只有 r=0.12（不显著）。翻译过来：调对工具、用对顺序，几乎等于做对；参数填得飘一点，只要语义等价（"Alice" vs "alice"、大小写不敏感的查找），根本不影响结果。

这推翻了两个常见误区。其一是"一致性 = 正确性"——并不全对，是"结构一致性 ≈ 正确性，参数一致性无关"。其二是想用自然语言输出来断言测试——输出层精确匹配 <5%，哪怕工具序列完全相同，模型最后那段话每次措辞都不一样。论文原话很扎心：拿文本断言，等于在测试代码里去 assert 一条日志而不是 assert 返回值。

工程上这意味着监控信号可以做得极轻。与其在线做语义判定（贵、慢、自身也不确定），不如只比对工具名序列：

def is_reliable_run(run_tool_seq, reference_seqs, top_k=2):
    # 只比前两步：60% 的分叉发生在这里
    head = tuple(run_tool_seq[:top_k])
    ref_heads = {tuple(s[:top_k]) for s in reference_seqs}
    return head in ref_heads   # 偏离参考序列 → 失败概率约 3 倍

# reference_seqs 由离线跑 k 次同一任务类型建立；
# 生产中每条运行 O(1) 比对，无需正确性标签即可筛高风险运行

优缺点：TSS 当代理的代价是它只对"有标准流程"的任务类有效——查、算、发、排这类确定性强的流程，TSS 高基本等于做对；但开放探索类（如"帮我准备明天会议"）本来就有多条合法路径，低 TSS 不一定错，需要结合任务类型加权。变现评估：把"前两步比对 + 偏离即重试/转人工"做成一个 sidecar 监控服务，按调用量计费，是比卖课更可持续的 SaaS 形态，尤其适合金融、医疗这类对可审计性要求高、容不得重试抖动的场景。

四、前两步定生死：分叉的 60% 集中在头部

论文另一个可直接落地的结论：当分叉发生时，它发生得很早。60% 的首次分叉落在管线前两步，平均分叉点 = 2.2。这并不反直觉——工具调用是马尔可夫式累积的，第一步选错工具（比如该查邮件却去查联系人），后续每一步都建立在错误前提上，分叉会沿着依赖链放大；而前两步走对之后，剩下的工具往往是模板化的收尾（算个总数、发个确认），几乎不会再分叉。

这条规律把监控的成本砍到了脚踝。一个只检查前两个工具调用、和参考轨迹比对的监视器，就能捕获 60% 的行为方差，却不需要完整重放整条链。对长链任务（如多工具组合 compose-004：查邮件→查日历→查与会人→发提醒）尤其值钱——你不必等它跑完 4 步才发现走偏。

flowchart TD
    A[生产请求进入] --> B[参考轨迹库: 每任务类型离线跑k次]
    B --> C[抓取本次运行前2个工具调用 head]
    C --> D{head ∈ 参考head集合?}
    D -- 是 --> E[放行: 高TSS组, 正确率~90%]
    D -- 否 --> F[标记高风险: 失败概率约3倍]
    F --> G{任务类型?}
    G -- 确定性流程 --> H[自动重试 / 转更稳模型]
    G -- 开放探索 --> I[转人工复核: 合法路径可能]
    E --> J[落库 + 更新参考集]
    H --> J
    I --> J

优缺点：前两步监控的盲区是"前两步对、后面飘"的尾部——约 40% 的分叉发生在第 3 步及之后，这类要靠完整 TSS 兜底。另一个陷阱是参考轨迹本身要可靠，论文强调参考集必须用确定性模拟工具建立，否则环境噪声会污染基准。变现评估：可作为训练营里"可观测性"模块的实战题——让学员在自家 Agent 上跑出分叉点分布直方图，多数人会震惊地发现分叉比想象的更靠前，这种"看见"的体验是课程复购的钩子。

五、模糊即失稳：歧义任务降 AC 28%，比换模型还猛

换更贵的模型能让工具调用更稳吗？论文的答案是：在参数层，几乎不能。歧义任务（"帮我准备明天的会议""这周该专注什么"这类多解请求）相对结构化任务，AC 直接掉 28%（0.52 vs 0.72，d=0.74，p=0.001），TSS 也从 0.89 掉到 0.79。而模型间的参数一致性差异在 ANOVA 下根本不显著（η²=0.08）。换句话说：任务说明书的质量，比模型档位更能决定参数稳不稳。

这条结论对预算分配是颠覆性的。很多团队本能地想"工具调用不稳就上 GPT-4.1 / Claude Opus"，但数据说，把"帮我准备明天的会议"改成"列出我明天 3 场会议的标题、时间、与会人，并为每场生成 3 条准备要点"，对一致性的提升（d=0.74）远超换模型（n.s.）。歧义是确定性最大的敌人，因为歧义下"填什么参数都算对"，模型每次自然填得不一样。

优缺点：这条策略的硬约束是——有些任务天生歧义（用户自己说不清要什么），你没法靠改 prompt 解决，只能靠多轮澄清对话把它结构化。另一个边界是结构层（TSS）确实受模型影响（F=3.52, p=0.003），所以换模型对"调对序"有用，对"填对参"无用，得分层下药。变现评估：可包装成"歧义任务重构工作坊"——拿企业真实工单，逐条做结构化改写并 A/B 测 AC 提升幅度，用 d 值这种统计语言给老板汇报，比"AI 更准了"有说服力十倍。

六、temperature=0 不等于确定性：基础设施层的暗坑

到此讨论都假设"降温能买到一致性"。但 BaristaLabs 2026 年 3 月的文章指出一个被低估的事实：temperature=0 并不保证确定性，且这是 OpenAI 托管 API、vLLM、SGLang 等"几乎所有生产推理栈多年来的已知问题"。原因不是简单的浮点并行，而是批次不变性（batch-invariance）缺失。

机制是这样：推理服务器会把并发请求拼成一个大 batch 跑，同一个 token 在 batch=1 时和在 batch=32 时，被 GPU kernel 用不同的规约顺序累加，浮点加法又不满足结合律，于是中间舍入不同、最终 token 概率分布不同、贪心采样选的就可能不同。Thinking Machines Lab 的研究把锅坐实：根因是标准 PyTorch 算子的 reduction 策略随 batch 大小变，不是抽象的"并发"。对一般聊天无感，但对审计日志、回归测试、跨部署 diff、需要幂等的结构化输出，这是实打实的失败模式。

三层修法，三种取舍：

优缺点：托管 API（OpenAI/Anthropic/Google）用户碰不到 kernel 层，能拿到的最多是 session 级 seed，且 seed 也挡不住批次抖动——也就是说，如果你真要审计级确定性，托管 API 不是合适的底座。SGLang 的批次不变模式是当下最生产可用的路径，代价是吞吐折损。变现评估：对金融合规、医疗审计、法律取证这类"每次响应必须可重建"的客户，"确定性推理栈部署"是高客单咨询项目——它解决了企业不敢上 AI 的最后一公里恐惧，比单纯卖 Agent 开发更难被低价替代。

七、并行-顺序悖论：最能并行的模型最不会等

确定性不只受采样和基础设施影响，还受模型架构倾向影响。J.D. Hodges 2026 年 3 月的本地实测（13 个模型、40 用例、8 工具）暴露了一个"并行-顺序悖论"：最擅长并行调工具的模型，最不擅长判断什么时候该停下来等。

经典用例："先在网上搜 USD→EUR 汇率，然后把 500 美元换算成欧元。"期望是两轮——先 web_search 拿结果，再 convert_currency 用真实汇率。结果 Qwen3.5 4B 和 GLM-4.7-Flash 两大并行高手，都直接在同一轮把 web_search 和 convert_currency 一起发了出去，导致换算发生在拿到汇率之前，毫无意义；反而是并行偏弱的 Nemotron Nano 4B 和 Mistral Nemo 12B 老老实实只发搜索、等结果回来再换算，全部 PASS。

这看起来像架构权衡而非 bug：训练里"高吞吐并行调用"被奖励得太狠，模型形成了并行惯性，对"then"这类顺序信号失敏。优缺点：这意味着选模型不能只看多工具总分（Qwen3.5 4B 多工具 7/8 最高），得看你业务是并行密集（查两个城市天气）还是顺序密集（搜索→换算→发邮件）。前者选 Qwen/GLM，后者选 Nemotron/Nemo。变现评估：这条悖论是本地化 Agent 选型咨询的杀手锏——多数企业不知道"并行强"在某些场景是负债，用一组"先X然后Y"探针帮客户测出模型的顺序耐性，直接决定选型，是能收咨询费的具体交付物。

八、榜单不迁移：BFCL 首页在 LM Studio 里只过 15%

工具调用确定性还有一个被广泛忽视的"迁移税"。Hodges 实测里三个专门做工具调用的模型——xLAM-2 8B（Salesforce，Berkeley Function Calling Leaderboard 榜首，在 BFCL 上力压 GPT-4o 和 Claude 3.5 Sonnet）、Hammer 2.1 7B（BFCL v3 同档最佳）、Mistral Small 3.2——分别只拿了 15%、20%、42.5%。Hammer 甚至在"不该调工具时正确拒绝"的边缘态拿 8/8 满分，却在"该调工具"的每个类别都是 0/8——它懂任务，但发不出结构化调用。

根因是 chat template 兼容性。这些模型用自定义的工具调用输出格式，LM Studio 的 OpenAI 兼容 API 没能正确翻译，模型字面上无法吐出可解析的 tool call。这和模型能力无关，却直接决定了"你能不能用"。

这条教训叠加"模型大小不预测工具调用质量"（3.4GB 的 Qwen3.5 4B 力压 18GB GLM、25GB Nemotron MoE、15GB Mistral Small），构成了本地 Agent 选型的两条铁律：榜单分要在你的真实推理服务上复测，参数量不能当筛选器。

# 把"榜单分"翻译成"实分"的最小探针：在你真实端点上跑迁移税测试
def migration_tax(model, server, cases):
    native = bfcl_score(model)                 # 榜单理想条件分
    served = run_through(server, model, cases) # 你的推理服务实际分
    return {
        "native": native,
        "served": served,
        "migration_tax": native - served,      # 差值=模板/量化/端点折损
        "verdict": "可用" if served > 0.8 and (native - served) < 0.15
                   else "换服务或换模型"
    }
# xLAM-2: native≈0.95, served=0.15, tax=0.80 → 榜单骗局，不可用

优缺点：迁移税最大的坑是"静默"——模型不会报错，它只是悄悄把 tool call 吞掉或退化成文本，不实测根本发现不了。BFCL 这类榜单跑的是原生 API 理想条件，和生产里的 OpenAI 兼容代理隔着一层翻译，这层翻译是排行榜不覆盖的灰色地带。变现评估：可做成"工具调用迁移税测评器"工具+报告服务——给企业一把测真实端点兼容性的尺子，比单纯推荐模型更落地，尤其适合大量用 LM Studio / vLLM / Ollama 自建本地栈的中小企业。

九、推荐方案：按确定性需求分层下注

把九条发现收敛成可执行的选型清单：

1. 测试与监控：断言工具名序列和参数模式，绝不断言自然语言输出（输出精确匹配 <5%）。监控只盯前两步，覆盖 60% 方差，O(1) 成本。2. 降歧义优先于换模型：参数飘动的最大杠杆是改写任务说明书（d=0.74），不是升级模型（n.s.）。3. 结构层选型：要高结构一致性选 GPT-4.1-mini（TSS 0.92，性价比双冠）；要高参数一致性且容许多策略，Claude Sonnet 4（AC 0.76）更优；Llama 3.3 70B 结构最不稳，歧义/组合任务慎用。4. 本地栈：Q4 量化下不迷信参数量，Qwen3.5 4B（97.5%）首选；顺序密集型选 Nemotron Nano 4B 或 Mistral Nemo 12B；并行密集型选 Qwen3.5/GLM-4.7-Flash。5. 审计级确定性：托管 API 给不了，自托管上 SGLang 批次不变 kernel（最实用）或 Groq（最强保证），交付前必跑迁移税复测。

一句话总结整条主线：工具调用确定性不是单点问题，是"调序稳（训练信号干净）→ 填参飘（实例化天然分散）→ 前2步定生死（马尔可夫放大）→ 模糊比模型更致命 → temperature=0 仍是赌（批次不变性缺失）→ 并行强≠顺序稳（架构权衡）→ 榜单分要本地复测（迁移税）"的七层栈。每一层都有独立的税，也都有独立的、可量化的修法。

参考来源

1. How Consistent Are LLM Agents? Measuring Behavioral Reproducibility in Multi-Step Tool-Calling Pipelines (arXiv:2605.28840, 2026) — 1140 条轨迹实证"结构稳参数飘"，TSS 预测正确性、分叉集中在前两步、歧义强于换模型等核心结论来源
2. Temperature Zero Doesn't Mean Deterministic: The LLM Reproducibility Gap (BaristaLabs, 2026-03) — temperature=0 不保证确定性的批次不变性机制，及 kernel/SGLang、Eigen、Groq 三层修法
3. I Tested 13 Local LLMs on Tool Calling: 2026 Eval Results (J.D. Hodges, 2026-03) — 本地模型并行-顺序悖论、参数量不预测质量、BFCL 榜单迁移税的实测数据来源
4. LLM Tool Calling Determinism: Production Patterns That Work (2026) — 工具调用确定性生产模式：降温、seed、参考序列比对的工程实践
5. Tool Use and Function Calling in AI Agents — Standards, Benchmarks (Zylos.ai, 2026-04) — 跨厂商工具/函数调用标准与基准（BFCL、τ-bench 等）的现状综述

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。