021、交互式模式入门：启动会话、对话循环与上下文管理
上周帮同事排查一个诡异的Bug：他写了个CodeX脚本，每次对话到第三轮就“失忆”，明明上一轮刚定义过的变量，下一轮就报“未定义”。他怀疑是CodeX的缓存机制有问题，我一看代码——好家伙，他把整个交互逻辑写成了单次请求，每次调用都新建一个会话，上下文自然清零。这让我意识到，很多人对CodeX的交互式模式理解还停留在“发一条消息，收一条回复”的层面，根本没摸到对话循环和上下文管理的门道。
今天这篇笔记，就从这个真实案例切入，把CodeX交互式模式的三个核心环节拆开揉碎：如何正确启动一个会话、如何设计健壮的对话循环、以及如何像管理内存一样管理上下文。全程代码可跑，注释里藏着我踩过的坑。
启动会话：别用“一次性”思维
CodeX的交互式模式，本质是维护一个有状态的对话通道。很多人第一次接触时，会下意识写成这样：
# 错误示范：每次请求都新建会话importcodexdefask_codex(prompt):session=codex.Session()# 每次调用都new一个sessionresponse=session.send(prompt)returnresponse这种写法在单轮问答里没问题，但一旦需要多轮对话，session对象在函数返回后就销毁了，下一轮调用时上下文归零。正确的做法是把session实例提升为全局或类级别，让它活在整个对话生命周期里：
# 正确姿势：session要持久化importcodexclassCodexChat:def__init__(self,model="codex-davinci-002"):self.session=codex.Session(model=model)# 只初始化一次self.history=[]# 自己维护一份历史记录，后面会用到defchat(self,user_input):# 这里踩过坑：session.send()默认会携带历史上下文# 但如果你手动清空了session，它就会失忆response=self.session.send(user_input)self.history.append({"role":"user","content":user_input})self.history.append({"role":"assistant","content":response})returnresponse启动会话时，还有两个容易被忽略的参数：temperature和max_tokens。别用默认值——默认的temperature=0.7在代码生成场景下太“发散”，我习惯设到0.2~0.3，让输出更确定。max_tokens则要根据你的对话长度预估，设太小会被截断，设太大浪费资源。
对话循环：别让循环变成死循环
有了持久化的session，下一步就是设计对话循环。最简单的版本长这样：
defrun_chat_loop():chat=CodexChat()print("CodeX交互式模式已启动，输入'exit'退出")whileTrue:user_input=input(">>> ")ifuser_input.lower()=="exit":breakresponse=chat.chat(user_input)print(f"CodeX:{response}")这个循环能跑，但生产环境里会出问题。比如用户输入空字符串时，CodeX会返回一个无意义的回复；或者网络波动导致session.send()抛出异常，循环直接崩溃。别这样写——至少加个重试机制和输入校验：
defrobust_chat_loop():chat=CodexChat()retry_count=0max_retries=3whileTrue:try:user_input=input(">>> ").strip()ifnotuser_input:print("输入不能为空，请重新输入")continueifuser_input.lower()in("exit","quit"):breakresponse=chat.chat(user_input)print(f"CodeX:{response}")retry_count=0# 成功后重置重试计数exceptcodex.exceptions.TimeoutError:retry_count+=1ifretry_count>max_retries:print("多次超时，请检查网络或API状态")breakprint(f"请求超时，正在重试({retry_count}/{max_retries})...")exceptExceptionase:print(f"发生未知错误:{e}")# 这里踩过坑：不要直接break，记录日志后继续# 因为可能是临时性错误continue注意那个continue——很多人习惯在异常处理里直接break或exit，但交互式对话中，用户可能只是输入了一个特殊字符导致解析失败，不应该因此终止整个会话。除非是认证失败这类不可恢复的错误，否则尽量让循环继续。
上下文管理：别让记忆变成负担
回到开头的案例——同事的脚本“失忆”，本质是上下文管理出了问题。CodeX的session内部维护了一个上下文窗口，但默认策略是无限累积。这意味着对话越长，发送给模型的token越多，最终要么超出模型限制（比如Codex-Davinci-002的4096 token上限），要么因为上下文过长导致响应变慢、成本飙升。
正确的做法是主动管理上下文窗口。我常用的策略是滑动窗口：
classSmartCodexChat:def__init__(self,max_context_tokens=3000):self.session=codex.Session()self.max_context_tokens=max_context_tokens self.context=[]# 存储历史消息的token数def_trim_context(self):# 别这样写：直接清空所有历史# self.context = []# 正确做法：从最旧的消息开始删除，直到总token数低于阈值total_tokens=sum(msg["tokens"]formsginself.context)whiletotal_tokens>self.max_context_tokensandself.context:removed=self.context.pop(0)total_tokens-=removed["tokens"]defchat(self,user_input):# 先修剪上下文，再发送请求self._trim_context()response=self.session.send(user_input)# 记录本次交互的token消耗self.context.append({"tokens":len(user_input)+len(response),# 简化计算，实际应使用tokenizer"content":response})returnresponse这里有个细节：_trim_context里我用了pop(0)，这在列表操作里是O(n)的，如果对话轮次非常多（比如上千轮），性能会急剧下降。生产环境建议用collections.deque替代列表，或者维护一个索引指针来模拟环形缓冲区。
另一个常见坑是手动清空session。有些开发者为了“重置”上下文，会调用session.clear()，但这会丢失所有历史，包括系统提示词（system prompt）。如果你只是想清除用户对话历史，保留系统提示，应该用session.reset(keep_system_prompt=True)——这个参数在官方文档里藏得很深，我也是翻源码才发现的。
个人经验性建议
永远不要依赖session的默认上下文管理。它只保证“不丢数据”，不保证“不超限”。自己维护一个token计数器，在每次send前检查，比事后报错强。
对话循环里一定要有“逃生门”。除了exit命令，还要考虑Ctrl+C中断、长时间无响应自动退出、以及API配额耗尽时的优雅降级。我见过最惨的案例是循环里没加break条件，结果API账单跑出几千美元。
上下文修剪策略要跟业务场景匹配。代码补全场景，最近3-5轮对话就够用了；但如果是代码审查场景，可能需要保留整个文件的修改历史。别一刀切用固定轮数，用token数做阈值更科学。
调试时把上下文dump出来。在
_trim_context前后打印当前token数和消息数量，能帮你快速定位“失忆”原因。我习惯在开发环境加一个--debug参数，开启后每轮对话都输出上下文快照。最后，别把交互式模式当REST API用。如果你只是单次请求，用
codex.Completion.create()就够了，没必要开session。session的开销比单次请求大一个数量级，滥用会导致响应延迟和成本上升。
这篇笔记的代码片段都来自我最近重构的一个CodeX CLI工具，完整版放在公司的内部仓库里。如果你在实现过程中遇到session神秘“失忆”或者上下文越界的问题，大概率是上面提到的某个细节没处理好。交互式模式的核心就三个字：有状态。理解了这一点，剩下的都是工程细节。
