大家好，我是卡夫卡。
OpenAI 于今天凌晨，隆重推出了 Codex 的研究预览版，这是一款基于云端的编码 Agent。
消息一出，一些标题党又开始活跃起来，诸如此类哗众取宠的标题很容易就把人误导。
这篇文章，我想用相对理性的角度，聊聊 Codex 到底是什么，适合哪些人用，又有哪些局限性，帮助大家重新审视这款产品。
“我想到有趣的事情”
在此之前，先聊一个有趣的点：Codex 这个名字，其实已经是第三次出现在 OpenAI 的产品中了。
最早，Codex 是一个基于 GitHub 代码微调的编码模型，以 API 的形式提供编码帮助。
后来，Codex CLI 推出，这是一个基于本地的轻量级编码 Agent，以命令行交互的形式执行编码任务。
再后来，就是我们今天看到的 Code Research Preview，一个基于云端的编码 Agent 版本了。
（论 OpenAI 有多喜欢 Codex 这个名字（笑）。）
从这条发展路径不难看出，OpenAI 一直在探索 AI 编码助手与开发者交互的新方式。
而这一次，他们尝试将编码 Agent 搬到云端，以此来解决纯本地交互可能存在的一些限制。
(在下文中，凡提及“Codex”，均指代最新发布的 Code Research Preview 版本。)
那么，首先我们还是得弄清楚——
Codex 是什么？
简单来说，Codex 是一款在云端运行的编码 Agent，它可以同时处理多项简单的编码任务。
比如，帮你编写新功能、代码库释疑、修复程序 Bug，甚至是提交代码合并请求等等。
每一项任务都会在一个独立的云端“沙箱”环境中运行。 这个环境会预先加载你的代码库，确保开发过程互不干扰，同时保持高效。
Codex 能够读取和编辑文件，还能运行各种命令，包括测试工具、代码规范检查器和类型检查器等。
完成一项任务通常需要 1 到 30 分钟不等，具体时间取决于任务的复杂程度。 你可以实时看到 Codex 处理任务的进度。任务完成后，Codex 会提交它所做的代码修改，供你审查。
Codex 是由 codex-1 模型驱动的，codex-1 模型是 o3 模型的优化版本，专门针对软件工程领域作了优化。
它通过真实世界中的编码任务进行强化学习训练，这使得 Codex 能够生成更符合人类编码风格和提交习惯的代码。它能精确地遵循指令，并且会迭代运行测试，直到测试通过为止。
——但请注意，以上这些优异表现，都需要你预先配置好开发环境、提供可靠的测试方法和清晰的引导文档（AGENTS.md ），Codex 才能发挥出最佳性能。
发现问题了吗？单是“代码审查”这一步，就与“Vibe Coding”那种倾向于“全盘接受 Agent 输出，直接从结果验证”的方式是相悖的，更遑论后面的配置环境、提供测试方法等一系列前提条件了。
所以，Codex 这款产品，目标用户根本不是那些没有任何编程基础的“赤脚程序员”，而是那些希望提升工作效率的专业工程师。
Codex 适合哪些人？
在专业工程师的待办事项里，经常会有一些重复性强、范围明确、难度不高但又很分散注意力的任务。 比如代码重构、批量修改文件名、编写测试用例等等。
Codex 的出现，正好可以让工程师把这些“碎片化的开发任务”交给云端的编码 Agent 来处理，就好像多了几个初级工程师帮忙打下手。
这样一来，人类工程师就可以最大限度地减少大脑在不同任务间的上下文切换，将更多精力投入到架构设计、复杂逻辑攻坚、用户体验优化等更需要人类智慧和创造力的环节。
至于那些“碎片化的开发任务”，只需要在 Codex 完成并提交代码后，抽出一段时间集中审查并通过即可。
Codex 的局限性
目前，Codex 的开发还处于早期阶段。 作为一个研究预览版，它缺少一些应有的功能。 同时，出于安全考虑，它也阉割掉了一些重要功能，比如：
无法访问互联网
Codex 助手被设计为在云端一个完全隔离的安全容器中运行。在执行任务期间，Codex 无法访问互联网，这意味着它不能访问外部网站、API 或其他在线服务。
Agent 的交互，只能通过 GitHub 代码库中明确提供的代码，以及用户通过安装脚本预先配置好的依赖项来进行。
这个特性直接导致了它在功能和应用场景上的一些明显限制，例如：
- 动态获取依赖受限：在任务执行过程中，无法临时安装新的、未在初始脚本中声明的软件包或依赖库。缺乏实时外部API与数据交互：无法直接调用外部 API 进行实时数据交换或集成测试，也无法获取实时的外部数据来指导代码生成。与最新在线信息隔绝：在执行任务时，无法查阅最新的技术文档或 API 变更，只能依赖于其训练数据截止日期之前的知识。
环境配置的差异性
另一方面，Codex 的有效性高度依赖于开发者预先配置的隔离环境是否准确和完整。
如果这个模拟环境与真实的开发、测试或生产环境存在一些细微但关键的差异，那么 Codex 生成的解决方案，可能在沙箱中看起来完美无缺，但在实际应用中却会出现诸多问题。
特别对于那些拥有复杂网络结构、依赖众多微服务、有特定硬件配置或专有内部系统的企业级应用来说，要在 Codex 的隔离容器中完整且精确地模拟整个依赖环境，可能会非常困难，甚至不太现实。
缺乏图像输入能力
Codex 目前还不支持图像输入，这对于前端开发工作来说是个短板。
这意味着，如果任务需要理解视觉设计稿（比如 PSD 或 Figma 文件）并将其转换为前端代码，Codex 目前难以胜任。
这极大地限制了它在端到端用户界面/用户体验（UI/UX）开发自动化方面的应用。 我们仍然需要手动将视觉需求，转化为详尽的文本描述。
缺乏即时纠错机制
在 Agent 工作时，Codex 缺少对其进行方向修正的功能。
这意味着，一旦任务启动，如果开发者发现 Agent 的理解出现偏差或者执行方向错误，就无法立即中断并进行修正。 只能等待任务完成后再进行调整。
对于复杂或耗时较长的任务而言，这可能会造成时间和计算资源的浪费。
异步委托的耗时问题
将任务委托给云端的 Agent，可能会比实时交互的本地 Agent 花费的时间更长。
Codex 目前的交互模式，无法用于替代所有类型的编程任务。对于简单、快速的修改，传统的交互式编辑或轻量级AI辅助（如行内代码补全）可能更高效，我们需要权衡任务的复杂性与委派给 Codex 所需的时间成本。
“研究预览版”的固有特性：
“研究预览版”这个词本身就暗示了产品可能存在的不稳定性、潜在的错误(bug)、行为不一致性，以及API或功能可能会在后续版本中发生较大变化。
这意味着我们目前只能将它用在一些实验性项目上，而没法用它来进行一些生产级的工作。
总结
总的来说，OpenAI Codex 仍然是一款具有创新性的产品。它的目标并非取代开发者，而是为开发者“打辅助”。通过异步自动化，将开发者从低价值的工作中解放出来，从而让他们能更专注于创新和解决复杂问题。
然而，目前的预览版仍处于不太稳定的状态，也存在诸多局限性。 我们仍需以审慎的态度看待它，并仅在测试婚假进行验证。
