乐正雕漆这个标题看着简单，但背后其实藏着一整套完整的基础设施设计。很多人把"AI 对话框里跑 Python"理解成"调个 exec 不就行了"，真做起来才知道，exec 只是最不起眼的一环——它前面有消息协议、任务调度、会话状态，后面有资源隔离、安全审计、性能兜底。这篇把 Zorv AI 对话框里 Python 执行功能的技术架构完整拆开，从需求边界到模块设计，从沙箱选型到并发优化，再到上线前后的踩坑记录，一次性讲透。
我直接把当时的架构设计笔记整理出来，适合正在做同类功能的团队参考，也适合想搞明白"聊天框里的代码到底是咋跑起来的"这类问题的读者。文章会比较长，但每一段都是实际落地时的真实取舍。
1. 从对话到代码执行：这条链路为什么非做不可
1.1 用户要的不是"执行代码"功能，而是"即时验证"的反馈闭环
Zorv AI 最开始就是个纯对话产品，用户问问题，模型给答案。后来收到大量共性反馈：AI 在回答数据分析、脚本编写、算法讲解类问题时，经常给出一段 Python 代码，用户拿到本地跑一遍，报错，把报错信息再粘回对话框，AI 改一遍，用户再跑……一个简单问题来回折腾四五轮。
这个体验太割裂了。代码在这个场景里不是"最终产物"，而是"验证手段"。用户真正想要的是：AI 给出代码的同时，立刻把执行结果、图表输出、错误信息一并返回。报错能被模型直接读到，模型基于真实运行结果修正代码，整个"生成-执行-反馈-修正"闭环在对话框内完成。
这个需求听起来直接，但牵扯的技术问题非常多：代码跑在哪、怎么隔离、怎么限制资源、变量能不能跨轮保持、并发多了怎么办、模型上下文里塞多少执行结果合适。架构设计必须先把这些问题全部想清楚，否则功能上线就是事故现场。
1.2 需求边界划定：哪些代码该在对话框里跑，哪些不该
这是整个架构设计的起点。我们给"Zorv AI 对话框可执行的 Python"划定了一个明确的能力边界，这个边界直接影响后面的所有技术选型。
适合放进来跑的：
- 数据分析与可视化，比如 pandas 读 CSV 做统计、matplotlib 画趋势图
- 教学演示代码，比如算法实现、数据结构操作、语法验证
- 轻量级脚本任务，比如 JSON 格式转换、时间日期处理、文本批量清洗
- 算法验证与结果对比，比如排序算法耗时对比、动态规划状态转移验证
明确不放进来跑的：
- 需要长时间运行的服务或守护进程
- 需要访问内网私有资源的代码
- 需要大规模分布式计算的任务
- 任何涉及敏感凭据的操作，比如直接读取服务器环境变量里的密钥
边界确定后，整个架构的目标就清晰了：在一个受控、隔离、有时限的执行环境里，安全跑完一段轻量级 Python 代码，把 stdout、stderr、异常堆栈、图像结果结构化地返回给对话层，并且让同一会话内的代码可以共享变量状态。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计：一次"输入到回显"的完整链路
2.1 三层模块划分：会话层、调度层、执行层
Zorv AI 的 Python 执行功能在架构上分成三个独立模块，模块之间通过内部 API 通信，互不直接依赖。
会话层（Conversation Layer） 做三件事：从对话消息中提取代码块；把代码执行请求按会话维度封装成任务；把执行结果转成适合模型读取的上下文片段。
调度层（Scheduler Layer） 负责任务排队、并发控制、超时管理、会话状态映射。它不关心 Python 代码本身，只关心"哪个会话提交了任务、这个任务该路由到哪个执行实例、当前并发水位是多少"。
执行层（Execution Layer） 是真正的沙箱，负责拉起隔离的 Python 运行时，执行代码，采集 stdout、stderr、exit code、运行耗时、资源消耗，然后把这些数据结构化成 JSON 返回给调度层。
整个调用链路是这样走的：用户在对话框发送一条包含 Python 代码的消息 → 会话层识别代码块并生成任务 → 调度层按会话 ID 找到对应的执行实例池或创建新实例 → 执行层在沙箱里运行代码并采集结果 → 结果回传会话层 → 会话层把 stdout、错误信息、图表路径整理成模型可读的上下文，再触发模型生成下一轮回复。
2.2 为什么执行环境首选 Python
这个问题团队内部