我之前读过讲上下文的文章 我记得每次对话都是把上下文重新塞进对话里 多轮循环之后会变得越来越长

回复 群友 8832： 对，这是现在所有对话式 agent 的默认做法：每一轮都是把完整历史重新拼成一次请求发给模型，模型本身无状态，不记得上一轮。所以轮数越多，上下文越长，成本和延迟一起涨，模型注意力也会被稀释。 但要说清楚两件事： 一是「上下文长」不等于「一定爆」。现在主流模型窗口都到 100k~1M token 了，日常多轮根本填不满。真正出问题的是几种情况：工具返回的内容特别大（比如读整个文件、爬一整页 HTML）、多轮里反复塞同样的系统提示和 skill 描述、还有 agent 自己越跑越久的 session。 二是「把历史重新塞进去」这个过程本身，现在的工程做法和你印象里已经不太一样了，主要在这几个层面动手： 前缀缓存。系统提示和早期历史在每轮开头都是一样的，服务商把这部分缓存下来，命中缓存的部分便宜很多、也快很多。这也是为什么前面说 Super-agent 去掉直通机制后，Router 的读缓存 token 涨了三成——省的是缓存钱。 截断和摘要。老轮次不是无限留着，要么按 token 预算从最早的开始丢，要么滚一个摘要。这是最简单粗暴也最有效的。 按引用管理长内容。这就是 DeepSeek 那篇里的 Inline & Spill：近期要用的直接内联，长内容只留摘要加一个 ID，需要时顺着 ID 往回转。好处是上下文里始终只有「索引」，原文不占窗口。 不把整段会话喂给所有 agent。子 agent 拿到的是切好的任务上下文，不是完整群聊。这个和上下文长不长是一回事的两个面：不去控制谁看什么，再大的窗口也会被噪音吃掉。 一个实际的坑：很多人以为「窗口大所以随便塞」，结果中间那部分内容模型根本注意不到（lost in the middle），放窗口中间的信息召回率明显低于开头和结尾。所以重要的东西尽量放在开头或结尾，别指望它自己翻。 你读的那篇文章如果讲的是「每轮重塞」这件事本身，那没说错；但如果结论是「所以上下文必然一直涨」，那是没考虑上面这几种处理。你要是把链接贴出来我可以对照着看它说细到哪一步了。