模型没有记忆，token 就是钱，上下文窗口就是天花板
大家有没有发现，跟 AI 聊得越久，它越像”记得”你说过的话：上午聊的方案，下午问一句”我刚才说的那个方案呢？”，它接得天衣无缝。所以很多人理所当然地认为：大模型是有记忆的。可其实呢？
大模型内部有三个工作机制，它们不复杂，但很多人对它们的理解是错的。对大模型的错误理解，是很多人做 Agent 架构设计翻车的根源：为什么 skill 要写成文件？为什么 Agent 跑一轮要花那么多 token？为什么上下文要精打细算？答案，都在这三个机制里。
问题一：大模型记得我们说的话，是有记忆吗？
大模型的每次调用，都是独立的请求响应，上一次聊了什么，它一点也不记得。架构上管这叫”无状态”（stateless）。
站点层、服务层都应该设计成无状态，才方便水平扩展。
那为什么我们觉得 Agent 能接上话，好像有记忆似的？那是因为 Agent 每次调用大模型时，都把之前的聊天记录重新打包发给了它。大模型是看着完整记录，现场”重放”出连贯感的。
我们看到的： 一轮连续的对话，模型记得一切
实际发生的： 第 1 轮：发送 [消息1] → 模型回复
第 2 轮：发送 [消息1, 回复1, 消息2] → 模型回复
第 3 轮：发送 [消息1, 回复1, 消息2, 回复2, 消息3] → 模型回复
每一轮都是全新计算，历史是每次都重新塞进去的所以”它记得我”只是个错觉，是 Agent 在替它记。模型自己，其实什么都不知道。想做自己的 Agent，这一点尤为重要。
记忆不是模型自带的，而是 Agent 架构设计出来的。想让 Agent 记住什么，就得由我们把信息保存下来、在合适的时机塞回上下文。这是第 4 讲“长任务的记忆”要展开的内容，咱们这里先埋下这个认知。
问题二：token 为什么就是钱？
模型看的不是字，也不是词，而是 token——模型眼里的最小单位。理解、生成、计费，全都按它算。
官方是叫词元。
这里有个有意思的知识点，大伙可以先自测一下：表达同样的意思，中文费 token 多，还是英文费 token 多？
3、2、1……公布答案：通常来说，中文消耗 token 更多。举个例子：
"上下文窗口就是天花板。" → 约 10-15 个 token
"The context window is the ceiling." → 约 7-10 个 token
同样的信息，中文往往更"贵"具体多少 token，和 tokenizer 切分有关。
钱又是怎么计算的？
一次调用的成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价你不要以为，这一点差异而已，中文英文也没差多少。回到第一个机制：每一轮对话都要把累积的历史重新发一遍。普通聊天里，这个放大效应还不明显，可 Agent 是循环工作的，跑十轮，每一轮的输入都在膨胀。有生产数据估算，Agent 类交互的 token 消耗大约是普通聊天的 4 倍，多 Agent 系统可能达到 15 倍。Agent 的成本问题本质是输入 token 问题——这个账我们在第 10 讲会完整算一遍。
不要无脑鼓吹多 Agent 多好多好，光从 token 费用这一点上来说，我个人持保留意见。
问题三：窗口那么大，为什么还会”忘”？
上下文窗口（context window），就是模型一顿饭的饭量——一次调用能吃进去的 token 总量，碗就这么大。输入加输出，都得装进这个碗。
窗口满了会怎样？报错吗？硬限制确实存在，超出窗口直接报错或截断。但更值得警惕的是软退化：在远没撞线的时候，模型的表现就已经开始下滑了。Anthropic 官方把这种现象称为上下文腐烂（context rot），原话是：
上下文里的 token 越多，模型从里面准确捞出信息的能力越差。
明明没有到窗口上限，为什么模型表现就开始下降呢？注意力机制。Transformer 有个规矩：每个 token 都得关联计算其他所有 token。n 个 token，就要处理 n² 组关系。上下文越长，每段关系分到的注意力就越薄。所以装满窗口不是一个开关，而是渐变：还能用，但越来越糊涂——回忆精度和长程推理，都在慢慢下降。
别被”百万 token 窗口”骗了，窗口越大，塞得越多，想捞的信息越难被准确捞回来。上下文是稀缺资源——这个判断是第 3 讲的全部内容。
三个机制合起来
三个机制合起来，就是 Agent 架构设计需要重点考虑的：
模型没有记忆 → 记忆要我们自己设计，塞进上下文
token 就是钱 → 塞进上下文的每个 token 都有成本
窗口是天花板 → 上下文能装的有限，塞多了还会退化这三条，就是 Agent 设计的基石。后面十一讲，本质上都在回答同一个问题：在这三个约束之下，怎么把 Agent 设计好。让我们一起，一步一步，实现自己业务专属的 mini-agent。
贯穿案例：sdd-site-agent
从第 3 讲起，每一讲的末尾都有一个「落到 sdd-site-agent」的小节，每讲的作业也都在它身上做。先花一分钟混个脸熟——后面十几讲，全靠它练手。
sdd-site-agent 是一个”规格驱动”（spec-driven）的站点生成 Agent：输入一句话需求（我们叫它”需求 a”），它按流程产出四样东西——需求文档、原型、架构方案、可运行的代码。
它干活要遵守团队的三种规范：需求规范（需求文档怎么写）、原型规范（原型怎么画）、架构规范（方案和代码怎么出）。这三个规范是全课的道具——分层加载拿它们练手、记忆结构拿它们设计、工具拿它们当读写对象、最后它们会变成三个 skill。
它还有一个几百行 Python 的迷你实现，叫 mini-agent——从第 3 讲起，每讲作业后面的「作业实现思路」里，你会看到咱们设计的东西在它身上长什么样。
选这个案例不为别的：它个头不大，但 Agent 设计的典型问题——上下文、记忆、循环、工具、规范、验收、安全、成本——它一个不落全有。麻雀虽小，五脏俱全。
实操演练（约 25 分钟）
大伙别急着往下翻，这一讲的三个机制必须亲手验证一遍才会变成自己的东西。必做部分 + 一步加餐，做完必做部分，核心手感就到手了。准备一个我们日常在用的 AI 助手（任意平台）和一个在线 tokenizer 工具（各大平台都有，搜索引擎搜”tokenizer”即可，比如 OpenAI 的 tokenizer 页面）。
检验一下
① 一组 token 实测：一段中文 + 对应英文的 token 数，记录工具名称和两组数字；
② 一笔真实账：按所用平台实时价格，算出自己一个真实场景的完整成本（含输入输出）；
③ 一次失忆验证：连续对话 10 轮后开新会话问”我们刚才聊了什么”，记录它的回答。
三份记录自己留存——第 3 讲和第 10 讲会用到这次的数据，到时候翻出来对照，感受会完全不一样。
大伙如果想深挖一层，读这篇：Anthropic · Effective context engineering for AI agents
上下文腐烂（context rot）和注意力预算（attention budget）这两个概念就出自这篇。它也是第 3、4 讲的终审依据，15 分钟阅读量，值得现在就翻一遍（这篇沈剑读了不止一遍，每读一遍都有新东西）。
但还有一个没解决的问题：没有记忆也就罢了，大模型还会一本正经地编——编论文标题、编 API、编得比真的还真。它为什么这么爱编？我们又该怎么防？——第 2 讲，我们讲能力边界与幻觉。
知其然，知其所以然。思路比结论更重要。