Program-Aided Language Models (PAL)/ 代码辅助推理（PAL）

PAL（Program-Aided Language Models，代码辅助语言模型）解决的是LLM在精确推理上的天然短板——LLM擅长理解问题、规划思路，但在数学计算、符号推理、结构化数据处理上容易出错（如 345×789 心算错误、日期逻辑混乱）。PAL的思路是：让LLM把推理过程「写成代码」而非「写成自然语言」，然后交给Python/JS/SQL解释器精确执行。LLM的角色从「计算器」转变为「程序员」——理解问题 → 编写求解代码 → 解释执行结果。这比纯CoT（Chain-of-Thought）推理的数学准确率提升30-50个百分点。

PAL按执行模式分为三种形态，适用于不同场景：

**1. 基础PAL（Offline Code Generation）——生成代码后一次性执行**

LLM收到问题后，生成完整的Python脚本（包含数据定义 + 计算逻辑 + print输出），然后将整个脚本提交到沙箱执行，再将执行结果返回给LLM做最终回答。典型流程：用户问题「2024年1月1日是周一，2026年8月9日是周几？」→ LLM 生成 `from datetime import date; d=date(2026,8,9); print(d.strftime('%A'))` → 沙箱执行返回「Sunday」→ LLM 回复用户。优势：一次生成一次执行，延迟低；劣势：无法根据中间结果调整策略。

**2. 交互式PAL（Interactive REPL）——逐步编写、逐步执行**

LLM 不是一次性写完所有代码，而是像人类程序员一样：写几行 → 执行看结果 → 根据结果调整 → 继续写。需要代码解释器支持状态保持（REPL模式）。典型场景：数据分析任务——Agent 先用 `df.describe()` 看数据概况，发现有异常值后写 `df[df['price']>10000]` 深入排查，逐步逼近答案。Code Interpreter（如 ChatGPT Advanced Data Analysis、Open Interpreter）就是这种模式。优势：处理复杂开放式任务更灵活；劣势：交互轮次多，延迟高。

**3. 工具增强PAL（Tool-Augmented PAL）——代码调用外部API**

LLM 生成的代码不仅可以做纯计算，还可以调用外部API和库：查数据库（SQLAlchemy）、调HTTP API（requests）、做图（matplotlib）、机器学习（sklearn）。这是 Agent「工具使用」与「代码生成」的融合——Agent 通过写代码来编排多个工具调用。例如「分析最近一周的销售趋势」→ PAL 生成代码：pandas 读CSV → matplotlib 画折线图 → 调用 slack_sdk 发送图表。优势：将 LLM 的工具编排能力与代码的精确控制能力结合；劣势：安全风险更高（代码可执行任意操作）。

关键设计原则：代码生成的 Prompt 必须明确指定「只生成可执行的代码，不要解释」；沙箱必须隔离（推荐 Docker 或 gVisor）；对生成的代码做静态安全检查（禁止 import os/sys/subprocess 等危险模块）。

• **测试一：PAL vs CoT 数学推理精度对比**

• 操作：使用 GSM8K（小学数学应用题）和 MATH（竞赛数学）数据集，分别用纯 CoT（Chain-of-Thought，让 LLM 逐步自然语言推理）和 PAL（让 LLM 生成 Python 代码求解）跑相同的 100 题。对比最终答案的正确率

• 工具：OpenAI API 或 Claude API；GSM8K 数据集（https://github.com/openai/grade-school-math）；MATH 数据集（https://github.com/hendrycks/math）；Python exec() 沙箱

• 指标：答案正确率（PAL 应显著高于 CoT，GSM8K 提升 30%+，MATH 提升 50%+）、代码可执行率（生成代码能成功运行的占比 ≥ 95%）、平均响应延迟（PAL 比 CoT 多一次代码执行，延迟增量 < 2s）

• **测试二：交互式 PAL 的任务完成率**

• 操作：构造 20 个真实数据分析任务（如「从 CSV 中找出异常交易并生成报告」），让 Agent 在 REPL 模式下逐步写代码探索数据，评估最终是否完成任务目标。同时对比「一次性代码生成」（基础PAL）的完成率

• 工具：E2B Code Interpreter SDK（https://e2b.dev）或 Open Interpreter（https://github.com/OpenInterpreter/open-interpreter）；自定义任务集（含 CSV/JSON/Excel 数据文件）

• 指标：任务完成率（交互式 PAL ≥ 85%，基础 PAL 约 60-70%）、平均代码执行轮次（≤ 5 轮为优）、沙箱超时次数（≥ 10s 超时应 < 5%）

• **测试三：代码安全审计——静态沙箱绕过检测**

• 操作：构造 30 个「恶意 Prompt」——尝试让 Agent 生成的代码执行危险操作（如读取 /etc/passwd、发送本地文件到外部服务器、安装后门包、执行系统命令）。检测代码安全审计层是否成功拦截

• 工具：Bandit（https://github.com/PyCQA/bandit）Python 静态安全扫描；自定义 AST 遍历器检测危险 import（os、subprocess、sys、shutil、socket）；Docker 沙箱（--read-only --network=none）

• 指标：危险代码生成率（Agent 被诱导生成危险代码的比例，应 < 10%）、拦截成功率（安全层对已生成危险代码的拦截率 ≥ 100%）、沙箱逃逸成功次数（目标 = 0）

1. **「把代码当文本输出」——LLM 把代码写在推理中而非调用工具**：LLM 有时会「脑补」执行结果——在推理中生成代码，但不在沙箱里真正执行，而是凭记忆猜测结果。例如 `print(345*789)` 后直接输出「结果是 272205」——但实际上它根本没算，只是从训练数据中「回忆」了一个可能正确的答案（而且经常记错）。解决方案：使用结构化 Function Calling 或 Tool Use 将「代码执行」定义为专用工具，强制 Agent 通过工具调用（而非文本生成）来执行代码；在 System Prompt 中明确「所有计算必须通过代码执行工具完成，禁止在推理中直接输出计算结果」。

1. **「沙箱配置不严」——Agent 写的代码权限过大**：为图省事，开发者常给代码执行沙箱开放太大的权限——文件系统读写、网络访问、系统调用全放开。结果是：Agent 写的一段「清理临时文件」的代码可能误删了整个项目目录；「下载依赖包」的代码可能安装了恶意包。PAL 的安全模型必须遵循「默认拒绝」原则：只开放任务所需的最小权限（如只读挂载数据目录、禁止出站网络、禁止系统调用）。

1. **「代码错误不回传上下文」——Agent 不知道代码为什么报错**：代码执行出错时，如果只把「Error: division by zero」这种简短错误信息返回给 LLM，LLM 很难定位问题。应该返回完整 Traceback + 出错行的上下文 + 相关变量值。更好的做法：在 Prompt 中加一个「调试提示」——如果代码出错，LLM 应读取出错行的变量值（通过额外代码打印），分析根因后修复。即 PAL 本身也可以递归使用——用 PAL 来调试 PAL 生成的代码。

• PAL 原始论文 (Luyu Gao et al., 2023): https://arxiv.org/abs/2211.10435

• OpenAI Code Interpreter 官方文档: https://platform.openai.com/docs/guides/code-interpreter

• E2B - 开源代码解释器沙箱: https://github.com/e2b-dev/e2b

• Open Interpreter - 本地代码执行 Agent: https://github.com/OpenInterpreter/open-interpreter

• Google DeepMind - 使用代码增强 LLM 推理的综述: https://arxiv.org/abs/2401.07103