有点想放弃codex了，codex工程化能力缺陷太明显
- 内容介绍
- 文章标签
- 相关推荐
codex工程化能力真的有问题
1.subagent每次派发都要重新链接一圈MCP，浪费流量+token+时间，并且一直有个BUG没修复，一旦某个MCP超时，他就会一直重连，一直到内存爆炸。
2.subagent派发出去后管生不管养，任务已经结束，但是subagent不会自动关闭，还在后台，一直要到agent满到不能继续派发才会选择关闭，这中间返回对话又浪费token又浪费时间。
3.skill执行力够，memory执行力也够，一旦memory和skill还有agent.md有略微的提示词差异，就开始无限兜底来确保安全性，没有一点人工智能的感觉，常常用的人心累。CC在这方面实在是强很多，层级明确，memroy永远是辅助功能，agent.md是规范，skill是技能。
4.为了确保所谓的安全性，对mcp和skill的触发不够敏捷，除非你用了完整的提示词或者$，很多项目场景明明用context7或者deepwiki就可以解决，他偏要执行一套假设------验证------猜测------分析的循环，浪费TOKEN+时间。
5.对话啰嗦，反复重复代码内容，agent的意义在于用户少读代码，多看结果，然而codex的实际情况是多给你发代码，再给你读结果，大量的文字阅读会让人精神疲倦，在agent的使用过程中会分散个人注意力。cc在这里非常好，每次汇报都是很核心的内容，让你能第一时间分析目前逻辑动态。
6.插件机制的不完善，现在vibecoding分为插件、MCP、SKILL，而CODEX把这些层级编排的很混乱，没有明确的上下级关系，即使有，也会因为上下文漂移导致幻觉率飙升。
这是我个人发现的问题，可能因为我个人才疏学浅，对agent的理解太过于薄弱出了这些闹笑话的想法。总而言之，我以前觉得CODEX的生态没有claude codex好，是开发者有病，用了这么久，我觉得开发codex生态的人才有病。
CODEX太过于臃肿，从设计之初感觉就没有好好规划，从头到尾都有一种"你有我也要有"的感觉，但是他并没有想明白为什么要有，他只是做了这些功能，但是没有后续的延伸和逻辑上的闭环。
傻逼的AI开发了傻逼的程序，因果报应了属于是，A吹牛B说自己用AI开发的CC，傻逼OAI还真信了
网友解答：--【壹】--：
试试opencode，不过我在opencode里基本上不用sub agent，用的话也是用自带的，并且它内置的sub agent不是放后台的，是要等sub agent工作结束后主agent收到结果了才继续，我感觉是没啥问题
image2560×1540 205 KB
--【贰】--：
我都是Claude Code配合gpt干活，其实也还挺好用的，主要还是gpt便宜大碗
--【叁】--：
嫌 codex cli 不行就反代去用 cc 呗
--【肆】--：
cc跟codex都开了，一般是先用codex，复杂的上cc
--【伍】--：
如果对subagent有要求，相比于codex或者cc里黑盒一样的subagent机制，可以试一些多agent框架。
稍微严谨一些的任务我现在都是直接关闭subagent的。
--【陆】--：
之前有段时间高强度用codex，但这个子代理问题真的挺难受，而且很多功能都是claude有了，codex很久才跟进，而且自动审批权限这个出来之前，权限管理这块基本没法自定义，现在基本都是反代到claude用
--【柒】--：
留在 codex 纯纯因为 gpt 力大砖飞
--【捌】--：
感觉是不如cc好用，消耗是比cc少，但总是返工
--【玖】--：
但是他便宜啊 现在这渠道来说好像没有比他性价比更高的了把
--【拾】--：
最拉的是Gemini CLI，其次就是Codex，
而最好用的是Opencode跟Claude Code
--【拾壹】--：
子agent这个功能的意义，就是不让一些任务对会话造成漂移，比如调研任务，基础的代码执行任务，如果放到主会话里会对内容造成污染，上下文一旦拉长会出现严重的幻觉，这个设计本身是非常合理的，cc在这里确实下来很大的功夫，很少会造成污染和不合理（前提不乱用插件），codex的设计问题太严重了。
--【拾贰】--：
你需要工作流，可以用codex中spawn agents on csv 方法强制挂起，效率会大幅度提高，只不过消耗量大，参考 【长期贴】 Claude-code-workflow(CCW) --使用技巧分享-自认为最工程化的harness workflow - 开发调优 - LINUX DO
--【拾叁】--：
和cc比差距太大了，cc对skill和mcp调用的逻辑非常好，agent派发出去也很合理，提示词每次都写的很清晰，用户看一眼就知道这个agent到底在干什么，他能做什么，最重要的是不会因为返回结果而出现对话漂移，CODEX这里做的就像一坨屎。400K的5.5黄金上下文也就100K，基于他的安全策略就会反复兜底，上下文浪费，token浪费，时间浪费，全是浪费，放在生产力场景这就相当于请了个智商极高，但是操作能力低下的残障人士。
--【拾肆】--：
工作流也都是基于强提示词和HOOK，codex的HOOK机制有问题，提示词工程也是名存实亡，所谓的task返回机制也是笑话，实际做出来的项目让我感觉就是一坨大的，无限的兜底，看不完的代码，找不完的硬编码。
--【拾伍】--：
感觉codex还可以，主要是一个mcp也没用，subagent也是偶尔调用，一次最多用两个subagent，你说的问题还没碰到过，现在模型越来越聪明，工具尽可能简单。
--【拾陆】--：
我的经验是 subagent 永远只做补充上下文的活
本地 mcp 能用 skills 替换的全都关掉
--【拾柒】--：
不太懂cc那边是怎么实现的，不过opencode这里是主agent会收到子agent结束后的最后一句话
image2560×1540 232 KB
--【拾捌】--：
codex的subagent连半成品都算不上 差不多是废品
--【拾玖】--：
只能说便宜是最大的优势了，性价比只要足够高，他的缺点都会被大家克服
codex工程化能力真的有问题
1.subagent每次派发都要重新链接一圈MCP，浪费流量+token+时间，并且一直有个BUG没修复，一旦某个MCP超时，他就会一直重连，一直到内存爆炸。
2.subagent派发出去后管生不管养，任务已经结束，但是subagent不会自动关闭，还在后台，一直要到agent满到不能继续派发才会选择关闭，这中间返回对话又浪费token又浪费时间。
3.skill执行力够，memory执行力也够，一旦memory和skill还有agent.md有略微的提示词差异，就开始无限兜底来确保安全性，没有一点人工智能的感觉，常常用的人心累。CC在这方面实在是强很多，层级明确，memroy永远是辅助功能，agent.md是规范，skill是技能。
4.为了确保所谓的安全性，对mcp和skill的触发不够敏捷，除非你用了完整的提示词或者$，很多项目场景明明用context7或者deepwiki就可以解决，他偏要执行一套假设------验证------猜测------分析的循环，浪费TOKEN+时间。
5.对话啰嗦，反复重复代码内容，agent的意义在于用户少读代码，多看结果，然而codex的实际情况是多给你发代码，再给你读结果，大量的文字阅读会让人精神疲倦，在agent的使用过程中会分散个人注意力。cc在这里非常好，每次汇报都是很核心的内容，让你能第一时间分析目前逻辑动态。
6.插件机制的不完善，现在vibecoding分为插件、MCP、SKILL，而CODEX把这些层级编排的很混乱，没有明确的上下级关系，即使有，也会因为上下文漂移导致幻觉率飙升。
这是我个人发现的问题，可能因为我个人才疏学浅，对agent的理解太过于薄弱出了这些闹笑话的想法。总而言之，我以前觉得CODEX的生态没有claude codex好，是开发者有病，用了这么久，我觉得开发codex生态的人才有病。
CODEX太过于臃肿，从设计之初感觉就没有好好规划，从头到尾都有一种"你有我也要有"的感觉，但是他并没有想明白为什么要有，他只是做了这些功能，但是没有后续的延伸和逻辑上的闭环。
傻逼的AI开发了傻逼的程序，因果报应了属于是，A吹牛B说自己用AI开发的CC，傻逼OAI还真信了
网友解答：--【壹】--：
试试opencode，不过我在opencode里基本上不用sub agent，用的话也是用自带的，并且它内置的sub agent不是放后台的，是要等sub agent工作结束后主agent收到结果了才继续，我感觉是没啥问题
image2560×1540 205 KB
--【贰】--：
我都是Claude Code配合gpt干活，其实也还挺好用的，主要还是gpt便宜大碗
--【叁】--：
嫌 codex cli 不行就反代去用 cc 呗
--【肆】--：
cc跟codex都开了，一般是先用codex，复杂的上cc
--【伍】--：
如果对subagent有要求，相比于codex或者cc里黑盒一样的subagent机制，可以试一些多agent框架。
稍微严谨一些的任务我现在都是直接关闭subagent的。
--【陆】--：
之前有段时间高强度用codex，但这个子代理问题真的挺难受，而且很多功能都是claude有了，codex很久才跟进，而且自动审批权限这个出来之前，权限管理这块基本没法自定义，现在基本都是反代到claude用
--【柒】--：
留在 codex 纯纯因为 gpt 力大砖飞
--【捌】--：
感觉是不如cc好用，消耗是比cc少，但总是返工
--【玖】--：
但是他便宜啊 现在这渠道来说好像没有比他性价比更高的了把
--【拾】--：
最拉的是Gemini CLI，其次就是Codex，
而最好用的是Opencode跟Claude Code
--【拾壹】--：
子agent这个功能的意义，就是不让一些任务对会话造成漂移，比如调研任务，基础的代码执行任务，如果放到主会话里会对内容造成污染，上下文一旦拉长会出现严重的幻觉，这个设计本身是非常合理的，cc在这里确实下来很大的功夫，很少会造成污染和不合理（前提不乱用插件），codex的设计问题太严重了。
--【拾贰】--：
你需要工作流，可以用codex中spawn agents on csv 方法强制挂起，效率会大幅度提高，只不过消耗量大，参考 【长期贴】 Claude-code-workflow(CCW) --使用技巧分享-自认为最工程化的harness workflow - 开发调优 - LINUX DO
--【拾叁】--：
和cc比差距太大了，cc对skill和mcp调用的逻辑非常好，agent派发出去也很合理，提示词每次都写的很清晰，用户看一眼就知道这个agent到底在干什么，他能做什么，最重要的是不会因为返回结果而出现对话漂移，CODEX这里做的就像一坨屎。400K的5.5黄金上下文也就100K，基于他的安全策略就会反复兜底，上下文浪费，token浪费，时间浪费，全是浪费，放在生产力场景这就相当于请了个智商极高，但是操作能力低下的残障人士。
--【拾肆】--：
工作流也都是基于强提示词和HOOK，codex的HOOK机制有问题，提示词工程也是名存实亡，所谓的task返回机制也是笑话，实际做出来的项目让我感觉就是一坨大的，无限的兜底，看不完的代码，找不完的硬编码。
--【拾伍】--：
感觉codex还可以，主要是一个mcp也没用，subagent也是偶尔调用，一次最多用两个subagent，你说的问题还没碰到过，现在模型越来越聪明，工具尽可能简单。
--【拾陆】--：
我的经验是 subagent 永远只做补充上下文的活
本地 mcp 能用 skills 替换的全都关掉
--【拾柒】--：
不太懂cc那边是怎么实现的，不过opencode这里是主agent会收到子agent结束后的最后一句话
image2560×1540 232 KB
--【拾捌】--：
codex的subagent连半成品都算不上 差不多是废品
--【拾玖】--：
只能说便宜是最大的优势了，性价比只要足够高，他的缺点都会被大家克服