我做的 AI Agent 跑短任务都好好的,可一上真实的长会话就越来越慢越来越贵,最后直接报 context length exceeded 整个挂掉,我对着每轮把全部历史和工具结果无限塞进上下文这个设计排查了大半天的复盘
这是我第一次做"能自己调用工具、多轮推进任务"的 AI Agent 时,栽的一个又贵又致命的跟头。它教会我的东西,比我之前读的所有 Agent 教程加起来都多。
需求很典型:做一个能帮用户查资料、读文件、调接口、然后综合给出答案的 Agent。我照着 ReAct 那套经典范式实现:Agent 在一个循环里,每轮把"系统提示 + 到目前为止的全部对话历史 + 工具调用结果"发给大模型,模型决定下一步是继续调工具还是给出最终答案,如此往复,直到任务完成。Demo 阶段,跑几个简单问题,丝滑流畅,我美滋滋地以为大功告成。
可一接入真实场景——用户和它多轮对话、任务需要调好几次工具、有的工具还会返回一整个网页或一大段 JSON——问题就暴露了:Agent 的每一轮响应,肉眼可见地越来越慢;后台账单,触目惊心地越涨越快;而最要命的,是跑得稍微长一点的会话,会突然抛出一个错误,然后整个任务彻底挂掉:
Error: This model's maximum context length is 128000 tokens.
However, your messages resulted in 143620 tokens.
Please reduce the length of the messages.
# 翻译: 你这次请求塞进去的内容(143620 token)
# 超过了模型的最大上下文窗口(128000 token), 请减少消息长度。
# 现象总结:
# - 短任务(2-3轮): 正常, 快, 便宜
# - 中等任务(若干轮+几次工具调用): 明显变慢, 变贵
# - 长会话/多轮工具调用: token 持续暴涨 → 最终 context length exceeded → 整个挂掉
我盯着这个 143620 tokens 的数字,百思不得其解:我每轮发的"当前这条消息"明明不长啊,怎么会撑到 14 万 token?
第一件事:看清根因——Agent 的上下文是"累积"的,每一轮都在重发整个历史
我把每一轮真正发给大模型的完整请求体打印出来、数了数 token,才终于看清这个我一直忽视的、却是 Agent 架构最核心的事实——大模型是"无状态"的,而 Agent 的"记忆",是靠每一轮把"全部历史"重新发一遍来实现的。
Agent 上下文累积的真相
# 大模型本身是【无状态】的:
# - 它不记得你上一轮跟它说过什么。每次 API 调用都是独立的、全新的。
# - 它"看到"的, 只有这一次请求里你发给它的全部内容。
# 所以 Agent 要有"记忆/上下文", 只能这样实现:
# - 每一轮, 把【从头到现在的全部对话历史 + 所有工具调用和结果】
# 统统重新打包, 作为这一次请求的输入, 再发一遍。
# 于是上下文像滚雪球一样【累积】:
# 第1轮发: system + 用户问题 (比如 1k token)
# 第2轮发: system + 用户问题 + AI第1轮回复 + 工具调用 + 工具结果 (比如 1k + 一个网页 30k = 31k)
# 第3轮发: system + 上面全部 + AI第2轮 + 又一个工具结果(20k) (51k)
# 第4轮发: system + 上面全部 + ... (越来越大)
# ...
# 第N轮: 把前面所有轮的一切, 又发了一遍 → 轻松突破 10万 token
# 雪上加霜的是【工具结果】:
# - 一次工具调用返回的一整个网页 HTML、一大段 JSON、一个文件全文,
# 可能就是几万 token。它一旦进了历史, 之后【每一轮都要重发一遍】!
# - 我调了3次"读网页", 3个网页的全文就永久占在上下文里, 每轮重发。
# 双重恶果:
# 1. 慢: 每轮输入越来越大, 模型处理越来越慢。
# 2. 贵: API 按 token 计费, 每轮重发全部历史 = 重复付费; 长会话成本是平方级增长!
# 3. 崩: 累积总量一旦超过模型上下文窗口(如128k), 直接报错, 任务挂掉。
# 核心: 大模型无状态, Agent 的记忆靠"每轮重发全部历史"实现; 历史(尤其大块工具结果)
# 会无限累积、每轮重复发送, 导致越来越慢、成本平方级增长、最终撑爆上下文窗口。
真相浮出水面的那一刻,我后背一凉。原来我那个"每轮把全部历史发给模型"的、看似天经地义的写法,藏着一个会随会话变长而不断恶化的"定时炸弹"。大模型是无状态的——它不记得上一轮,每次调用都是全新的;Agent 之所以显得"有记忆、能连续推进任务",全靠我每一轮把"从头到现在的所有对话和工具结果"重新打包、再发一遍。于是上下文像滚雪球一样累积:第 N 轮请求,塞进去的是前面每一轮的一切之和。而工具结果是雪上加霜的元凶——我调了几次"读网页",每个网页的整页 HTML(几万 token)一旦进了历史,之后每一轮都要重发一遍,永久占着窗口。恶果是三重的:每轮输入越来越大所以越来越慢;每轮重发全部历史、按 token 重复计费,长会话成本是平方级增长所以越来越贵;累积总量一旦超过上下文窗口就直接报错、任务崩掉。我那个 143620 的数字,正是无数轮历史 + 几个网页全文,被一遍遍重发、累积出来的。
第二件事:正解——主动管理上下文,别让它无限累积
搞懂了根因,正解就清晰了:Agent 必须主动"管理"上下文——控制每轮真正发给模型的内容,既保留推进任务所需的关键信息,又不让它无限膨胀。这是一套组合拳。
# ====== 正解一: 截断/压缩工具结果, 别把原始大块塞进历史 ======
def run_tool(name, args):
raw = actually_call_tool(name, args) # 比如返回一整个网页 HTML, 30k token
# ✗ 别把 raw 原样塞进历史! 而是先提炼:
if len(raw) > MAX_TOOL_RESULT_CHARS:
# 方式a: 截断 + 提示
summary = raw[:MAX_TOOL_RESULT_CHARS] + "\n...[结果过长已截断]"
# 方式b(更好): 用小模型/规则把工具结果摘要成"任务相关的要点"
# summary = summarize(raw, focus=current_task)
return summary
return raw
# ====== 正解二: 滑动窗口 —— 只保留最近 N 轮, 老的丢弃或归档 ======
def build_messages(system, history, max_recent=10):
# 永远保留 system, 只带最近 max_recent 条历史
recent = history[-max_recent:]
return [system] + recent
# → 上下文有了"上限", 不会随会话无限增长
# ====== 正解三: 摘要式记忆 —— 把老历史压缩成一段摘要 ======
def compact_history(history, keep_recent=6):
if len(history) <= THRESHOLD:
return history
old = history[:-keep_recent]
recent = history[-keep_recent:]
# 用模型把"老对话"压成一段简短摘要(保留关键事实/决定/结论)
summary = llm_summarize(old) # "之前: 用户要X, 已查到A、B, 决定用C方案..."
return [{"role": "system", "content": f"早前对话摘要: {summary}"}] + recent
# → 老历史从"逐字全文"变成"几百token的摘要", 大幅压缩
# ====== 正解四: 外部记忆 + 检索(RAG式) —— 大资料不进上下文, 用时再取 ======
# 把工具拿到的大文档存进向量库/外部存储, 上下文里只放"引用/摘要";
# 真需要细节时, 按当前问题检索出最相关的几段, 临时注入。
def get_relevant_context(query):
chunks = vector_store.search(query, top_k=3) # 只取最相关的几段
return "\n".join(chunks)
# → 海量资料留在外部, 上下文只进"此刻真正需要的那一点"
# 核心: 主动管理上下文 = 工具结果截断/摘要 + 滑动窗口(只留最近N轮)
# + 老历史摘要压缩 + 大资料放外部按需检索; 让发给模型的内容始终"可控、精炼"。
修复的核心,是"从'无脑发全部历史'转向'主动管理、精炼上下文'"。正解一:截断/压缩工具结果——别把一整个网页 HTML 原样塞进历史,先截断或用小模型/规则摘要成"任务相关的要点"再入历史,从源头掐掉最大的膨胀源。正解二:滑动窗口——永远保留 system,只带最近 N 轮历史,老的丢弃,让上下文有一个"上限",不随会话无限增长。正解三:摘要式记忆——当历史超过阈值,用模型把"老对话"压成一段简短摘要(保留关键事实/决定/结论),老历史从"逐字全文"变成几百 token 的摘要。正解四:外部记忆 + 检索(RAG 式)——把大文档存进向量库/外部存储,上下文里只放引用/摘要,真需要细节时按当前问题检索出最相关的几段临时注入,海量资料留在外部、上下文只进此刻真正需要的那一点。归根结底:主动管理上下文 = 工具结果截断/摘要 + 滑动窗口 + 老历史摘要压缩 + 大资料外部按需检索,让发给模型的内容始终可控、精炼。
第三件事:Agent 上下文管理的其他常见坑
排查后我把 Agent 在"上下文/token"上的其他常见坑也系统梳理了一遍,它们一样隐蔽又费钱。
Agent 上下文/token 的其他常见坑
# 1. 无限累积历史(本文): 每轮重发全部 → 慢/贵/崩。→ 窗口+摘要+截断。
# 2. 工具结果不加约束: 一个工具返回几万token的原始数据全进上下文。
# → 工具层就该限制返回大小、只返回结构化的关键字段。
# 3. system prompt 过于臃肿: 几千token的超长系统提示, 每轮都重发。
# → 精简 system; 把不常用的指令挪到按需注入。
# 4. 没有任何"轮数/token上限", Agent 死循环: 工具一直调、不收敛,
# token 烧到爆。→ 设最大轮数/最大token预算, 到顶就停并兜底。
# 5. 重复调用同一工具拿同样结果: 没缓存, 同一个网页读了5遍, 占5份。
# → 工具结果做缓存/去重。
# 6. 把整个文件/日志直接喂进去: "帮我分析这个10万行日志" 一次性全塞。
# → 分块 + 检索 + 摘要, 而非整坨塞。
# 7. 多模态/图片 token 黑洞: 一张高清图可能等于上千token, 累积起来惊人。
# → 控制图片数量/分辨率, 用完及时移出历史。
# 共同根源: 没把"上下文窗口"当成一种【稀缺、要主动管理的有限资源】,
# 而是当成"无限的、可以随便往里塞东西的口袋"。
# 核心: 上下文窗口是有限且昂贵的资源; Agent 工程的核心能力之一, 就是
# "上下文管理"——决定每一轮该放什么、不放什么、怎么压缩, 让有限窗口装最有用的信息。
排查让我把 Agent 上下文的其他坑也梳理清了。一、无限累积历史(本文)。二、工具结果不加约束(几万 token 原始数据全进)。三、system prompt 过于臃肿(几千 token 每轮重发)。四、没有轮数/token 上限导致死循环(工具一直调不收敛、token 烧到爆)。五、重复调用同一工具拿同样结果(没缓存,同一网页读 5 遍占 5 份)。六、把整个文件/日志直接喂进去(该分块+检索而非整坨塞)。七、多模态/图片 token 黑洞(一张高清图上千 token)。它们的共同根源是:没把"上下文窗口"当成一种稀缺、要主动管理的有限资源,而是当成"无限的、可以随便往里塞东西的口袋"。核心是:上下文窗口是有限且昂贵的资源;Agent 工程的核心能力之一就是"上下文管理"——决定每一轮该放什么、不放什么、怎么压缩,让有限窗口装最有用的信息。下面这张图,是这次 Agent 上下文爆炸的成因与解法:
第四件事:几种上下文管理策略对比速查
这次踩坑后,我把常见的几种上下文管理策略整理成一张表,按场景选用。
| 策略 | 做法 | 优点 | 代价 | 适用 |
|---|---|---|---|---|
| 全量历史(我最初) | 每轮发全部 | 信息最全 | 慢/贵/会爆窗口 | 只适合超短任务 |
| 滑动窗口 | 只留最近N轮 | 简单, 有上限 | 丢失早期信息 | 不太依赖远期历史 |
| 摘要压缩 | 老历史压成摘要 | 保留要点又省 | 摘要有损/需额外调用 | 长对话/需记住早期 |
| 外部记忆+检索 | 大资料外部, 按需取 | 窗口极省, 可扩展 | 架构复杂, 检索质量影响 | 海量知识/文档 |
| 工具结果截断 | 大结果先截断/提炼 | 掐掉最大膨胀源 | 可能丢细节 | 工具返回大块数据 |
这张表把上下文管理策略钉死了。核心是:没有一种策略包打天下,它们都是在"信息完整度"和"上下文成本(token/速度/钱)"之间做权衡;实际工程里往往是组合使用(滑动窗口 + 摘要 + 工具结果截断 + 外部检索一起上)。它给我的最大启发是:Agent 的"上下文管理",本质是一个"在有限的窗口预算内,如何分配注意力"的资源优化问题——你要在每一轮,决定把宝贵的 token 预算,花在哪些信息上(最近对话?早期结论?某个工具结果?外部知识?),让模型在"看得见的有限信息"下做出最好的决策。这其实和人类处理复杂任务的方式异曲同工:人脑的"工作记忆"也是有限的,我们处理长期、复杂的任务时,不会(也无法)把所有细节都同时记在脑子里;而是靠"记住关键结论、把细节记在纸上/外部、需要时再翻查、不断把旧信息归纳成更抽象的要点"来应对;好的 Agent 上下文管理,做的正是同一件事——用摘要、外部记忆、检索,模拟一套"有限工作记忆 + 可检索的外部记忆"的认知架构。把上下文窗口当成宝贵的"工作记忆"来精心经营,而非无限的垃圾桶,是做好 Agent 的关键心法。
第五件事:成本的账,必须算明白
这次最让我肉疼的是账单。我把"全量历史"和"管理后"的成本差异具体算了一下,触目惊心。
| 维度 | 全量历史(无管理) | 主动管理后 |
|---|---|---|
| 第N轮的输入量 | 前N轮之和(累积) | 窗口上限(基本恒定) |
| 总 token 消耗 | 约 O(N²) 平方级 | 约 O(N) 线性 |
| 长会话费用 | 暴涨, 越聊越贵 | 平稳可控 |
| 响应速度 | 越来越慢 | 基本稳定 |
| 能否撑住长会话 | ✗ 必然撑爆窗口 | ✓ 可长期运行 |
| 大块工具结果 | 永久占位, 每轮重发 | 截断/摘要/外置, 只占一点 |
这张成本对比表,让我对"token 即金钱"有了切肤之痛的认识。核心是:"全量历史"的总成本是随轮数 O(N²) 平方级增长的(第 N 轮要重发前面所有轮),而"主动管理(窗口恒定)"是 O(N) 线性的;这个量级差异,在长会话里就是"账单暴涨到不可承受 + 必然撑爆窗口" vs "平稳可控、能长期运行"的天壤之别。它给我的启发,超越了 Agent 本身:在用 LLM 的系统里,"token"是一种需要像内存、带宽、金钱一样被认真对待和优化的"核心资源";很多 LLM 应用看起来 Demo 惊艳、一上规模却又慢又贵到跑不动,根因往往就是"没有把 token 当成稀缺资源来设计"——随意地、无节制地把内容塞进上下文。这让我把一种"资源意识"延伸到了 AI 工程:做传统系统,我们会算时间复杂度、空间复杂度、网络开销;做 LLM 系统,同样要算"token 复杂度"——每个设计,随着数据量/对话轮数增长,它消耗的 token 是线性还是平方级?会不会撑爆窗口?成本曲线长什么样?;把"token 经济性"纳入架构设计的核心考量,是 LLM 时代工程师的一项必备新素养。像优化性能一样优化 token 消耗——这,是我用一张吓人的账单,换来的、关于 AI 工程成本的清醒认知。
第六件事:设计 Agent 上下文时,我现在的判断习惯
现在每当我设计一个 Agent、或往上下文里加东西,我都会按这张图先想清楚:
这张图的精髓,是"放进上下文前先问大不大、真需要全部吗、会不会无限累积"。小而关键的直接放但留意累积;大块数据(网页/文件/JSON 全文)绝不原样放,只需要要点就摘要抽取、需要细节但量大就存外部按需检索。对话轮数会很多时:加滑动窗口 + 老历史摘要压缩,并设最大轮数/token 预算上限兜底。这套习惯,让我设计 Agent 时,从"无脑把一切塞进上下文"变成了"精打细算每一份 token 的去处"——核心始终是:上下文窗口是有限昂贵的资源,主动管理(截断/窗口/摘要/外置)才能让 Agent 成本线性、长期稳定运行。
我立下的几条规矩
这场"Agent 上下文爆炸"的事故,换来了我做 AI Agent 时,刻进骨子里的几条铁律:
- 大模型无状态,记忆靠每轮重发历史。理解这点,才理解 token 为何累积。
- 上下文窗口是有限且昂贵的资源。当工作记忆经营,别当无限垃圾桶。
- 工具结果绝不原样塞。大块数据先截断/摘要/抽取关键字段。
- 长对话上滑动窗口 + 摘要压缩。让上下文有上限,成本从平方降到线性。
- 海量资料放外部 + 检索。上下文只进此刻真正需要的那一点。
- 必设最大轮数/token 预算。防 Agent 死循环把钱烧爆。
- 把 token 复杂度纳入设计。每个方案先算它随规模是线性还是平方。
附:一个带上下文管理的极简 Agent 循环骨架
这次踩坑后,我把"带上下文管理"的 Agent 主循环抽成了一个固定骨架,新 Agent 都从它起步,从一开始就不给"无限累积"留口子:
MAX_TURNS = 20 # 最大轮数, 防死循环烧钱
MAX_RECENT = 12 # 滑动窗口: 只带最近12条消息
SUMMARIZE_AFTER = 16 # 历史超过这个数就压缩老的
MAX_TOOL_CHARS = 4000 # 单个工具结果最大字符, 超了就截断/摘要
def agent_loop(system_prompt, user_query, tools):
history = [{"role": "user", "content": user_query}]
summary = "" # 老历史压缩成的摘要
for turn in range(MAX_TURNS): # ★ 1. 硬上限, 绝不无限循环
# ★ 2. 组装这一轮真正发送的上下文(主动管理, 而非全量)
msgs = [{"role": "system", "content": system_prompt}]
if summary:
msgs.append({"role": "system", "content": f"早前对话摘要: {summary}"})
msgs += history[-MAX_RECENT:] # 只带最近 N 条
resp = llm_call(msgs, tools=tools) # 调模型
history.append(resp.message)
if resp.tool_calls: # 模型要调工具
for call in resp.tool_calls:
raw = run_tool(call.name, call.args)
# ★ 3. 工具结果先约束大小, 再入历史(关键!)
result = raw if len(raw) <= MAX_TOOL_CHARS else \
summarize(raw, focus=user_query)[:MAX_TOOL_CHARS]
history.append({"role": "tool", "name": call.name, "content": result})
else:
return resp.message.content # 没有工具调用 = 给出最终答案, 结束
# ★ 4. 历史太长就把"老的"压成摘要, 控制累积
if len(history) > SUMMARIZE_AFTER:
old, history = history[:-MAX_RECENT], history[-MAX_RECENT:]
summary = llm_summarize(summary + "\n" + format_msgs(old))
return "已达最大轮数, 任务未在预算内完成" # ★ 5. 到顶兜底, 而非无声烧钱
# 核心: 一个生产级 Agent 循环, 从骨架就内建五道防线——最大轮数、滑动窗口、
# 工具结果约束、老历史摘要压缩、到顶兜底; 让"上下文/成本"从设计之初就可控。
这个小小的循环骨架,是我这次踩坑后最有价值的沉淀。它把我血泪换来的几条教训,固化成了 Agent 主循环里"从一开始就在"的五道防线:最大轮数(防死循环烧钱)、滑动窗口(只带最近 N 条)、工具结果约束(大块先截断/摘要再入历史)、老历史摘要压缩(控制累积)、到顶兜底(而非无声地一直烧钱)。它和我最初那个"天真"版本最大的不同,不在于多了多少代码,而在于一种根本的设计立场转变:最初的版本,默认"上下文可以无限增长",出了事再补救;而这个骨架,从第一行起就假设"上下文是有限的、会膨胀的、必须主动约束的",把管理内建在了循环的骨子里。这正是我想用这个骨架,留给自己也分享给你的核心思想:对于那些"会随时间/规模增长而消耗资源"的系统(Agent 的 token、长连接的内存、消息队列的积压……),"资源管理"不该是事后出了问题才打的补丁,而该是设计之初就内建的、贯穿始终的一等公民。因为这类问题有一个共同的残酷特性:它们在小规模(Demo、短任务)时完全不显现,让你误以为没问题;却在真实规模(长会话、高负载、生产环境)下必然爆发,且往往以"突然崩溃"的剧烈方式;所以唯一可靠的应对,是在设计时就为"规模增长"做好准备,把资源的上限、增长、回收,从一开始就考虑进去。为增长而设计、把资源管理内建进系统的骨架——这,是我用一次 Agent 上下文爆炸的事故,换来的、关于构建"能扛住真实世界规模"的系统的、最实用的工程信条。
写在最后
回头看,这场由"上下文无限累积"引发的、又慢又贵又崩的事故,真正教给我的,远不止"加个滑动窗口"这一个技巧。它让我对"用大模型构建系统"这件事的本质,有了一次脱胎换骨的认识。我栽跟头,是因为我带着"调用一个普通函数/API"的旧直觉,去用大模型——以为"把信息给它、它处理、返回结果"是一次廉价、无副作用的调用。可我忽略了:大模型的"上下文窗口",是它一切能力的舞台,也是一种有严格物理上限、且每次都要按量付费的稀缺资源;而 Agent 这种"多轮、带记忆、调工具"的模式,会让进入这个窗口的内容,以一种我没意识到的方式(每轮重发、不断累积)疯狂膨胀。这让我领悟到一个深刻的认知:用大模型构建复杂系统(尤其 Agent),"上下文工程(Context Engineering)"——即精心地、有策略地管理"每一轮到底让模型看到什么"——是和"提示词工程"同等重要、甚至更底层的核心能力;因为模型的输出质量、系统的速度、成本、能否稳定运行,全都取决于你喂给它的那个有限上下文里,装的是什么。这其实呼应了一个更普遍的工程智慧:任何强大的能力,都建立在对"它所依赖的有限资源"的精心管理之上——CPU 靠调度、内存靠管理、带宽靠优化;而大模型的智能,靠的是对那个宝贵上下文窗口的精心经营。看清你所用工具背后的"稀缺资源"是什么,并学会像守财奴一样精打细算地使用它,是从"能跑通 Demo"迈向"能扛住生产"的必经之路。把上下文窗口当成最宝贵的资源来经营——这,是我用一次又贵又崩的 Agent 事故,换来的、关于 AI 工程、也关于一切"资源约束下的工程"的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次做 Agent 时,先想想"我这一轮,到底该让模型看到什么、不看到什么",那我对着那个 143620 tokens 的报错和飞涨的账单熬的这大半天,就值了。
—— 别看了 · 2026