021、交互式模式入门：启动会话、对话循环与上下文管理

原创已于 2026-06-21 16:52:59 修改 · 128 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#spring #java #后端 #azure #flask

于 2026-06-21 16:48:13 首次发布

CodeX教程：打通AI编程Agent的每个环节专栏收录该内容

25 篇文章

订阅专栏

021、交互式模式入门：启动会话、对话循环与上下文管理

上周帮同事排查一个诡异的Bug：他写了个CodeX脚本，每次对话到第三轮就“失忆”，明明上一轮刚定义过的变量，下一轮就报“未定义”。他怀疑是CodeX的缓存机制有问题，我一看代码——好家伙，他把整个交互逻辑写成了单次请求，每次调用都新建一个会话，上下文自然清零。这让我意识到，很多人对CodeX的交互式模式理解还停留在“发一条消息，收一条回复”的层面，根本没摸到对话循环和上下文管理的门道。

今天这篇笔记，就从这个真实案例切入，把CodeX交互式模式的三个核心环节拆开揉碎：如何正确启动一个会话、如何设计健壮的对话循环、以及如何像管理内存一样管理上下文。全程代码可跑，注释里藏着我踩过的坑。

启动会话：别用“一次性”思维

CodeX的交互式模式，本质是维护一个有状态的对话通道。很多人第一次接触时，会下意识写成这样：

# 错误示范：每次请求都新建会话
import codex

def ask_codex(prompt):
    session = codex.Session()  # 每次调用都new一个session
    response = session.send(prompt)
    return response

这种写法在单轮问答里没问题，但一旦需要多轮对话，session对象在函数返回后就销毁了，下一轮调用时上下文归零。正确的做法是把session实例提升为全局或类级别，让它活在整个对话生命周期里：

# 正确姿势：session要持久化
import codex

class CodexChat:
    def __init__(self, model="codex-davinci-002"):
        self.session = codex.Session(model=model)  # 只初始化一次
        self.history = []  # 自己维护一份历史记录，后面会用到
    
    def chat(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})
        return response

启动会话时，还有两个容易被忽略的参数：temperature和max_tokens。别用默认值——默认的temperature=0.7在代码生成场景下太“发散”，我习惯设到0.2~0.3，让输出更确定。max_tokens则要根据你的对话长度预估，设太小会被截断，设太大浪费资源。

对话循环：别让循环变成死循环

有了持久化的session，下一步就是设计对话循环。最简单的版本长这样：

def run_chat_loop():
    chat = CodexChat()
    print("CodeX交互式模式已启动，输入'exit'退出")
    while True:
        user_input = input(">>> ")
        if user_input.lower() == "exit":
            break
        response = chat.chat(user_input)
        print(f"CodeX: {response}")

这个循环能跑，但生产环境里会出问题。比如用户输入空字符串时，CodeX会返回一个无意义的回复；或者网络波动导致session.send()抛出异常，循环直接崩溃。别这样写——至少加个重试机制和输入校验：

def robust_chat_loop():
    chat = CodexChat()
    retry_count = 0
    max_retries = 3
    
    while True:
        try:
            user_input = input(">>> ").strip()
            if not user_input:
                print("输入不能为空，请重新输入")
                continue
            if user_input.lower() in ("exit", "quit"):
                break
            
            response = chat.chat(user_input)
            print(f"CodeX: {response}")
            retry_count = 0  # 成功后重置重试计数
        except codex.exceptions.TimeoutError:
            retry_count += 1
            if retry_count > max_retries:
                print("多次超时，请检查网络或API状态")
                break
            print(f"请求超时，正在重试({retry_count}/{max_retries})...")
        except Exception as e:
            print(f"发生未知错误: {e}")
            # 这里踩过坑：不要直接break，记录日志后继续
            # 因为可能是临时性错误
            continue

注意那个continue——很多人习惯在异常处理里直接break或exit，但交互式对话中，用户可能只是输入了一个特殊字符导致解析失败，不应该因此终止整个会话。除非是认证失败这类不可恢复的错误，否则尽量让循环继续。

上下文管理：别让记忆变成负担

回到开头的案例——同事的脚本“失忆”，本质是上下文管理出了问题。CodeX的session内部维护了一个上下文窗口，但默认策略是无限累积。这意味着对话越长，发送给模型的token越多，最终要么超出模型限制（比如Codex-Davinci-002的4096 token上限），要么因为上下文过长导致响应变慢、成本飙升。

正确的做法是主动管理上下文窗口。我常用的策略是滑动窗口：

class SmartCodexChat:
    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"] for msg in self.context)
        while total_tokens > self.max_context_tokens and self.context:
            removed = self.context.pop(0)
            total_tokens -= removed["tokens"]
    
    def chat(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
        })
        return response

这里有个细节：_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的开销比单次请求大一个数量级，滥用会导致响应延迟和成本上升。