3.4 会话的本质：为什么不要在一个窗口里问所有问题

前两节讲了记忆和上下文工程的技术实现。这一节讲一个更实际的问题：你怎么用一个会话。

很多人用 AI 工具的方式是：开一个窗口，从早聊到晚，什么都往里塞。写代码、问问题、改文档、聊想法——全在同一个会话里。

我以前也这样。直到我发现，会话越长，AI 越不好使。

会话的本质是什么？

先说一个关键认知：会话 = 上下文窗口。

你在会话里说的每一句话、AI 回的每一段内容、工具调用的每一次结果，全都存在同一个上下文窗口里。这个窗口是有大小限制的——就像一张桌子，桌面就那么大，放的东西越多，能放的越少。

【一个会话的上下文窗口】

┌─────────────────────────────────────────┐
│  System Prompt（角色定义 + 规范）         │  ← 固定占位，约 2000-5000 tokens
│  Skill 目录 + Rule 约束                  │  ← 固定占位
│  ─────────────────────────────────────  │
│  记忆事实 + 项目上下文                    │  ← 每次对话都带
│  ─────────────────────────────────────  │
│  对话历史                                │
│  ├── 第 1 轮：讨论 A 需求                 │
│  ├── 第 2 轮：修改 B 模块                 │
│  ├── 第 3 轮：调试 C 接口                 │
│  ├── 第 4 轮：问 D 问题                   │
│  ├── ...                                │
│  └── 第 N 轮：当前问题                    │  ← 越来越挤
│  ─────────────────────────────────────  │
│  工具调用结果（文件内容、搜索结果...）      │  ← 最容易膨胀的部分
└─────────────────────────────────────────┘
           ↑ 总量有上限，超出就出问题

换句话说，你在一个会话里聊的所有内容，LLM 都要"记住"。 不是选择性记住，是全部记住。因为这就是它能看到的全部信息。

理解了这一点，很多使用上的问题就想得通了。

问题 1：Token 消耗随会话长度线性增长

最直接的后果：会话越长，每次调用消耗的 Token 越多。

LLM 每次回复，不是只读你最新的一句话。它要把整个上下文窗口里的所有内容都读一遍——System Prompt、历史消息、工具调用结果——然后才能生成回复。

第 1 轮调用：读 3000 tokens → 回复 500 tokens → 花费 3500 tokens
第 10 轮调用：读 15000 tokens → 回复 500 tokens → 花费 15500 tokens
第 50 轮调用：读 80000 tokens → 回复 500 tokens → 花费 80500 tokens

你只是问了一个简单的问题，但因为会话已经很长，LLM 要处理 8 万 tokens 的历史才能回答。就像你问同事一个简单问题，但他得先翻完前面 50 页会议纪要才能回答你。

这不只是钱的问题（虽然 Token 费用确实会涨），更是速度的问题——上下文越长，响应越慢。

问题 2：话题分散导致 LLM 注意力稀释

这个问题更隐蔽，但影响更大。

LLM 的注意力机制（Attention）是在整个上下文窗口上做计算的。当你的会话里只有一个话题时，所有注意力都集中在这个话题上——LLM 能精确理解你的意图、记住前面的细节、给出高质量的回答。

但当你的会话里混了五六个不相关的话题时：

会话内容：
├── A 话题：C# 异常处理（10 轮对话）
├── B 话题：前端组件设计（8 轮对话）
├── C 话题：数据库迁移（5 轮对话）
├── D 话题：部署配置（3 轮对话）
└── E 话题：你现在在问的新问题（1 轮）

LLM 在回答 E 的时候，它的注意力会被 A、B、C、D 的内容分散。就像一个程序员同时开五个需求，每个需求都只推进了一点——切换成本是真实存在的。

LLM 也有"上下文切换成本"。 话题越多，它在每个话题上的"专注度"越低。

我的实践经验

我后来养成了一个习惯：问题要聚焦，一个会话只解决一个主题。

如果一个会话里解决不了我的问题，我不会在这个会话里死磕。而是让 LLM 帮我整理当前上下文和遇到的问题：

"请帮我整理一下：
1. 我们在这个会话里做了什么
2. 当前遇到了什么问题
3. 关键的代码/配置/决策有哪些"

拿到整理结果后，开一个新窗口，把整理结果贴进去，继续解决问题。

几乎每次，新窗口都能很快解决问题。因为新窗口的上下文是干净的——没有历史噪音，LLM 的全部注意力都在你当前的问题上。

问题 3：会话超长引发各种异常

上下文窗口是有物理上限的。当会话内容超过窗口限制时，各种奇怪的问题就来了：

• 回复质量突然下降：LLM 开始"忘记"前面的内容，回答前后矛盾
• 工具调用出错：之前调用的工具结果被截断，LLM 拿到的是不完整的信息
• 格式混乱：输出开始丢失结构，JSON 不完整，代码缺半截
• 响应超时：上下文太长，处理时间变长，甚至直接超时

这些问题不是 LLM 变笨了，是上下文装不下了。就像你往一个杯子里倒水，倒满了还继续倒，水只会溢出来。

问题 4：主动压缩导致信息丢失

为了解决会话超长的问题，大多数 AI 工具都有上下文压缩机制——在上下文接近上限时，自动压缩历史消息。

压缩的方式通常是：把早期对话总结成一段摘要，替换掉原始内容。

压缩前：
  第 1-10 轮完整对话（5000 tokens）

压缩后：
  "用户之前讨论了 C# 异常处理规范，决定采用异常透明模式，
   禁止外层捕获，要求异常自然上抛。"（200 tokens）

看起来不错？但问题是：压缩一定会丢信息。

那段 200 token 的摘要，不可能包含 5000 token 原始对话的所有细节。当你后面需要引用前面的某个具体决策、某段代码、某个边界条件时，LLM 可能已经"不记得"了——不是它不想记，是压缩把它丢了。

压缩的本质是"用模糊换空间"。 你得到了更长的会话，但失去了精确的上下文。解决问题的效率因此降低——你得重新解释那些被压缩掉的信息。

问题 5：系统开销挤占有效空间

很多人不知道，上下文窗口里不只有你的对话。在你开口之前，窗口里已经被塞了一堆东西：

内容	大约占用	说明
System Prompt	2000-5000 tokens	角色定义、行为规范
Skill 目录	500-2000 tokens	可用技能列表
Rule 约束	1000-3000 tokens	项目规范、代码约束
记忆事实	500-2000 tokens	用户偏好、项目信息
AGENTS.md	1000-3000 tokens	项目架构、命名规范

你还没说第一句话，上下文窗口已经被占了 5000-15000 tokens。

如果你的上下文窗口是 128K tokens，看起来很大。但扣掉系统开销，再扣掉 LLM 回复需要的空间，真正留给对话历史的可能只有 100K 左右。如果你在一个会话里做大量工具调用（读文件、执行命令、搜索代码），这些结果会迅速填满剩余空间。

问题 6：工具调用结果是最大的"上下文杀手"

对话本身其实不算太长——你说一句、AI 回一句，一轮对话可能就几百 tokens。

真正撑爆上下文的是工具调用结果。

用户：帮我看看 PluginController.cs 有什么问题
  → LLM 调用 read_file("PluginController.cs")
  → 文件内容 500 行 = 约 3000 tokens 塞入上下文

用户：再帮我搜一下哪里用到了这个方法
  → LLM 调用 search("PluginController")
  → 搜索结果 20 个文件 = 约 5000 tokens 塞入上下文

用户：把那个文件也读一下
  → LLM 调用 read_file("另一个文件.cs")
  → 又是 3000 tokens

几次工具调用下来，上下文就涨了几万 tokens。这就是为什么"让 AI 帮我重构整个项目"这种操作特别容易出问题——每次读文件、改文件，结果都堆在上下文里，几轮下来就满了。

怎么用好一个会话？

理解了上面的问题，使用方法就很清楚了：

原则 1：一个会话，一个主题

每个会话只解决一个问题或一个任务。不要在一个会话里又写代码、又问概念、又改文档。

原则 2：问题复杂就开新窗口

如果一个会话里来回十几轮还没解决问题，别死磕。让 LLM 整理上下文，开新窗口继续。新窗口的"干净上下文"往往能更快找到答案。

原则 3：避免不必要的工具调用

每次工具调用的结果都会占用上下文。如果一个问题靠对话就能解决，不要让 AI 去读文件。减少不必要的工具调用，就是给上下文"减负"。

原则 4：长任务分阶段推进

如果一个任务确实很大（比如重构一个模块），不要指望一个会话搞定。分阶段推进：

会话 1：分析现状 → 输出重构方案
会话 2：执行重构第一步 → 输出进度和遇到的问题
会话 3：继续第二步 → 基于上次的进度继续

每个会话开始时，把上次的进度贴进去作为上下文。这比在一个超长会话里硬撑高效得多。

原则 5：善用"整理上下文"

当你感觉会话开始变慢、AI 回答质量下降时，不要继续追问。先让 AI 整理：

"请整理当前会话的关键信息：
1. 我们讨论了什么
2. 做了什么决策
3. 还有哪些问题没解决"

拿到整理结果后，开新窗口继续。

关键认知

会话不是聊天窗口，是 LLM 的工作台。工作台就那么大，堆满了东西，干活效率必然下降。

理解了这一点，你就理解了为什么 AI 编程工具都在强调"上下文管理"——不是因为 LLM 记性差，是因为上下文窗口是物理有限的资源。

用好 AI 的关键，不是问更好的问题，而是给 LLM 一个更干净的上下文。