深度解读：OpenAI 自己人肯定不用 Codex App

背景

OpenAI 在 2024 年底至 2025 年初陆续推出了多款 AI 开发工具，其中 Codex 系列（包括 Codex App 以及其子代理功能）旨在帮助开发者通过自然语言指令自动完成代码编写、重构、调试等任务。然而，用户在 LINUX DO 论坛上发帖，直言 Codex 子代理的设计存在严重问题，并怀疑 OpenAI 内部员工自己根本不用这些产品。该帖引发了多位参与者的讨论，反映了对 OpenAI 产品迭代方向的不满。

核心内容

帖子作者最近仔细研究了 Codex 的子代理（sub-agent）功能，发现其体验令人难以接受。主要问题包括：

• 模型适配混乱：尤其是 max 模型（可能指 OpenAI 代号为 max 的高性能模型）无法准确判断哪些任务可以下发给子代理，哪些不能。max 模型倾向于让一个低智能（low‑intelligence）模型去评判代码重构方案的好坏，而用户明明已经明确告知这些子代理只能处理一些基础的、耗时较长且上下文较少的机械性工作。

• 工作流低效：作者认为，虽然花时间调整子代理的配置可能最终能调好，但过程太麻烦，不如直接在 prompt 里把子任务的编排写清楚来得直接。这意味着子代理的智能调度还不如用户手动拆分任务来得高效。

• 内部使用怀疑：作者严重怀疑 OpenAI 内部有一套自己的特制 prompt、配置和自定义版本，或者干脆是通过内部反代（reverse proxy）连接 Cursor/Codex 等工具的特殊版本。因为之前 OpenAI 把 Codex App 的上下文窗口删除了（减少了上下文长度），导致用户无法有效利用长上下文，作者在 GitHub 上和其他开发者一起激烈批评了这一点。

• 产品自测质疑：作者认为，像 Codex 这种经常更新一些“蠢货设计”的产品，OpenAI 内部员工肯定自己不用。如果真的在用，不会测不出这些明显的问题。

该帖子共有 13 条回复，6 位参与者参与了讨论。

关键要点

• Codex 子代理的模型适配存在严重缺陷：max 模型无法区分任务是否适合下放给子代理，甚至错误地让低智模型评判高难度重构。
• 用户明确告知子代理只能做基础、长上下文、低智力的工作，但系统仍不遵守指令。
• 手动在 prompt 中编排子任务比使用子代理更高效，说明子代理的智能调度尚未成熟。
• 上下文窗口被无预警删除，引起社区强烈不满，用户认为 OpenAI 开发者缺乏实际使用体验。
• 作者推断 OpenAI 内部使用定制化版本或反代方案，避免公开产品的缺陷。
• 整体评论反映出对 OpenAI 产品迭代方向和质量控制的批评，认为其自身不 dogfood（自用）自己的产品。

意义与影响

这一讨论揭示了当前 AI 开发工具从“演示级”向“生产级”过渡时面临的典型问题：模型能力与用户真实需求之间的错配。Codex 子代理的失败不仅在于技术实现不成熟，更在于产品团队可能没有充分倾听用户反馈，甚至没有自己实际使用。上下文窗口的擅自缩减更是直接伤害了重度用户的工作流。

如果 OpenAI 内部确实存在“特供版”或“反代版”，那将严重损害外部用户对产品公平性和透明度的信任。类似事件也提醒开发者：即使是大公司的 AI 工具，也未必经过充分的自测和 dogfooding。用户在使用早期产品时，应当保持警惕，并积极通过社区反馈推动改进。

长远来看，这类批评如果被 OpenAI 重视，可能会促使 Codex 团队重新审视子代理的调度逻辑、模型选择策略以及上下文窗口的设计。否则，用户可能会转向更开放、更可控的替代方案（如开源模型配合自定义 agent）。