多智能体系统中的温度治理：为什么方差是一类预算

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。

温度究竟控制什么

在设计基于角色的策略之前，准确理解温度的作用及其局限性是很有帮助的。

温度会缩放从最后一个 Transformer 层输出的 Logit 值，然后通过 Softmax 将其转换为概率。当温度为 0 时，模型在每一步都会确定性地选择概率最高的 Token。当温度为 1.0 时，则直接使用原始分布。较高的值会使分布变平，从而让低概率的 Token 更具竞争力。

温度不会做两件事：它不会将某些 Token 排除在考虑范围之外（那是 top-k 和 top-p 做的事），它也不保证在零温度下输出完全确定（即使在那时，浮点精度和批处理效应也会引入方差）。对于多智能体设计而言，更重要的一点是，它不控制模型知道或不知道什么——它控制的是模型表达其所知内容的连贯性。

现代参数栈更进一步。Top-p（核采样）通过累积概率质量进行过滤。Top-k 固定了候选池的大小。Min-p 在 ICLR 2025 的口头报告后获得了广泛关注，它根据最高概率 Token 的概率值动态调整阈值——当模型充满信心时，它要求更高质量的候选者；当不确定时，它则会放宽限制。对于生产环境的多智能体系统，温度结合 min-p 正日益成为开源部署的标准方案。

重复惩罚（Repetition penalty）是一个完全独立的机制。它通过在应用温度之前对 Logit 进行操作，来抑制重复使用已生成的 Token。将重复性问题误认为是温度问题是生产环境调试中最常见的误诊之一。

很少被放在一起讨论的两种故障模式

大多数关于温度的讨论都集中在一个维度上：太低很乏味，太高则语无伦次。但在多智能体系统中，故障模式会根据角色清晰地划分，你需要在跨不同的流水线阶段同时考虑两端的情况。

过度自信的分类器出现在你在温度为 0 或接近 0 的情况下运行分类智能体时。模型总是选择概率最高的答案，这听起来不错，直到你遇到边界情况。一个无法表达不确定性的分类器永远不会将文档标记为需人工审核——即使正确答案确实模棱两可，它也会做出绝对的判断。针对多智能体共识框架的研究发现，适度的温度（0.1-0.3）允许模型在边界情况下偶尔选择其他分类，这正是下游组件或人工审核者所需要的不确定性信号。

极低温度分类器的另一种故障模式是采样意义上的表面模式过拟合：模型塌缩到模糊输入的单一最高概率解释上，而不是维持合理替代方案的分布。这不同于训练过拟合，但会产生类似的症状——在分布外输入上给出自信的错误答案。

创造力不足的生成器出现在内容生成智能体在适用于结构化任务的温度下运行时。运行在 0.2 温度下的摘要智能体会产生语法正确、语义精准的输出，但读起来就像公文——每次都是相同的句式、相同的过渡词、相同的段落节奏。用户不会抱怨准确性，他们会抱怨内容感觉很机械。如果同时设置了 frequency_penalty=0，单纯提高生成器的温度是无法解决这个问题的——解决方案需要两者兼备：调高温度以探索分布，并将 frequency_penalty 设置在 0.3-0.5 左右，以抑制在多次生成中重复使用相同的词汇和短语。

高温度结构化任务导致的 Schema 违规是第三种故障模式，它们在多智能体流水线中与其他模式相互作用。当一个温度为 0.9 的生成器将输出馈送给一个同样处于 0.9 温度的结构化提取智能体，且该智能体需要生成有效的 JSON 时，你就制造了一个复合问题。在没有约束解码的情况下，即使在适中温度下，原始 JSON 生成也有 15-20% 的失败率。在 1.5 的温度下，会出现首次明显的准确率下降。一项关于临床信息提取的 2024 年研究发现，GPT-4o 在温度从 0.0 到 1.5 之间能保持 98.7-99.0% 的格式准确率，第一次显著退化发生在 1.75 以上——但这只是针对单个模型而言。在一个链式多智能体流水线中，每个阶段的故障概率都会复合叠加。

将采样策略与角色匹配

一旦你区分了角色，实际的框架就很简单了：

分类器和路由器应在 0.1-0.3 的温度下运行。不要设为零——你希望模型偶尔通过采样略微偏离众数（mode）来表达不确定性。零温会产生虚假的自信。目标是高确定性且带有极小的不确定性信号，而不是完全的确定性。

结构化提取器和格式化器应在 0.0-0.2 的温度下运行，并尽可能使用提供商原生的结构化输出 API（受限解码、语法采样或在生成时强制执行输出格式的工具调用模式）。OpenAI 的结构化输出 API（Structured Outputs API）实现了接近 100% 的 Schema 合规性——远高于原始 JSON 提示词下的 40% 以下——这是通过在 token 级别强制执行 Schema，而不是寄希望于模型自我纠正来实现的。低于 0.2 的温度加上 Schema 约束，可以同时为你提供变差控制和结构保证。

生成叙述性内容的生成器应在 0.7-1.0 的温度下运行。如果你在这些温度下看到重复，解决方法是频率惩罚（frequency_penalty，建议 0.3-0.7），而不是降低温度。降低温度通过将分布压缩到众数来解决重复，但这也会压缩多样性。频率惩罚专门针对已经生成的 token，而不会影响整体分布的形状。

验证器和评审器需要中等设置（0.3-0.7），因为它们执行的评估工作受益于一定的探索性推理，但不应在多次运行中产生截然不同的结论。一个温度为 0.9 的验证器可能会在两次相同的运行中推翻自己的结论，这会使流水线以不可预测的方式变得非确定性。

共识和聚合智能体（用于合成多个上游智能体输出的智能体）应在低温度（0.1-0.2）下运行。在流水线的这个阶段，多样性已经在上游引入了。聚合者的工作是做出可靠的最终决策，而不是引入额外的变差。关于演绎编码中多智能体共识的研究发现，一旦使用了合理的温度，温度对共识准确性的影响微乎其微——共识机制的设计比精确的温度值更重要。

方差预算框架

多智能体温度治理的一个有用思维模型是“方差预算”：在累积的不确定性超过你的错误阈值之前，系统中允许的总随机量。

每个在温度 > 0 下运行的智能体都会贡献方差。在一个五阶段的流水线中，五个各自贡献少量方差的智能体可能会累积成一个不可靠的系统，而这种不可靠性是任何单智能体分析都无法预测的。这就是为什么调试“流水线有时会给出错误答案”时，通常会发现没有哪个单独的智能体是损坏的——失败是从复合采样方差中产生的涌现现象。

方差预算分配遵循几个原则：

• 前置方差，后置一致性。 让生成器和头脑风暴者高温运行；让验证器和格式化器低温运行。你希望早期有创意多样性，后期有可靠的收敛。
• 结构化任务消耗零方差预算。 如果一个阶段产生由下游代码解析的结构化输出，它应使用 0.0-0.1 的温度和受限解码。在格式化上花费方差预算是浪费的。
• 不确定性信号是有价值的，而不只是噪声。 一个运行在 0.2 温度下的分类器，如果偶尔对相同的输入输出不同的标签，它是在告诉你该输入处于边界情况。将边界案例路由到人工审核或第二意见智能体是一个特性，而不是 bug。
• 复合效应是乘性的，而不是加性的。 五个各有 2% 错误率的智能体并不会给你 10% 的流水线错误率——它们会给你大约 10%（源于 1-(0.98^5)≈0.096），但当上游错误向下游传播时，会产生关联性故障。

最近关于多智能体稳健性的研究提出了使用自适应两阶段采样的正式方差预算编制：首先使用少量样本进行初步探测以估计方差，然后根据观察到的不确定性确定更大规模样本集的大小。这一原理转化为流水线设计即是——使用低成本的探测来检测高方差阶段，然后在方差超出预期的位置应用更严格的采样约束。

生产环境中的常见错误配置

在存在温度问题的生产系统中，有几种模式反复出现：

“复制粘贴型”温度：统一应用温度 0.7，因为某个 Notebook 里就是这么写的。这对于分类器来说太高了，而对于创意生成器来说又太低了。几乎没有哪个生产级多智能体系统应该在所有组件中都使用单一的温度值。

试图通过降低温度来修复重复：这是最常见的误诊。如果生成器重复短语，降低温度通过压缩多样性来“修复”重复——但现在生成器在处理实际工作时表现更差了。正确的干预措施是使用 frequency_penalty。

忽视推理模型的限制：一些前沿推理模型（包括 o1 系列模型的某些配置）将温度锁定在 1.0 且不允许修改。如果你的流水线将某些任务路由到推理模型，你的温度策略需要考虑到你无法控制参数的阶段。

同时使用温度和 top-p 过度参数化：标准指南是修改温度或 top-p，而不是同时修改两者。当你两者都用时，它们会产生冲突信号：温度说“将不太可能的 token 视为更合理”，而严苛的 top-p 则说“只考虑可能性最高的 token”。对于大多数生产用例，将温度设置为你的目标值，并将 top-p 保持在 0.9。如果你需要更严格的多样性控制，请降低 top-p 而不是进一步降低温度。

高温度提取器导致的 Schema 违规：这一点很微妙：团队经常引入结构化提取阶段来“清理”创意生成器的输出，然后让提取器在与生成器相同的温度下运行。提取器应在 0.0-0.1 的温度下配合受限解码运行。

制定策略

在实践中，记录你的 Temperature 策略与设置它同样重要。对于系统中的每个 Agent：

• 这个 Agent 扮演什么角色？（分类、生成、验证、格式化、聚合）
• 这个阶段的可接受错误率是多少？
• 这个阶段是否产生由下游代码解析的结构化输出？
• 这个阶段是否是多样性至关重要的创意生成器？

根据这些回答，一份针对每个角色的 Temperature 表格几乎可以自动生成。核心见解是，Temperature 是一种基于角色的资源分配决策——即这个阶段需要多少方差（variance）来完成其工作，以及考虑到后续环节，这个阶段能承受多少方差。

大多数团队设置一次 Temperature 后就不再管了。而那些调整特定角色策略的团队往往会发现，他们的“模型准确度”问题其实一直是采样策略问题——而修复这些问题的成本要低得多。

衡量什么

一旦你有了针对每个角色的 Temperature 策略，监控的问题就是每个阶段的行为是否与其设置保持一致。

对于分类器：跟踪相同输入下的标签方差（多次运行相同的输入并测量输出的分布）。Temperature = 0.1 的分类器应该具有极低的方差；如果在低 Temperature 下对相同输入产生高方差，则表明分类任务确实存在歧义，应交由人工审核。

对于生成器：在多次运行中测量输出多样性指标（词汇广度、n-gram 多样性）。如果 Temperature = 0.8 的生成器在重复运行时产生相同的输出，其重复惩罚（repetition penalty）可能设置得太高了。

对于结构化提取器：将 Schema 验证失败率作为主要指标，而非边缘情况进行跟踪。如果可以使用受限解码（constrained decoding），Schema 失败率应该为零。如果你依赖 Prompt 指令来生成 JSON，请明确跟踪失败率。

对于整个流水线：通过在完整流水线中运行相同输入并测量输出一致性，来衡量端到端方差。当单个 Agent 的 Temperature 调整正确时，系统层级出现意料之外的高方差，通常揭示了流水线运行之间存在非预期的状态泄漏。

Temperature 治理无法解决由糟糕的 Prompt、劣质的检索或错误的工具选择所引起的问题。但在多 Agent 系统中，令人惊讶的是，很大一部分“模型不可靠”的抱怨可以直接追溯到从未根据流水线实际结构进行设计的采样策略。