AI 编程 on Codexer

沙箱不是银弹：7 种方式让 AI 编程助手从「信任的文件」中逃逸

Tue, 21 Jul 2026 09:00:00 +0800

上周我们讨论了 GPT-5.6 Sol 因为一个没设置的 sandbox flag，在 72 小时内误删了多个开发者的文件和数据库。那条推文获得了 550 万次浏览，整个技术圈都在讨论「AI Agent 该不该有文件系统访问权限」。

如果你以为给 Agent 套上沙箱就万事大吉了，这篇文章可能会让你重新坐直。

Pillar Security 的安全研究团队花了几个月时间，在 Cursor、OpenAI Codex、Google Gemini CLI 和 Antigravity 这四款最流行的 AI 编程助手中，找到了 7 种沙箱逃逸方法。他们没有攻击沙箱本身，甚至没有尝试绕过任何安全边界。他们只是让 Agent 写了一个文件，然后静静地等着宿主系统上的可信工具自己去执行它。

这 7 个发现被整理成一个系列，叫做「沙箱逃逸周」（Week of Sandbox Escapes），每天揭露一种新的攻击面。

问题的本质：文件不是惰性的

所有 AI 编程助手的沙箱都画了一条看似清晰的线：Agent 在项目工作区内是可信的，宿主系统在外部是受保护的。这条线的逻辑是，「Agent 不能直接运行系统命令，所以它无法危害宿主」。

但 Pillar 团队揭露了一个被忽视的事实：工作区内的文件不是惰性的。

你的 IDE 和 CLI 工具无时无刻不在沙箱外运行自己的组件：Python 扩展在解析解释器路径，Git 集成在扫描仓库元数据，VS Code 在执行任务配置文件，hook 引擎在触发命令钩子，Docker Desktop 在暴露本地 socket。这些东西都是可信的，它们在沙箱外运行，而且它们会读取工作区里的文件。

一个被沙箱约束的 Agent 可以完全遵守所有规则，同时精确地塑造那些被宿主组件读取的文件内容。攻击触发点呢？Prompt Injection，一段恶意指令藏在 README、Issue、依赖描述或 diff 里，它自己不会执行任何命令，但它会让 Agent 写下一个文件，这个文件随后被沙箱外的可信工具加载、解析或运行。逃逸就这样发生了，Agent 全程没出过沙箱。

Pillar 将这 7 个发现归纳为四种失败模式，每一种都值得开发者认真对待。

Codex 模型三天后退役，你的代码还在硬编码模型名吗？

Mon, 20 Jul 2026 09:00:00 +0800

上周六的下午，我喝了一杯完全不享受的咖啡，用 git bisect 逐帧回放，才定位到一个诡异的生产事故：工具调用参数突然变了，但代码一行没改。

凶手是一个 -latest 别名。OpenAI 静默地把它指向了一个新快照，新快照的工具调用行为有一处微妙差异，我的解析器立刻崩了。一个本该轻松度过的周六，被一个浮动别名吃掉了。

从那以后，我所有东西都指向带日期的固定快照。gpt-5-codex 就是其中之一。

然后，上周我花了十五分钟认真读了一遍 OpenAI 的模型废弃页面，而不是像往常一样扫一眼就关掉。然后我看到了它：gpt-5-codex，退役日期 2026 年 7 月 23 日，安静地躺在另外十个模型旁边。

今天已经是 7 月 20 日。三天。

如果你像我一样锁定了下面这些快照，这篇文章就是给你的预警。以下是完整的退役清单、如何用大约十分钟排查暴露面、每个模型该迁移到哪里、该回归测试什么，以及最重要的一件事：那次让我把「被迫迁移」从恐惧变成无聊的结构性改动。

退役清单（2026-07-23）

以下内容直接来自 OpenAI 的 API 废弃页面，我在写作时逐行核对过。行动前也请你自己再看一遍，因为日期和替换方案可能会修订。

退役模型	OpenAI 建议替换
`gpt-5-codex`	`gpt-5.5`
`gpt-5.1-codex`	`gpt-5.5`
`gpt-5.1-codex-max`	`gpt-5.5`
`gpt-5.1-codex-mini`	`gpt-5.4-mini`
`gpt-5.2-codex`	`gpt-5.5`
`gpt-5-chat-latest`	`gpt-5.5`
`gpt-5.1-chat-latest`	`gpt-5.5`
`gpt-4o-search-preview-2025-03-11`	`gpt-5.4-mini`
`gpt-4o-mini-search-preview-2025-03-11`	`gpt-5.4-mini`
`gpt-4o-mini-tts-2025-03-20`	`gpt-4o-mini-tts-2025-12-15`
`computer-use-preview-2025-03-11`	`computer-use-preview`（或 `gpt-5.4-mini`）

看清楚规律就好办了。*-codex 几乎全线收束到 gpt-5.5，只有 gpt-5.1-codex-mini 降级到了 gpt-5.4-mini。*-chat-latest 别名也折叠到 gpt-5.5。两个 *-search-preview 快照都指向 gpt-5.4-mini。TTS 和 Computer Use 只是滚动到更新的快照。看清楚这几个桶，迁移就没表格看起来那么吓人。

Codex 删光了你的文件？问题不在模型，在一个你没设置的 Flag

Sun, 19 Jul 2026 09:00:00 +0800

2026 年 7 月 9 日，OpenAI 发布了 GPT-5.6 Sol，三个模型层级、全新的推理引擎、多 Agent 协作能力。技术圈一片沸腾，仿佛一个新时代已经到来。

72 小时后，科技投资人 Matt Shumer 发了一条推文，获得了 550 万次浏览和 6000 个赞。内容很短：「GPT-5.6 Sol 刚刚几乎删掉了我 Mac 上的所有文件。」

他不是唯一一个。开发者 Bruno Lemos 说 Sol 清空了他的生产数据库。Joey Kudish 丢失了大批他从未让 Agent 接触过的文件。这些事故有一个完全相同的模式：Agent 在无沙箱保护的完全访问模式下运行，它尝试覆盖 $HOME 环境变量来创建一个临时目录，而环境变量展开失败了，一个本该清理临时文件的指令，变成了对用户真实主目录执行 rm -rf。

这不是一个关于模型「变坏」的故事。这是一个关于默认配置的故事，一个默认配置让模型的一次无心之过，变成了一场灾难。

复盘：「一次诚实的错误」

事件发生一周后，OpenAI Codex 团队的 Tibo Sottiaux 发布了事故复盘，该推文获得了 110 万次浏览和 8400 个赞。事故链条如下：

完全访问模式开启：用户使用了 --sandbox danger-full-access 参数运行 Codex，禁用了所有文件系统限制
自动审查未开启：没有二级模型来检查 Agent 提出的命令再执行
$HOME 覆盖尝试：模型尝试将 $HOME 设置为临时目录以实现工作区隔离
环境变量展开失败：变量解析出错，Agent 的清理命令瞄准了真实的主目录而非临时文件夹

OpenAI 把这称为「一次诚实的错误」。正如 The Register 的报道标题所述：模型并非恶意，只是搞错了，而没有任何机制阻止它执行这个错误。

告别 Vibe Coding：用语义合约重建 AI 代码的信任链条

Sat, 18 Jul 2026 09:00:00 +0800

你用 Codex 或 Claude Code 让 AI 帮你写了一个复杂的支付模块。代码看起来没啥问题，测试也通过了，你就放心地合并了。两周后，一个边缘 case 触发了隐秘的 bug，导致部分用户的余额被重复扣除。你翻回去看那次对话记录，试图搞清楚 AI 当时到底是怎么想的，但聊天日志里只有一段模糊的描述和几轮来回修改。

这不是什么虚构的场景，这是每个深度使用 AI 编程工具的开发者都在面对的现实。

AI 编程的信任危机

过去一年里，「Vibe Coding」席卷了整个开发者社区。你不需要深入理解每一行代码，你只需要描述你想要什么，AI 就会吐出能跑的代码。效率提升是真实存在的，Codex 和 ChatGPT Work 的日活用户从 600 万跳到 700 万只用了 24 小时，这个数字本身就说明了一切。

但效率提升的背后，我们丢掉了一个至关重要的东西：对代码的信任。

在 AI 时代之前的软件工程流程是这样的：需求 → 架构设计 → 详细设计 → 编码 → 测试 → 代码审查 → 部署。每一步都有明确的输入、输出和人类负责人。我们信任软件，是因为我们信任这个流程。即使不能数学上 100% 证明代码没有 bug，我们也确信它经过了多层人工审查和自动化测试。

到了 AI 时代，这个流水线被压扁了。你输入一个 prompt，AI 直接输出可运行代码，中间环节全部消失。虽然我们试图用 prompt engineering 和自动化测试来追赶，但从用户提示到最终代码的路径依然是一个黑箱。

问题具体表现在四个方面：

第一，AI 行为不可预测。 代码来自千亿参数的神经网络，我们无法完全理解或预测。完全相同的 prompt 可能产生底层完全不同的代码。

第二，bug 难以溯源。 AI 代码出问题时，你很难把故障追溯到某个具体的设计缺陷或逻辑错误。你不知道是 prompt 的问题、模型的问题、还是上下文的问题。

给你的 AI 编程助手装一个「智能调度员」：Weave Router 深度解析

Sat, 27 Jun 2026 09:00:00 +0800

一个让你肉疼的场景

凌晨两点，你刚让 Codex 帮你修了一个小小的拼写错误。它用了 GPT-5.5。成本：$0.38。

上午十点，你让 Claude Code 帮你检查一下代码风格。它用了 Opus 4.8。成本：$0.52。

下午三点，Cursor 帮你补全了一行 import 语句。它可能也调了顶级模型。成本：你不确定，但你隐约觉得不对劲。

这些场景每天都在数以万计的开发者电脑上发生。AI 编程助手让我们效率翻倍，但也让 API 账单悄悄膨胀。问题出在哪？你只用一把「牛刀」杀了所有的「鸡」。

细看一个典型的 AI 编程会话：有时你在描述复杂架构，有时你只是让它重命名一个变量。这两种场景对模型能力的要求天差地别，但你为它们付了同样的费用。

答案：给 API 请求加一个「调度层」

这个问题的解法很直观：不同难度的任务，用不同级别的模型。 但这说来容易做起来难。谁来判定？怎么判定？手动切换模型吗？一天切换几十次？

六月底，Hacker News 上一个项目悄然走红，收获了 140 个推荐和 88 条讨论。它就是 Weave Router，一个为 AI 编程助手量身打造的智能模型路由器。

Weave Router 的核心理念非常简洁：它像一个透明的代理，插在你的编程助手和 AI 服务商之间。每个 API 请求经过它时，它会实时判断这个请求该交给哪个模型处理，然后帮你做出最优选择，全程你不需要做任何事。

它是怎么判断「该用哪个模型」的？

这可不是简单的「检查关键词」或「启发式规则」。Weave Router 用的是强化学习。

背后的逻辑是这样的：Weave 团队收集了上万个真实编程场景的 Agent 执行轨迹（traces），包括请求内容、最终任务是否成功完成、用了多少 Token 等。他们以此训练了一个路由模型，奖励机制很简单：选对了模型，任务成功完成，加分；选了过强或过弱的模型导致浪费或失败，扣分。

训练完成后，这个路由模型能够在接收到新请求时，快速判断出用哪个模型最合适。具体来说：

当你描述一个复杂架构变更，它会把请求路由到 Opus 4.8 或 GPT-5.5，因为你确实需要顶级的推理能力；
当 Codex 派生出的子 Agent 去浏览代码库收集上下文，它会用 DeepSeek V4 Flash 这样的快速模型；
当你拿到计划开始具体实现，它会切换到 GLM 5.2 这类性价比更高的模型。

这不是凭感觉切换，而是基于成千上万个真实案例训练出来的决策。决策依据来自请求内容的语义特征，而非关键词匹配或硬编码规则。

AI 编程助手的五个 Token 黑洞，以及如何堵上它们

Fri, 26 Jun 2026 09:00:00 +0800

你正在让 AI 编程助手处理一个真实的 bug。它已经理解了整个仓库的结构，面前是一个失败的测试用例，下一轮对话就能给出修复方案。突然，它停了。没有错误提示，没有预警，只有一个冰冷的提示框：使用额度已耗尽。

最让人沮丧的不是任务没完成，而是烧掉 Token 限额的，大概率不是你真正需要的工作内容。真凶往往是重复的上下文、丢失的缓存、臃肿的工具定义、过度强大的模型，以及持续膨胀的对话历史。

大多数 Token 浪费是机械性的，而不是智力性的。要堵上这些漏洞，首先得理解上下文是怎么被发送、缓存、重复和计费的。

脑内模型：每次对话都是一次「重新认识」

很多人下意识地以为 AI 编程助手在连续对话时，会像人类一样「记住」之前的交流。事实恰恰相反。

每一次你发送消息，助手都会把一整套上下文重新打包发给模型：系统指令、工具定义、历史对话、文件片段、工具执行结果，以及它认为有帮助的任何信息。模型并不会从一个「私人记忆」里延续上一轮的状态，它需要重新读一遍整个 prompt。

所以真正的消耗公式不是「我让它做了多少事」，而是：

每轮 Token 消耗 × 回合数

浪费，就发生在这个乘积和实际工作需要之间的落差里。下面是我观察到的五个最显著的泄漏点。

漏洞一：Prompt 缓存频频失效

Prompt 缓存是所有优化手段中杠杆效应最高的。道理很简单：编码助手的对话里充满了重复内容，系统 prompt、工具定义、代码摘要、历史消息，这些东西从前一轮到后一轮几乎不变。

主流模型提供商都对重复的 prompt 前缀提供大幅折扣。Claude Opus 的标准输入价格是每百万 Token 5 美元，而缓存读取只要 0.5 美元，差了 10 倍。OpenAI 的缓存输入定价逻辑类似，重复的前缀 Token 比全新输入便宜得多。

一个关键的健康指标是缓存命中率：

缓存命中率 = 缓存读取 / (缓存读取 + 缓存创建 + 未缓存输入)

在一个正常的编码会话中，这个值应该很高。如果偏低，说明你在为模型刚刚才看过的内容支付全价。

最常见的「自毁缓存」行为包括：

频繁修改 prompt 开头的上下文。
在稳定内容前面注入动态状态、时间戳、或变化的进度文本。
每轮对话之间重新排列工具定义或 MCP 工具 schema。
把大文件整段粘贴到对话里，而不是让助手按需读取。

修复方式并不复杂：把 prompt 的前缀保持稳定，把可变信息往后放。不要把系统上下文每轮都洗牌重来。把工具定义当成热路径的一部分来管理，因为它们确实就是热路径。

漏洞二：上下文持续膨胀

长上下文是很有用，但它不是免费的。对话中保留的每一段内容，都会被带入下一轮，除非助手主动压缩或丢弃。

一个典型的坏模式很容易识别：你让助手做一个任务，任务途中变成了三个任务；调试演变成了实现，实现又变成了发版说明。两小时前的完整考古记录还安安稳稳地躺在上下文里。

操作方法：比较前五个回合和后五个回合的平均输入长度。如果后面的回合大了两倍以上，且对话已经超过约 30K Token，那你大概率在每一轮都交了「长上下文税」。

Codex Record & Replay：AI 终于学会「看一遍就会做」

Thu, 25 Jun 2026 09:00:00 +0800

你是一名内容创作者，每周要在 YouTube 上传五六个视频。每次上传的流程一模一样：选中视频文件，填标题，写描述，选缩略图，上传字幕，设置隐私选项。你重复了很多次，闭着眼睛都能点完。

现在想象你打开 Codex，把这个流程从头到尾做了一遍。然后你告诉它：「以后就这么上传」。

第二天，你只需要把视频文件放在指定文件夹，Codex 自动把剩余工作全部完成。

这不是什么遥远的设想。OpenAI 在 2026 年 6 月为 Codex 推出了一个叫 Record & Replay 的功能，核心逻辑简单到只有一句话：演示一次，永久自动执行。

什么是 Record & Replay？

Record & Replay 是 Codex 桌面端（macOS）的一项新能力。它让 AI 不再依赖你写的提示词或脚本，而是直接「看」你操作。

你打开 Record 模式，像平时一样走完一个工作流。Codex 会捕捉整个过程中所有的鼠标点击、文件选择、文本输入和界面交互。录制结束后，这个工作流就变成了一个可复用的「技能（skill）」，存储在 Codex 的配置里。下次你想执行相同的任务，只需要触发这个技能，Codex 就能独立完成全部步骤。

OpenAI 官方演示的场景是 YouTube 视频上传：选中 .mp4 文件，填入标题和描述，上传缩略图，加载 .srt 字幕文件，最后将视频设为「不公开」。Codex 完整捕获了这组操作，随后成功独立复现。

比简单回放更进一步的是，Codex 不只是记住了「点击哪里」，它还学会了判断逻辑。比如在隐私设置里，它理解「Private」「Unlisted」「Public」三种选项的区别，能够根据上下文选择正确的可见性。当字幕文件的 Python 处理环境缺失时，它还能从已安装的 skill 目录中直接读取回退方案，而不是报错后干等。

「看一遍就会」意味着什么？

过去我们让 AI 干活，靠的是两种方式：要么写好 prompt 描述需求，要么写好脚本定义流程。这两种方式的共同问题是，它们都要求你预先知道怎么用语言或代码表达一个任务。

Record & Replay 打破了这个前提。

你不需要知道怎么「描述」上传 YouTube 视频的步骤，你只需要正常上传一次就行。就跟教实习生一样：别跟我说，看我怎么做的就行。

这对非技术用户尤其友好。一个市场人员想批量发布社交内容，一个 HR 想定期整理候选人数据，一个财务分析师想反复生成同一份报表，他们不需要学 Python，不需要写 prompt，只要做一遍就好。从这个角度看，Record & Replay 把 AI 自动化的门槛从「会编程」拉低到了「会用电脑」。

Flask 之父深度解析：AI 编程的「循环革命」已经来了

Wed, 24 Jun 2026 09:00:00 +0800

想象这样一个场景：你打开终端，不再跟 AI 助手一对一对话。你启动的是一个「循环」，它会自己拆解任务，自己调工具，自己判断是否完成，如果没完成，就再来一轮。等你喝完咖啡回来，代码已经写好了，review 也做完了，patch 也合入了 main 分支。

你甚至不知道中间发生了什么。

这不是科幻。Flask 和 Jinja2 的创造者 Armin Ronacher 在 2026 年 6 月 23 日发表了一篇题为《The Coming Loop》的长文，指出 AI 编程正在经历一场从「人在循环中」到「循环接管一切」的范式转移。

这篇文章在 Hacker News 上引发了激烈讨论，300 多赞，200 多条评论。以下是我对原文的梳理和延伸思考。

两种循环：Agent Loop 与 Harness Loop

Ronacher 区分了两种性质截然不同的循环。

**Agent Loop（代理层循环）**是每个 AI 编程工具内部都有的那一层：模型调一个工具，拿到结果，再调下一个工具，读文件，改文件，跑测试，最后输出答案。Codex、Claude Code、Cline，这些工具的核心都是这样工作的。这个循环我们已经很熟悉了。

**Harness Loop（架构层循环）**则是一个外层的、更高阶的循环。它不关心单次对话的结束，而是把一个任务放进队列，让机器去执行，执行完之后，由 harness（可以理解为「调度器」或「评价器」）来判断：这真的是终点了，还是需要再来一轮？如果不够好，harness 可以继续当前会话、注入新消息、启动新的 session、甚至把任务转发给另一台机器。

打个比方：Agent Loop 像是一个工人在车间里操作各种设备完成一个零件，Harness Loop 则像是车间经理，在流水线的尽头检查零件质量，不合格就打回去重做，或者重新分配任务。

Ronacher 引用了 Boris Cherny 的一句话：「我已经不再直接跟 Claude 对话了。我写循环，让循环去跟 Claude 对话。」

循环已经在哪些领域大杀四方？

Ronacher 是诚实的。尽管他对这种趋势持保留态度，他清楚地看到了循环模式在特定场景下的惊人效果。

代码迁移是最亮眼的例子。最轰动的是 Bun 从 Zig 到 Rust 的大规模迁移工作。这本质上是一种机械翻译：给定一个已有的、经过验证的代码库，让 AI 逐段翻译成另一种语言。验证标准非常明确，要么编译通过并且行为一致，要么就不行。Ronacher 自己用这种方式把 MiniJinja 从 Rust 迁移到了 Go，效果出色。