你的产品视图从未呈现的推理 Token

一位客户给支持团队发了邮件。AI 助手告诉他们在错误的司法管辖区申报纳税，他们非常生气，想知道助手是如何得出那个答案的。你的支持人员打开问题队列，看到了最终回复：自信、听起来很有道理，但却是错误的。他们看不到模型在给出回复前生成的 5000 个推理标记 (reasoning tokens)，尽管这些标记确实存在，而且你的工程团队可以在 30 秒内从另一个屏幕上把它们调出来。证据就在公司里，只是拿在错误的人手中。

这就是团队在生产环境的智能体上启用扩展思考 (extended thinking) 时产生的差距。推理成为了每一次调用的核心产物，而你的组织尚未决定谁在什么时候、以何种精度、以及在多长时间内可以看到它。默认决策是由负责各个界面的团队分别做出的，他们的默认设置各不相同，而这些缝隙恰恰是客户投诉产生的地方。

推理是一个界面，而非副作用

当你开启扩展思考时，模型会产生两个流：面向用户的回答和一段长得多的、用于解释该回答的推理轨迹 (reasoning trace)。模型提供商在单独的字段中返回推理内容，SDK 将其公开为结构化对象，应用程序存储它（因为存储完整响应是最省事的做法），而产品 UI 只显示最终答案，因为产品团队的职责范围仅限于“用户看到的内容”。

这些决策在局部看来都是正确的，但没有一个演变成深思熟虑的策略。结果是，推理轨迹存在于你的追踪存储中（通常是出于偶然），并被挡在你碰巧首先打开的那个团队的工具之后。

需要这些内容的群体各不相同：

• 工程师需要完整的轨迹来调试回归问题：模型关注了哪些检索片段、考虑过拒绝哪些内容、逻辑链在何处偏离了方向。
• 支持人员需要一份经过清洗的摘要，以便向客户转述：足以解释答案，但又不会暴露模型内部细节或其他用户的数据。
• 产品经理 (PM) 和产品分析师需要聚合信号：推理何时不确定、何时陷入循环、何时在轨迹中途改变主意，以便在客户报告之前发现质量偏差。
• 事故指挥员需要在复盘模版中嵌入固定格式的摘录，因为重建智能体的推理过程现在已成为基础的取证步骤。
• 隐私合规人员需要知道哪些推理字段包含用户衍生的数据，因为这决定了数据的保留类别。

你无法用同一个原始数据块 (raw blob) 来满足所有这些群体的需求。但如果你在没有设计的情况下发布产品，你最终得到的就只是原始数据块，外加一个写着“咨询工程团队”的 Confluence 页面。

没人审查过的个人隐私信息 (PII) 问题

推理标记具有一种属性，使其在法律上与常规模型输出不同：它们由用户输入塑造，但从未被作为用户衍生数据进行审查。用户输入查询。查询中提到了姓名、诊断结果、薪资或地址。最终答案经过了清洗——也许你的防护层在显示前擦除了 PII——但位于上游一层的推理轨迹会原封不动地重述 PII，因为模型需要针对眼前的具体案例进行思考。

最近的研究对此直言不讳。思维链 (Chain-of-thought) 轨迹经常在推理过程中重述姓名、人口统计信息、医疗细节和其他隐私属性，即使模型已被指示不要在最终输出中这样做，而且较长的推理往往会增加而不是减少泄露。模型正在利用 PII 进行推理，而推理过程正在被存储。

你的隐私审查几乎肯定忽略了这一点。签署数据流合规的团队考虑的是请求体、响应体和日志。推理轨迹看起来像是模型遥测数据——内部的、面向工程的——因此它被划归到了与延迟指标相同的保留类别中。事实并非如此。它是具有与原始提示词相同敏感度的用户内容，有时还附带额外的推论。一条写着“用户提到他们是 HIV 阳性并询问加州的保险范围”的推理轨迹，现在就是存储在你的追踪表中的敏感医疗记录。

解决方法不是“在存储前清洗推理内容”。清洗是有损的，工程人员确实需要未经清洗的版本来进行调试。解决方法是认识到推理内容应该针对不同受众制定保留和脱敏策略，并在数据落地到任何地方之前进行明确的设计。

存储成本变成了你从未写过的采样策略

存储推理标记的成本并不低。典型的扩展思考响应产生的标记数量是非推理调用的 3 到 10 倍，而且追踪记录必须保留其周围的结构化外壳——调用 ID、工具调用、中间状态——这增加了追踪存储中每一行的成本。乘以请求量后，推理轨迹的存储账单会让答案本身的存储账单显得微不足道。

因此，团队在发布时会带上采样规则。通常这是隐式的：可观测性供应商 SDK 中的默认设置，保留 10% 调用的完整轨迹，其余仅保留元数据。有时它是显式但粗糙的：保留错误的完整推理，丢弃成功的。无论哪种方式，采样规则都在对哪些轨迹重要进行一场无声的赌博。

当你需要它的那一天，这场赌博几乎总是输的。客户投诉很少来自于报错的调用——那些调用通常被重试并恢复了。投诉来自于那些以自信姿态给出错误答案的成功调用，而“自信的错误”恰恰是你的“仅保留错误”规则所丢弃的轨迹类别。当三天后客户投诉到来，而轨迹已被采样过滤掉时，你将一无所有。

有一些模式比一刀切的采样效果更好：

• 基于智能体质量信号的尾部采样 (Tail-based sampling)：当用户给出差评、请求被下游检查标记、答案与工具结果相矛盾、或者调用消耗的推理标记超过该工作负载的中位数时，保留完整推理。负面信号案例正是复盘开始的地方。
• 针对特定客户的保留覆盖：对审计需求严格的企业客户，其租户下的调用进行全量保留。默认租户进行采样。成本由支撑该需求的合同承担。
• 分级精度，而非非黑即白：为每次调用始终保留推理的结构化摘要（长度、决策点、考虑过的工具）。仅对有必要的部分子集保留原始标记。摘要成本低廉，且保留时间可以远超原始数据。

加载中…