1. 问题现象与核心症结定位Agent 类应用在长时间对话后变慢甚至卡死这个现象我在过去一年多的 agent 开发实践中反复遇到过。不管是基于 workbuddy 这类工具搭建的对话助手还是用 openclaw 部署的自动化 agent只要对话轮次一多、上下文一长响应速度就会肉眼可见地往下掉最后干脆卡住不动。很多人第一反应是“模型不行”或者“网络问题”但实测下来绝大多数情况下根因都在上下文管理和执行上下文生命周期这两个地方。先把这个问题的典型表现说清楚方便你对号入座。第一种是渐进式变慢前十几轮对话响应很快到三四十轮之后每次回复要等十几秒甚至更久。第二种是突然卡死某个节点之后 agent 完全无响应日志里可能出现session file locked (timeout 60000ms)这类报错或者干脆没有任何输出。第三种是假死状态界面还在转圈但 agent 的 execution 已经 terminated只是前端没有正确感知。这三种表现背后的机制其实不一样。渐进式变慢通常是上下文窗口被历史消息填满每次推理都要处理越来越长的 token 序列计算量和内存占用线性甚至超线性增长。突然卡死往往是会话文件锁竞争或者执行上下文没有正确释放导致的死锁。假死则多半是前端与 agent 后端的心跳机制失效属于工程层面的问题。注意不要一上来就怀疑模型能力。我踩过的坑里90% 的“agent 变慢”问题换成更小的模型反而更快这说明瓶颈根本不在模型本身而在上下文处理链路。理解这个问题的价值在于它直接决定了你的 agent 能不能支撑长会话场景。客服机器人、代码助手、自动化运维 agent这些真实业务场景都要求 agent 能连续工作几十分钟甚至几小时。如果上下文管理做不好产品根本没法上线。下面我会从设计思路、核心细节、实操实现、问题排查四个维度把这套解决方案完整拆开讲。2. 上下文膨胀的底层机制与设计取舍2.1 为什么上下文会越用越慢大模型的推理成本与输入 token 数量强相关。假设你的 agent 每轮对话平均产生 500 token 的历史记录那么第 N 轮对话时输入给模型的上下文长度大约是 500×N。第 10 轮是 5000 token第 50 轮就是 25000 token。看起来还好但问题在于注意力机制的计算复杂度是 O(n²)token 数量翻倍计算量翻四倍。我用一个实际案例说明。之前部署的一个 openclaw agent配置的是 32K 上下文窗口。前 20 轮对话平均响应时间 2 秒到第 40 轮时响应时间涨到 15 秒第 60 轮直接超过 60 秒触发超时。抓取日志发现每轮实际送入模型的 token 数从最初的 3000 涨到了 28000接近窗口上限。这时候模型不仅要处理当前问题还要“回忆”前面几十轮的无关内容效率极低。更隐蔽的问题是上下文污染。历史消息里如果包含大量工具调用返回的原始数据比如网页抓取结果、文件内容这些内容会一直占据上下文空间而且对后续对话几乎没有价值。我见过一个案例agent 抓取了一个 8000 字的网页之后每一轮对话都带着这 8000 字直接把上下文撑爆。2.2 上下文工程的三种主流策略针对上下文膨胀业界目前有三类处理思路各有适用场景。第一类是滑动窗口截断。只保留最近 N 轮对话更早的直接丢弃。实现简单但缺点是会丢失长期记忆用户提到“刚才说的那个方案”时 agent 可能已经忘了。适合对上下文连续性要求不高的场景比如单次问答。第二类是摘要压缩。把历史对话用一个小模型或者规则方法压缩成摘要只保留关键信息。比如把 20 轮对话压缩成 200 字的摘要。这样能大幅降低 token 占用同时保留核心记忆。缺点是摘要过程本身有信息损失而且需要额外的模型调用。第三类是向量检索增强。把历史对话存入向量数据库每轮对话时根据当前问题检索最相关的历史片段只把相关部分拼进上下文。这是目前最优雅的方案但工程复杂度最高需要维护向量库和检索链路。我的实践经验是混合使用。短期用滑动窗口保证对话流畅中期用摘要压缩保留关键信息长期用向量检索做记忆召回。workbuddy 这类工具内置了部分上下文管理能力但默认配置往往不够激进需要手动调优。2.3 执行上下文的生命周期陷阱除了 token 层面的上下文还有一个容易被忽视的问题执行上下文execution context的生命周期管理。在 agent 框架里每次任务执行都会创建一个 execution context里面包含会话状态、工具句柄、临时文件等资源。如果这些资源没有正确释放就会导致内存泄漏和文件锁竞争。我遇到过最典型的情况是session file locked报错。agent 在处理一个长任务时会锁定会话文件防止并发写入。如果任务因为异常中断锁没有被释放下一次请求就会一直等待直到 60 秒超时。这个问题在 openclaw 部署的 agent 上特别常见因为它的会话持久化机制默认比较保守。解决思路是给每个 execution context 设置明确的超时和清理钩子。无论任务成功还是失败都要确保锁被释放、临时文件被删除、内存被回收。这听起来是基础工程问题但在实际 agent 开发中恰恰是最容易出问题的地方。3. 核心细节解析与实操要点3.1 上下文窗口的监控与阈值设定要解决变慢问题第一步是能看见上下文的使用情况。你需要一个监控机制实时统计每轮对话的 token 占用。大部分 agent 框架都提供了 token 计数接口比如 tiktoken 这类库可以精确计算文本的 token 数。我的做法是在每次调用模型前先计算当前上下文的 token 总数并记录到日志。同时设定三级阈值阈值等级占用比例触发动作绿色 50%正常对话不做处理黄色50%-75%启动摘要压缩压缩最早 30% 的历史红色 75%强制截断 向量检索召回只保留最近 5 轮这套阈值机制实测下来很稳。关键是黄色阈值要提前触发不要等到上下文快满了才处理因为压缩本身也需要 token 预算。我一般把黄色阈值设在 50%给压缩留足空间。提示不同模型的 token 计算方式不一样中文和英文的 token 比例差异很大。中文大约 1 个字对应 1.5-2 个 token英文大约 1 个单词对应 1.3 个 token。做阈值计算时要用实际模型的分词器不要用估算值。3.2 摘要压缩的具体实现摘要压缩是性价比最高的方案。我的实现方式是当上下文进入黄色区间时取出最早的 30% 历史消息调用一个小模型比如 7B 级别的生成摘要然后用摘要替换原始消息。摘要的 prompt 设计很关键。我用的模板是这样的请将以下对话历史压缩成不超过 200 字的摘要保留以下信息 1. 用户的核心需求和目标 2. 已经确认的关键事实和参数 3. 未完成的待办事项 4. 重要的工具调用结果只保留结论不要原始数据 对话历史 {history} 摘要这个模板的要点是明确告诉模型保留什么、丢弃什么。如果不加约束模型会把所有内容都塞进摘要压缩效果很差。实测下来200 字的摘要能替代大约 3000 字的原始对话压缩比 15:1而且关键信息保留率在 90% 以上。注意事项摘要压缩会引入额外的模型调用延迟大约 1-2 秒。所以不要在每轮对话都做只在阈值触发时做。另外摘要本身也要计入上下文所以摘要长度要严格控制。3.3 向量检索召回的工程细节向量检索是长期记忆的核心。实现链路是每轮对话结束后把对话内容切片、向量化、存入向量库下一轮对话时用当前问题去检索最相关的 top-k 片段拼进上下文。切片策略很重要。我一般按语义单元切片而不是固定长度。比如一轮完整的问答作为一个切片或者一个工具调用的完整过程作为一个切片。切片太碎会丢失上下文切片太大检索精度会下降。经验值是每个切片 200-500 字。检索的 top-k 一般设 3-5 个。太多会撑爆上下文太少会漏掉关键信息。检索相似度阈值设在 0.7 左右低于这个值的片段不要召回因为相关性太低反而会干扰模型。注意向量检索的 embedding 模型要和对话模型分开选型。embedding 模型不需要太强但要求稳定、快速、便宜。我一般用开源的 bge 系列或者 text-embedding-3-small 这类轻量模型。3.4 执行上下文的资源清理前面提到的 session file locked 问题解决方案是显式管理锁的生命周期。具体做法获取锁时设置超时时间比如 30 秒。超时后自动放弃避免无限等待。用 try-finally 结构包裹任务执行确保无论成功失败都释放锁。定期清理僵尸锁比如每小时扫描一次释放超过 5 分钟未释放的锁。在 openclaw 这类框架里这些配置通常在 agent 的初始化参数里。我一般会把锁超时从默认的 60 秒调到 30 秒因为 60 秒的等待对用户体验来说太长了。同时开启自动清理防止异常中断导致的死锁。内存泄漏的排查稍微麻烦一些。我的做法是给每个 execution context 设置内存上限超过就强制回收。同时用内存分析工具定期检查找出没有释放的对象。常见泄漏点包括未关闭的文件句柄、未清理的定时器、未释放的模型缓存。4. 完整实操流程与关键环节实现4.1 环境准备与基础配置假设你用的是 openclaw 或者类似的 agent 框架第一步是确认版本和依赖。我建议用 Linux 环境部署Windows 下 WSL 有时候会有文件锁的兼容性问题导致卡住。如果必须用 Windows确保 WSL 的版本是 2并且给 WSL 分配足够的内存。基础配置清单上下文窗口大小根据模型能力设定一般 32K 起步有条件上 128K摘要模型选一个 7B 级别的小模型响应快、成本低向量库本地用 Chroma 或 FAISS生产环境用 Milvus 或 Qdrantembedding 模型bge-small-zh 或同类轻量模型锁超时30 秒内存上限根据机器配置一般 2-4GB per context配置完成后先跑一个基准测试连续对话 50 轮记录每轮的响应时间和 token 占用。这个基准数据是后续优化的参照。4.2 上下文管理模块的实现核心代码逻辑分三块监控、压缩、召回。我用伪代码说明整体流程def process_message(user_input, session): # 1. 计算当前上下文 token 数 current_tokens count_tokens(session.history) max_tokens session.config.max_context_tokens # 2. 根据阈值决定处理策略 ratio current_tokens / max_tokens if ratio 0.75: # 红色强制截断 向量召回 session.history session.history[-5:] relevant vector_search(user_input, session.vector_store, top_k3) session.history relevant session.history elif ratio 0.5: # 黄色摘要压缩最早 30% early session.history[:int(len(session.history)*0.3)] summary summarize(early) session.history [summary] session.history[int(len(session.history)*0.3):] # 3. 调用模型 response call_model(session.history [user_input]) # 4. 更新历史并存入向量库 session.history.append(user_input) session.history.append(response) vector_store.add(user_input, response) return response这段逻辑的关键点是阈值判断要在调用模型之前而不是之后。因为模型调用本身会消耗 token如果先调用再判断可能已经超限了。4.3 参数计算与调优过程上下文管理的参数需要根据实际场景调优。我以 32K 窗口为例说明参数计算过程。假设每轮对话平均 500 token那么 32K 窗口理论上能容纳 64 轮对话。但实际不能用到 100%因为要给模型输出留空间。一般输出预留 4K token所以可用上下文是 28K约 56 轮。但这是理想情况。实际中工具调用返回的数据可能很大一轮就占几千 token。所以我把黄色阈值设在 50%即 16K token大约 32 轮对话时触发压缩。压缩后上下文降到 8K 左右又能撑 16 轮。这样循环下来agent 可以无限对话下去每 16 轮做一次压缩。压缩的延迟大约 1.5 秒用户基本感知不到。相比不压缩时第 40 轮要等 15 秒这个代价完全可以接受。4.4 实操现场记录与验证我在一个客服 agent 上做了完整验证。优化前50 轮对话后响应时间从 2 秒涨到 25 秒第 60 轮卡死。优化后连续对话 200 轮响应时间稳定在 2-3 秒没有卡死。验证方法是写一个自动化脚本模拟用户连续提问记录每轮的响应时间和 token 占用。脚本跑完后生成曲线图直观看到优化效果。这个脚本我建议每个 agent 项目都准备一个作为回归测试的一部分。提示验证时要用真实的对话数据不要用重复的测试语句。因为重复语句的 token 计算和向量检索结果都不真实测不出问题。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象可能原因排查方法解决方案渐进式变慢上下文膨胀查看每轮 token 数启用摘要压缩突然卡死会话文件锁未释放检查锁状态和超时日志设置锁超时 自动清理假死无响应执行上下文泄漏检查内存和句柄数设置内存上限 定期回收响应时间波动大向量检索召回不稳定检查检索相似度分布调整 top-k 和阈值摘要后答非所问摘要丢失关键信息对比摘要前后内容优化摘要 prompt5.2 独家避坑技巧第一个坑不要在压缩时丢弃工具调用的原始结果。我一开始做摘要压缩时把工具调用返回的原始数据也压缩了结果 agent 后续需要引用这些数据时找不到只能重新调用工具反而更慢。正确做法是工具调用的结论保留在摘要里原始数据存入向量库需要时再检索。第二个坑锁超时不要设太长。默认 60 秒的超时意味着用户要等 60 秒才能看到错误。我调到 30 秒后用户等待时间减半而且大部分正常任务在 30 秒内都能完成不会误杀。第三个坑向量检索的 embedding 要缓存。每轮对话都重新计算 embedding 很浪费尤其是历史消息的 embedding 不会变。我的做法是给每条消息的 embedding 加缓存只在消息新增时计算一次。第四个坑注意 WSL 下的文件锁兼容性。在 WSL 里跑 agent文件锁的行为和原生 Linux 有差异容易出现锁不释放的问题。如果遇到建议把会话文件放在 WSL 的原生文件系统里不要放在 Windows 挂载的目录下。5.3 性能监控与预警光解决问题不够还要能提前发现。我建议加一套监控指标每轮对话的 token 占用和响应时间摘要压缩的触发频率和耗时向量检索的召回数量和相似度锁等待时间和超时次数执行上下文的内存占用这些指标接入监控系统设置预警阈值。比如响应时间超过 10 秒就告警锁超时次数超过 3 次就告警。这样能在问题恶化前介入。我在实际使用中发现大部分 agent 变慢问题都是可以预防的。只要上下文管理做扎实锁和内存管理做到位agent 连续跑几百轮对话完全没问题。真正难的不是技术方案而是坚持做监控和调优。很多团队上线后就不管了等到用户投诉才来排查那时候问题已经积累很久了。最后分享一个小技巧如果你的 agent 支持多会话给每个会话独立的上下文管理实例不要共享。共享会导致一个会话的上下文膨胀影响其他会话而且锁竞争会更严重。独立实例虽然多占一点内存但稳定性和隔离性好得多。 Agent长对话变慢卡死？上下文管理与执行上下文生命周期优化实战
1. 问题现象与核心症结定位Agent 类应用在长时间对话后变慢甚至卡死这个现象我在过去一年多的 agent 开发实践中反复遇到过。不管是基于 workbuddy 这类工具搭建的对话助手还是用 openclaw 部署的自动化 agent只要对话轮次一多、上下文一长响应速度就会肉眼可见地往下掉最后干脆卡住不动。很多人第一反应是“模型不行”或者“网络问题”但实测下来绝大多数情况下根因都在上下文管理和执行上下文生命周期这两个地方。先把这个问题的典型表现说清楚方便你对号入座。第一种是渐进式变慢前十几轮对话响应很快到三四十轮之后每次回复要等十几秒甚至更久。第二种是突然卡死某个节点之后 agent 完全无响应日志里可能出现session file locked (timeout 60000ms)这类报错或者干脆没有任何输出。第三种是假死状态界面还在转圈但 agent 的 execution 已经 terminated只是前端没有正确感知。这三种表现背后的机制其实不一样。渐进式变慢通常是上下文窗口被历史消息填满每次推理都要处理越来越长的 token 序列计算量和内存占用线性甚至超线性增长。突然卡死往往是会话文件锁竞争或者执行上下文没有正确释放导致的死锁。假死则多半是前端与 agent 后端的心跳机制失效属于工程层面的问题。注意不要一上来就怀疑模型能力。我踩过的坑里90% 的“agent 变慢”问题换成更小的模型反而更快这说明瓶颈根本不在模型本身而在上下文处理链路。理解这个问题的价值在于它直接决定了你的 agent 能不能支撑长会话场景。客服机器人、代码助手、自动化运维 agent这些真实业务场景都要求 agent 能连续工作几十分钟甚至几小时。如果上下文管理做不好产品根本没法上线。下面我会从设计思路、核心细节、实操实现、问题排查四个维度把这套解决方案完整拆开讲。2. 上下文膨胀的底层机制与设计取舍2.1 为什么上下文会越用越慢大模型的推理成本与输入 token 数量强相关。假设你的 agent 每轮对话平均产生 500 token 的历史记录那么第 N 轮对话时输入给模型的上下文长度大约是 500×N。第 10 轮是 5000 token第 50 轮就是 25000 token。看起来还好但问题在于注意力机制的计算复杂度是 O(n²)token 数量翻倍计算量翻四倍。我用一个实际案例说明。之前部署的一个 openclaw agent配置的是 32K 上下文窗口。前 20 轮对话平均响应时间 2 秒到第 40 轮时响应时间涨到 15 秒第 60 轮直接超过 60 秒触发超时。抓取日志发现每轮实际送入模型的 token 数从最初的 3000 涨到了 28000接近窗口上限。这时候模型不仅要处理当前问题还要“回忆”前面几十轮的无关内容效率极低。更隐蔽的问题是上下文污染。历史消息里如果包含大量工具调用返回的原始数据比如网页抓取结果、文件内容这些内容会一直占据上下文空间而且对后续对话几乎没有价值。我见过一个案例agent 抓取了一个 8000 字的网页之后每一轮对话都带着这 8000 字直接把上下文撑爆。2.2 上下文工程的三种主流策略针对上下文膨胀业界目前有三类处理思路各有适用场景。第一类是滑动窗口截断。只保留最近 N 轮对话更早的直接丢弃。实现简单但缺点是会丢失长期记忆用户提到“刚才说的那个方案”时 agent 可能已经忘了。适合对上下文连续性要求不高的场景比如单次问答。第二类是摘要压缩。把历史对话用一个小模型或者规则方法压缩成摘要只保留关键信息。比如把 20 轮对话压缩成 200 字的摘要。这样能大幅降低 token 占用同时保留核心记忆。缺点是摘要过程本身有信息损失而且需要额外的模型调用。第三类是向量检索增强。把历史对话存入向量数据库每轮对话时根据当前问题检索最相关的历史片段只把相关部分拼进上下文。这是目前最优雅的方案但工程复杂度最高需要维护向量库和检索链路。我的实践经验是混合使用。短期用滑动窗口保证对话流畅中期用摘要压缩保留关键信息长期用向量检索做记忆召回。workbuddy 这类工具内置了部分上下文管理能力但默认配置往往不够激进需要手动调优。2.3 执行上下文的生命周期陷阱除了 token 层面的上下文还有一个容易被忽视的问题执行上下文execution context的生命周期管理。在 agent 框架里每次任务执行都会创建一个 execution context里面包含会话状态、工具句柄、临时文件等资源。如果这些资源没有正确释放就会导致内存泄漏和文件锁竞争。我遇到过最典型的情况是session file locked报错。agent 在处理一个长任务时会锁定会话文件防止并发写入。如果任务因为异常中断锁没有被释放下一次请求就会一直等待直到 60 秒超时。这个问题在 openclaw 部署的 agent 上特别常见因为它的会话持久化机制默认比较保守。解决思路是给每个 execution context 设置明确的超时和清理钩子。无论任务成功还是失败都要确保锁被释放、临时文件被删除、内存被回收。这听起来是基础工程问题但在实际 agent 开发中恰恰是最容易出问题的地方。3. 核心细节解析与实操要点3.1 上下文窗口的监控与阈值设定要解决变慢问题第一步是能看见上下文的使用情况。你需要一个监控机制实时统计每轮对话的 token 占用。大部分 agent 框架都提供了 token 计数接口比如 tiktoken 这类库可以精确计算文本的 token 数。我的做法是在每次调用模型前先计算当前上下文的 token 总数并记录到日志。同时设定三级阈值阈值等级占用比例触发动作绿色 50%正常对话不做处理黄色50%-75%启动摘要压缩压缩最早 30% 的历史红色 75%强制截断 向量检索召回只保留最近 5 轮这套阈值机制实测下来很稳。关键是黄色阈值要提前触发不要等到上下文快满了才处理因为压缩本身也需要 token 预算。我一般把黄色阈值设在 50%给压缩留足空间。提示不同模型的 token 计算方式不一样中文和英文的 token 比例差异很大。中文大约 1 个字对应 1.5-2 个 token英文大约 1 个单词对应 1.3 个 token。做阈值计算时要用实际模型的分词器不要用估算值。3.2 摘要压缩的具体实现摘要压缩是性价比最高的方案。我的实现方式是当上下文进入黄色区间时取出最早的 30% 历史消息调用一个小模型比如 7B 级别的生成摘要然后用摘要替换原始消息。摘要的 prompt 设计很关键。我用的模板是这样的请将以下对话历史压缩成不超过 200 字的摘要保留以下信息 1. 用户的核心需求和目标 2. 已经确认的关键事实和参数 3. 未完成的待办事项 4. 重要的工具调用结果只保留结论不要原始数据 对话历史 {history} 摘要这个模板的要点是明确告诉模型保留什么、丢弃什么。如果不加约束模型会把所有内容都塞进摘要压缩效果很差。实测下来200 字的摘要能替代大约 3000 字的原始对话压缩比 15:1而且关键信息保留率在 90% 以上。注意事项摘要压缩会引入额外的模型调用延迟大约 1-2 秒。所以不要在每轮对话都做只在阈值触发时做。另外摘要本身也要计入上下文所以摘要长度要严格控制。3.3 向量检索召回的工程细节向量检索是长期记忆的核心。实现链路是每轮对话结束后把对话内容切片、向量化、存入向量库下一轮对话时用当前问题去检索最相关的 top-k 片段拼进上下文。切片策略很重要。我一般按语义单元切片而不是固定长度。比如一轮完整的问答作为一个切片或者一个工具调用的完整过程作为一个切片。切片太碎会丢失上下文切片太大检索精度会下降。经验值是每个切片 200-500 字。检索的 top-k 一般设 3-5 个。太多会撑爆上下文太少会漏掉关键信息。检索相似度阈值设在 0.7 左右低于这个值的片段不要召回因为相关性太低反而会干扰模型。注意向量检索的 embedding 模型要和对话模型分开选型。embedding 模型不需要太强但要求稳定、快速、便宜。我一般用开源的 bge 系列或者 text-embedding-3-small 这类轻量模型。3.4 执行上下文的资源清理前面提到的 session file locked 问题解决方案是显式管理锁的生命周期。具体做法获取锁时设置超时时间比如 30 秒。超时后自动放弃避免无限等待。用 try-finally 结构包裹任务执行确保无论成功失败都释放锁。定期清理僵尸锁比如每小时扫描一次释放超过 5 分钟未释放的锁。在 openclaw 这类框架里这些配置通常在 agent 的初始化参数里。我一般会把锁超时从默认的 60 秒调到 30 秒因为 60 秒的等待对用户体验来说太长了。同时开启自动清理防止异常中断导致的死锁。内存泄漏的排查稍微麻烦一些。我的做法是给每个 execution context 设置内存上限超过就强制回收。同时用内存分析工具定期检查找出没有释放的对象。常见泄漏点包括未关闭的文件句柄、未清理的定时器、未释放的模型缓存。4. 完整实操流程与关键环节实现4.1 环境准备与基础配置假设你用的是 openclaw 或者类似的 agent 框架第一步是确认版本和依赖。我建议用 Linux 环境部署Windows 下 WSL 有时候会有文件锁的兼容性问题导致卡住。如果必须用 Windows确保 WSL 的版本是 2并且给 WSL 分配足够的内存。基础配置清单上下文窗口大小根据模型能力设定一般 32K 起步有条件上 128K摘要模型选一个 7B 级别的小模型响应快、成本低向量库本地用 Chroma 或 FAISS生产环境用 Milvus 或 Qdrantembedding 模型bge-small-zh 或同类轻量模型锁超时30 秒内存上限根据机器配置一般 2-4GB per context配置完成后先跑一个基准测试连续对话 50 轮记录每轮的响应时间和 token 占用。这个基准数据是后续优化的参照。4.2 上下文管理模块的实现核心代码逻辑分三块监控、压缩、召回。我用伪代码说明整体流程def process_message(user_input, session): # 1. 计算当前上下文 token 数 current_tokens count_tokens(session.history) max_tokens session.config.max_context_tokens # 2. 根据阈值决定处理策略 ratio current_tokens / max_tokens if ratio 0.75: # 红色强制截断 向量召回 session.history session.history[-5:] relevant vector_search(user_input, session.vector_store, top_k3) session.history relevant session.history elif ratio 0.5: # 黄色摘要压缩最早 30% early session.history[:int(len(session.history)*0.3)] summary summarize(early) session.history [summary] session.history[int(len(session.history)*0.3):] # 3. 调用模型 response call_model(session.history [user_input]) # 4. 更新历史并存入向量库 session.history.append(user_input) session.history.append(response) vector_store.add(user_input, response) return response这段逻辑的关键点是阈值判断要在调用模型之前而不是之后。因为模型调用本身会消耗 token如果先调用再判断可能已经超限了。4.3 参数计算与调优过程上下文管理的参数需要根据实际场景调优。我以 32K 窗口为例说明参数计算过程。假设每轮对话平均 500 token那么 32K 窗口理论上能容纳 64 轮对话。但实际不能用到 100%因为要给模型输出留空间。一般输出预留 4K token所以可用上下文是 28K约 56 轮。但这是理想情况。实际中工具调用返回的数据可能很大一轮就占几千 token。所以我把黄色阈值设在 50%即 16K token大约 32 轮对话时触发压缩。压缩后上下文降到 8K 左右又能撑 16 轮。这样循环下来agent 可以无限对话下去每 16 轮做一次压缩。压缩的延迟大约 1.5 秒用户基本感知不到。相比不压缩时第 40 轮要等 15 秒这个代价完全可以接受。4.4 实操现场记录与验证我在一个客服 agent 上做了完整验证。优化前50 轮对话后响应时间从 2 秒涨到 25 秒第 60 轮卡死。优化后连续对话 200 轮响应时间稳定在 2-3 秒没有卡死。验证方法是写一个自动化脚本模拟用户连续提问记录每轮的响应时间和 token 占用。脚本跑完后生成曲线图直观看到优化效果。这个脚本我建议每个 agent 项目都准备一个作为回归测试的一部分。提示验证时要用真实的对话数据不要用重复的测试语句。因为重复语句的 token 计算和向量检索结果都不真实测不出问题。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象可能原因排查方法解决方案渐进式变慢上下文膨胀查看每轮 token 数启用摘要压缩突然卡死会话文件锁未释放检查锁状态和超时日志设置锁超时 自动清理假死无响应执行上下文泄漏检查内存和句柄数设置内存上限 定期回收响应时间波动大向量检索召回不稳定检查检索相似度分布调整 top-k 和阈值摘要后答非所问摘要丢失关键信息对比摘要前后内容优化摘要 prompt5.2 独家避坑技巧第一个坑不要在压缩时丢弃工具调用的原始结果。我一开始做摘要压缩时把工具调用返回的原始数据也压缩了结果 agent 后续需要引用这些数据时找不到只能重新调用工具反而更慢。正确做法是工具调用的结论保留在摘要里原始数据存入向量库需要时再检索。第二个坑锁超时不要设太长。默认 60 秒的超时意味着用户要等 60 秒才能看到错误。我调到 30 秒后用户等待时间减半而且大部分正常任务在 30 秒内都能完成不会误杀。第三个坑向量检索的 embedding 要缓存。每轮对话都重新计算 embedding 很浪费尤其是历史消息的 embedding 不会变。我的做法是给每条消息的 embedding 加缓存只在消息新增时计算一次。第四个坑注意 WSL 下的文件锁兼容性。在 WSL 里跑 agent文件锁的行为和原生 Linux 有差异容易出现锁不释放的问题。如果遇到建议把会话文件放在 WSL 的原生文件系统里不要放在 Windows 挂载的目录下。5.3 性能监控与预警光解决问题不够还要能提前发现。我建议加一套监控指标每轮对话的 token 占用和响应时间摘要压缩的触发频率和耗时向量检索的召回数量和相似度锁等待时间和超时次数执行上下文的内存占用这些指标接入监控系统设置预警阈值。比如响应时间超过 10 秒就告警锁超时次数超过 3 次就告警。这样能在问题恶化前介入。我在实际使用中发现大部分 agent 变慢问题都是可以预防的。只要上下文管理做扎实锁和内存管理做到位agent 连续跑几百轮对话完全没问题。真正难的不是技术方案而是坚持做监控和调优。很多团队上线后就不管了等到用户投诉才来排查那时候问题已经积累很久了。最后分享一个小技巧如果你的 agent 支持多会话给每个会话独立的上下文管理实例不要共享。共享会导致一个会话的上下文膨胀影响其他会话而且锁竞争会更严重。独立实例虽然多占一点内存但稳定性和隔离性好得多。