---

前言

很多开发团队选 AI 编程工具时，都是这样进行的：打开一张功能对比表，比谁生成的代码好、谁的补全快，挑分最高的装上。可真正用起来才发现，顺不顺手和"分数"关系不大——有人把它当更聪明的补全，有人拿它指挥一整支代理队伍，同一款工具在两种用法下体验天差地别。

差别不在模型，在"你跟它怎么协作"。2026 年，主流工具的底层模型能力已经高度接近，把用户分开的是各自的协作重心：是让 AI 待在编辑器里随时补位，还是让它接管终端去跑测试、构建、提交。

为什么"编辑器中心"和"终端中心"是两种完全不同的用法？四个主流工具各自的重心落在哪、能力差在哪？国内的工具又能不能顶上？接下来让我们一起一探究竟。

---

一、先看三种协作重心，再谈选哪个

把主流工具按"AI 待在哪、主导权给谁"归类，会发现它们落在三种重心上：

• • 编辑器中心（Cursor）：你仍然坐在编辑器里敲代码，AI 负责 Tab 补全、内联编辑、对话改代码；近几年它也长出了 Agent 模式和多智能体窗口，但根始终扎在 IDE 里。

• • 终端中心（Claude Code / Codex / OpenCode）：你把任务交出去，AI 自己读代码库、改文件、跑命令、验证结果，人退到"下指令 + 验收"的位置。三者内部又分两种节奏——Claude Code 像指挥一支代理团队（子代理可开在隔离的 git worktree 里并行干活），Codex 更像把活委托出去、做完再来审查。

三种重心没有高下，只有匹配度。终端里跑测试、构建、Git、脚本多的团队，终端中心更顺；前端、全栈这种依赖编辑器交互的场景，编辑器中心的体验更连贯。一项基于 PR 接受率的研究也提示：任务类型对结果的影响，往往比工具本身的差异更大——别指望"换个工具就翻倍"，先想清楚你的日常任务长什么样。

---

二、四个工具，各自强在哪

2.1 Claude Code：终端里的完整工程 Agent

Claude Code 是 Anthropic 的终端 Agent，核心循环是"收集上下文 → 采取行动 → 验证结果"。它的长处是配置机制最全：项目指令（CLAUDE.md）、权限模式、生命周期钩子、Skills、MCP、子代理、插件一应俱全，用户能自定义的颗粒度在几个工具里最细。

最能拉开差距的是它的多代理编排：子代理各自拥有独立上下文窗口，可以开在隔离的 git worktree 里并行干活；实验性的 Agent Teams 更进一步，让多个代理共享一份带依赖追踪的任务列表、彼此直接通信（默认关闭，需手动开启）。有公开案例称，一批 Claude 子代理协作写出了能编译 Linux 内核的十万行 C 编译器。模型侧锁定 Claude，但可以通过环境变量把请求指向兼容 Anthropic Messages API 的端点。

2.2 Codex：委派后审查，OpenAI 生态的入口

Codex 是 OpenAI 的编码 Agent，运行在本机，也和 OpenAI 账户、模型、开发者生态贴得最紧——对 OpenAI 用户来说接入成本最低。它的定位是"我先把活干了，你来验收"：任务丢进相对隔离的环境，跑完把 diff 交给你。

配置上，Codex 的插件结构覆盖 skills、mcpServers、apps、hooks，还带操作系统级的隔离原语（macOS 用 seatbelt，Linux 用 Landlock + seccomp），钩子未经信任不会自动运行、需用户审核。子代理方面，Codex 本身支持多代理（自定义代理以 TOML 文件放在 .codex/agents/，并发上限默认 6），但打包能力不如 Claude Code 完整：文档化的插件 manifest 字段不含 agents、subagents、commands，也就是"打包好的子代理定义"不能随插件分发，只能落在项目或个人配置里。

2.3 Cursor：从补全工具长成了多智能体 IDE

Cursor 是桌面 IDE，也是这两年变化最大的一个。早期它靠 Tab 补全和编辑器体验出圈，现在得按新面貌来看：

• • 有了自研模型。2026 年 3 月发布 Composer 2，主打"长周期智能体编程"——能自主处理需要数百个操作的多步任务，20 万 token 上下文，定价每百万 token 输入 0.5 美元、输出 2.5 美元，比上一代 Composer 1.5 降了约 86%，且只跑在 Cursor 内部、不对外提供 API。发布后社区发现它基于月之暗面开源的 Kimi K2.5 训练，Cursor 随后承认了这一点。

• • 有了多智能体窗口。Cursor 2.0 把界面从"以文件为中心"改成"以智能体为中心"；Cursor 3 起提供 Agents Window，可以同时管理多个在本地、worktree 或云端运行的代理。到这一步，它已经不只是一款"补全工具"。

• • 模型不只自家。Cursor 内置自研 Composer，也提供 Claude、GPT、Gemini 等精选三方模型，用 Cursor Router 按请求自动路由，用量分"自研模型"和"三方模型"两个池子计费。要留意的是，它不支持接入自选或本地的 provider——这点和 OpenCode 正相反。

• • 价格按档位来：Free、Pro 20 美元、Pro+ 60 美元、Ultra 200 美元、Teams 40 美元/人；付费档用量按额度池消耗，超出后按需计费，Auto 模式也已不再是免费无限。

2.4 OpenCode：开源，把模型选择权还给你

OpenCode 是开源的终端 Agent，差异点就一个词：自由。它可以接 OpenAI、Anthropic，也可以指向本地 Ollama，甚至任意兼容的端点。对金融、政企这类有数据不出内网要求的团队，这是 Claude Code、Codex、Cursor 都给不了的选择。代价是功能和打磨度取决于所选模型与社区进度，适合愿意自己搭、自己调的人。

---

三、能力对比：Skills、子代理、规则与模型来源

跑通一个任务不难，真正拉开效率的是"配置层"能力——能不能把团队规范、可复用工作流沉淀下来。三个工具的放置位置如下：

配置机制	Claude Code	Codex	Cursor
Skills（可复用工作流）	.claude/skills/	.codex/skills/ （新版主推 .agents/skills/）	.cursor/skills/ （也读 .claude/skills/）
子代理	.claude/agents/	.codex/agents/ （TOML，插件不打包）	.cursor/agents/
自定义命令	.claude/commands/	~/.codex/prompts/	.cursor/commands/
生命周期钩子	settings.json	.codex/hooks.json	.cursor/hooks.json
项目规则	—	—（指令统一写进 AGENTS.md）	.cursor/rules/*.mdc
项目指令文件	CLAUDE.md	AGENTS.md	AGENTS.md

几个容易被忽略的细节：

• • Cursor 的规则文件扩展名必须是 .mdc，写成 .md 没有 frontmatter，会被规则系统静默忽略——这是"配了却不生效"的常见原因。

• • Cursor 会读 Claude 的 skills 目录：.claude/skills/ 它能直接识别，跨工具复用有捷径（.claude/agents/ 是否同样兼容，各家说法不一，用前建议实测）。

• • Codex 没有独立的规则目录：指令统一写进 AGENTS.md；.codex/rules/ 是命令执行策略，别把它当规则文件用。

• • AGENTS.md 正在成为跨工具标准：Codex 原生支持，Cursor 弃用了老的 .cursorrules（仅保留兼容）转向 AGENTS.md。

一句话总结能力边界：要高级编排（子代理、命令、钩子），Claude Code 和 Cursor 最全；Codex 覆盖 skills、MCP、hooks、子代理，只是这些能力散落在项目配置里、不像前两者那样能打包成插件分发；OpenCode 则把重点放在"换模型自由"上。

四、选型建议与上手要点

4.1 一张表对号入座

维度	Claude Code	Codex	Cursor	OpenCode
形态	终端 Agent	终端 + 云端沙箱	桌面 IDE	开源终端 Agent
协作重心	指挥代理团队	委派后审查	编辑器内为主，兼有多智能体	自选
子代理 / 并行	有（子代理 + worktree，Agent Teams 实验性）	有（TOML 定义，插件不打包）	有（Agents Window）	有限
模型来源	锁定 Claude（可指向兼容端点）	锁定 OpenAI	自研 Composer + 精选三方，不支持自选 provider	多 provider / 本地
成本	Claude 订阅或 API Key	ChatGPT 订阅或 API Key	Free / Pro 20 美元 / Pro+ 60 美元 / Ultra 200 美元	开源免费，模型费自付
适合	终端工作流重	先说结论再验收、OpenAI 生态用户	前端/全栈、偏好编辑器交互	数据合规、要掌控模型来源

PR 接受率参考上几家的差距并不悬殊（一份研究里 Codex 77.9%、Cursor 74.5%、Claude Code 71.9%），再次说明"工具分数"不该是主要决策依据。

Tip

更实际的做法是：先定协作重心，再选工具，最后统一项目规则的位置、权限边界和验证标准。企业不建议一上来就全员铺开多套，选一个主工具跑顺，再按需补位。

4.2 上手其实只要三条命令

装和跑不复杂，够用就行。三个终端 Agent 都能用一条 npm 命令装齐（Codex 已是 Rust 实现，仅借 npm 分发），环境备好 Node.js（Codex 建议 22+，Claude Code 需 18+）和 Git 即可：

npm install -g @anthropic-ai/claude-code @openai/codex opencode-ai

Cursor 走官网下载安装包。终端工具装完，claude、codex、opencode 首次运行会引导登录账号或配置密钥，opencode auth login 用来选模型来源。

第一次先在小项目上让它做件小事——读一个 Service、抽一段重复代码、跑一次模块测试——感受一下它到底怎么干活，比看十张对比表都直接。

五、国内工具也值得看

上面四个都是海外工具。国内这两年同样一梯队齐整：阿里的通义灵码（基于 Qwen-Coder，中文语境和 Java/Go 后端是强项，和阿里云生态深度绑定）、字节的 Trae（AI 原生 IDE，目前免费，前端/全栈原型友好）、腾讯的 CodeBuddy（IDE + 插件 + CLI 三形态，把 PRD → 设计稿 → 代码 → 部署串成一条线）、百度的文心快码 Comate（主打 SPEC 规范驱动与多智能体），外加月之暗面的 Kimi Code 等。

这篇不把它们并进来细讲，有两个原因：

• 切面不同。本文的线索是"协作重心"——编辑器、终端、云端三种形态的张力。国内主力工具目前多是 IDE 形态（插件或 AI 原生 IDE），差异化更多落在"云生态集成"和"规范驱动"上，协作模型的对比不如这四个突出，值得单独一篇。

• 绑定更深。国内工具往往和本厂云（阿里云、腾讯云）耦合紧密，迁移、合规、计费逻辑都另成一套，硬塞进同一张表里对比，反而容易失真。

值得一提的反差是：模型层面已经出现"反向输出"——前面说的 Cursor Composer 2，底座正是月之暗面开源的 Kimi K2.5。工具可以按地域选，模型早就全球流动了。

写在最后

2026 年的 AI 编程工具，底层模型能力已经互相咬紧，竞争重心转向了插件组合、生命周期钩子、子代理编排、分发与信任这些"工程化"层面，更新迭代很快。装之前值得花十分钟翻一下各工具的官方文档，确认当前版本的行为，标准化安装、权限或自动化流程前尤其如此。

对开发团队来说，选型的落脚点很清晰：让 AI 顺着你现有的工作流干活，而不是让你去适应它。工具会换，AGENTS.md 和清晰的模型接入抽象，才是能留下来的东西。

---

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识
Claude Code、Cursor、Codex、OpenCode 怎么选？先定协作模型再定工具

---