Codex 的野心,MCP 和 Skill 的下一步 · AI HOT
宝玉@dotey66
2026-05-12 04:47·52天前
AI 摘要Codex、Claude等顶尖Agent应用均采用三栏界面,反映其从问答转向任务执行与审查的演进。Codex野心是成为“处理一切任务”的平台,但用户需二次编辑AI生成内容。目前MCP解决工具连接,Skill解决执行方法,仍缺编辑闭环。作者认为,建立类似VSCode的插件生态是合理路径,将文件预览、专业编辑等能力开放给社区开发,实现商业化,从而为中小团队提供开发垂直插件的机遇。
宝玉@dotey · X2026-05-12 04:47·52天前
在 X 看原推· x.comAI 摘要Codex、Claude等顶尖Agent应用均采用三栏界面,反映其从问答转向任务执行与审查的演进。Codex野心是成为“处理一切任务”的平台,但用户需二次编辑AI生成内容。目前MCP解决工具连接,Skill解决执行方法,仍缺编辑闭环。作者认为,建立类似VSCode的插件生态是合理路径,将文件预览、专业编辑等能力开放给社区开发,实现商业化,从而为中小团队提供开发垂直插件的机遇。
想做这件事的不止 Codex 一家。Cursor 我能看到类似的影子。唯独 Claude Code 和 Cowork,目前没看到这个方向的产品迹象--也许他们不屑于做,也许只是还没走到这一步。
如果 Codex 真的跑通了插件生态,对中小团队意味着什么?
除了自己做一个垂直 Agent,还有另一条路:在 Codex 这样的平台上做插件。不用自己搭 Agent 调度层,不用解决 Token 接入,用户分发也靠平台。你只需要专注在那个"最后一公里"--帮用户把 Agent 生成的结果处理好、编辑好、用得顺手。
这个窗口不会开太久。先进去的能拿到冷启动红利,晚进去的只剩存量竞争。
Codex 的野心摆在那里,"几乎任何任务"这个口号要真正兑现,插件机制是绕不过去的一步。如果 OpenAI 在这件事上继续犹豫,那才是真的失误。
你觉得这个插件生态最后会是哪家先跑通?或者说你觉得有更适合 Agent 的产品表现形式?欢迎留言分享!
于是各家开始悄悄升级右侧工作区,让它从只能看文件编辑记录,变成了一个多功能区。Codex 在 4 月 16 日的大版本更新里,右侧工作区的改动幅度是所有功能里最大的。
交互细节上各家略有差异。Codex 和 Cursor 用 Tab 切换,Claude 用浮动面板。我自己用下来觉得 Codex 最顺手,Claude 的浮动面板方案设计感有余、实用性不足,迟早要改。
但如果只把这个变化读成"设计界面进化",就低估 Codex 了。
Codex 4 月大版本发布时的口号是"Codex for (almost) everything"--几乎任何任务都能做。你可以把它理解成一句广告口号,但更像是一个产品方向的声明。
要兑现这句话,Codex 不能只是个擅长写代码的 Agent,它必须能处理各种文件格式,支持各领域的专业工作流,还要让用户能在它里面完成全程闭环,包括最后的人工微调。
目前 Codex 还做不到最后一步:生成之后无法编辑,代码、Markdown、PPTX 都不行。这可能是产品上有意为之的克制,可能是技术上还没跑通,也可能是在等一个统一的解决方案出现。
要理解 Codex 在等什么,得先想清楚 Agent 能力拼图里现在差哪一块。
MCP 解决了"连接"问题:Agent 通过统一规范接入各种工具,数据库、日历、代码仓库,都能打通。
Agent Skills 解决了"怎么做"的问题:Agent 学会了它没训练过的领域知识和最佳实践,比如怎么写特定风格的文章,怎么处理某类复杂任务。
这两件事做得都还不错。但有一块缺口始终没补上:用户的二次编辑。
你让 AI 写完一篇文章,最后还是要自己打开编辑器改几处,毕竟很多时候最后那 5% 的精准度,只有自己动手才能到位。就算将来 AI 再聪明,它也做不到百分百的懂你,还是少不了要手动去做修改。
于是最近 Markdown 编辑器又火了,各种 Vibe Coding 出来的 Markdown 产品满天飞。
但 Codex 不会自己做一个 Markdown 编辑器,因为每个人的偏好都不一样,做出来永远有人不满意;更何况它也不可能把每个垂直领域的专业编辑器都集成进来。
把 Agent 做成平台,让社区来贡献插件,就像 VSCode 和 Chrome 那样。
Codex 只需要聚焦在 Agent 调度这一层,把文件预览、二次编辑、垂直领域的专业能力都交给插件来扩展。用户按需安装,做设计的装设计插件,写作者装写作插件。
插件机制还能顺手解决一个长期没有答案的问题:Skill 没办法商业化。
我自己的 baoyu-skills 快 2 万 Star 了,但从中赚到的钱是 $0。Skill 这东西几乎是透明的,对 Agent 透明,对人也透明,复刻成本极低,不管你写得再好,护城河都很浅。
插件不一样。App Store 和 Chrome 插件市场已经跑通了一套收费和版权保护机制,把它移植到 Agent 插件市场完全可行。好插件可以收费,开发者才有持续打磨的动力,生态才真正能转起来。
Codex 现在已经有了一个非常原始的插件市场。从这里到成熟的收费插件生态,还有很长的路,但方向是对的。
想做这件事的不止 Codex 一家。Cursor 我能看到类似的影子。唯独 Claude Code 和 Cowork,目前没看到这个方向的产品迹象--也许他们不屑于做,也许只是还没走到这一步。
如果 Codex 真的跑通了插件生态,对中小团队意味着什么?
除了自己做一个垂直 Agent,还有另一条路:在 Codex 这样的平台上做插件。不用自己搭 Agent 调度层,不用解决 Token 接入,用户分发也靠平台。你只需要专注在那个"最后一公里"--帮用户把 Agent 生成的结果处理好、编辑好、用得顺手。
这个窗口不会开太久。先进去的能拿到冷启动红利,晚进去的只剩存量竞争。
Codex 的野心摆在那里,"几乎任何任务"这个口号要真正兑现,插件机制是绕不过去的一步。如果 OpenAI 在这件事上继续犹豫,那才是真的失误。
你觉得这个插件生态最后会是哪家先跑通?或者说你觉得有更适合 Agent 的产品表现形式?欢迎留言分享!