摘要GPT-6 官方明确说 persistent agent 能连续干几小时的活提示缓存命中还能省最多九成的输入 token 成本——成本被官方补贴了工程问题没人替你解决。长会话里 Agent 的记忆分三层会话状态、工作上下文、跨会话记忆。本文按会话中、会话变长、会话结束三个阶段把每一层该放哪、该留什么、该丢什么讲清楚文末附一张可直接勾选的长会话设计检查清单。文章目录开头Agent 能跑一整天的活了然后呢会话、上下文、记忆先把概念对齐阶段一会话进行中状态放哪阶段二上下文满了怎么压缩阶段三会话结束记忆怎么留产出物长会话设计检查清单边界有些场景根本不需要长会话总结开头Agent 能跑一整天的活了然后呢9 月 22 号 OpenAI 发了篇东西讲 GPT-6 的提示缓存优化Better prompt caching for GPT-6我盯着里面一句话看了半天persistent agent 现在可以连续工作几个小时做代码库重构、做长文档调研那种活。缓存命中率上去了输入 token 最多能省九成。翻译一下官方把长会话的成本问题补贴了让你敢让 Agent 跑久一点。但成本只是第一道坎。我第一次让 Agent 跑长任务是在沙箱里搭的一堆假订单——原计划是让它一口气处理完别中间停下来问我。结果跑到后半程它开始用自己默认的习惯做事开头交代的规矩全当没听见。我当时第一反应是模型又犯蠢了排查到后面才发现问题出在我没替它管好记忆。这篇把我在那轮演练里踩出来的三个决策点讲清楚状态放哪、上下文怎么压缩、记忆怎么留。每个都给边界别照着抄完就以为万事大吉。会话、上下文、记忆先把概念对齐长会话翻车多半是这三个词混着用导致的。先把定义对齐后面全部按这个口径说不然容易绕晕。会话状态Agent 当前这一步在干什么、手里有什么数据。比如处理到第几条、当前订单的 id 是什么。上下文窗口每次请求发给模型的全部内容指令、工具定义、历史对话都塞在里面。窗口是有限的GPT-6 给了更大的窗口但再大也有头。记忆我理解是跨会话还能用上的东西比如金额一律按分返回这种约定、用户偏好、业务规则。三个东西的寿命不一样。会话状态跟着这次会话走上下文窗口每次请求都会重建历史还在只是越来越挤记忆是要跨越会话留下去的。维度会话状态上下文窗口跨会话记忆生命周期单次会话内每次请求随窗口滚动跨会话/跨天典型内容处理到第几条、当前数据指令、工具、历史对话约定、偏好、规则存放位置内存/外部存储随请求发送给模型外部存储/数据库丢了会怎样任务中断可重试细节丢失Agent 按默认习惯办事每次会话从头学表 1 会话状态、上下文窗口、跨会话记忆的对比判断标准就一句话凡是丢了会让 Agent 办错事的信息都不该只活在上下文窗口里。这条后面反复用到。阶段一会话进行中状态放哪先说最容易踩的坑单轮能完的事别上状态。这条看着像废话但很多人一上来就把 Agent 做成带状态的结果单轮问答也背着全套历史白白增加出错的面积。我之前给 Agent 配过一个问答工具让它根据用户问题查资料回答一次一问问完就完。那种场景给 Agent 塞一套状态管理纯属给自己找事——每次请求都带全量上下文答完就丢干净利落。真正需要管状态的是长链路任务批量处理几百条数据、分步骤生成内容、跟外部系统打多轮交道。这种任务里 Agent 自己记不住处理到第几条它的工作记忆每次请求都在重置。我的做法比较土用一个 JSON 文件当状态层Agent 每处理一条就把进度和当前结果写回去。// state.js —— 一个极简的会话状态层Node 25.8.2 实测// 为什么看这段长任务里 Agent 的进行到哪了不该靠它自己记// 而是外部持久化重启不丢、可对账。constfsrequire(fs);constSTATE_FILE./agent-session.json;functionloadState(){if(!fs.existsSync(STATE_FILE)){return{processed:0,agreements:null,results:[]};}returnJSON.parse(fs.readFileSync(STATE_FILE,utf8));}functionsaveState(state){fs.writeFileSync(STATE_FILE,JSON.stringify(state,null,2));}// 运行结果Node 25.8.2 实测第一条处理完后的状态文件 { processed: 1, agreements: 金额按分返回库存字段禁止修改, results: [ { id: O-1001, amountInCents: 12990, status: ok } ] }注意看agreements这个字段它是这个方案的核心把开头跟 Agent 约定好的规矩直接写进状态文件而不是只存在于对话开头那几轮里。后面阶段二会讲为什么这条救了我的命。这里有个明显的边界状态全塞一个 JSON 文件扛不住并发和多 Agent 同时写。真上线我会换数据库或 Redis演练阶段图省事用文件够了。你要是做高并发长任务别学这个但思路是一样的。阶段二上下文满了怎么压缩长任务跑起来上下文窗口会被中间输出快速灌满。历史对话不能全删——Agent 后面要用前面的结论。这时候只有两条路压缩或者换会话。先说换会话这条路很多人容易忽略如果任务能拆成独立小步骤步骤之间只共享少量数据那就别硬撑一个长会话。每个步骤新开会话、只把必要数据传过去上下文干净翻车面也小。我后来复盘才发现当初那个订单任务本来可以拆是我图省事硬让一个会话从头跑到尾。拆不动的时候才谈压缩。压缩常见三种各有各的坑压缩策略怎么做保留什么最容易丢什么适合场景直接截断最早的对话滚出窗口最近的内容早期指令、开头的约定早期内容真没用了摘要压缩把历史对话喂给模型产出摘要事件主干数字、单位、禁止项这类细节叙事型任务结构化压缩把关键信息抽成结构化字段状态、结果、约定推理过程和中间讨论有明确数据边界的任务表 2 三种压缩策略对比我的经验是摘要压缩是最大的坑AI 摘要是会丢细节的而且丢的恰恰是金额按分返回这种看起来不起眼、丢了就要命的信息。OpenAI 自己的缓存指南也印证了这一点——他们专门提醒开发者用 append-only 的方式维护上下文新指令追加在末尾覆盖旧的而不是去修改中间内容就是为了保持上下文稳定、别把前面的东西弄丢。所以压缩之前先做一件事把不可丢的信息钉死在状态里。就是阶段一那个agreements字段。上下文随便压只要 Agent 每步都能从状态文件里读到关键约定摘要丢多少都不怕。这个效果我在演练里实测过没钉约定之前跑到后半程金额单位错了九十多条把约定写进状态文件重跑从头到尾零漂移——完整对账脚本和数字在另一篇演练复盘里有这篇不重复贴。这个策略的边界也讲清楚钉死约定只解决约定丢失解决不了模型对约定的理解漂移。Agent 读到了约定但执行时打折那是另一层问题需要靠验证环节兜。阶段三会话结束记忆怎么留长任务跑完会话就结束了但 Agent 干活的规矩不能跟着会话一起结束。这时候要决定哪些东西值得留到下次会话。我的取舍标准很简单留规则不留过程。业务约定、输出格式、禁止操作这些是规则留中间某一步具体怎么算出来的那是过程下次基本用不上删。收尾这段用一个归档脚本搞定// archiveRules.js —— 会话结束后规则入库过程丢弃// 为什么看这段收尾不是把整个会话原样存下来而是只提取规则层// 下次会话载入的也是这份规则不是几 MB 的历史对话。constfsrequire(fs);constsessionJSON.parse(fs.readFileSync(./agent-session.json,utf8));construlesArchive{savedAt:2026-09-28,agreements:session.agreements,// 规则留resultCount:session.results.length,// 只留数量过程结果丢弃lastId:session.results.at(-1)?.id// 断点续跑用留个锚};fs.writeFileSync(./rules.json,JSON.stringify(rulesArchive,null,2));// 运行结果Node 25.8.2 实测archiveRules.js 产出的 rules.json { savedAt: 2026-09-28, agreements: 金额按分返回库存字段禁止修改, resultCount: 428, lastId: O-1428 }留多久、放哪看信息敏感度纯业务规则金额单位、字段命名放项目配置或状态文件长期留。带用户数据的用户偏好、历史操作放数据库按业务合规要求定保留期。敏感的token、密钥、用户 PII别留在任何 Agent 可读的上下文里交给专门的密钥管理。这段说得直白点记忆不是越多越好。我之前见过有人给 Agent 配了个无限记忆把几年对话全存进去结果每次请求都背着几 MB 的历史贵不说Agent 反而被无关老对话带偏。ASCII 图是长会话生命周期的完整样子会话开始 → 阶段一状态初始化约定写入 agreements ↓ 任务循环读状态 → 干活 → 写状态 ↓ 上下文窗口滚满 → 阶段二先钉死约定 → 再压缩 ↓ 任务完成 → 阶段三规则入库过程丢弃 ↓ 下次会话 → 载入 agreements不用从头教图 1 长会话生命周期约定从开头写进状态压缩不丢结束入库产出物长会话设计检查清单把上面的决策整理成一张能勾选的表我演练完之后就一直按这个检查检查项具体动作勾选1 单轮够用任务能一次问答解决就别上状态☐2 需要外部状态吗长链路任务才需要先确认拆不掉☐3 约定有没有钉死关键约定写进状态文件不只活在对话里☐4 压缩策略选对了吗数据型任务用结构化别用摘要☐5 压缩前先固化先钉不可丢信息再让上下文滚☐6 留规则不留过程会话结束只入库规则过程丢弃☐7 敏感信息隔离token/PII 不进 Agent 可读上下文☐8 能拆就拆步骤独立就拆会话别硬撑长会话☐表 3 长会话设计检查清单这套清单只覆盖记忆与上下文这个维度。长会话还有别的坑——成本监控、任务取消与恢复、超时重试——这篇不展开真要上线得单独过一遍。清单落地之后怎么验收我自己验证的方式是三遍对账跑一遍长任务用对账脚本盯漂移点把约定钉进状态文件重跑看漂移是否消失再删掉状态文件重跑看漂移是否回来。这三步和同一轮演练的复盘文里用的脚本是一套读者可以照搬——比我觉得没问题可靠得多。边界有些场景根本不需要长会话写到最后必须泼一盆冷水。长会话不是越久越好。多数日常任务根本用不到长会话问答、单次生成、独立小任务短会话干净利落反而省事。硬把简单任务拉成长会话等于给自己引入状态管理、压缩策略、记忆持久化一整套复杂度收益为零。适合长会话的是那种必须在一个上下文里连续推理、中间结果互相依赖的任务——批量处理共享约定的数据、多步骤长文档、跨系统协调。判断标准就一条拆开会话后要不要频繁地把前面的结论手动搬过来要就别拆。我见过不少团队一上来就追求Agent 跑一整天其实他们那个场景拆成几十个短任务反而更稳。先想清楚你的任务配不配长会话再谈长会话怎么设计。总结回头看那轮演练翻车的不是我让 Agent 跑得久是我让它的记忆全活在上下文窗口里而窗口是会滚、会压、会丢的。三个决策点再压一遍状态放外部约定先钉死记忆留规则不留过程。做到这三点Agent 跑几小时还是跑一天差别就没那么大了。