《Agent原理，架构与实践》

第1讲：大模型的三个核心工作机制

准备起一个新的系列《Agent原理与实践》，讲讲agent的原理，架构与实践。目标不贪心：

1. 希望每篇文章有1-2个点能让大家有收获；

2. 希望不被骂；

本期第一讲，咱们开始。

【0】

大家有没有发现，跟AI聊得越久，它越像"记得"你说过的话：上午聊的方案，下午问一句"我刚才说的那个方案呢？"，它接得天衣无缝。

所以很多人理所当然地认为：大模型是有记忆的。可其实呢？

大模型内部有三个工作机制，它们不复杂，但很多人对它们的理解是错的。对大模型的错误理解，是很多人做Agent架构设计翻车的根源：

1. 为什么skill要写成文件？

2. 为什么问一个“你好”要花那么多token？

3. 为什么上下文要精打细算？

答案，都在这三个机制里。

【1】

第一个机制：模型是没有记忆的。

大模型的每次调用，都是独立的请求响应，上一次聊了什么，它一点也不记得。架构上管这叫"无状态"（stateless）。

画外音：站点层，服务层都应该设计成无状态，才方便水平扩展。

那为什么我们觉得Agent能接上话，好像有记忆似的？

那是因为Agent每次调用大模型时，都把之前的聊天记录，重新打包发给了它。大模型是看着完整记录，现场"重放"出连贯感的。

第1轮：发送[消息1] → 模型回复； 

第2轮：发送[消息1，回复1，消息2] → 模型回复；

第3轮：发送[消息1，回复1，消息2，回复2，消息3] → 模型回复。

每一轮都是全新计算，历史聊天记录是每次都重新塞进去的。

所以，"它记得我"只是个错觉，是Agent在替它记。模型自己，其实什么都不知道。

记忆不是模型自带的，而是Agent架构设计出来的。想让Agent记住什么，就得由我们把信息保存下来、在合适的时机塞回上下文。

画外音：想做自己的Agent，这一点尤为重要。

【2】

第二个机制：token就是钱。

模型看的不是字，也不是词，而是token，它是模型眼里的最小单位，理解、生成、计费，全都按它算。

画外音：官方是叫词元。

这里有两个有意思的知识点，大伙可以自测一下。

其一：表达同样的意思，一般来说，中文耗费存储多，还是英文耗费存储多？

3

2

1

...

公布答案：通常来说，中文消耗存储更少。

举个例子：

"上下文窗口就是天花板。"，中文按照GBK编码，差不多20多个字节。

而

"The context window is the ceiling."，差不多30多个字节。

其二：相同的情况，中文耗费token多，还是英文耗费token多呢？

3

2

1

...

公布答案：通常来说，中文消耗token更多。

还是上面的例子：

"上下文窗口就是天花板。"，中文差不多10多个token。

而

"The context window is the ceiling."，则是7个token左右。

画外音：具体多少token，和tokenizer切分有关。

一般来说，表达同一个意思，中文通常比英文费token。也就是说，同样的信息，中文往往更"贵"。

钱又是怎么计算的？

一次调用的成本 = 输入token数 × 输入单价 + 输出token数 × 输出单价

你不要以为，这一点差异而已，中文英文也没差多少。但回到第一个机制：每一轮对话都要把累积的历史重新发一遍。普通聊天，里这个放大效应还不明显，可Agent是循环工作的，跑十轮，每一轮的输入都在膨胀。

有生产数据估算：Agent类交互的token消耗，大约是普通聊天的4倍；多Agent系统，可能达到15倍。

画外音：不要无脑鼓吹多Agent多好多好，光从token费用这一点上来说，我个人持保留意见。

【3】

第三个机制：上下文窗口就是天花板。

上下文窗口（context window），就是模型一顿饭的饭量，一次调用能吃进去的token总量，碗就这么大。输入加输出，都得装进这个碗。

窗口满了会怎样？

报错吗？硬限制确实存在，超出窗口直接报错或截断。但更值得警惕的是软退化：在远没撞线的时候，模型的表现就已经开始下滑了。

Anthropic官方把这种现象称为上下文腐烂（context rot），原话是：

As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.

画外音：上下文里的token越多，模型从里面准确捞出信息的能力越差。

明明没有到窗口上限，为什么模型表现就开始下降呢？

注意力机制。

Transformer有个规矩：每个token都得关联计算其他所有token。n个token，就要处理n²组关系。上下文越长，每段关系分到的注意力就越薄。

所以装满窗口不是一个开关，而是渐变：还能用，但越来越糊涂——回忆精度和长程推理，都在慢慢下降。

别被"百万token窗口"骗了，窗口越大，塞得越多，想捞的信息越难被准确捞回来。

【4】

三个机制合起来，就是Agent架构设计需要重点考虑的：

1. 模型没有记忆：我们要自己设计记忆，塞进上下文；

2. token就是钱：塞进上下文的每个token都有成本；

3. 上下文窗口是天花板：上下文能装的内容有限，塞多了还会退化。

这三条，就是Agent设计的基石。后面十一讲，本质上都在回答同一个问题：在这三个约束之下，怎么把Agent设计好。让我们一起，一步一步，实现自己业务专属的mini-agent。

补充阅读：《Agents设计之高效上下文工程》

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

下一讲，我们聊聊：大模型有幻觉，Agent架构设计，如何尽量减少幻觉的出现。

知其然，知其所以然。

思路比结论更重要。

===全文完==

这个话题，是否值得聊一聊？期待你的反馈。

PS：公众号只能贴静态图文，无法用js实时互动，在线版设计了课后习题与实操演练，欢迎阅读原文体验。