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

大多数生产环境中的多智能体系统都采用单一的温度（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）下运行。在流水线的这个阶段，多样性已经在上游引入了。聚合者的工作是做出可靠的最终决策，而不是引入额外的变差。关于演绎编码中多智能体共识的研究发现，一旦使用了合理的温度，温度对共识准确性的影响微乎其微——共识机制的设计比精确的温度值更重要。

方差预算框架

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

加载中…