指南/异常缓存与运行环境
没配置缓存却出现缓存字段，还暴露了陌生运行环境，怎么判断
客户端没有写缓存配置，响应里却出现了缓存字段；工具结果或错误还带着陌生目录、容器与远端环境信息。这两类现象可能来自官方自动缓存、固定响应结构、托管工具或中转层转换。字段从哪里产生、代码在哪里执行，要分别取证。
缓存字段出现，有三种不同含义
先看字段和值。响应结构里有 cached_tokens，值为 0，只说明接口 schema 预留了缓存明细；值大于 0 或 cache_read_input_tokens 增加，才表示服务方报告本次读取了缓存。自然语言回答里说「我使用了缓存」，证据更弱，它只是模型生成的文字。
客户端没有显式配置，也可能得到缓存命中。Google 的上下文缓存文档说明，Gemini 2.5 及后续模型默认启用隐式缓存。OpenAI 当前的模型指南也区分隐式与显式 Prompt Caching，并建议从 Usage 的缓存读写字段核对成本。
Anthropic 的当前机制不同。Prompt Caching 文档要求请求通过顶层 cache_control 使用自动断点，或在内容块上放显式断点。若客户端完整出站请求没有该字段，而中转响应持续报告缓存读取，可能是中转层补了配置、协议转换产生了字段，或中转站自行填写了 Usage。缺少上游请求时，这些都只是解释。
还要区分「字段由谁定义」与「缓存由谁执行」。中转站可以沿用 OpenAI 风格的 cached_tokens 字段，却把请求转到另一家上游；也可以从上游读取缓存明细，再换成兼容字段返回。字段名称只描述客户端看到的协议外形，不能确定缓存存放在中转站、云厂商还是模型平台。
怎样核对字段包含关系和命中条件，见 Prompt Cache 到底命中了没有。不同厂商 Usage 不能直接横比，见三家 Token 用量字段对照。
缓存命中不等于共享会话
Prompt Cache 复用的是相同输入前缀的计算结果，不负责把另一个会话的消息拼进当前请求。Anthropic 文档说明，缓存命中要求前缀精确匹配，缓存不改变输出生成；不同组织之间隔离，Claude API 的缓存还按工作区隔离。缓存字段本身因此不能证明看到了其他用户的上下文。
中转站仍可能使用自己的上游工作区、缓存实现、日志或会话存储。官方平台的隔离承诺不会自动约束独立中转服务。若响应出现了与当前请求无关的真实业务内容，需要按数据事件处理，但归因对象可能是会话存储、日志回放、应用状态或响应拼接，不能只写成「缓存串号」。
缓存与持久会话也要分开。缓存保存可复用的模型计算；持久会话保存消息、文件、工具结果或环境 ID。二者可能同时存在，生命周期和隔离范围由各自接口决定。
陌生工作目录先看它出现在哪里
同一段路径出现在不同位置，证据强度差很多：
| 出现位置 | 能支持的判断 | 主要边界 |
|---|---|---|
| 模型自然语言回答 | 模型生成过这个目录字符串 | 可能来自猜测、系统说明或上下文，不能证明执行过命令 |
tool_call 的参数 | 模型请求工具访问该路径 | 只代表调用意图，工具可能尚未执行或已被拒绝 |
结构化 tool_result、标准输出或错误 | 某个执行器返回了该路径相关结果 | 还要确认执行器在客户端、中转站还是官方平台 |
| 官方托管工具结果与环境标识 | 本次 API 使用了服务端工具或容器 | 只能证明对应平台环境，不能推到中转站的其他请求 |
| 普通业务流程里跨请求保留的文件状态 | 某个持久环境被复用 | 需要环境 ID、工具日志或服务方记录确认隔离范围 |
模型自报属于弱证据。它可以复述提示词里写过的 /workspace，也可能根据常见开发环境补全一个看似合理的目录。工具调用参数同样由模型生成，只有执行结果返回后，才能确认某个执行器接触了该路径。
Anthropic 的工具参考把工具分成两类：server tools 在 Anthropic 基础设施执行，client tools 由调用方应用执行。其代码执行文档还说明托管代码运行在隔离容器中，响应带有可复用的 container 信息。Google 也在工具文档里区分服务端内置工具与由客户端执行的自定义函数。
所以，看到陌生 Linux 路径不自动指向中转站。路径可能来自本地 Agent、官方托管容器、第三方 MCP 服务或中转站自己的执行器。要沿着工具类型和返回方向确认来源。
按原始记录确认执行位置
保存出现异常的完整响应事件、工具类型、调用 ID、请求 ID、错误对象和时间。敏感正文可以脱敏，但不要删掉字段层级与事件顺序；仅剩一张聊天截图时，模型文本和工具结果很容易混在一起。
随后核对客户端发出的 tools 定义。自定义函数通常由本地应用执行，服务端内置工具由厂商执行；中转层若转换了工具协议，还需要它提供转换说明或脱敏后的上游事件。若响应里带 container、environment 或同类资源标识，检查它是否符合所用官方接口的字段定义，以及应用是否在后续请求里复用了该标识。
错误来源也能缩小范围。浏览器或本地 SDK 在执行客户端工具时抛出的路径，多半属于本机或应用容器；API 的结构化服务端工具结果更接近托管环境；普通 HTTP 错误页中的主机名和目录则可能来自中转网关。错误被代理重新包装后，来源会再次变得不确定，所以原始响应头、事件类型和调用 ID 要一起保留。
证据可以写成三层：
- 可观察事实：缓存字段及其数值、工具事件类型、返回路径、错误体、环境标识和请求 ID。
- 有依据的解释：字段符合某个官方自动缓存机制，或工具结果符合某种托管容器结构，同时保留客户端执行和中转转换等替代解释。
- 缺少证据：只有模型自述或界面文案，无法确认缓存命中、执行位置、环境持久性与多用户隔离。
发现真实密钥、客户内容或其他用户数据时，应停止向该调用路径发送敏感内容，作废可能暴露的凭据并保存原始记录。中转站能读取哪些请求数据、日志政策如何核对，见中转站数据安全。
结论要停在证据覆盖的范围
缓存字段存在，可以确认响应采用了包含缓存明细的结构；正数缓存用量可以确认服务方报告了命中。两者都不能单独证明共享会话、跨用户数据泄露或中转站私自保存 Prompt。
陌生目录出现在工具结果里，可以确认某个执行器返回了环境信息；执行器属于谁、是否持久、是否与其他用户共享，仍要看工具类型、环境标识和服务方记录。若中转站只承诺「OpenAI API 兼容」，还要核对它在哪一层转换工具与 Usage，相关方法见OpenAI API 兼容性检查。
LinkyMonitor 关联保存请求、响应、Usage 与网络上下文；缓存或工具行为变化时，可以回到原始记录核对。