从零构建智能代码解释器：LLM与沙箱的工程实践

1. 项目概述当代码有了“思考”的能力最近在GitHub上看到一个挺有意思的项目叫haseeb-heaven/code-interpreter。光看名字你可能觉得这又是一个普通的代码执行工具或者一个在线编程环境。但如果你点进去花点时间研究一下它的README和代码结构你会发现它的野心远不止于此。这个项目试图构建的是一个能够理解自然语言指令、自主规划并执行代码、最终给出结果和解释的“智能体”。简单来说它想让代码拥有“思考”和“行动”的能力而不仅仅是机械地执行。这让我想起了OpenAI之前推出的“代码解释器”Code Interpreter功能它允许GPT-4模型在一个安全的沙箱环境中编写和执行Python代码从而解决复杂的数学问题、数据分析、文件处理等任务。haseeb-heaven/code-interpreter这个开源项目可以看作是朝着这个方向的一个社区实现和探索。它的核心价值在于它试图将大型语言模型LLM的推理能力与代码执行环境无缝结合创造一个能够“动手”解决问题的AI助手。这对于数据分析师、研究人员、开发者甚至是想用代码解决日常问题的普通用户来说都极具吸引力。想象一下你只需要用自然语言描述你的需求比如“帮我分析一下上个月的销售数据找出增长最快的三个品类”这个智能体就能自己写出Python代码加载你的Excel文件进行计算、可视化并给你一份清晰的报告。这个项目背后涉及的技术栈相当丰富它不仅仅是一个简单的Python脚本执行器。它需要处理LLM的API调用比如OpenAI的GPT系列、构建一个安全的代码沙箱环境、设计一套让LLM能够“思考”和“规划”的提示词Prompt工程、管理执行过程中的状态和上下文还要能处理各种文件格式。接下来我们就深入拆解一下这个项目的核心设计与实现思路看看它是如何一步步让代码“活”起来的。1.1 核心需求与设计哲学要理解这个项目首先要明白它要解决的根本问题是什么。传统的编程模式是“人编写指令机器执行”。而code-interpreter项目探索的是“人描述意图AI生成并执行指令”。这带来了几个核心需求意图理解系统必须能准确理解用户用自然语言提出的、有时是模糊或开放式的请求。任务分解与规划将复杂的用户请求拆解成一系列可执行的、线性的代码步骤。例如“画一个正弦波图”需要分解为导入库、生成数据、创建画布、绘图、添加标签、显示图像。安全执行生成的代码必须在严格受限的沙箱环境中运行以防止恶意代码对主机系统造成破坏比如删除文件、访问网络或消耗过多资源。上下文管理代码执行是连续的上一步的变量和结果需要能被下一步的代码访问。系统需要维护一个会话状态。结果解释与呈现执行完成后系统需要将代码的输出文本、图表、错误信息以一种对人类友好的方式呈现出来并可能附上解释。haseeb-heaven/code-interpreter项目的设计哲学正是围绕这些需求展开的。它没有尝试去发明一个新的编程语言或执行引擎而是巧妙地充当了一个“协调者”或“翻译官”的角色。它的架构可以概括为一个强大的“大脑”LLM负责理解和规划一个可靠的“双手”Python沙箱负责执行而项目本身则是一套精密的“神经系统”负责在两者之间传递信息、管理状态和控制流程。这种设计的好处是模块化且灵活。你可以更换不同的“大脑”比如从GPT-4换成Claude或本地部署的模型也可以调整“双手”的能力比如安装不同的Python包。项目的核心价值就在于它提供的这套协调机制、安全策略以及经过精心设计的与LLM交互的“对话协议”。2. 核心架构与组件拆解要亲手搭建或深度使用这样一个系统我们必须先把它拆开看看里面到底有哪些关键部件在协同工作。haseeb-heaven/code-interpreter的架构虽然可能因版本迭代而变化但其核心思想是稳定的。我们可以将其抽象为以下几个层次交互层负责接收用户的自然语言输入并将最终的输出文本、图片、错误信息返回给用户。这可以是一个命令行界面CLI、一个Web API端点或者一个聊天机器人界面。智能体层核心这是项目的“大脑”和“调度中心”。它主要包含两个子模块规划模块调用LLM API将用户请求和历史对话上下文转化为一个具体的“行动计划”。这个计划通常是一段或多段Python代码。这里涉及到复杂的提示词工程告诉LLM“你是一个Python数据分析专家请根据我的要求编写代码...”。状态管理模块维护整个会话的上下文。这包括之前对话的历史、已经执行过的代码、生成的变量、输出的结果尤其是图像等非文本内容。这个上下文会在每次调用LLM时被发送过去以确保智能体有“记忆”。执行层这是项目的“双手”。它接收来自智能体层的代码并在一个隔离的环境中运行。代码沙箱这是安全性的基石。通常使用Docker容器来创建一个纯净、资源受限的Python环境。容器里预装了常用的科学计算和数据分析库如numpy,pandas,matplotlib等。代码在容器内运行无法访问宿主机的文件系统除非显式映射了特定目录、网络或其他资源。执行引擎负责在沙箱中启动Python解释器注入代码捕获标准输出、标准错误以及最终的执行结果包括matplotlib生成的图像在内存中的表示。工具与扩展层为了让智能体更强大项目通常会设计一套“工具”系统。LLM可以被引导去调用这些工具。例如一个“文件读取”工具允许LLM知道如何加载用户上传的CSV文件一个“网络搜索”工具如果安全策略允许可以让它获取实时信息。code-interpreter项目可能通过让LLM生成特定格式的指令来间接调用这些功能。注意安全是执行层的生命线。一个设计不当的沙箱可能会被生成的代码逃逸导致严重的安全问题。因此沙箱必须进行严格的资源限制CPU、内存、运行时间并禁用危险的操作如os.system,subprocess调用等。通常采用白名单机制只允许导入安全的库。2.1 关键技术点提示词工程与ReAct模式项目最精妙的部分在于如何与LLM沟通让它扮演好“代码解释器”这个角色。这完全依赖于提示词工程。系统发送给LLM的提示词Prompt不是一个简单的问题而是一个结构化的“剧本”定义了角色、规则、能力和工作流程。一个典型的提示词结构可能包含系统指令定义AI的角色和能力。例如“你是一个运行在安全Python沙箱中的高级数据分析AI。你可以编写和执行Python代码来解决用户的问题。沙箱中已安装pandas,numpy,matplotlib等库。”工作流程说明告诉AI如何思考。这里常常会用到ReAct (Reasoning Acting)模式。即让AI先“思考”Reasoning该做什么然后“行动”Acting——生成代码。在提示词中可能会要求AI以“Thought: ...\nAction: Python\npython\n...\n”这样的格式来响应。上下文提供当前会话的历史消息、之前生成的代码及其输出、当前环境中已有的变量等。用户当前请求用户这一次提出的问题。通过这样精心设计的提示词LLM就被“框定”在了我们期望的行为模式内它像一个谨慎的工程师先思考步骤再写出代码而不是天马行空地闲聊。2.2 另一个关键会话状态与代码执行上下文的管理代码执行不是一次性的。用户可能会说“把刚才那个图表的颜色改成红色”。这时智能体必须知道“刚才那个图表”对应的是哪个matplotlib的figure对象或者至少知道相关的数据变量是什么。因此项目需要维护一个会话状态。这个状态通常包括对话历史用户和AI的每一轮问答。代码执行历史每一段被执行的代码及其输出stdout,stderr,result。环境状态沙箱Python解释器中的全局命名空间globals()。这通常通过在执行完一段代码后有选择地将一些变量比如大型DataFrame可能只存储其摘要或所有变量序列化并保存下来。更常见的做法是让每一段新代码都在一个继承了之前所有变量定义的环境中执行。这可以通过在沙箱中维护一个持久的Python进程或IPython内核来实现而不是每次执行都启动一个新的解释器。管理这个状态是实现连贯对话的关键也是技术难点之一。状态太大存储所有数据会使得上下文膨胀很快超过LLM的令牌限制状态太小丢失关键变量会导致智能体失忆。通常的策略是只保留最后几轮对话的详细上下文并对更早的历史进行摘要。3. 从零开始构建你自己的简易代码解释器理解了核心架构后我们完全可以尝试动手搭建一个简化版本。这不仅能加深理解也能让你根据自身需求进行定制。下面我将以一个使用OpenAI API Docker沙箱 FastAPI Web接口的方案为例拆解实现步骤。3.1 环境准备与依赖安装首先我们需要一个工作环境。假设你使用Linux/macOS系统并已安装Python 3.9和Docker。创建一个新的项目目录并初始化虚拟环境mkdir my-code-interpreter cd my-code-interpreter python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate安装核心Python依赖pip install openai fastapi uvicorn docker python-dotenvopenai: 用于调用GPT API。fastapiuvicorn: 用于构建Web API服务器。docker: Python的Docker SDK用于以编程方式管理容器。python-dotenv: 用于管理环境变量如API密钥。准备一个Docker镜像作为我们的沙箱。创建一个DockerfileFROM python:3.9-slim WORKDIR /workspace # 安装系统依赖清理缓存以减小镜像体积 RUN apt-get update apt-get install -y \ gcc \ g \ rm -rf /var/lib/apt/lists/* # 安装常用的Python科学计算库 RUN pip install --no-cache-dir numpy pandas matplotlib seaborn scipy scikit-learn jupyter ipykernel # 创建一个非root用户运行代码增强安全性 RUN useradd -m -u 1000 coder USER coder CMD [python]构建这个镜像docker build -t code-sandbox:latest .3.2 核心模块实现沙箱执行器这是执行层的核心。我们创建一个sandbox.py文件实现一个基于Docker容器的代码执行器。import docker import json import base64 from io import BytesIO import time class CodeSandbox: def __init__(self, image_name“code-sandbox:latest”): self.client docker.from_env() self.image_name image_name self.container None # 启动一个持久化的容器 self._start_container() def _start_container(self): 启动一个Docker容器作为持久化执行环境 # 设置资源限制防止代码滥用 container_config { “image”: self.image_name, “command”: “python -c ‘import IPython; IPython.start_ipython([])’”, # 使用IPython内核以支持更好的状态保持 “stdin_open”: True, # 保持标准输入打开用于交互 “tty”: True, # 分配一个伪终端 “working_dir”: “/workspace”, “mem_limit”: “512m”, # 内存限制512MB “cpu_period”: 100000, “cpu_quota”: 50000, # 限制CPU使用率为50% “network_disabled”: True, # 禁用网络防止对外请求 “read_only”: True, # 根文件系统只读 } self.container self.client.containers.run(**container_config, detachTrue) # 等待容器内IPython内核启动 time.sleep(2) def execute_code(self, code: str, timeout: int 10): 在容器中执行一段Python代码 if not self.container: raise RuntimeError(“Sandbox container not running”) # 构造一个在IPython中执行代码的命令 # 这里简化处理实际应用中可能需要通过IPython的Kernel Client进行更复杂的通信 exec_command f“exec(‘‘‘{code}‘‘‘)” full_cmd [“python”, “-c”, exec_command] try: # 使用docker exec执行命令 exec_result self.container.exec_run( cmdfull_cmd, demuxTrue # 分离stdout和stderr ) exit_code, (stdout_bytes, stderr_bytes) exec_result stdout stdout_bytes.decode(‘utf-8’) if stdout_bytes else “” stderr stderr_bytes.decode(‘utf-8’) if stderr_bytes else “” # 尝试捕获matplotlib生成的图像简化版实际需更复杂处理 # 可以通过在代码中强制将图形保存为base64来实现 output_images [] # 这里只是一个示意真实场景需要解析代码输出或监控文件系统 return { “success”: exit_code 0, “stdout”: stdout, “stderr”: stderr, “images”: output_images, “exit_code”: exit_code } except Exception as e: return { “success”: False, “stdout”: “”, “stderr”: f“Execution failed: {str(e)}”, “images”: [], “exit_code”: -1 } def cleanup(self): 停止并清理容器 if self.container: self.container.stop() self.container.remove()实操心得在生产环境中上述沙箱实现是高度简化的。一个健壮的沙箱需要考虑更多1) 使用pysandbox或seccomp等更严格的内核级隔离2) 实现真正的IPython内核连接以完美维护变量状态3) 设置更细粒度的超时控制防止无限循环4) 处理更复杂的输出类型如交互式图表、音频。对于学习原型这个简化版足够了但切勿直接用于公开服务。3.3 核心模块实现LLM智能体与提示词接下来是大脑部分。创建agent.py文件。import openai import os from dotenv import load_dotenv load_dotenv() openai.api_key os.getenv(“OPENAI_API_KEY”) class CodeInterpreterAgent: def __init__(self, model“gpt-4”): self.model model self.conversation_history [] # 维护对话历史 def _build_messages(self, user_query, execution_context“”): 构建发送给LLM的消息列表 system_prompt “““你是一个运行在安全Python沙箱中的高级数据分析AI助手。你的名字是CodeBot。 你的能力 1. 你可以编写和执行Python代码来解决用户的问题。 2. 沙箱环境已安装以下库numpy, pandas, matplotlib, seaborn, scipy, scikit-learn。 3. 你生成的代码必须完整、可独立运行。如果需要进行可视化请使用matplotlib并确保使用plt.show()或plt.savefig()来生成图像。 4. 你非常注重代码的安全性和简洁性。绝不执行任何危险操作如文件删除、网络访问等。 5. 请按照以下格式思考和工作 Thought: 用中文简要分析用户请求规划步骤 Action: Python python # 你的代码 here 6. 如果代码执行后需要向用户解释结果请在代码块后添加一个简短的‘解释‘部分。 当前执行上下文已有的变量等{context} “““.format(contextexecution_context) messages [{“role”: “system”, “content”: system_prompt}] # 添加历史对话为了控制长度可以只保留最近几轮 messages.extend(self.conversation_history[-6:]) # 保留最近3轮对话 # 添加当前用户请求 messages.append({“role”: “user”, “content”: user_query}) return messages def generate_code(self, user_query, execution_context“”): 调用LLM根据用户查询生成代码和思考过程 messages self._build_messages(user_query, execution_context) try: response openai.ChatCompletion.create( modelself.model, messagesmessages, temperature0.1, # 低温度让输出更确定、更专注于代码 max_tokens1500, ) full_response response.choices[0].message.content self.conversation_history.append({“role”: “user”, “content”: user_query}) self.conversation_history.append({“role”: “assistant”, “content”: full_response}) # 解析响应提取Thought和Code thought, code self._parse_response(full_response) return thought, code except Exception as e: return f“调用AI模型时出错{e}”, “” def _parse_response(self, response): 解析LLM的响应分离出Thought和Python代码块 thought “” code “” lines response.split(‘\n’) in_thought False in_code False for line in lines: if line.startswith(‘Thought:’): in_thought True thought line.replace(‘Thought:’, ‘‘).strip() elif line.startswith(‘Action: Python’): in_thought False elif line.startswith(‘python’): in_code True continue elif line.startswith(‘’) and in_code: in_code False continue if in_thought: thought ‘ ‘ line.strip() elif in_code: code line ‘\n’ return thought.strip(), code.strip()3.4 服务集成与API构建最后我们创建一个main.py文件用FastAPI将沙箱和智能体粘合起来提供一个Web API。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from sandbox import CodeSandbox from agent import CodeInterpreterAgent import threading import logging app FastAPI(title“My Code Interpreter API”) # 使用线程锁保证同一时间只有一个请求操作沙箱简化处理生产环境需更复杂并发管理 sandbox_lock threading.Lock() sandbox None agent None class UserRequest(BaseModel): query: str def get_sandbox(): global sandbox if sandbox is None: sandbox CodeSandbox() return sandbox def get_agent(): global agent if agent is None: agent CodeInterpreterAgent(model“gpt-3.5-turbo”) # 初始可用gpt-3.5-turbo成本更低 return agent app.post(“/execute”) async def execute_code(request: UserRequest): 接收用户查询生成并执行代码返回结果 with sandbox_lock: current_agent get_agent() current_sandbox get_sandbox() # 1. 生成代码 logging.info(f“用户查询{request.query}”) thought, code current_agent.generate_code(request.query) if not code: raise HTTPException(status_code400, detail“未能生成有效的代码。”) logging.info(f“AI思考{thought}”) logging.info(f“生成代码\n{code}”) # 2. 执行代码 execution_result current_sandbox.execute_code(code) logging.info(f“执行结果{execution_result}”) # 3. 构建响应 response { “thought”: thought, “generated_code”: code, “execution_success”: execution_result[“success”], “stdout”: execution_result[“stdout”], “stderr”: execution_result[“stderr”], “images”: execution_result[“images”] # base64编码的图片 } return response app.on_event(“shutdown”) def shutdown_event(): 应用关闭时清理沙箱 if sandbox: sandbox.cleanup() if __name__ “__main__”: import uvicorn uvicorn.run(app, host“0.0.0.0”, port8000)现在运行python main.py你的简易代码解释器API服务就在本地的8000端口启动了。你可以用curl或Postman发送一个POST请求到http://localhost:8000/executeJSON body为{“query”: “请生成一个包含10个随机数的列表并计算它们的平均值和标准差最后画一个折线图。”}看看它会如何工作。4. 深入核心安全、状态与错误处理一个玩具原型和可用产品之间的差距往往就体现在这些“非功能性”的细节上。haseeb-heaven/code-interpreter这类项目的复杂性很大程度上也在于此。4.1 安全性的多层防御代码生成与执行是高风险操作。我们必须建立多层防御LLM提示词约束第一道防线。在系统提示词中明确禁止危险操作如“绝不使用os.system,subprocess,__import__(‘os’)绝不访问网络绝不尝试读写/etc/,/home等目录”。引导LLM生成安全的代码。静态代码分析在代码执行前进行简单的语法分析和模式匹配。检查代码中是否包含黑名单中的危险函数、模块或字符串如“rm -rf”,“eval(”。可以使用Python的ast抽象语法树模块进行更精准的分析。动态沙箱隔离这是最核心的防线。Docker容器提供了命名空间和cgroups隔离。资源限制必须设置内存(mem_limit)、CPU(cpu_quota)、进程数(pids_limit)、运行时间通过timeout参数控制的上限。文件系统隔离容器应以只读(read_only: True)模式运行根文件系统。如果允许用户上传文件应通过volumes将宿主机的一个临时目录以只读方式挂载到容器的特定路径。网络隔离除非必要否则禁用容器网络(network_disabled: True)。能力限制使用Docker的cap_drop参数移除容器的所有Linux能力如SYS_ADMIN,NET_RAW最大限度地降低权限。运行时监控在代码执行期间进行监控。可以设置一个看门狗线程如果执行超时则强制终止容器。监控内存使用如果接近上限也提前终止。4.2 会话状态管理的挑战与策略在3.2节的简化沙箱中我们每次都用docker exec执行一个独立的命令这会导致变量状态丢失。为了实现真正的“解释器”体验我们需要维护一个持久的执行内核。方案一使用Jupyter Kernel这是更成熟和强大的方案。你可以在Docker容器内启动一个Jupyter内核如IPython kernel然后在宿主机上使用jupyter_client库与之通信。这样所有的代码都在同一个内核会话中执行变量状态得以完美保持。haseeb-heaven/code-interpreter很可能采用了类似方案。方案二维护自定义的全局命名空间在沙箱容器内运行一个长期存在的Python进程比如一个简单的TCP/HTTP服务器该进程维护一个全局字典作为命名空间。每次执行代码时通过进程间通信将代码发送过去在该命名空间下执行exec(code, global_namespace)并将结果返回。这需要自己处理序列化、通信和错误恢复但可控性更高。状态剪裁与摘要无论用哪种方案随着对话进行上下文变量、历史会越来越庞大。我们需要定期进行“状态剪裁”变量摘要对于大型数据如DataFrame不存储整个数据而是存储其shape、head()或描述性统计。当LLM后续需要时可以提示它“数据已加载名为df其形状为(1000, 5)”。对话历史摘要当对话轮数过多时调用LLM对之前的对话历史进行总结用一段简短的摘要替换掉详细的历史记录以节省Token。4.3 错误处理与用户引导生成的代码不可能永远正确。LLM可能会写出有语法错误、运行时错误或逻辑错误的代码。系统的错误处理机制至关重要。捕获并解析错误沙箱执行器必须能清晰地区分stdout正常输出、stderr错误输出和exit_code。将完整的错误信息包括Traceback返回给智能体。让AI自我纠错这是最巧妙的部分。当代码执行失败时将错误信息作为新的上下文连同原始用户请求再次发送给LLM。提示词可以调整为“你之前生成的代码执行失败了错误信息是...。请分析错误原因修正你的代码并重新尝试。” 这实现了AI的自我调试能力。用户友好反馈最终呈现给用户的不应该是一段原始的Python Traceback。系统应该尝试让LLM用自然语言解释错误原因例如“看起来我试图除以零了因为列表是空的”并告知用户它正在尝试修复。如果多次尝试后仍失败应优雅地告知用户限制并建议更清晰的提问方式。5. 进阶应用场景与扩展思路一个基础的代码解释器已经能完成很多任务但它的潜力远不止于此。结合haseeb-heaven/code-interpreter项目可能的发展方向我们可以探索以下扩展5.1 多模态与文件处理真正的“代码解释器”需要能处理用户上传的文件。这需要扩展架构文件上传接口在Web API中增加一个上传端点将文件暂存到宿主机。文件映射在创建或复用沙箱容器时通过Docker Volume将存放用户文件的宿主机目录以只读方式挂载到容器内的固定路径如/mnt/data。提示词增强在系统提示词中告知AI“用户上传的文件位于容器的/mnt/data/目录下你可以使用pandas.read_csv(‘/mnt/data/your_file.csv’)来读取。” AI生成的代码就能正确引用这些文件。多模态输出除了文本和图表还可以支持生成音频使用librosa、处理图像使用PIL/OpenCV等。输出时需要将这些二进制数据编码如base64后通过API返回。5.2 工具调用与外部集成让AI只局限于预装库和沙箱内的数据是不够的。我们可以引入“工具”的概念让LLM学会在特定时机调用外部API或执行特定函数。工具定义定义一系列工具函数如search_web(query: str) - str,get_current_time() - str,query_database(sql: str) - List[Dict]。每个工具都有清晰的名称、描述和参数格式。提示词调整修改系统提示词告诉AI“你除了编写代码还可以调用以下工具...。当你需要使用时请以Tool: [工具名]的格式提出并提供参数。”执行调度在智能体层解析AI的响应。如果发现Tool: ...的指令则中断代码生成流程调用相应的工具函数将工具返回的结果作为新的上下文再让AI继续。这相当于赋予了AI“手脚”使其能获取实时信息或操作外部系统。5.3 领域专业化与微调通用代码解释器在处理专业领域问题时可能不够精准。我们可以对其进行专业化领域特定提示词为金融、生物信息、机械设计等不同领域定制系统提示词包含该领域的常用库、数据格式和分析范式。领域知识库结合RAG检索增强生成技术。当用户提问时先从领域知识库如技术文档、论文中检索相关片段并将其作为上下文提供给LLM从而生成更专业、准确的代码。模型微调如果有足够的领域代码和指令数据可以对基础LLM进行监督微调SFT让它更擅长生成特定领域的代码和解释。6. 常见问题、排查与优化实录在实际搭建和运行过程中你一定会遇到各种各样的问题。下面是我在类似项目中踩过的一些坑和总结的经验。6.1 执行超时与资源耗尽问题现象用户请求一个复杂计算如训练一个大模型沙箱执行长时间无响应最终超时或内存溢出导致容器被杀。排查首先检查Docker容器的资源限制配置mem_limit,cpu_quota。通过docker stats命令实时监控容器资源使用情况。解决前置校验在AI生成代码后、执行前加入一个简单的启发式检查。例如如果代码中包含for i in range(1000000):或np.ones((10000, 10000))可以预测其资源消耗大直接拒绝执行或要求用户确认。更细粒度的超时不仅设置整个请求的超时在沙箱内部对exec操作也设置超时可以使用signal模块或multiprocessing。用户引导在系统提示词中要求AI“生成高效的代码避免不必要的循环和大内存分配”。对于明确需要长时间运行的任务提示用户分解问题。6.2 LLM生成低质量或危险代码问题现象AI生成的代码语法错误频发或者偶尔会生成尝试导入os模块进行危险操作的代码。排查查看LLM的完整响应和系统提示词。是否是温度(temperature)参数设置过高导致输出不稳定提示词是否足够明确地禁止了危险操作解决降低温度将temperature设为0.1或0.2使输出更确定、更遵循指令。强化提示词在系统指令中多次、以不同方式强调安全规则。使用“绝不要(never)”、“必须避免(must avoid)”等强语气词。可以提供正面和反面例子。后置过滤与重试对生成的代码进行静态分析如使用ast模块遍历查找Import、Call节点如果发现危险模式则丢弃该次生成并带着“你生成了不安全代码请重写”的反馈再次调用LLM。6.3 会话上下文过长导致API调用失败或成本激增问题现象随着对话轮数增加发送给LLM的上下文越来越长最终超过模型的最大Token限制如GPT-4的8K/32K导致调用失败。同时长上下文也意味着更高的API成本。排查记录每轮请求的Token数量。观察对话历史是如何被构建的。解决智能截断不要无脑地将所有历史都塞进上下文。只保留最近N轮完整对话例如3-5轮。对于更早的历史进行摘要。动态摘要当历史达到一定长度时主动调用一次LLM使用更便宜的模型如gpt-3.5-turbo指令为“请将以下对话历史总结成一段简洁的摘要保留核心问题和解决方案...”。然后用这段摘要替换掉原有的详细历史。选择性记忆并非所有信息都需要记住。可以设计规则只保留代码执行结果中的关键信息如创建了哪些重要变量得出了什么结论而忽略冗长的中间输出。6.4 图像/二进制结果的处理与返回问题现象代码生成的图表无法显示或者在API响应中变成乱码。排查检查沙箱中代码是否正确地生成了图像文件或将图形对象保存在了内存中。检查执行器是否正确捕获并编码了这些二进制数据。解决标准化输出方式在提示词中严格要求AI使用特定的代码模式来生成图像。例如“如果生成图表请使用plt.savefig(‘/tmp/output.png’)将图像保存到/tmp/output.png然后通过print(‘IMAGE:’ file_to_base64(‘/tmp/output.png’))输出图像标识。” 然后在执行器中解析stdout寻找IMAGE:开头的行并处理后面的base64数据。使用交互式内核如果使用Jupyter内核图形可以直接作为display_data类型的消息返回其中包含图像的image/png格式数据更容易提取和编码。API响应设计在API的响应结构中将文本输出(stdout)和图像输出(images)分开。images字段可以是一个列表包含多个图像的base64字符串或URL。搭建一个可用的代码解释器就像在教一个极其聪明但缺乏实践经验的新手程序员。你需要为它划定安全的练习场沙箱提供清晰的编程手册提示词并在它犯错时给予明确的反馈错误处理与重试。haseeb-heaven/code-interpreter项目为我们提供了一个优秀的范本展示了如何将LLM的创造力与代码的执行力结合起来。通过拆解其架构并亲手实现核心模块你不仅能深刻理解其工作原理更能获得根据实际需求定制和扩展它的能力。无论是用于内部数据分析自动化还是作为智能编程助手的基础这套技术栈都充满了想象空间。