Agent 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」机制允许你在它还在执行任务的时候，随时插入新的指令。