Codex 的野心，MCP 和 Skill 的下一步 · AI HOT
宝玉@dotey66
2026-05-12 04:47·52天前
AI 摘要Codex、Claude等顶尖Agent应用均采用三栏界面，反映其从问答转向任务执行与审查的演进。Codex野心是成为“处理一切任务”的平台，但用户需二次编辑AI生成内容。目前MCP解决工具连接，Skill解决执行方法，仍缺编辑闭环。作者认为，建立类似VSCode的插件生态是合理路径，将文件预览、专业编辑等能力开放给社区开发，实现商业化，从而为中小团队提供开发垂直插件的机遇。
宝玉@dotey · X 2026-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 的产品表现形式？欢迎留言分享！