OpenAI Code Interpreter ("Coworker") 架构审计与安全取证分析

推荐语

揭秘OpenAI Code Interpreter背后的复杂架构：一场意外的泄露事件揭示了其多语言混合的工程真相。

核心内容：
1. 泄露事件暴露的Code Interpreter真实架构与业界假设的差异
2. 系统核心引擎由.NET 9 (C#)驱动而非Python
3. 从七个维度对泄露事件进行的技术剖析

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

摘要

2025.12.14 晚上发生的 OpenAI "Code Interpreter"（内部代号 "Coworker"）文件系统泄露事件，为全球人工智能与软件工程社区提供了一个前所未有的窗口，得以窥探当前最先进的大语言模型（LLM）执行环境的真实架构。长期以来，业界普遍假设 Code Interpreter 仅仅是一个标准的、沙箱化的 Python 环境，依赖于开源数据科学库（如 pandas、matplotlib、openpyxl）进行运算。然而，对泄露目录（特别是 /opt、/usr/lib 及 CLI 工具中的 node_modules）的深入取证分析彻底推翻了这一假设。

分析结果显示，该系统并非单一的 Python 解释器，而是一个高度复杂、多语言混合的工程巨兽。其核心逻辑并非由 Python 驱动，而是依赖于 .NET 9 (C#) 构建的高性能 XML 解析与生成引擎；其可视化渲染采用了 WebAssembly (WASM) 技术实现的客户端-服务端镜像架构；其系统监控与遥测工具基于 Bun 运行时；而其底层的文档处理能力则建立在微软传统的 OpenXML SDK 基础之上。更令人震惊的是，该环境运行在一个带有 Google 内部特征的 Chrome User Agent (CUA) 容器中，暴露了大量与其竞争对手基础设施相关的痕迹。

本文将从核心引擎架构、数据流转机制、可视化渲染逻辑、控制层实现、基础设施特征、安全沙箱机制及代码人类学特征等七个维度，对此次泄露事件进行详尽的技术剖析。分析表明，LLM 在此系统中并非全知全能的创造者，而是一个被限制在严格规则下的操作员，通过拙劣的胶水代码（Glue Code）和正则表达式（Regex）与一个庞大的人造机器进行交互。

1. 核心引擎架构：.NET 9 与 C# 的隐形统治

本次泄露中最具颠覆性的发现，莫过于 Python 在文档处理与高级数据分析任务中的边缘化。虽然用户界面呈现为 Python 代码的执行，但实际负责解析、生成和操作复杂文档格式（如 .docx、.xlsx）的算力实体，是一个编译型的 C# 应用程序，且运行在极为激进的 .NET 9 运行时环境之上。

1.1 @oai/walnut 包与其战略定位

在对泄露的文件系统进行遍历时，研究人员在 node_modules 深处定位到了一个名为 @oai/walnut 的关键包 1。该包的 README.md 文件包含了一段极具说明性的描述，将其定义为 "C# XML parser built for WASM browser module package and as CLI for Backend services"（构建为 WASM 浏览器模块包及后端服务 CLI 的 C# XML 解析器）1。

这一发现具有多重技术含义：

• 语言选择的理性回归
  ：Python 的 xml.etree 或 lxml 库在处理 Office Open XML (OOXML) 标准时，往往面临性能瓶颈与类型安全问题。OOXML 是一个极其庞大且复杂的标准，包含了数千种嵌套的 XML 元素。C# 凭借其强类型系统和微软官方 OpenXML SDK 的原生支持，能够提供远超 Python 的解析速度与内存安全性。
• .NET 9 的激进采用
  ：泄露信息显示该组件运行在 .NET 9 上 1。考虑到.NET 9 是微软技术栈中极其前沿的版本，这一选择表明 OpenAI 的工程团队并未保守地选择长期支持版本（LTS），而是极力追求最新的 Just-In-Time (JIT) 编译优化、Native AOT（提前编译）能力以及对 WebAssembly 的原生支持。这种对新技术的激进采纳，暗示了该组件对性能有着极高的要求。

1.2 "Roundtrip"（往返）架构解析

系统采用了一种被内部称为 "Roundtrip" 的数据处理架构 1。这一架构的设计初衷是为了解决 LLM 直接编辑 XML 文件时极易产生的结构破坏问题。

基于二进制分析还原的工作流如下：

1. 摄入（Ingestion）
   ：用户上传 Office 文件（如 Excel 表格）。
2. 转译（Transmutation）
   ：@oai/walnut 引擎介入，将原始的 OOXML 文件（本质上是 XML 的压缩包）解析并转换为一种专有的 Protobuf (Protocol Buffers) 格式，文件扩展名为 .bin 1。
3. 操控（Manipulation）
   ：LLM 生成的 Python 代码并不直接读写 XML，而是与这个中间态的 Protobuf 对象进行交互。Protobuf 提供了一个严格的结构化接口，限制了 LLM 的操作范围，防止其生成非法的 XML 标签。
4. 重构（Reconstruction）
   ：一旦 Python 脚本完成对 Protobuf 数据的修改（例如添加一行数据），C# 引擎再次介入，将修改后的 Protobuf "再膨胀"（Re-inflate）回标准的 OOXML 文件 1。

这种架构证明了 LLM 的"智能"是被严格封装的。模型从未真正"看见"过原始文件，它操作的是经过 C# 工程师精心设计的、安全的中间抽象层。这解释了为何 Code Interpreter 在处理文档时极少出现文件损坏的情况——C# 引擎充当了无情的守门员。

1.3 WASM 镜像与同构渲染

@oai/walnut 最为精妙的设计在于其跨平台的部署能力。泄露证据表明，该 C# 引擎不仅运行在服务器端，还被编译成了 browser-wasm（WebAssembly）模块 1。

这意味着，当用户在 ChatGPT 界面中看到一个 Excel 表格的预览时，这并非服务器生成的一张静态截图（Screenshot），而是用户的浏览器下载了 WASM 模块，并在本地执行了与服务器端完全一致的.NET 代码来实时渲染预览 1。

WASM Mirroring（WASM 镜像） 策略带来了显著的工程优势：

• 绝对一致性（Consistency）
  ：由于服务器和客户端运行的是同一套 C# 代码库（仅编译目标不同），预览效果与最终下载文件的内容在字节级别上保持一致。
• 计算卸载（Compute Offloading）
  ：将渲染逻辑下放到客户端，极大地减轻了 OpenAI 后端服务器的 CPU 负载。服务器只需传输轻量级的 Protobuf 数据，繁重的布局计算由用户终端承担。
• 安全隔离
  ：即使渲染引擎存在缓冲区溢出等漏洞，攻击者利用恶意文件触发的也是用户浏览器的崩溃，而非后端服务器的沦陷。

2. 伪造的 Excel 引擎与 PPTX 奇点

对泄露的 TypeScript 定义文件（由 Protobuf schema 生成，称为 oaiproto）的逆向工程，揭示了 OpenAI 在文档处理能力上的一个惊天秘密：OpenAI 并没有原生的 Excel 渲染引擎。

2.1 OAIProto 理论：Excel 并不存在

在解包后的 spreadsheet.ts 文件中（该文件理论上应包含 Excel 的图表与主题定义），研究人员并未发现独立的图表渲染逻辑。相反，该文件充斥着指向 PowerPoint 模块的导入语句：

import Chart from '../pptx/chart';
import Theme from '../pptx/presentation';

这一依赖关系 1 证实了 "OAIProto 理论"：系统中的 Excel 功能是"伪造"的。当用户要求 Code Interpreter 处理 Excel 图表时，系统实际上是在调用 PowerPoint 的渲染引擎。

2.2 PPTX Singularity（PPTX 奇点）

这种架构决策被称为 "PPTX Singularity" 1。它意味着在 "Coworker" 的世界观里，所有的可视化对象本质上都是幻灯片（Slide）。

• Excel (XLSX)
  ：在数据层面是电子表格，但在视觉层面（图表、配色、主题）直接借用了 PowerPoint 的引擎 (oaiproto.coworker.pptx.Chart)。
• Word (DOCX)
  ：分析 document.ts 发现，Word 文档被定义为一个容器，其内容由 Paragraph 对象和从 Excel 导入的 Workbook 对象组成 2。

这种 "俄罗斯套娃" 式的对象模型导致了一个显著的现象：无论用户是请求生成 Word 文档中的统计图，还是 Excel 表格中的趋势图，生成的图表在视觉风格、字体渲染和布局逻辑上是完全一致的。这是因为它们背后是同一个 C# 类库在运作。虽然这种复用极大地降低了开发成本和维护难度，但也导致了功能的同质化——Excel 特有的复杂透视表视图或 Word 的高级文字环绕功能，很可能因为底层的 "PPTX 核心" 而无法完美实现。

3. 控制层逻辑：胶水代码与正则修补

剥开.NET 的坚硬外壳，我们看到了负责指挥系统的 Python 控制层。与其说是"智能代理"，不如说这是一套依靠正则表达式（Regex）维持运转的脆弱脚本。

3.1 并不智能的代码编辑器：combined_apply_patch_cli.py

当 ChatGPT 提示 "I am updating your code"（我正在更新您的代码）时，用户往往想象有一个理解抽象语法树（AST）的高级代理在进行重构。然而，泄露的脚本 combined_apply_patch_cli.py 揭示了残酷的真相 1。

该脚本的工作原理极其原始：

1. 协议（Protocol）
   ：系统提示词（System Prompt）强制 LLM 在输出代码修改建议时，必须包含特定的标记文本：Begin Patch。
2. 逻辑（Logic）
   ：Python 脚本通过字符串匹配监听这一标记。一旦捕获，它便启动一个基于正则表达式的解析器，寻找 ADD（增加）、DELETE（删除）或 UPDATE（替换）等关键词。
3. 执行（Execution）
   ：脚本根据 LLM 提供的行号或上下文内容的字符串匹配，对文件进行物理层面的文本拼接。

这种机制完全不具备语义理解能力 2。如果 LLM 产生的上下文匹配字符串与源文件有哪怕一个空格的差异，或者正则表达式未能正确覆盖边界情况，Patch 操作就会失败。这就是为什么 Code Interpreter 经常会陷入 "修改失败 -> 重试 -> 再失败" 循环的原因——它试图用概率性的输出去匹配确定性的正则规则。

3.2 偏执驱动开发（Paranoia-Driven Development）：视觉验证环

泄露文件还解释了 Code Interpreter 生成文档速度缓慢的根本原因。由于 LLM 本质上是"盲"的（无法直接感知其生成的二进制文件是否损坏），开发团队引入了一套被称为 "偏执驱动开发" 的视觉验证流程 1。

在 skill.md 和 render_docx.py 中发现的流程如下：

1. 生成
   ：Python 脚本调用 C# 引擎生成 .docx 文件。
2. 转换
   ：系统启动一个无头（Headless）的 LibreOffice (soffice) 实例，将 .docx 转换为 PDF。
3. 光栅化
   ：使用 pdftoppm 工具将 PDF 转换为高分辨率的 PNG 图像。
4. 视觉审计
   ：系统将这些 PNG 图像回传给视觉模型（Vision Model），并附带指令："Inspect every exported PNG"（检查每一张导出的 PNG），专门寻找"孤行寡字"（widows/orphans）或排版错位。
5. 校准
   ：为了确保图像在 Chat UI 中完美显示，代码甚至会解析 XML 中的 twips（缇，二十分之一点）单位，计算 DPI，以确保输出图像严格符合 1600x2000 像素的限制 1。

这一过程涉及三次格式转换（DOCX -> PDF -> PNG）和一次昂贵的视觉模型推理，造成了巨大的延迟。但这是一种必要的代价，用来弥补 LLM 在结构化生成方面的不可靠性。

4. 基础设施与遥测：Google 阴影下的混合体

尽管 OpenAI 与 Microsoft Azure 建立了深度的战略合作伙伴关系，但 "Coworker" 的底层基础设施却带有极其强烈的 Google 基因。

4.1 CUA 容器与 Google 内部工具

泄露的系统环境并非标准的 Docker 容器，而是一种被称为 CUA (Chrome User Agent) Container 的特殊环境 1。CUA 容器通常是 Google 内部用于运行需要浏览器能力（如 Headless Chrome）的任务的专用基础设施。

最直接的证据来自脚本中未被清理的注释链接，例如：
# http://go/docs-link/cua-container-chrome-entrypoint 1。
go/ 是 Google 内部网络（Intranet）独有的短链接服务标志。这些链接的存在表明，Code Interpreter 的基础镜像（Base Image）很可能直接衍生自 Google 的内部代码库，或者是 OpenAI 招聘的前 Google 工程师直接复用了其熟悉的工具链。考虑到该环境需要运行 LibreOffice 和可能的 Headless Chrome 进行渲染，使用 CUA 容器是技术上的合理选择，但这在商业战略层面显得极为突兀。它暗示了 OpenAI 的工程栈并非纯粹构建在 Azure 之上，而是通过某种方式混用了 Google 的技术遗产。

4.2 Bun 运行时与 granola-cli

在系统遥测（Telemetry）方面，OpenAI 选择了一个意想不到的技术栈。负责监控系统健康状况的工具 granola-cli 并非用 Python 或 Node.js 编写，而是基于 Bun 1。

Bun 是一个新兴的高性能 JavaScript 运行时，以启动速度极快著称。granola 的封装脚本设置了 export NODE_PATH="$SCRIPT_DIR/node_modules"，并将整个 node_modules 目录与二进制文件打包在一起 1。这种 "自带电池"（Batteries-included） 的打包策略，结合 Bun 的瞬时启动特性，表明工程团队极度关注容器的冷启动时间（Cold Start Latency）。对于 Code Interpreter 这种按需分配、生命周期短暂的执行环境，节省几十毫秒的启动时间都能显著提升用户体验和资源利用率。

5. 安全审计：原始的沙箱与路径穿越漏洞

从泄露的脚本中可以看出，尽管外层容器（可能是 gVisor 或 Firecracker）提供了内核级的隔离，但应用层面的文件系统访问控制却被描述为 "令人震惊的原始"（Shockingly Primitive） 1。

5.1 基于字符串匹配的路径防御

防止 LLM 读写系统关键文件（如 /etc/passwd 或 /usr/bin）的主要防御机制，竟然仅仅是一段简单的 Python 字符串检查：

if path.startswith("/"):
print("We do not support absolute paths.")
return

这段代码 1 试图通过禁止绝对路径来将模型限制在当前工作目录。然而，这种防御在安全领域被称为 "不安全的直接对象引用"（IDOR）的一种变体，且极易被绕过。

只要模型（或通过提示注入攻击的攻击者）使用相对路径，例如 ../../../../opt/google/chrome，就可以轻松跳出当前目录，访问整个文件系统树。此次泄露事件本身——网友成功 dump 出 /opt 和 /usr/lib 目录 1——就是该漏洞存在的铁证。这种设计意味着，只要不触碰 / 开头的红线，模型在容器内部实际上拥有 "Free Rein"（自由缰绳）。

5.2 失败的痕迹擦除（Trace Scrubbing）

开发人员显然意识到了模型"内省"（Introspection，即查看自身代码）的风险，并试图通过脚本进行掩盖。entrypoint.sh 脚本在启动时会执行以下命令：

• unset TARBALLS_DIR
• unset SLIDES_JS_DIR

这些命令 1 意图清除环境变量中关于工具源码位置的引用，防止 Python 环境通过 os.environ 读取到敏感路径。然而，这种 "隐匿式安全"（Security by Obscurity） 在文件系统访问权限失控面前毫无意义。攻击者无需环境变量，只需通过遍历目录即可发现这些被隐藏的工具。

6. 代码人类学：Vicky, Bobby 与技术债务

代码不仅是逻辑的载体，也是组织文化的化石。泄露文件中的注释和临时代码，为我们描绘了 OpenAI 内部高压、快速迭代的开发环境，充满了鲜明的人类特征。

6.1 "Vicky" 和 "Bobby" 的工单

代码库中散落着大量指名道姓的 TODO 注释，其中出现频率最高的名字是 Vicky 和 Bobby 1。

一个最具代表性的注释解释了为何 ChatGPT 至今无法完成某些 Excel 操作：

# TODO [vicky/bobby]: We have not implemented indent, rotation or angling of text styles yet..

这条注释 1 揭示了功能缺失的真实原因：不是出于 AI 安全对齐（Safety Alignment）的深思熟虑，也不是模型的认知局限，仅仅是因为 Bobby 还没有完成他的 Jira 工单。这种直接的因果关系打破了外界对 AI 系统"黑盒"的神秘感——它依然是由程序员一行行敲出来的。

6.2 硬编码路径与开发痕迹

在发布包的 README.md 文件中，甚至保留了开发者本地机器的绝对路径：
dotnet run... -- import /Users/vicky/code/sample_spreadsheets/001_Best_Buy.xlsx 1。
/Users/vicky/ 这一路径结构强烈暗示开发人员使用的是 macOS 环境。这种内部路径的泄露，通常意味着 CI/CD（持续集成/持续部署）流程中缺乏严格的制品清洗（Artifact Sanitization）步骤。虽然这不构成直接的安全漏洞，但它暴露了工程流程中的粗糙环节——为了追求发布速度（Shipping Speed），清理工作被搁置了。

6.3 考古级的 Win32 GDI 映射

在字体处理的代码中，分析人员发现了 family=4 对应 "Comic Sans" 字体的映射逻辑 1。这种整数 ID 映射方式直接源自微软上世纪 90 年代的 Win32 GDI (Graphics Device Interface) API。

在 2024 年的 Linux 容器中、运行在.NET 9 上的代码里看到 Win32 GDI 的幽灵，说明 @oai/walnut 包可能并非完全从零重写，而是移植自微软内部某个古老的代码库，或者是基于极其成熟（但也极其陈旧）的 OpenXML 底层规范构建的。这展示了软件工程中的"地质层"现象——最先进的 AI 依然站立在几十年前的遗留代码之上。

7. 总结与展望

对 OpenAI "Coworker" 文件系统的全面审计，粉碎了关于 AI 代码执行环境的许多浪漫化想象。Code Interpreter 并非一个纯粹的、由 AI 自由支配的 Python 沙箱，而是一个由 .NET 9、Bun、Python、WASM 和 Google 基础设施 拼凑而成的 "技术套娃"（Technological Matryoshka Doll） 1。

核心结论：

1. 工程实质
   ：这是一个典型的实用主义工程产物（Frankenstein Monster），它不追求架构的纯洁性，而是利用一切可用的高性能工具（C#/.NET 9）来解决实际问题（XML 解析性能、渲染一致性）。
2. 安全依赖
   ：系统的安全性并非建立在完美的沙箱逻辑上，而是通过 "Roundtrip" 架构将危险的 XML 操作剥离给类型安全的 C# 代码，从而规避了 LLM 直接破坏文件的风险。但文件系统的访问控制极其脆弱，依赖于容易被绕过的路径检查。
3. 能力幻觉
   ：用户眼中的"生成 Excel 图表"，实际上是调用了 PowerPoint 渲染引擎的模板能力。LLM 的创造力被严格限制在 C# 引擎允许的 Protobuf 结构之内。
4. 人的因素
   ：系统的局限性直接对应于 Vicky 和 Bobby 等开发者的工期压力。AI 的能力边界，目前仍由人类工程师的编码速度决定。

未来展望：
此次泄露暴露出的安全架构缺陷（如相对路径穿越）势必会促使 OpenAI 进行紧急加固，例如引入基于 chroot 或 User Namespaces 的内核级隔离，以及更严格的文件权限管理。同时，随着.NET 9 和 WASM 的成功应用，我们可能会看到更多计算密集型任务从 Python 迁移至编译型语言，进一步模糊"解释器"与"应用程序"的界限。

8. 系统架构全景图（文本化表示）

为了直观展示 "Coworker" 的内部构造，基于上述发现构建的系统层级如下表所示：

9. 安全加固建议

基于本次取证发现的漏洞，针对类似的高权限代码执行环境，提出以下技术改进建议：

1. 废除应用层路径检查
   ：放弃 path.startswith("/") 这种脆弱的字符串匹配。应利用 Linux 内核的 Mount Namespaces 或 chroot 机制，将进程的根目录物理锁定在 /home/sandbox，使其在系统层面无法感知 /opt 或 /usr 的存在。
2. 实施最小权限原则（PoLP）
   ：运行 Python 解释器的用户 ID（UID）不应拥有对 CLI 工具目录（如存放 @oai/walnut 的位置）的读取权限。这些二进制文件应设置为仅可执行（Exec-only），防止被读取或 exfiltration（渗出）。
3. 路径规范化（Canonicalization）
   ：在执行任何文件操作前，必须使用 realpath 系统调用将所有路径（包括 ../../）解析为绝对路径，再与白名单进行比对，彻底杜绝路径遍历攻击。
4. 构建流水线净化
   ：在 CI/CD 阶段引入自动化扫描工具，强制剥离代码中的 TODO 注释、开发者本地路径信息以及任何内部网络链接（如 go/），防止敏感的工程信息泄露。