复杂需求让 AI 写代码：ChatGPT 后台跑 Python 真算数，不是猜出来的结果

一、问题的本质：为什么 LLM "算不准"

1.1 概率预测器与符号运算器的根本错配

要理解 ChatGPT 为什么要"跑 Python"，必须先理解它为什么"算不准"。Transformer 架构的核心是自注意力机制（Vaswani 等，2017），其训练目标是最大化下一个 token 的似然。这意味着模型学到的是"在给定上下文下，什么 token 最可能接着出现"，而不是"两个数相加等于多少"这样的确定性规则。当被问到 27×453 时，模型输出的不是运算结果，而是训练语料中"看起来像答案"的 token 序列。

这种机制在短算式上往往表现尚可，因为训练数据中包含了海量类似模式，模型可以通过记忆与近似完成"查表"。但一旦数字位数增加、涉及进位链变长，错误率会迅速攀升。本文评述：这不是"模型不够聪明"，而是任务类型与建模范式之间的结构性错配——用统计近似去逼近一个本应由符号系统精确求解的问题。

1.2 来自基准测试的量化证据

学术界对此有系统的量化研究。GSM8K（Cobbe 等，2021）作为小学数学应用题基准，早期 GPT-3 的准确率仅约 20% 上下；即便引入思维链（Chain-of-Thought，CoT，Wei 等，2022），准确率提升到 50%–60% 区间，仍远未达到可靠。更严苛的 MATH 数据集（Hendrycks 等，2021）包含竞赛级题目，纯语言模型的准确率长期低于 10%。

值得注意的是，这些基准的评测方式本身也在演进。早期评测只比对最终答案，后来研究者发现模型可能"答案对、过程错"，于是引入过程验证。这从侧面说明：可靠性的度量必须包含可验证性，而可验证性恰恰是自然语言生成最欠缺的属性。

1.3 幻觉与"自信的错误"

更棘手的是，模型在算错时往往语气笃定，不附带任何不确定性标记。这与人类专家形成鲜明对比——人类在不确定时会说"我需要算一下"。这种"自信的错误"在数据分析和财务场景中危害极大，因为用户很难凭直觉判断一个数字是否可信。

核心矛盾：LLM 的输出空间是"所有可能的 token 序列"，而数学问题的解空间是"唯一正确的数值"。两者的交集需要外部机制来强制收敛。

二、工具增强推理：从 CoT 到 PAL 与 ReAct

2.1 思维链（CoT）：让推理"显式化"

CoT 的核心洞察是：如果让模型在给出答案前先写出中间步骤，准确率会显著提升。Wei 等（2022）的实验显示，在 GSM8K 上，CoT 提示相比标准提示可将准确率提升数倍。其原理可以理解为——把一次"跳跃式预测"分解为多次"小步预测"，每一步的错误概率更低，且中间步骤为后续 token 提供了更丰富的上下文。

笔者认为：CoT 是必要但不充分的。它让推理过程可见，却依然没有引入外部验证——模型仍可能"一本正经地推错"。CoT 解决的是"过程透明度"，而非"结果正确性"。

2.2 PAL：把计算外包给解释器

Program-Aided Language Models（PAL，Gao 等，2023）提出了一个关键转向：与其让模型"算出"答案，不如让模型"写出"能算出答案的程序，再交给 Python 解释器执行。PAL 在 GSM8K 上的表现优于纯 CoT，尤其在需要多步算术的题目上优势明显。

PAL 的哲学意义在于任务分解：LLM 负责"语义理解与形式化"（把自然语言转成代码），解释器负责"确定性执行"。两者各司其职，避开了 LLM 最不擅长的精确计算。本文评述：这是一种"能力互补"而非"能力替代"的设计思路，也是当前所有代码执行 Agent 的理论基石。

2.3 ReAct：推理与行动的交替循环

ReAct（Yao 等，2023）进一步把"推理"和"行动"编织成交替循环：Thought → Action → Observation → Thought……模型先思考需要做什么，再调用工具（搜索、计算器、代码执行），观察返回结果，然后继续推理。这种模式让模型能够根据执行反馈动态调整策略，而不是一次性生成全部内容。

ReAct 的工程价值在于容错：如果第一次生成的代码报错，Observation 会包含错误信息，模型可以据此修正。这构成了"生成—执行—观察—修正"的闭环，正是 ChatGPT 后台 Python 运行的核心逻辑。

三、代码执行沙箱的架构解剖

3.1 整体数据流

当用户在 ChatGPT 中上传一个 CSV 并问"帮我算一下各地区的销售增长率"时，后台大致经历以下流程：

1. 意图解析：LLM 判断这是数据处理任务，需要代码执行。
2. 代码生成：模型写出 pandas 脚本，读取文件、分组聚合、计算增长率。
3. 沙箱执行：代码被送入隔离的 Python 运行时，真实执行。
4. 结果回传：stdout、报错信息、生成的图表被送回模型上下文。
5. 自然语言总结：模型基于真实执行结果组织回答。

关键点在第 3 步：用户看到的数字来自解释器，而不是模型的"记忆"或"猜测"。这就是"真算数"与"猜结果"的分水岭。

3.2 隔离机制：为什么必须是沙箱

执行任意 LLM 生成的代码，本质上是"执行不可信输入"。如果直接在服务器主进程运行，模型可能（被诱导）写出删除文件、发起网络请求、读取敏感数据的代码。因此工业级实现必须包含：

• 进程隔离：每次会话独立容器，会话结束即销毁。
• 文件系统隔离：只挂载用户上传的临时目录，只读或受限写。
• 网络限制：默认禁止外联，防止数据外泄。
• 资源配额：CPU、内存、执行时长上限，防止死循环拖垮服务。
• 系统调用过滤：通过 seccomp 等机制限制危险 syscall。

本文评述：沙箱不是"可选项"而是"必需品"。开源方案如 E2B、Pyodide（浏览器内 WASM 执行）、Jupyter Kernel Gateway 都提供了不同权衡的实现路径。E2B 提供云端 Firecracker 微虚拟机，启动快、隔离强；Pyodide 把 CPython 编译到 WebAssembly，在浏览器内运行，零服务端风险但生态受限。

3.3 状态保持与多轮交互

真实分析任务往往需要多轮：先加载数据，再清洗，再建模，再画图。这意味着沙箱必须保持会话状态——变量、已导入的库、已生成的文件都要在轮次间存活。实现方式通常是维持一个常驻的 Python 内核（类似 Jupyter Kernel），每轮把新代码注入执行。

# 伪代码：会话级内核调度
class SessionKernel:
    def __init__(self):
        self.ns = {}          # 持久命名空间
        self.files = {}       # 会话文件
    def run(self, code: str):
        try:
            exec(code, self.ns)   # 真实执行
            return {"ok": True, "stdout": capture()}
        except Exception as e:
            return {"ok": False, "error": repr(e)}

这段伪代码揭示了本质：所谓"AI 会算数"，其实是 exec() 在算。模型的价值在于把"人类模糊需求"翻译成"可执行代码"，而非亲自完成运算。

四、工程落地：搭建一个可复现的代码执行 Agent

4.1 最小可行架构

下面给出一条从零搭建的路径，读者可据此复现一个"会跑代码"的分析助手。整体分为四层：模型层、编排层、执行层、存储层。

用户请求
   │
   ▼
[编排层] ReAct 循环 ──► [模型层] 生成代码/决策
   │                        │
   │◄──── Observation ──────┘
   ▼
[执行层] 沙箱 (Docker/E2B) ──► 结果/报错
   │
   ▼
[存储层] 会话文件 + 向量记忆

4.2 关键步骤与代码骨架

第一步是定义工具 schema，让模型知道"可以执行代码"。以 OpenAI 的 function calling 为例：

tools = [{
  "type": "function",
  "function": {
    "name": "run_python",
    "description": "在隔离沙箱中执行 Python 代码并返回 stdout",
    "parameters": {
      "type": "object",
      "properties": {
        "code": {"type": "string", "description": "要执行的 Python 代码"}
      },
      "required": ["code"]
    }
  }
}]

第二步是编排循环：模型若返回工具调用，就执行并把结果塞回对话，直到模型给出最终答复。第三步是错误自愈：把 traceback 原样回传，模型通常能在 1–2 轮内修正语法或逻辑错误。

笔者认为：错误自愈是代码执行 Agent 相比纯文本生成最被低估的能力。它把"一次性正确"的苛刻要求，转化为"允许试错、逐步收敛"的工程过程，显著降低了实际可用门槛。

4.3 提示词工程要点

• 明确告知模型"你有 Python 环境，遇到计算请写代码而非心算"。
• 要求先打印数据结构（df.head()、df.dtypes）再操作，减少盲写。
• 要求把中间结果 print 出来，便于观察与调试。
• 约定输出格式（如 JSON），便于下游解析。

可参考 OpenAI 官方 Cookbook 中关于代码执行的实践指南（cookbook.openai.com），以及 E2B 的官方文档（e2b.dev/docs）了解沙箱接入细节。

五、数据科学场景：Text-to-SQL 与自动分析

5.1 Text-to-SQL 的演进

把自然语言转成 SQL 是代码执行思想在数据库领域的映射。Spider 基准（Yu 等，2018）长期是衡量标准，早期模型准确率不足 30%，而随着 LLM 与执行反馈的引入，最新方法在 Spider 上的执行准确率已大幅提升。关键改进同样来自"执行验证"：生成 SQL 后在真实数据库上跑一遍，看是否报错、结果是否合理，再迭代修正。

BIRD 基准（Li 等，2023）进一步引入大规模真实数据库与外部知识，强调"脏数据"下的鲁棒性。本文评述：Text-to-SQL 与 Python 执行共享同一哲学——用可执行环境的反馈来约束生成，这是从"语言流畅"走向"事实正确"的通用路径。

5.2 自动数据分析 Agent

更进一步的形态是"给一个数据集，自动完成探索性分析并产出报告"。代表性工作包括：

• Data Interpreter（2024）：让 Agent 规划分析步骤并生成代码。
• AutoGen（Wu 等，2023）：多 Agent 协作，分析者与执行者分工。
• OpenAI Advanced Data Analysis：产品化的端到端方案。

这类系统的共同挑战是"长程规划"：分析任务往往需要十几步，中间任何一步出错都可能累积。工程上的应对是引入检查点与人工确认，在关键节点让用户介入。

六、安全、成本与可靠性权衡

6.1 安全边界

代码执行引入了全新的攻击面。提示注入（prompt injection）可能诱导模型生成恶意代码；上传文件中可能嵌入恶意指令。防御策略包括：输入净化、代码静态审查（禁止 os.system、subprocess、eval 等危险调用）、运行时监控、最小权限原则。

笔者认为：安全与能力在这里是此消彼长的。限制越严，能做的事越少；放得越开，风险越高。合理的做法是分级——个人本地环境可放宽，多租户云端必须严格隔离。

6.2 成本结构

代码执行 Agent 的成本由三部分构成：模型 token 消耗（多轮循环会放大）、沙箱运行资源、以及失败重试的额外开销。相比单次生成，ReAct 循环的 token 消耗可能增加数倍。优化方向包括：缓存常用代码片段、限制最大循环轮数、对小任务用更小的模型。

6.3 可靠性度量

评估这类系统不能只看"最终答案对不对"，还要看"过程是否可复现"。建议引入三项指标：执行成功率（代码能否跑通）、结果正确率（输出是否符合预期）、以及可复现率（同样输入能否稳定得到同样结果）。本文评述：可复现率是被严重忽视的指标，它直接决定了系统能否用于生产环境。

七、前沿预判与开放问题

7.1 从"调用工具"到"原生工具使用"

当前主流做法是"外挂"工具，模型通过文本协议调用。未来趋势是模型在训练阶段就内化工具使用能力，减少对提示工程的依赖。已有研究探索在预训练中混入代码执行轨迹，让模型更自然地"想到用代码"。

7.2 形式化验证的引入

代码执行保证了"算得对"，但不保证"算的是对的问题"。下一步是把形式化方法引入——用 SMT 求解器、类型系统、契约检查来验证代码语义是否真正满足用户意图。这可能是可靠性从"工程可用"迈向"关键任务可用"的关键一步。

7.3 多模态与端侧执行

随着 WebAssembly 与端侧模型成熟，代码执行可能下沉到用户设备，既降低延迟又保护隐私。Pyodide、WebContainers 等技术已展示可行性。本文评述：端侧执行与云端大模型的分工，可能成为下一阶段的重要架构选择。

八、结论与操作清单

ChatGPT 后台跑 Python 这件事，表面是产品功能，深层是一次范式转变：从"让模型记住一切"转向"让模型学会调用外部能力"。这条主线贯穿了 CoT、PAL、ReAct 到今天的各类 Agent 系统。

给读者的操作清单：

1. 遇到计算类需求，先问自己"这能不能写成代码"。
2. 搭建 Agent 时，优先实现"执行—观察—修正"闭环。
3. 沙箱隔离是底线，不要在生产环境直接 exec 模型输出。
4. 用执行成功率、正确率、可复现率三项指标评估系统。
5. 关注 E2B、Pyodide 等成熟方案，避免重复造轮子。

拓展阅读：OpenAI Cookbook（cookbook.openai.com）、LangChain 文档（python.langchain.com）、E2B 沙箱（e2b.dev）、以及 ReAct 论文官方仓库（github.com/ysymyth/ReAct）。

主要参考文献