非确定性意味着相同输入可以产生不同输出。用完全相同的上下文运行模型两次，可能得到两个不同答案——有时只差一个词，有时会采用完全不同的方案。即使代码没有任何变化，也会发生这种情况。
它既源于模型生成文本的方式，也源于模型提供商处理请求的方式。推理期间，模型会为可能的下一个 Token 生成概率分布，再从中采样一个；这个过程通常会有意保留一定随机性，因为始终选择最高概率 Token 会产生重复且质量更低的文本。回答早期只要有一个 Token 的采样不同，之后的每个 Token 都会受到影响，于是一个词的差异就可能演变成完全不同的方案。提供商侧的服务过程还会增加更多变化：多个请求在共享硬件上批处理，不同批次之间极小的浮点差异，也可能让两个概率接近的 Token 得出不同选择。没有任何一个开关能够让这些差异完全消失。
面对同一任务，应预期智能体会给出一系列不同结果。大多数回答的质量落在合理的钟形曲线中间——这也是非确定性尚可接受的原因——但两端确实存在：有些时候模型显得十分敏锐，有些时候却像完全失去方向。同一任务，只是掷出了不同结果。这带来两个实际结论。第一，重试是正当策略：一次失败只是从分布中抽到的一个样本，重新尝试同一任务可能自然得到更好结果。第二，验证比使用确定性工具时更重要——不能只测试一次智能体行为就相信它会重复，因此必须通过自动化检查捕获较差样本。
注意不要过度为这种现象编故事。人类擅长寻找模式，一连串糟糕运行很容易被解释成“模型这周变差了”的证据；通常那只是概率分布的正常表现。
用法：
“Claude 今天表现很糟。他们是不是上线了更差的版本？”
“大概没有——模型输出具有非确定性。同一任务也会有表现好的时候和表现差的时候。先等明天再试一次，再考虑是否需要寻找其他原因。”