深色模式
Claude Code、Cursor、Codex 与 Antigravity 对比
如果你已经同时在用 Claude Code、Cursor、Codex、Antigravity，很容易陷入一种错觉：它们看起来都支持规则文件、都能接 MCP、都能调用工具、都能改代码，于是差别似乎只剩下模型和界面。
但从真实使用感受看，四者最大的区别并不在“有没有这些能力”，而在“这些能力被放在什么位置”。同样是 skills、MCP、项目规则、工具调用，有的工具把它们做成主工作流的一部分，有的工具把它们做成 IDE 附属能力，有的工具更强调多 agent 编排和可验证产物。对一个专业的 Vibe coder 来说，真正重要的不是选四选一，而是理解它们背后的共通结构，以及它们在同一套开发链路里各自最顺手的角色。
先说结论
这四个工具本质上都在做同一件事：把大模型从“会聊天的助手”推进成“能进入真实开发环境、读取项目约束、调用外部系统并完成任务的 agent”。
如果用一句话概括它们的主战场：
| 工具 | 更像什么 | 工作流中心 | 可复用能力的主要形态 | MCP 的位置 |
|---|---|---|---|---|
| Claude Code | 终端里的 agent 操作台 | Shell、仓库、任务拆解 | CLAUDE.md、SKILL.md、subagents、plugins | 原生主轴，和 skills、plugins 结合很深 |
| Cursor | IDE 里的 agent 平台 | 编辑器、聊天面板、Cloud Agents | Rules、Skills、AGENTS.md、Commands | 原生主轴，且与 IDE、Cloud Agents 深度整合 |
| Codex | OpenAI 体系下的终端 + IDE coding agent | CLI、IDE extension、配置链 | AGENTS.md、config.toml、MCP、subagents | 原生支持，但表达方式更偏配置与会话控制 |
| Antigravity | agent-first 的开发平台 | Manager Surface、异步代理、Artifacts | knowledge base、任务产物、平台内 agent 记忆 | 公开资料显示生态明显拥抱 MCP，但主叙事更偏 agent 编排与验证 |
所以，四者不是简单的替代关系，更像是同一代 AI 开发栈的四种前端。
它们相通在哪里
如果站在工具设计层去看，这四个产品共享的是同一套能力模型。一个成熟的 AI 开发工具，通常都需要解决下面五层问题。
第一层是上下文层。模型默认并不记得你的仓库，也不理解你的团队约束，所以需要一个长期存在的入口把项目背景、目录结构、命令约定和禁区灌进去。Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md，Cursor 同时支持 Rules 和 AGENTS.md，Antigravity 的公开表述则更偏向可持续积累的 knowledge base。
第二层是能力层。模型不只是读文本，还要会调用终端、浏览器、设计稿、数据库、工单系统和文档系统。这里四者都在走向同一个方向：让 agent 不再困在纯文本对话里，而是进入真正的工具环境。
第三层是工作流层。不是每个任务都适合“问一句，回一句”。复杂任务需要拆解、并行、验证、恢复上下文，甚至需要异步跑很久。Claude Code 有 subagents 和面向任务的 skills，Cursor 有本地 Agent 和 Cloud Agents，Codex 也把 CLI、IDE 和 Cloud task 连接起来，Antigravity 则把多 agent 编排直接做成核心界面。
第四层是约束层。工具不仅要“能做”，还要“按你的方式做”。因此 Rules、Skills、AGENTS.md、权限控制、工具白名单、审批机制，都是这类产品的核心，而不是边角功能。
第五层是验证层。AI 真正进入生产工作流之后，最重要的问题不是“它会不会写”，而是“你如何信任它写的东西”。Claude Code、Cursor、Codex 都在往更细的工具调用可见性、权限审批、会话控制上走；Antigravity 则更进一步，把 Artifacts 作为主要反馈界面，用截图、录像、计划和中间产物代替原始日志。
从这个角度看，四者的相通点远多于表面上的品牌差异。
从专业 Vibe coder 的角度看，真正要比较什么
老手在意的通常不是“哪家能生成代码”，而是下面这些问题：
- 我怎样把自己的工作习惯沉淀进去，而不是每次重讲一遍。
- 我怎样把外部系统接进来，让 agent 直接拿到数据库、工单、浏览器、设计稿和线上信息。
- 我怎样控制它改动的边界，避免它一上来把整个仓库搅乱。
- 我怎样在同步编辑、异步执行、并行代理之间切换。
- 我怎样在结果可见、可验证、可复盘的前提下，把更多任务交给它。
而 Claude Code、Cursor、Codex、Antigravity 的差别，恰好就是围绕这几件事展开的。
Skills、规则与项目记忆：目标相同，实现不同
如果只看表面，你会觉得它们都支持“长期记忆”或“可复用工作流”。这没错，但四者对这件事的理解并不一样。
Claude Code：把 skills 做成一等能力
Claude Code 在这方面是非常明确的。它不只是支持 CLAUDE.md 作为项目记忆，还把 SKILL.md 做成正式机制。skills 可以自动触发，也可以通过 /skill-name 手动调用；它不仅能写指令，还能带 supporting files、脚本、模板，甚至能指定模型、允许的工具和是否在 forked subagent 里运行。
这意味着在 Claude Code 里，CLAUDE.md 更像稳定背景，skills 更像可复用工作流。前者回答“这个项目是什么、怎么做事”，后者回答“遇到某类任务时，按什么流程执行”。对终端重度用户来说，这种分层非常顺手。
更重要的是，Claude Code 的 plugins 还能把 skills、agents、hooks、MCP servers 打包在一起。也就是说，它不是单独提供几个零散特性，而是逐渐形成一个以 agent 为中心的可扩展运行时。
Cursor：Rules 和 Skills 并存，更偏 IDE 工作流
Cursor 的思路和 Claude Code 很接近，但它明显更贴近 IDE 心智。
它把短约束放进 Rules，把长流程放进 Skills。Rules 更像系统级指导，支持 .cursor/rules、用户规则、团队规则，以及 AGENTS.md。Skills 则是面向多步骤流程的复用单元，支持 /create-skill 创建，也能通过 /skill-name 或 @skill-name 调用。
一个很值得注意的细节是，Cursor 不只支持自己的 .cursor/skills/，还会兼容 .claude/skills/、.codex/skills/ 这类目录。这说明 Cursor 在产品设计上已经默认承认：未来不是每个工具都维护一套完全隔离的 agent 工作流格式，而是会出现跨工具迁移和复用。
所以如果你已经是多工具用户，Cursor 在“承接不同规则体系”和“把这些能力揉进 IDE 日常编辑”方面，会显得非常自然。
Codex：更偏 AGENTS.md + 配置链，而不是把 skills 单独抬出来
Codex 也支持长期指导和可扩展能力，但它的表达方式更偏 OpenAI 风格的配置链。
官方公开资料里，Codex 把 AGENTS.md 放在很重要的位置，并且支持从全局目录到项目目录再到子目录的分层发现与覆盖。再加上 config.toml、CLI/TUI、IDE extension、approval mode、subagents，这套体系非常完整。
但和 Claude Code、Cursor 相比，Codex 当前更突出的不是“把 skills 当作一等原语”，而是把项目指导、MCP、会话配置和代理执行组合成一套统一工作流。也就是说，你当然可以在 Codex 里沉淀套路，但它更像是通过 AGENTS.md、配置项和工具集成来完成，而不是像 Claude Code 那样把 skill 设计成一个非常显性的中心概念。
对于同时使用多家工具的人，这一点很重要：在 Codex 里，你关注的不是“有没有 skills 按钮”，而是“我能否把指导、工具和执行链组织成一套稳定模式”。答案是可以，只是形态不同。
Antigravity：公开叙事更偏知识沉淀与 agent 编排
从公开资料看，Antigravity 的重点并不是把 skills 作为一个文件系统级原语摆在前台，而是把“学习”和“任务产物”做成平台能力。
它强调 agents 可以把有用的上下文和代码片段保存进 knowledge base，用来改善后续任务；同时强调 Manager Surface、Artifacts、异步多 agent 和跨 editor、terminal、browser 的端到端执行。也就是说，Antigravity 更像是在把“经验沉淀”做成平台级记忆和任务编排能力，而不是先让你手工维护一堆规则文件。
因此，如果你用惯了 Claude Code 或 Cursor，到了 Antigravity，最需要调整的不是 prompt，而是视角。你面对的不只是一个会写代码的聊天框，而是一个把任务分发、执行、验证和记忆整合在一起的 agent 平台。
MCP：四者都支持，但地位并不一样
如果说项目规则解决的是“让模型知道该怎么做”，那么 MCP 解决的就是“让模型真的有东西可用”。
这四个工具都在拥抱 MCP，但拥抱的方式不完全一样。
Claude Code：MCP 已经进入主工作流
Claude Code 对 MCP 的支持非常深。它不仅原生支持本地 stdio、远程 HTTP、SSE 等方式接入 MCP server，还把 MCP 和 plugins、channels、skills 放在同一套 agent 体系里。
这会带来一个非常明显的体验差异：在 Claude Code 里，MCP 不是“给聊天框加几个外部接口”，而是 agent 真正的能力扩展层。你可以让它接工单、查监控、读数据库、拉设计稿、监听外部事件，再结合 skills 和 subagents 去完成更复杂的链路。
所以 Claude Code 的强项，不只是“支持 MCP”，而是它把 MCP 接进来之后，能自然进入任务执行流。
Cursor：MCP 深度绑定 IDE 和 Cloud Agents
Cursor 对 MCP 的支持同样成熟，而且它的一个优势是把 MCP 直接放进 IDE 和 Cloud Agents 这两个场景。
本地聊天面板里，Agent 可以直接使用 MCP tools；Cloud Agents 也能在隔离环境里继续使用这些外部能力。官方文档还明确列出了对 Tools、Prompts、Resources、Roots、Elicitation 以及 MCP Apps 的支持，这比很多“只支持调 tool” 的集成更完整。
这意味着 Cursor 的 MCP 更适合做两件事：一是在 IDE 里快速把外部上下文带进当前编辑任务，二是在异步云代理里把外部系统整合进长任务执行链。对于需要边改代码、边查需求、边看设计、边跑浏览器验证的人来说，这种一体化很实用。
Codex：MCP 是统一 CLI 与 IDE 的扩展接口
Codex 的特点在于，CLI 和 IDE extension 共用同一套 MCP 配置。你在 config.toml 或 .codex/config.toml 里配好的 server，可以同时服务终端和 IDE。
这个设计听起来朴素，但对多工具老手非常关键。它意味着你不需要把“终端模式”和“编辑器模式”当成两套完全不同的系统维护。只要你的工作主线已经围绕 Codex 的配置链建立起来，MCP 就会成为两个入口共享的能力底座。
因此，Codex 的 MCP 更像一层稳定基础设施，而不是一个 UI 功能点。
Antigravity：更强调 agent-first 平台与可验证执行
截至目前公开资料，Antigravity 的官方叙事重点仍然是 editor + manager surface + artifacts + 多 agent 编排，而不是像 Claude Code、Cursor、Codex 一样，把用户级 MCP 配置细节讲得很展开。
但它所处的 Google 生态正在明显拥抱 MCP，例如官方已经推出了面向开发文档和公共数据的 MCP server。把这些信号放在一起看，Antigravity 的方向很清楚：它不是排斥 MCP，而是把 MCP 看成更大 agent 平台中的一个接入面。
所以在 Antigravity 身上，MCP 更像“平台能力的一部分”，而不是用户感知最强的主角。你最直接感受到的，往往不是 server 怎么配，而是 agent 如何在 editor、terminal、browser 之间连续工作，以及如何通过 Artifacts 向你汇报结果。
真正决定体验差异的，不是功能表，而是工作流中心
同样支持规则、skills、MCP 和工具调用，为什么四者用起来还是很不一样？因为它们的工作流中心不同。
Claude Code 的中心是终端会话。你会很自然地把它当作一个进入仓库、读规则、调工具、拆任务、跑命令的 agent 操作台。它适合那些已经习惯 shell、git、脚本和命令式工作流的人。
Cursor 的中心是IDE 协作。它的很多能力不是孤立存在，而是和编辑器上下文、文件选择、Rules、MCP、Cloud Agents 串在一起。你在 Cursor 里会更频繁地体验到“边看代码边调 agent”的连续感。
Codex 的中心是统一的 agent 配置链。它既能在 CLI 里跑，也能在 IDE extension 里跑，还能共享 AGENTS.md 和 MCP 配置。这种设计对希望在不同入口下保持同一套操作习惯的人很有吸引力。
Antigravity 的中心是任务编排与验证。你不是主要围着会话转，而是围着任务、agent、Artifacts、Manager Surface 转。它适合那些希望把 AI 从“协助写代码”进一步升级成“并行推进任务系统”的用户。
这也是为什么一个成熟用户往往不会只用其中一个工具。
联系比差异更重要的地方
如果你同时使用这四个工具，最有价值的认知升级其实是：不要把它们看成四个互斥竞品，而要把它们看成四种不同的 agent 交互壳。
你可以把它们理解成围绕同一套底层理念展开：
- 用规则文件或长期记忆，让模型持续理解项目。
- 用
skills、命令、模板或知识库，让经验变成可复用流程。 - 用 MCP 把数据库、文档、设计稿、浏览器、工单和线上系统接进来。
- 用审批、权限和验证产物控制风险。
- 用多 agent、云代理或异步任务放大吞吐量。
当你把它们放进这个统一框架里之后，很多“功能对比”就会变得不那么重要。真正重要的是：哪一个更适合作为你当前这一步的外壳。
一个更实用的分工视角
如果让我用专业 Vibe coder 的视角给它们分工，我会这样看：
- Claude Code 适合做“仓库内、终端驱动、步骤清晰”的重执行任务，尤其适合把规则、skills、MCP 和 shell 命令组合成稳定流程。
- Cursor 适合做“IDE 内持续协作”的主力环境，特别适合边编辑边调用外部上下文，或者把本地工作切到 Cloud Agents 做异步延伸。
- Codex 适合那些希望在 OpenAI 生态里同时拥有 CLI 和 IDE 两个入口、并保持同一套
AGENTS.md与 MCP 配置的人。 - Antigravity 适合把 agent 当成真正的后台执行者来管理，尤其是需要多 agent 并行、浏览器验证和基于 Artifacts 审核结果的时候。
换句话说，四者并不是谁覆盖谁，而是谁在不同工作段里更顺手。
什么时候该切换，什么时候该组合
一个常见误区是：总想选出“唯一主力工具”。但对已经进入多 agent 开发阶段的人来说，更现实的做法是组合使用。
例如，你可以在 Cursor 里完成日常编辑和局部协作，把复杂终端任务交给 Claude Code，把需要统一 OpenAI 工作流的仓库交给 Codex，把长时间后台推进、需要多代理和可视化验证的任务放进 Antigravity。
这时你的判断标准就不再是“谁功能更多”，而是：
- 当前任务更依赖终端、IDE、还是异步编排。
- 你更需要严格控制步骤，还是更需要平台帮你组织任务。
- 你需要的是即时对话产出，还是可审核的中间产物。
- 你的团队已经把规则和工具链沉淀在哪一套体系里。
一旦这样思考，四个工具之间的联系就会变得非常清楚。
最后的判断
Claude Code、Cursor、Codex、Antigravity 代表的不是四条完全独立的路线，而是同一代 AI 开发基础设施的四种实现重点。
Claude Code 最像“终端 agent 运行时”，Cursor 最像“IDE 中枢”，Codex 最像“统一 agent 配置链”，Antigravity 最像“agent-first 任务平台”。它们都在把规则、MCP、工具调用、长期记忆和执行验证这些原语重新组织，但组织方式不同，于是工作流感受就不同。
对同时使用这四个工具的人来说，最值得建立的不是某个单品偏好，而是一种更抽象的判断力：你要先看当前任务最需要哪一种交互壳，再决定让哪个 agent 上场。