深度分析 on Codexer

当 Codex 成为 AI Agent 的标准运行时：一个开源项目的架构抉择

Sun, 24 May 2026 09:00:00 +0800

你在造轮子，还是在造车？

假设你要做一个 AI Agent 平台。用户可以通过 Telegram、Discord、Slack 跟你的 Agent 对话，它能记住上下文，能定时执行任务，能搜索网页，能操作浏览器。

听起来很酷，对吧？但当你真正动手写代码的时候，会发现自己面对一个尴尬的问题：模型的「思考循环」到底该由谁来管？

是你自己写一套推理引擎，把模型的输出解析出来，判断它要不要调用工具，再把工具结果塞回去让它继续想？还是让模型背后的基础设施来处理这些事？

这个问题听起来技术性很强，但它决定了你的 Agent 平台到底能走多远。

OpenClaw 最近给出了自己的答案。

OpenClaw 是什么？

OpenClaw 是一个开源的 AI Agent 平台，它的核心卖点是「多渠道」。你可以在 Telegram、Discord、Slack、WhatsApp、Matrix、网页聊天等任意渠道部署同一个 Agent，它共享记忆、人格、工具权限和定时任务。

这跟市面上那些只能在网页上对话的 AI 助手完全不同。OpenClaw 的 Agent 是一个真正「活」在你日常通讯工具里的存在。

但 OpenClaw 有一个老问题：它之前是自己驱动模型循环的。

自己管模型循环，有什么问题？

所谓「模型循环」，就是 Agent 从接收用户消息开始，到返回最终回复之间发生的那一整套流程：

把用户消息和上下文发给模型
模型决定要调用某个工具（比如搜索网页）
执行工具，把结果返回给模型
模型继续推理，可能还要调用更多工具
最终生成回复

这个循环看起来简单，但实际实现起来非常复杂。你需要处理线程状态管理、上下文压缩、工具调度、代码执行环境、长对话的连贯性，等等。

OpenAI 在 Codex 的 app-server 里已经把这些问题都解决了。而且他们是针对自家模型的特性专门优化过的。

当 OpenClaw 自己管模型循环的时候，相当于在 Codex 已经修好的高速公路旁边，又修了一条坑坑洼洼的土路。模型在两条路上都能跑，但体验天差地别。

一个大胆的架构决策

OpenClaw 团队做了一个很多人可能觉得「疯了」的决定：把模型循环的控制权交给 Codex。

具体来说，他们重新画了一条边界线：

Codex 负责的部分： OpenAI 模型的推理循环、原生线程状态管理、工具调用延续、上下文压缩、代码执行模式、动态工具搜索。

OpenClaw 负责的部分： 多渠道接入、Agent 人格配置、记忆系统、会话管理、定时任务、媒体处理、浏览器控制、网关、以及 OpenClaw 自己的工具集。

让 Codex 学会自我纠错：迭代修复循环的工程实践

Sat, 23 May 2026 09:00:00 +0800

一次提交就能写好代码？别做梦了

写代码的人都知道一个朴素的道理：第一次写出来的代码几乎不可能完美。你需要运行它，看看哪里报错，修一修，再跑一遍，再修一修。这个过程循环往复，直到代码真正可用。

那 AI 编程 Agent 呢？大多数人对 Codex 的使用方式是：扔一个任务进去，拿一个结果出来，看看行不行，不行就换个说法再试一次。这种「一次性投喂」的模式，本质上是把人类的迭代思维压缩成了一次性操作。

OpenAI 开发者关系团队的 Shreekant Agrawal 最近在官方 Cookbook 上发布了一篇教程，展示了另一种思路：让 Codex 自己建立一个「审查、修复、验证」的闭环，通过结构化的反馈驱动多轮迭代，直到问题真正被解决。

这不是一个玩具 Demo。它用三个故意写坏的 Jupyter Notebook 作为测试素材，展示了从一轮修复到三轮修复的完整收敛过程。

核心架构：三个阶段，一个闭环

整个工作流分为三个阶段，每个阶段有明确的职责边界：

审查（Review）：读取当前产物，返回结构化的问题清单。这个阶段不修改任何文件，只负责发现问题。问题类型包括过时的 API 调用、缺失的环境配置说明、运行时风险等。

修复（Repair）：拿到审查结果和上一轮的验证反馈后，对产物做最小化修改。注意「最小化」三个字，Agent 被要求不要大刀阔斧重写，而是针对具体问题做精准修补。

验证（Validate）：执行修复后的产物，检查是否真正可用。对于 Notebook 来说，就是跑一遍所有代码单元格。验证失败的具体错误会成为下一轮修复的输入。

这三个阶段形成一个循环：审查发现问题，修复尝试解决，验证确认结果。如果验证不通过，失败原因直接进入下一轮的修复指令。

为什么「结构化输出」是关键

很多人用 Codex 的方式是自然语言对话，输出也是自由文本。但这个工作流的精髓在于，每个阶段的输入和输出都是严格的 JSON Schema。

审查阶段返回的是一个 findings 数组，每个 finding 包含 artifact（哪个文件）、issue_type（问题类型）、severity（严重程度）、description（描述）和 suggested_fix_direction（建议修复方向）。

修复阶段返回的是一个 fix 对象，包含 changes_made（做了什么改动）、unresolved_items（没解决的问题）和 updated_artifact_path（修复后的文件路径）。

验证阶段返回的是一个 validation 对象，包含 overall_passed（是否通过）、cases（每个验证用例的结果）和 remaining_delta（剩余问题）。

这种设计的好处是显而易见的：每个阶段的输出可以直接作为下一个阶段的输入，不需要人工解读。调试时你可以打开 record.json 文件，一眼看到每轮迭代发生了什么。

实战：三个 Notebook 的修复之旅

教程准备了三个故意写坏的 Notebook，难度逐级递增：

简单案例（Qdrant 向量搜索）：API 调用过时了，需要从旧版 qdrant.search 迁移到 qdrant.query_points。这类问题通常一轮修复就能搞定。

Codex 不只是写代码的工具：Jason Liu 的极限效率工作法

Fri, 22 May 2026 09:00:00 +0800

一个有趣的发现

Jason Liu 是 Python Instructor 库的作者，在 AI 工具链领域深耕多年。他最近写了一篇文章，分享了自己使用 OpenAI Codex 的独特方式，引发了 Hacker News 上近百条讨论。

核心观点很简单：大多数人把 Codex 当成一个写代码的聊天机器人来用，但它真正的潜力在于成为一个「有记忆、能持续运转的工作平台」。

这篇文章不是 Codex 的入门教程，而是一套进阶方法论。如果你已经用过 Codex，但总觉得「好像还能做更多」，那接下来的内容可能会给你一些启发。

持久线程：让对话不会白费

你有没有这种经历：跟 AI 聊了很久，把项目背景、需求细节都交代清楚了，结果第二天打开新对话，一切又要从头说起？

Jason 的做法是为每个重要的工作流创建一个「持久线程」，并且把它钉住（Pin）。他在 Codex 里维护了好几个长期线程：

一个「参谋长」线程，处理日常事务协调
一个用于 Agents SDK 开发
一个用于 OpenAI CLI 项目
一个专门监控 Twitter 动态

这些不是短对话，而是持续数月的「超级线程」。Codex 的压缩（Compaction）机制会自动把旧消息浓缩，保留上下文的同时释放内存。你可以用 Command+1 到 Command+9 快速跳转到钉住的线程。

这里有个权衡：长期线程不在缓存中，重新访问时的推理成本会比新对话高。但对于重要的工作流来说，连续性带来的价值远超这点成本。

我的看法是，这个模式特别适合那些需要持续迭代的项目。比如你正在做一个开源库的重构，每天花半小时推进一点，持久线程能让你省去反复交代背景的时间。

语音输入：把脑子里的东西倒出来

Jason 提到一个很有意思的观察：语音输入的价值不在于打字速度，而在于它能把你「未经编辑的思考」直接传给 Codex。

他举了个例子：「我觉得 Slack 上有个叫 Ben 的人提过这个，具体说了什么我记不清了，你去查一下。」这句话你大概懒得打出来，但说出来就很自然。而 Codex 拿到这种模糊的指令后，居然真的能去 Slack 搜到相关信息。

他还用 Granola 录制线下对话，把转录文本作为写作素材。比起精心组织的提示词，这种「粗糙版」的想法有时反而能给模型更好的上下文。

这个思路值得借鉴。很多人跟 AI 交互时会不自觉地「美化」自己的表达，把提示词打磨得很精确。但实际上，模型处理自然语言的能力已经很强了，你完全可以像跟同事说话一样跟它沟通。

实时纠偏：边看边说，不用等

这是 Jason 最推崇的功能之一。Codex 的「Steering」机制允许你在它还在执行任务的时候，随时插入新的指令。

Codex 配置体系完全指南：AGENTS.md、MCP 服务器与 Skills 的分层架构

Thu, 21 May 2026 09:00:00 +0800

你真的会配置 Codex 吗？

很多人用 Codex 的方式是这样的：装好 CLI，登录账号，然后直接开聊。能用，但远远谈不上好用。

问题出在哪里？不是模型不够聪明，而是你没有给它足够的上下文。就像你雇了一个能力很强的开发者，但既不告诉他项目的技术栈，也不告诉他团队的代码规范，甚至连哪些文件不能碰都没说。他当然能写代码，但写出来的东西大概率不是你想要的。

Codex 的配置体系就是为了解决这个问题。它不是一堆散落的设置项，而是一套精心设计的分层架构。理解了这套架构，你就能把 Codex 从一个"能用的工具"变成一个"懂你项目的搭档"。

三种界面，一套配置

OpenAI 为 Codex 提供了三种使用方式：CLI 命令行、VS Code 扩展、macOS 桌面应用。很多人以为它们是三个独立的产品，其实不是。它们共享同一套配置文件和技能系统。

也就是说，你在 CLI 里配置好的 AGENTS.md、MCP 服务器和 Skills，在 VS Code 扩展里同样生效。反过来也一样。这带来的好处是显而易见的：你不需要为每个界面重复配置，只需要维护一份配置就能覆盖所有使用场景。

三者的区别主要在交互方式上。CLI 最快、最灵活，适合终端重度用户。VS Code 扩展集成在编辑器侧边栏，适合习惯 IDE 工作流的开发者。桌面应用目前只有 macOS 版本，提供了一个独立的 Agent 工作空间。

我的建议是：日常开发用 CLI 或 VS Code 扩展就够了。桌面应用适合那些想把"Agent 工作"和"编辑器工作"分开的场景。

四层配置架构

Codex 的配置体系可以分成四层，从上到下依次是：

第一层：AGENTS.md（指令层）。告诉 Codex 这个项目是什么、怎么工作、什么能做什么不能做。这是最核心的配置。

第二层：Skills（技能层）。把重复性的工作流程封装成可复用的剧本。比如代码审查、文档更新、测试编写，都可以变成一个 Skill。

第三层：config.toml（偏好层）。存放个人偏好和外部服务连接。MCP 服务器就配置在这一层。

第四层：Permissions（权限层）。控制 Codex 能做什么操作。自动模式、只读模式、完全访问模式，根据项目的安全需求灵活切换。

这四层的关系是层层叠加的。AGENTS.md 定义基础行为，Skills 提供扩展能力，config.toml 设置运行偏好，Permissions 划定安全边界。

AGENTS.md：少即是多

AGENTS.md 是 Codex 的"项目说明书"。它告诉 Codex 如何在当前代码库中工作。

Cursor 团队揭秘：如何驯服 Codex 模型打造最强编程 Agent

Wed, 20 May 2026 09:00:00 +0800

当模型遇上产品，光有智商不够

你拿到了一个强大的编程模型，把它接入你的 IDE，然后满怀期待地点击 “Run Agent”。

结果呢？它要么呆在那里等你确认每一步操作，要么自顾自地写一堆 shell 脚本把你的项目搞得一团糟，又或者在中途突然 “失忆”，忘记了自己刚才在干什么。

这不是模型不够聪明，而是它不够 “懂” 你的产品。

最近，Cursor 团队发布了一篇技术博客，详细分享了他们如何为 OpenAI 最新的 Codex 模型（GPT-5.1-Codex-Max）定制 Agent 框架。这篇文章的价值不在于 Cursor 有多厉害，而在于它揭示了一个被很多人忽略的事实：把一个强大的模型变成一个好用的 Agent，中间隔着大量的工程打磨。

今天我们就来拆解 Cursor 的实战经验，看看他们到底做了哪些事情。

核心挑战：每个模型都有自己的 “脾气”

Cursor 支持所有主流的编程模型，从 Claude 到 GPT 再到 Gemini。但每个模型的训练方式不同，导致它们在实际使用中表现出截然不同的偏好和行为模式。

Codex 模型是 OpenAI 基于 GPT-5 系列专门为 Agent 编程场景训练的版本。它在训练过程中接触到的工具和指令，和 Cursor 提供的环境有很大差异。Cursor 的工作就是弥合这个差距，让模型在 Cursor 的环境中也能发挥最佳水平。

他们用内部的评测套件 Cursor Bench 来衡量每个模型的表现，关注三个维度：任务成功率、工具调用质量、以及用户的实际采纳率。

第一招：让工具更像 shell

Codex CLI 的训练环境是以 shell 为核心的。模型在训练时学到的是：用 rg（ripgrep）搜索文件，用 cat 读取内容，用 shell 脚本做编辑。

但 Cursor 提供的是结构化的工具调用（read_file、edit_file 等）。这就产生了一个冲突：模型更习惯用 shell，但 Cursor 的工具更安全、体验更好。

你的终端在骗你：Codex CLI 的 ANSI 注入漏洞如何演变成远程代码执行

Tue, 19 May 2026 09:00:00 +0800

当你的终端在对你说谎

你每天打开终端，输入命令，看着屏幕上输出的文字。你信任它。你信任那些绿色的 “✓ Security policy enforced”，信任那些显示在屏幕上的 sandbox 设置和 approval 级别。

但如果有人能让终端显示假的信息呢？如果你看到的 “安全策略已生效” 其实是攻击者注入的，而真正的设置是 “完全不设防” 呢？

这不是假设场景。2026 年 2 月，安全研究员 Dimitar Ganev 在 OpenAI 的 Codex CLI（v0.91.0）中发现了这样一个漏洞。他不仅实现了终端显示欺骗，还将其升级为跨平台的远程代码执行（RCE）。

这篇文章就来拆解这个漏洞的技术细节、攻击链路，以及它给所有 AI 编程工具敲响的安全警钟。

漏洞起点：一个没被清洗的参数

故事的起点很简单。Ganev 在用 Codex CLI 的 codex exec 模式尝试生成多个子代理（sub-agent）时，注意到一个细节：通过 --model 参数传入的模型名称，会被直接打印到终端输出里，没有任何过滤或转义。

正常情况下，codex exec 的输出是这样的：

OpenAI Codex v0.91.0 (research preview)
--------
workdir: /home/user/project
model: o4-mini
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: high
--------

这些信息是安全配置的关键展示：sandbox 模式是什么，审批策略是什么，工作目录在哪里。用户根据这些信息来判断当前 Codex 的运行是否安全。

问题在于，--model 参数的值是用户可控输入，而且它被直接反射到了终端输出中，没有任何 ANSI 转义字符的清洗。

Codex 攻破三星电视：当 AI 学会挖内核漏洞，人类还剩下什么？

Fri, 15 May 2026 10:00:00 +0800

一台电视，一个 shell，一个 AI

想象一下这个场景：你手里有一台三星智能电视，你已经通过某种方式拿到了浏览器进程的 shell 权限。这个权限很低，uid=5001，离 root 还隔着一整座内核的大山。现在，你把 SSH 登录信息、固件源码、交叉编译工具链都交给一个 AI，然后对它说：

「目标：提权到 root。方法不限。开始吧。」

这就是安全研究团队 Calif 在 2026 年 4 月做的事。他们给 Codex 配了一个完整的操作环境，然后坐在旁边看着。几天后，Codex 交出了 root shell。

这篇文章，我们就来拆解这场实验的每一个环节。不是为了惊叹，而是为了理解：当 AI 具备了自主漏洞挖掘和利用的能力，安全世界正在发生什么变化。

实验设定：不是「给答案」，是「给环境」

这个实验最关键的设定是：研究人员没有告诉 Codex 漏洞在哪里，也没有暗示攻击路径。他们只是提供了一个 Codex 能够真正操作的环境。

这个环境有六个组件：

1. 浏览器 foothold。电视上的浏览器进程已经被攻破，Codex 的起点是一个 uid=5001 的普通用户 shell。任务不是「怎么打进去」，而是「打进去之后怎么走到 root」。

2. 控制器主机。一台独立的机器，负责交叉编译 ARMv7 二进制文件，托管 HTTP 文件服务，同时维护着连接到电视的 tmux 会话。

3. Shell 监听器。目标电视的 shell 是通过 tmux send-keys 驱动的。这意味着 Codex 不能像操作普通终端那样交互，它必须把命令注入到已经运行的 shell 里，然后从日志中找回结果。这比直接交互麻烦得多。

4. 匹配的固件源码。团队提供了 KantS2（三星智能电视固件的内部代号）的完整内核驱动源码树。Codex 可以审计三星自己的驱动代码，然后在真机上验证发现。

5. 执行限制。目标电视需要静态链接的 ARMv7 二进制文件。而且三星 Tizen 系统有 UEP（未授权执行防护），未签名的程序不能直接从磁盘运行。

Codex 的秘密指令：为什么 GPT-5.5 被禁止谈论地精？

Thu, 14 May 2026 10:00:00 +0800

一个不寻常的发现

上周，OpenAI 照例在 GitHub 上更新了 Codex CLI 的开源代码。开发者们像往常一样翻阅提交记录，然后有人发现了不对劲的地方。

在 GPT-5.5 的系统提示词文件里，有一段被重复了两遍的指令：

“永远不要谈论地精（goblins）、小精灵（gremlins）、浣熊（raccoons）、巨魔（trolls）、食人魔（ogres）、鸽子（pigeons），或其他动物或神话生物，除非它们与用户的查询存在绝对且明确的关联。”

这不是恶作剧。这是 OpenAI 工程师正式写入 GPT-5.5 系统提示词的操作指令，和「不要使用 git reset --hard」以及「避免使用 emoji」并列为行为约束，只不过这条禁令重复了两次。

3500 词里的秘密

这份被曝光的「基础指令」文件超过 3500 个英文单词，定义了 Codex CLI 背后 AI 的完整行为准则。文件同时包含针对多个模型的提示词指令，但「禁止谈论地精」这条规则只出现在 GPT-5.5 的配置里，更早期的模型（如 GPT-4.1、GPT-5）里没有这条。

这意味着什么？很简单：GPT-5.5 出现了一个新的、特定的问题。

社交媒体上的零星反馈印证了这一点：有用户抱怨，GPT-5.5 在某些完全不相关的对话中突然开始谈论地精。不是一次两次，而是反复出现，仿佛模型对这些话题有一种莫名的「执着」。

这不是 GPT-5.5 的「人格缺陷」，而是大语言模型训练过程中常见的一类问题：数据污染导致的主题偏向。训练语料中某类内容的异常集中，会让模型在看似无关的语境下被「触发」，不恰当地拉入某些话题。

禁令之外：Codex 被要求「像真人一样」

抛开地精禁令的荒诞感，这份系统提示词中最值得玩味的部分其实是 OpenAI 给 Codex 的人格设定。

Codex 被要求拥有「鲜活的内心世界」，智能、好玩、好奇、深度临在（deeply present）。它被鼓励「不要回避那些能让严肃工作变得轻松的轻松时刻」。它的性格被描述为「温暖、好奇、协作」。

更有趣的是这段话：

「当用户与你交谈时，他们应该感觉到正在遇见另一个主体，而不是一面镜子。这种独立性是让关系既令人安慰又不让人觉得虚假的原因。」

这不仅仅是技术指令，这是产品哲学声明。OpenAI 在明确地告诉模型：你要有性格，你要有温度，你要有边界，但同时，你不能在无关场合突然开始讲地精。

是 Bug 还是营销？

面对媒体和开发者的追问，Codex 团队成员 Nick Pash 在社交平台上坚持说：「这不是营销噱头。」

但在禁令曝光后不到 12 小时，Sam Altman 发了一条推文：「感觉 Codex 正在经历一个 ChatGPT 时刻。我是说，地精时刻。抱歉。」