缓存策略探测实验方案架构设计

执行摘要

本方案将缓存策略探测设计为 五阶段递进式实验流水线（Phase 0 → 4），核心思路是：

不要默认信任 cached_tokens------先用 Phase 1 验证这个字段是否在说真话
用决策树而非线性流程------每个阶段根据上一阶段的结论自动分叉到对应的下一阶段
双信源三角验证 ------cached_tokens + 响应延迟，互为校验
隔离优先于效率------探针污染是 test-V4 最大的方法论失败，本次方案将隔离性作为首要设计约束
接受"无法完全区分"作为合法结论------有些缓存机制的外部黑盒不可区分，方案明确标记这些盲区

关键决策 ：Phase 1 的结果决定整个实验是否值得继续。如果 cached_tokens 被证伪，实验必须切换到"延迟为主信源"模式。

1. 假设空间目录

在开始实验前，穷举所有可能的缓存实现方式。这是决策树的"叶节点"集合------所有分支最终都会收敛到这些假设之一。

1.1 缓存机制假设空间

编号	假设	核心特征	可探测性	test-V4 支持证据
H0	无缓存	`cached_tokens` 始终为 0；重复请求延迟无下降	⭐⭐⭐ 高	❌ 矛盾：所有报告显示 `cached_tokens > 0`
H1	固定响应字段	`cached_tokens = f(prompt_tokens)` 是纯公式，与实际缓存无关	⭐⭐⭐ 高	✅ 强证据：`cached = prompt - 1` 跨所有场景恒定
H2	内容哈希全局缓存	对整个请求内容序列化后做哈希，哈希匹配则全量命中	⭐⭐ 中	✅ 支持：Report D 中 v4-pro 的 `cached_tokens` 固定 806
H3	前缀匹配上下文缓存	标准 Prompt Caching：从第一个 token 开始匹配到分叉点	⭐⭐⭐ 高	❌ 矛盾：`different_system` 场景本应零命中却显示高命中
H4	采样哈希缓存	对内容做局部采样哈希（如每隔 N 个 token 采样），近似匹配	⭐ 低	部分兼容现有数据
H5	语义向量缓存	对内容做 embedding，相似度 > 阈值即命中	⭐ 低	部分兼容现有数据
H6	时间窗口缓存	在固定时间窗口内（如 5 分钟），同一 API key 的所有请求共享缓存	⭐⭐ 中	无直接证据
H7	会话级缓存	缓存绑定到特定会话/连接，跨会话不共享	⭐⭐ 中	无直接证据
H8	混合策略	上述 2+ 种机制的组合（如：前缀匹配 + 时间窗口）	⭐ 低	可能性存在

1.2 假设的 Bayesian 先验（基于现有 4 份报告）

基于 test-V4 的 4 份测试报告，我们对各假设的初始信念：

复制代码

P(H1: 固定响应字段) = 0.45  ← 最强先验：exact minus 1 模式
P(H2: 内容哈希缓存) = 0.30  ← Report D 固定 806 支持
P(H0: 无缓存)       = 0.05  ← 与 cached_tokens > 0 矛盾
P(H3: 前缀缓存)     = 0.10  ← different_system 假阳性矛盾
P(H4-H8: 其他)      = 0.10  ← 均匀分配

重要：这些先验只是实验设计的起点，不应影响实验结果的客观判断。

1.3 不可区分假设对

某些假设对在黑盒测试中无法区分。方案必须承认这些盲区：

假设对	不可区分原因	解决方案
H4 采样哈希 vs H5 语义向量	两者都可能对"相似但不相同"的内容产生命中	需要白盒信息或大量采样测试
H2 内容哈希 vs H1 固定响应	如果 API 确实缓存了所有内容（因为语料库有限），H2 的观测可能与 H1 相同	Phase 0 的语料空间独立性测试
H6 时间窗口 vs H7 会话级	两者都在"短时间"内产生缓存命中	需要跨 API key / 跨 IP 测试

2. 阶段架构

总览

复制代码

Phase 0: 信号源盘点        (前置，1 小时)
    ↓
Phase 1: 信号真实性验证    (关键分叉，2-4 小时)
    ↓
    ├─ 信号可信 ──→ Phase 2: 机制区分  (核心，4-8 小时)
    │                   ↓
    │               Phase 3: 边界映射  (细化，4-8 小时)
    │                   ↓
    │               Phase 4: 鲁棒性测试 (收尾，2-4 小时)
    │
    └─ 信号不可信 ──→ 切换到延迟信源 → Phase 2-4 (同上，仅信源不同)

总耗时估算：15-25 小时（含 API 调用冷却等待时间）

Phase 0: 信号源盘点

目标：在写一行测试代码之前，明确所有可用的观测信号

产出：信号清单 + 信噪比预估

信号	类型	获取方式	预期信噪比	优先级
`cached_tokens`	直接	API 响应的 `usage.prompt_tokens_details.cached_tokens`	未知（待验证）	P0
`prompt_tokens`	直接	API 响应的 `usage.prompt_tokens`	高（基础计数）	P0
总响应延迟	间接	客户端 RTT 计时	中（受网络抖动影响）	P0
首 token 延迟 (TTFT)	间接	流式模式首个 chunk 到达时间	中-高（更能反映计算时间）	P1
响应 body 一致性	间接	对比相同 prompt 的响应内容是否逐字相同	中（受 temperature 影响）	P1
API 计费报告	间接	从 API 供应商 dashboard 获取实际扣费	高（如果可获取）	P1
速率限制头	间接	响应头中的 `X-RateLimit-*` 或类似字段	低（大多数代理不暴露）	P2

关键决策点 ：如果 Phase 1 发现 cached_tokens 不可信，我们必须切换到"延迟"和"计费"作为主信源。如果所有间接信源也都不可靠，则实验终止------结论是"该 API 的缓存行为无法从外部探测"。

Phase 1: 信号真实性验证

目标：回答一个问题------cached_tokens 是在报告真实的缓存命中，还是在执行一个固定公式？

核心思路 ：构造两组请求，如果 cached_tokens 是真实测量，它们应该有显著差异；如果它是固定公式，它们将相同。

1.1 独立性探针（H0 vs H1 区分）

测试逻辑：发送两组「内容词汇完全不重叠」的请求。

第一组：主题 A（如：中国古代史）
第二组：主题 B（如：量子计算）

如果 cached_tokens 是真实的，第二组请求的缓存命中应为 0（因为内容完全不相关）。如果 cached_tokens 仍然为非零固定值（如 prompt_tokens - 1），则 H1 成立。

判定规则：

复制代码

if 所有请求的 cached_tokens > 0（含内容完全不相关的请求）:
    → H1 或 H8（固定响应或内容无关缓存）
    → 切换到延迟信源
elif 仅相同/相似内容出现 cached_tokens > 0:
    → 信号可能真实
    → 继续 1.2

1.2 一致性探针（验证信号与物理缓存的相关性）

测试逻辑 ：发送完全相同的一对请求，间隔足够的时间（确保第一次的副作用写入完成）。如果 cached_tokens 真实，第二次请求应显示大量缓存命中。同时测量两次请求的延迟差。

判定规则：

复制代码

if cached_tokens(2nd) >> cached_tokens(1st) AND latency(2nd) < latency(1st):
    → 信号与物理缓存行为一致
    → ✅ 信号可信，使用 cached_tokens 作为主信源
elif cached_tokens(2nd) == cached_tokens(1st) AND latency(2nd) < latency(1st):
    → 物理缓存存在但字段不反映它
    → ⚠️ 信号不可信，切换到延迟信源，但实验可继续
elif cached_tokens(2nd) == cached_tokens(1st) AND latency(2nd) ≈ latency(1st):
    → 无缓存
    → ❌ 终止：H0 成立

1.3 跨端点对照探针

测试逻辑 ：在两个被测端点上同时运行 1.1 和 1.2。如果两个端点行为不同，说明至少有一个端点的 cached_tokens 语义不同。

关键约束 ：需确认是否有官方 DeepSeek API（api.deepseek.com）作为基准对照。如果官方 API 的 cached_tokens 行为是已知的（标准前缀缓存），则可以作为校准基准。

Phase 2: 缓存机制区分

前置条件 ：Phase 1 确认至少有一个可信信源（cached_tokens 或延迟）

目标：从 8 个假设中确定最可能的缓存机制

2.1 内容哈希 vs 前缀缓存区分（H2 vs H3）

这是整个实验中最关键的一次区分 。两种机制在大多数场景下表现相似（相同内容都命中），但有一个根本差异：对"顺序重排"的响应不同。

决定性探针：顺序重排测试

构造两个 system prompt：

Prompt A：段落 1 + 段落 2 + 段落 3（原始顺序）
Prompt B：段落 3 + 段落 2 + 段落 1（反转顺序）

预期：
- 前缀缓存：A 和 B 的第一个 token 就不同 → 缓存命中 = 0
- 内容哈希缓存：A 和 B 的内容完全相同 → 缓存命中 = 100%
- 固定响应公式：A 和 B 的 cached_tokens = f(prompt_tokens) → 完全相同

决策逻辑：

复制代码

if 重排后缓存命中 ≈ 0 → H3（前缀缓存）→ 进入 Phase 3b
if 重排后缓存命中 ≈ 100% → H2（内容哈希）→ 进入 Phase 3a
if 重排后缓存命中 ≈ f(prompt_tokens) 不变 → H1（固定响应）→ 回退 Phase 1

2.2 前缀缓存分叉点探针（H3 确认）

测试逻辑：构造一系列 prompt 对，前缀共享比例从 0% 逐步增加到 100%（以 token 为单位，非字符）。

复制代码

共享比例: 0% → 25% → 50% → 75% → 90% → 100%
预期 H3:  cached ≈ 共享前缀的 token 数
预期 H2:  cached = 0（0%）或 100%（100%），中间值全为 0
预期 H4:  cached ≈ f(共享比例)，但可能非线性

2.3 时间与会话维度探测（H6 vs H7）

测试逻辑：

使用不同 API key 在短时间内发送相同请求
使用相同 API key 在 TTL 后发送相同请求

if 跨 key 仍然命中 → H2 或 H6（全局/时间窗口缓存）
if 仅同 key 命中 → H7（会话级缓存）

Phase 3: 边界映射

根据 Phase 2 的结论进入不同的子阶段

Phase 3a: 内容哈希缓存边界映射

探针维度	测试内容	关键问题
哈希敏感度	改变单个字符、空白符、换行符、标点	哈希是否对微小变化敏感？是否是标准化哈希（忽略空白）？
序列化格式敏感度	JSON key 顺序变化、messages 数组顺序	哈希输入是原始 JSON 还是规范化后的表示？
内容长度边界	从 1 token 逐步增加到 10000+ tokens	是否存在最小/最大缓存长度？超大内容是否绕开缓存？
哈希碰撞概率	大量不同内容（>1000 种）的缓存命中模式	是否存在可检测的碰撞模式？

Phase 3b: 前缀缓存边界映射

探针维度	测试内容	关键问题
分叉点精度	前缀共享比例：0%, 10%, 20%, ..., 100%	分叉点检测精度是 token 级还是字符级？
中断规则	在共享前缀中间插入一个不同 token，后面又恢复相同	缓存是否在第一个差异处断开（不可恢复）？还是可以"跳过"差异？
Breakpoint 行为	构造多个分叉点（前缀 A 共享，中间 B 分叉，后缀 C 又共享）	缓存能否在分叉后"重新匹配"？
最小匹配长度	前缀长度从 1 token 逐步增加	最短多少 token 的前缀可以触发缓存？

Phase 3c: TTL 衰减曲线（所有机制适用）

测试逻辑：

写入缓存（发送一个"播种"请求）
在时间点 t = $1s, 5s, 10s, 30s, 60s, 120s, 300s, 600s, 1800s, 3600s$ 发送相同请求
记录每个时间点的缓存命中率
拟合衰减曲线

关键约束：每个时间点的探测请求本身会刷新缓存。因此每对"播种→探测"必须是独立的内容（用唯一 UUID 区分）。

复制代码

正确设计（隔离）：
  播种_A → 等待 10s → 探测_A  (测 TTL=10s 的衰减)
  播种_B → 等待 30s → 探测_B  (测 TTL=30s 的衰减，独立于 A)
  
错误设计（污染）：
  播种_A → 等待 10s → 探测_A → 等待 20s → 探测_A
  ↑ 第一次探测_A 已经刷新了缓存，第二次测的是 20s 而非 30s

Phase 4: 鲁棒性测试

维度	测试内容	关键问题
并发写入	同时发送 5/10/20 个不同的"播种"请求，然后检测每个的缓存是否独立存在	缓存是否支持并发写入？是否有 race condition？
缓存容量	持续发送大量不同的内容（100+ 个唯一 prompt），然后回头检测最早的内容是否被逐出	LRU？FIFO？随机逐出？容量上限？
大载荷	单个 prompt 的 token 数达到 8K/16K/32K	大内容是否绕过缓存？
跨模型隔离	在端点 A（声称 deepseek-v3.2）和端点 B（deepseek-v4-pro）上发送相同内容	缓存是按模型隔离的还是全局共享的？
异常恢复	发送一个导致 4xx/5xx 的请求后，检测之前的缓存是否仍然存在	错误响应是否触发缓存清空？

3. 实验矩阵设计

3.1 矩阵维度

维度	类型	水平数	水平定义
D1: 内容相似度	自变量（操纵）	6	完全相同 / 前缀共享 / 后缀共享 / 顺序重排 / 部分重叠 / 完全不相关
D2: 请求序列位置	自变量（操纵）	3	首次请求（播种）/ 二次请求（探测）/ 第 N 次请求
D3: 时间间隔	自变量（操纵）	8-10	0s, 1s, 5s, 10s, 30s, 60s, 120s, 300s, 600s, 1800s
D4: 内容大小	自变量（操纵）	3	小型 ~200 tokens / 中型 ~1000 tokens / 大型 ~5000 tokens
D5: 修改粒度	自变量（操纵）	4	替换 1 字符 / 替换 1 token / 替换 1 段落 / 替换全部
D6: API 端点	分组变量	2-3	算优优 / 移动云 / 官方 DeepSeek（对照）
D7: 迭代次数	控制变量	≥5	每个条件重复至少 5 次（基于 test-V4 审查建议）

3.2 矩阵压缩策略

全因子实验的组合数是 6×3×10×3×4×3×5 = 32,400 个条件------不可行。

压缩策略：不是所有维度组合都有意义。按阶段裁剪：

阶段	活跃维度	典型组合数	说明
Phase 1	D1(2) × D2(2) × D6(2) × D7(≥5)	~40	仅需完全不同 vs 完全相同
Phase 2	D1(3) × D2(2) × D6(2) × D7(≥5)	~60	重排、前缀共享、完全不同
Phase 3a	D1(2) × D4(3) × D5(4) × D6(1) × D7(≥5)	~120	针对内容哈希的精细探测
Phase 3b	D1(2) × D4(3) × D5(2) × D6(1) × D7(≥5)	~60	针对前缀缓存的精细探测
Phase 3c	D3(10) × D6(2) × D7(≥3)	~60	TTL 曲线
Phase 4	视前序结果定制	~50-100	针对性鲁棒性测试

总计：约 390-440 次 API 调用（可管理）

3.3 随机化与阻塞

Phase 内随机化：同一 Phase 内的条件顺序应随机化（Fisher-Yates shuffle）
Phase 间隔离：每个 Phase 使用独立的内容域，避免 Phase 间缓存污染
端点间对照：算优优和移动云的测试应交替进行（而非先完成一个再另一个），以消除时间趋势混淆

4. 探针污染防护策略

这是 test-V4 最严重的架构缺陷。本次方案将污染防护从"建议"提升为"架构约束"。

4.1 污染类型与对策

污染类型	机制	test-V4 表现	本方案对策
跨场景污染	前序场景将内容写入缓存，后序场景误中	`different_system` 假阳性（P0 行动项 #4）	内容域隔离 + Phase 隔离
跨迭代污染	同一场景的迭代 1 写入缓存，迭代 2-5 全部命中	所有迭代显示相同 `cached_tokens`	每次迭代使用独立内容域
跨时间点污染	TTL 测试的探测请求刷新缓存	TTL 测试逻辑缺陷（P0 行动项 #7）	每个时间点使用独立"播种-探测"对
跨端点污染	端点 A 的缓存通过某种后端共享影响端点 B	未知	如果两个端点行为完全一致，需怀疑是否为同一后端

4.2 内容域隔离架构

核心思想：每个独立的测试单元使用完全不重叠的语料空间。

复制代码

内容域分配：
  Domain_Phase1_A:  语料集 {动物学, 植物学, 矿物学}
  Domain_Phase1_B:  语料集 {量子物理, 相对论, 弦理论}
  Domain_Phase2:    语料集 {法国历史, 英国历史, 德国历史}
  Domain_Phase3a:   语料集 {操作系统, 编译器, 数据库}
  Domain_Phase3b:   语料集 {油画技法, 雕塑技法, 版画技法}
  Domain_Phase3c_T1-T10:  语料集 {10 个独立的虚构公司简介}
  Domain_Phase4:    语料集 {奥运会历史, 世界杯历史, ...}

关键原则：

每个 Phase 使用独立的语料领域，词汇零重叠
每个 TTL 时间点使用独立的内容（用 UUID 标记）
阴性对照必须在每个 Phase 开始时首先执行
语料库本身不应在 API 的全局缓存中预先存在（使用随机生成的合成内容更好）

4.3 会话隔离检查清单

在每次 Phase 切换时执行：

复制代码

□ 当前使用的 API key 是否与上一 Phase 相同？
  → 如果相同：是否有证据表明上一 Phase 的内容已从缓存中逐出？
  → 如果不确定：等待 ≥ 推测 TTL × 2 的时间

□ 当前 Phase 的语料域是否与所有前序 Phase 的语料域零词汇重叠？
  → 用自动化脚本验证（集合交集检测）

□ 当前 Phase 的阴性对照是否在序列第一位？
  → 确保阴性对照结果不被任何前序操作污染

5. 风险、局限性与盲区

5.1 可探测性边界

以下情况，黑盒测试无法得出确定结论：

盲区	原因	影响	缓解措施
多层缓存	API 代理后可能有多层缓存（CDN → 代理 → 模型服务），探针只能看到最终聚合效果	可能将多层聚合误判为单一机制	通过不同时间尺度（秒级 vs 分钟级）的测试间接推断层次
动态切换策略	API 提供商可能根据负载动态调整缓存策略	不同时间的测试结果可能不一致	在多个时间段重复核心探针（早/中/晚各一次）
私有缓存键	缓存键可能包含探针无法控制的字段（如 IP、User-Agent、请求头顺序）	跨客户端测试结果不一致	在探针文档中明确声明所有请求头的取值
缓存预热	API 可能对热门内容做预先缓存（基于日志分析）	第一次请求就出现缓存命中	使用足够冷门的合成内容
概率性缓存	缓存可能只有一定概率生效（如：仅在负载高时启用）	结果有随机性	增大迭代次数（n ≥ 10），报告置信区间

5.2 如果 `cached_tokens` 完全虚假

这是本方案的最坏情况。如果 Phase 1 判定 cached_tokens 不可信（即 H1 成立），后续所有实验必须：

切换到双信源模式：
- 主信源：响应延迟（需在相同网络条件下多次测量取中位数）
- 辅助信源：API 计费仪表盘（如果可以获取实际扣费数据）
延迟测量的挑战：
- 网络抖动噪声：需要足够大的迭代次数（建议 n ≥ 10）和异常值过滤（IQR 方法）
- 模型推理时间方差：首 token 延迟（TTFT）比总延迟更有区分力，因为缓存应主要减少计算时间
- 需要非缓存场景的基线延迟作为对照
可接受的结论范围缩小：
- 可以确认："物理缓存是否存在"（通过延迟下降判断）
- 可以确认："缓存是否对内容敏感"（通过不同内容的延迟对比）
- 无法确认："缓存的精确命中率"------延迟下降只能告诉你有缓存，但不能精确量化命中了多少 token

5.3 探针自身的伦理边界

API 的速率限制：Phase 3c 和 Phase 4 可能触发速率限制。需要在方案中预留"冷却期"。
不要对生产 API 进行 DoS 级别的并发测试（Phase 4 的并发写入应限制在 20 个并发以内）
如果 API 返回 429，应自动退避而非重试

6. 后续执行方案：从实验到测试工具

6.1 结论到工具架构的映射

假设 Phase 4 完成后得出了确定的缓存模型，以下是各结论对应的测试工具架构原则：

场景 A：确认为「内容哈希全局缓存」

复制代码

测试工具的核心变更：
  ✗ 删除：所有基于"前缀共享比例"的测试场景（prefix_sweep, prefix_truncation,
          partial_overlap）------这些场景对内容哈希缓存无区分力
  ✓ 新增：内容复用率监测器------在对话历史中追踪内容块的重复出现频率
  ✓ 重构：cached_tokens 的语义从"前缀命中 token 数"改为"内容复用 token 数"
  ✓ 架构调整：测试场景从 6 个减少到 3 个核心场景：
      - identical（阳性对照）
      - content_reordered（敏感度测试：顺序重排是否影响命中）
      - content_modified（敏感度测试：微小修改是否影响命中）
  ✓ 监控指标变更：从"cache hit rate by prefix overlap"改为
      "cache hit rate by content similarity"

场景 B：确认为「前缀匹配上下文缓存」

复制代码

测试工具的核心变更：
  ✓ 保留：前缀类测试场景（prefix_sweep, prefix_truncation）------但需用 tiktoken
          精确计算 token 级分叉点
  ✗ 删除：current 的字符级切分方式
  ✓ 新增：分叉点精度测试（token-level bifurcation point detection）
  ✓ 新增：前缀缓存的中断与恢复测试（breakpoint and reattach）
  ✓ 监控指标：精确到 token 的缓存命中率，与预期前缀共享比例对比

场景 C：确认为「无缓存」（H0）或「固定响应」（H1）

复制代码

测试工具的核心变更：
  ✗ 整个缓存测试工具废止------如果无缓存，就没有可测的东西
  ✓ 替代方案：将工具重定位为"API 行为一致性验证器"
      - 验证 usage 字段的公式化关系
      - 监测不同 API 版本间的字段语义变化
      - 作为持续监控工具，在 API 升级后自动检测缓存行为是否发生变化

6.2 测试工具架构设计原则（独立于缓存结论）

无论最终确认的是哪种缓存机制，重构后的测试工具应遵循：

信源可切换 ：支持 cached_tokens、延迟、计费三种信源，通过配置项切换
探针隔离优先：每个探针单元使用独立的内容域，探针执行顺序可随机化
统计报告：所有测量附带 95% CI 和效应量，不再依赖 n=2 和固定阈值
自检机制：在每次测试运行的开头自动执行 Phase 1 级信号验证，如果信号模式异常则自动终止并报告
多端点支持：同时测试多个端点，自动执行对照分析
双模运行：支持"探测模式"（反向工程缓存机制）和"监控模式"（持续验证缓存行为是否变化）

7. 交付物清单

本方案产生

交付物	负责方	状态
缓存策略探测实验方案架构（本文档）	gstack-product-reviewer	✅ 已完成
决策树可视化（内嵌 SVG）	gstack-product-reviewer	✅ 已完成

需要后续产生

交付物	负责方	依赖
Phase 1-4 的具体探针测试用例（参数化规格）	gstack-investigator	本文档 Phase 架构
判定标准与统计显著性要求（含自动化判定逻辑）	gstack-qa-lead	本文档假设空间 + investigator 探针设计
综合执行脚本（整合三方输出）	team-lead	以上全部

缺陷对应关系

缺陷	缺陷描述	本方案如何解决
逻辑缺陷	CORPUS 重叠导致不同 system prompt 内容相同	Phase 架构 + 内容域隔离：每个 Phase 使用独立语料域，零词汇重叠
功能缺陷	prefix_sweep 重复 API 调用	不在本方案范围（implementation detail），但架构上要求每个探针是纯函数
方法论失效	exact minus 1 模式未被检测	Phase 1 信号真实性验证：自动检测固定公式模式并终止
缓存污染	场景顺序固定，后序被污染	Phase 间隔离 + 阴性对照优先 + 内容域隔离
场景构造	UUID 前缀不足以区分内容哈希	Phase 2 顺序重排探针：用完全反转的内容区分哈希缓存
场景构造	字符级切分 ≠ token 级切分	Phase 3b 要求 token 级精确切分（使用 tiktoken）
TTL 污染	探测请求刷新缓存	Phase 3c：每个时间点使用独立的"播种-探测"对
判定逻辑	固定阈值、n=2、错误处理	不在本方案范围（qa-lead 负责判定标准）

缓存策略探测实验方案架构设计

执行摘要

1. 假设空间目录

1.1 缓存机制假设空间

1.2 假设的 Bayesian 先验（基于现有 4 份报告）

1.3 不可区分假设对

2. 阶段架构

总览

Phase 0: 信号源盘点

Phase 1: 信号真实性验证

1.1 独立性探针（H0 vs H1 区分）

1.2 一致性探针（验证信号与物理缓存的相关性）

1.3 跨端点对照探针

Phase 2: 缓存机制区分

2.1 内容哈希 vs 前缀缓存区分（H2 vs H3）

2.2 前缀缓存分叉点探针（H3 确认）

2.3 时间与会话维度探测（H6 vs H7）

Phase 3: 边界映射

Phase 3a: 内容哈希缓存边界映射

Phase 3b: 前缀缓存边界映射

Phase 3c: TTL 衰减曲线（所有机制适用）

Phase 4: 鲁棒性测试

3. 实验矩阵设计

3.1 矩阵维度

3.2 矩阵压缩策略

3.3 随机化与阻塞

4. 探针污染防护策略

4.1 污染类型与对策

4.2 内容域隔离架构

4.3 会话隔离检查清单

5. 风险、局限性与盲区

5.1 可探测性边界

5.2 如果 cached_tokens 完全虚假

5.3 探针自身的伦理边界

6. 后续执行方案：从实验到测试工具

6.1 结论到工具架构的映射

场景 A：确认为「内容哈希全局缓存」

场景 B：确认为「前缀匹配上下文缓存」

场景 C：确认为「无缓存」（H0）或「固定响应」（H1）

6.2 测试工具架构设计原则（独立于缓存结论）

7. 交付物清单

本方案产生

需要后续产生

缺陷对应关系

5.2 如果 `cached_tokens` 完全虚假