README.md

2.1 聊天里的“记得”，是整段历史被重新发了一遍

怎么跑

op run --env-file experiments/aib.env -- .venv/bin/python experiments/2_1_stateless/run.py gemini-3.8-flash baseline
op run --env-file experiments/aib.env -- .venv/bin/python experiments/2_1_stateless/run.py deepseek-v4.1-flash

接口是 AI Builder Space（OpenAI 兼容），temperature=0。转写文本取自 corpus/memos.json 里的 W01、W07、W10、W12、W16、W17。

实验设计

• A：8 轮对话。 第 1 轮贴一段约 500 字的转写，并告诉模型“负责部署的叫蔺思远”。之后每轮只问一句很短的话。每轮记录两个数：用户实际打了多少字，接口这一轮实际计费的输入 token 是多少。
• B：不带历史重问最后一句。 把第 8 轮的问题单独发一次，前面的对话都不带。
• C：只发一个 “hi”。 记录各个模型计费的输入 token。

结果（2026-10-14）

A，gemini-3.8-flash（results_gemini-3.8-flash.json）：

第 8 轮只打了 13 个字，计费的输入却是 984 个 token。这一轮模型答对了：“蔺思远”。

B： 同一个问题不带历史再问一次，输入只有 20 个 token，模型回答“无法获取您团队或公司的内部信息”。

A 的复现，deepseek-v4.1-flash（results_deepseek-v4.1-flash.json）：输入从 751 涨到 1345 个 token；不带历史时同样答不出来。

C，只发一个 “hi” 的计费输入 token（baseline_hi.json）：

后两个模型的窗口里，有一两百到四百个 token 是用户从没打过的。我们不知道是谁加的、加了什么，但从账单上能确定它们在窗口里。这一点从外面就能看到，不需要知道任何产品的内部实现。

正文怎么用

• 2.1 的证据：多说一句，账单上的输入就涨一截。
• 2.1 的推理：模型知道新东西的唯一渠道是输入。
• “窗口里有你没写的东西”：C 的数字。

D：agent 工具里的上下文用量（DSH 截图）

dsh_demo.py 用 Playwright 驱动 DeepSeek Harness 的 Web 界面（模型 DeepSeek-V41-Flash，经 Ollama Cloud），工作区用公开的 deepseek_harness 仓库。侧栏折叠，不显示任何会话历史。跑完后会自动归档这个演示会话。截图在 assets/ch02_01/dsh_turn{1..6}.png，数字在 dsh_results.json。

• 第一轮只打了 557 个字，这一轮就用掉 18.2K token。多出来的是 agent 工具自己塞进窗口的系统提示和工具说明。
• 之后每轮只打几个字，每轮都要再花大约 18.5K token，因为整个窗口又被重新发了一遍。
• 缓存命中率从 0 一路涨到 83%，这是 5.6 前缀缓存的伏笔。
• 界面上的“上下文用量”一直显示 2%（窗口是 1M）。

这一节的读者看到的应该是：你只多说了一句，账单上就涨一整个窗口。

教材正文移出的细节（2.1 第二轮重写，2026 年 10 月）

• 正文只保留 gemini-3.8-flash 逐轮计费输入的首尾两个数（第 1 轮 361、第 8 轮 984），以及 deepseek-v4.1-flash 的 751 → 1345；完整的逐轮数字见上面 A 的表格。
• 正文不出现“temperature”（本模块的读者契约不讲温度），改写为“让它每次尽量给出同样的回答”；实际设置是 temperature=0。
• DSH 部分，正文只保留：第 1 轮 557 字对应 18.2K token；之后每轮约 18.5K；缓存命中率逐轮上涨（模块 5 解释）。逐轮的会话累计（18.2K、36.6K、55.1K、73.7K、92.4K、111K）、缓存命中率 0% → 83% 的逐轮数值、界面“上下文用量一直显示 2%（窗口 1M）”只保留在本 README 的 D 节。