[控场AI]
· 12 分钟阅读· 6,423 字

AI编程工具怎么选?六大阵营全解析

AI编程工具怎么选?六大阵营全解析

AI编程工具并非同类产品,应按智能体所住的六大阵营和生命周期场景选型,而非排名。

文章提出,把AI编程工具放一起排名本身是个错误问题,因为它们是不同类型的工具。核心区分在于模型与Harness:模型是引擎,Harness决定工具调用、上下文、运行位置、记忆和权限,当前多数产品差异来自Harness层。作者按“智能体住在哪里”将其分为六大阵营:编辑器内、终端、驾驶舱、云端队友、围绕代码的工作、给构建者的工具,并指出没有任何单一工具覆盖完整生命周期,多数团队需组合两三种。文章还强调MCP、AGENTS.md、Skills等跨工具标准正在收敛,构成可迁移投资;同时提醒认真对待厂商自身的安全警告。选型建议是做真实工单的小规模实测,核心指标是“每个被接受功能的成本”。

AI编程工具层出不穷,每周都有新产品冒出来。面对DeepSeek Harness、GitHub Copilot、Cursor、Claude Code、Codex等众多选择,开发者最常问的问题是:哪个最好?但YouTube频道RebelLion Labs在最新视频中给出了一个反直觉的答案——这个问题本身就问错了。这些工具并非同一类产品,把它们放在一起排名,就像拿螺丝刀和电钻比谁更好用。

核心概念:模型是引擎,Harness才是关键

在讨论具体工具之前,需要先厘清一个被普遍混淆的概念。模型是引擎,而Harness是引擎周围的一切——智能体能调用哪些工具、读取什么上下文、在哪里运行、记住什么、无需确认就能做什么、何时必须停下来等待人类。

这就解释了为什么两个产品使用相似的模型,体验却截然不同。据RebelLion Labs分析,当今大多数真正的差异恰恰来自Harness层。行业动向也印证了这一点:Google将其Anti-Gravity SDK描述为在Anti-Gravity Harness上构建自定义智能体的方式,DeepSeek广告更是直接把产品命名为DeepSeek Harness。

工具分类不是按公司名划分

**MCP(Model Context Protocol,模型上下文协议)**是 Anthropic 于 2024 年底开源的一项标准,用于让 AI 应用以统一方式连接外部数据源和工具。它采用客户端-服务器架构:AI 应用作为客户端,通过标准接口调用 MCP 服务器暴露的工具、资源和提示词;MCP 服务器则封装对数据库、API、文件系统等自有系统的访问。文章提到它已被 Claude Code、Copilot、Cursor、Kiro 和 Codex 广泛采用,这意味着开发者只需实现一次 MCP 服务器,就能让多个不同的 Harness 复用同一套工具接入,而不必为每个产品单独写集成。这正解释了为何文章将它列为“可迁移投资”的一部分。

AGENTS.md 是一个放在仓库中的项目指令文件,用自然语言记录项目的构建命令、代码约定、测试方式和注意事项,供 AI 智能体在开始工作前读取。它相当于给智能体的“入职手册”,使不同工具在同一项目中表现一致。Codex 原生使用该文件,Claude Code 也能读取它来替代自身的 CLAUDE.md,这降低了跨工具切换时的重复配置成本。

六大阵营:按“智能体住在哪里”分类

RebelLion Labs按一个简单问题对工具进行分家族:智能体住在哪里?它为谁工作?这套分类法覆盖了从规划到运维的完整软件生命周期,而且同一厂商往往同时推出应用、CLI、IDE插件和云端智能体,所以这些家族是体验类型而非公司名称。

第一家族:编辑器内的智能体

这是大多数开发者的起点。Cursor自称“AI编辑器与编程智能体”,具备Plan模式、规则、技能和MCP服务器。GitHub Copilot在IDE中提供Agent模式和Plan模式,后者会在改代码前先起草实施方案供审阅。Kiro将规格文档置于核心位置,强调需求、设计和任务,并配有Steering文件和Hooks。Google Anti-Gravity则是一个完整的智能体IDE。

优势是反馈回路最短——你可以在工作现场实时看到每一次diff,非常适合构建功能和熟悉代码库。劣势则在于它绑定你的机器和注意力:你不再盯着屏幕时,工作通常也就停了。对团队来说,切换编辑器的成本是实打实的。

第二家族:终端里的智能体

终端家族的最大特点是可脚本化。Claude Code能读取代码库、编辑文件、运行命令、提交commit并打开pull request,官方文档甚至展示了将git diff管道输入进行安全审查的用法。OpenAI的Codex CLI和Google的Gemini CLI均以Apache 2协议开源,GitHub有Copilot CLI,全开源阵营还有OpenCode、Kilo和Aider。

终端的优势在于可组合性——智能体可以跑在脚本和CI流水线中。Claude Code文档覆盖了GitHub Actions和GitLab管道,Codex列出了GitHub Action。开源智能体通常允许自带模型并审查代码。代价是可视化程度较低,且配置需要自己搞定;选择开源项目时务必确认其仍在积极维护。

第三家族:智能体驾驶舱

这是最新也最受关注的家族——桌面应用形态,让你同时监督多个智能体。据视频介绍,GitHub Copilot桌面应用面向智能体驱动开发,每个会话属于一个项目并在独立分支上隔离运行,可以同时跑多个。它有一个浏览器画布,支持“Pick and Polish”选取页面元素作为下一次请求的上下文;Agent Merge则处理pull request上的评审反馈、CI失败和合并冲突,但最终合并决策仍由人做出。

在驾驶舱中可同时运行多个智能体

同类产品还包括:Claude Code桌面应用支持多会话并排、定时任务和云端会话;Codex横跨ChatGPT桌面端、网页端、移动端以及CLI、IDE扩展和云端;Google Anti-Gravity应用是多个本地智能体并行工作的指挥中心;Cognition的Devin桌面端号称从单一界面管理本地和云端智能体集群。值得一提的是,windsurf.com现在会直接跳转到Devin。自托管用户则可关注OpenHands的Agent Canvas,它能在笔记本、Docker或自有服务器上运行OpenHands、Claude Code、Codex、Gemini CLI或OpenCode。

驾驶舱的短板在于人成为瓶颈——五个智能体产出五个pull request的速度,远快于一个人认真评审的速度。

第四家族:云端队友

这是最贴近运维的形态:分配任务、合上笔记本、回来收获一个pull request。GitHub的Copilot云智能体在临时云环境中工作,从issue、pull request或聊天中启动,每个任务对应一个分支和一个pull request。其文档给出了罕见的精确数字:单次会话最长运行59分钟,且仅支持托管在GitHub上的仓库。

Cursor的云智能体运行在隔离虚拟机中,可大量并行,并能从Slack、GitHub、Linear或API启动,返回pull request的同时附带截图、视频和日志作为验证证据。Claude Code有网页会话和云端例程,能在Slack中通过bug报告直接换回pull request。Codex有Codex Cloud,Devin则自称自主AI软件工程师,可在Slack、Teams、Linear或Jira中召唤并返回草稿pull request。

云端队友的优势是工作不依赖你的机器,最优秀的实现会展示证据而非仅给代码。代价是成本与配置:Cursor按模型API价格计费云端智能体并要求设置消费上限,每个云智能体都需要带依赖和密钥的可运行环境。GitHub官方文档写得很直白:在生产环境使用前请审查并测试输出。

**临时云环境(ephemeral cloud environment)**指为每个任务临时创建的、用完即弃的隔离运行环境,通常以容器或虚拟机形式提供,预装项目依赖、代码仓库和必要的密钥。GitHub Copilot 云智能体、Cursor 云智能体都采用这种模式:每次会话从干净状态启动,任务完成后环境被销毁,从而避免不同任务之间的状态污染,也便于大规模并行。代价是每个环境都必须可重复构建——依赖安装、密钥注入、测试数据库等都要自动化配置好,否则智能体一启动就会失败。这也是文章强调“每个云智能体都需要带依赖和密钥的可运行环境”的原因,它对团队的工程成熟度提出了比本地工具更高的要求。

第五家族:围绕代码的工作

ChatGPT Work和Claude Cowork并不属于编程工具,而是处理代码周边工作的智能体。ChatGPT Work被描述为委派真实工作的方式——简报、演示、分析、周期性更新,可运行在桌面端处理本地文件和应用,或在云端通过GitHub、Slack、Google Drive、SharePoint等插件工作。OpenAI称其核心能力与Codex相同,只是体验面向日常工作设计。Anthropic则将Cowork描述为把Claude Code的智能体能力带给知识工作,无需终端,包含项目、定时任务、子智能体和三种权限模式(手动、自动、跳过)。

办公套件同样在智能化。微软365 Copilot在Word、Excel、PowerPoint、Outlook和Teams内工作,高级许可下通过Microsoft Graph和WorkIQ以组织数据为依据生成答案。

微软365 Copilot高级许可下的数据接入

微软文档还列出了跨Microsoft 365执行任务的Copilot Cowork和仍处于Frontier Preview的Copilot Code。Gemini for Google Workspace在Gmail、Docs、Sheets、Drive和Meet中做同样的事,配合Gemini Notebook做基于来源的研究。Manus则提供幻灯片、网站和所谓“wide research”的智能体。选择这类工具的建议很朴素:选那个住在你文档、邮件和会议所在地的——为副手切换生态体系很少划算。

第六家族:给构建者的工具

这一家族不是拿来用的,而是拿来建造的。DeepSeek Harness是DeepSeek开源的智能体Harness,MIT协议,口号是“一切皆插件”。它提供网页UI或桌面应用,可使用DeepSeek模型或OpenAI兼容端点,并有通过对话构建插件的创造者模式。它对自己的状态相当坦诚:这是开发者预览版,README用大写字母写明“会有破坏兼容性的变更”。

同类构建套件还有Claude Code的Agent SDK、Google Anti-Gravity SDK(支持Python原型与评估)、作为SDK分发的Kilo,以及可与任意模型配合的开源OpenHands。构建者套件的优势是对模型、工具、权限和成本的完全控制,劣势是所有责任也归你。DeepSeek自己的安全声明承认该Harness未经过安全审计,建议在一次性虚拟机或容器中以最小权限运行。

生命周期全景与跨工具通用件

把六个家族摊到软件生命周期上看:规划阶段有Kiro这类规格优先工具、Copilot和Cursor的Plan模式以及工作类智能体;构建阶段是编辑器和终端智能体;验证阶段依赖云端环境运行测试并产出截图视频等证据;评审阶段有Copilot、Claude Code和Codex的代码评审;合并阶段有Agent Merge追CI失败和冲突;运维阶段则是定时例程、周期任务和从Slack bug报告变成pull request。

有意思的是,没有任何单一工具在每一个阶段都同样出色,多数团队会组合两三种——这既是视频的判断,也是这张全景图的自然结论。

更积极的信号是底层接口正在收敛。**MCP(Model Context Protocol)**出现在Claude Code、Copilot、Cursor、Kiro和Codex中;AGENTS.md是Codex使用的项目指令文件,Claude Code也能读取它来替代自己的CLAUDE.md;**技能(Skills)**这种可打包重复工作流出现在Claude Code、Copilot、Codex和Cursor中。

这意味着存在一个可迁移的投资结构:清晰的规格文档、写好的AGENTS.md、为自有系统准备的MCP服务器、以及能证明行为的测试。无论明年哪个Harness胜出,这些资产都保值。如果你的系统还不支持MCP,也不必慌张——已有的API契约、OpenAPI文件(很多人仍叫它Swagger)或工作流定义,本身就是很好的起点。视频中提到的Hoopy CLI正是做这件事:指向契约,即提供一个MCP服务器。

指向API契约即可生成MCP服务器

厂商自己的安全警告值得当真

视频引用了三句厂商原话:GitHub说“在生产环境使用前请审查并测试输出”;Anthropic谈Cowork时说“因其智能体性质和互联网访问而存在独特风险”;DeepSeek说“未经过安全审计”。当厂商自己写下这些,就应当认真对待:使用权限模式、设置消费上限、给智能体最小必要权限、让密钥远离其触及范围、并且始终保留人类在合并按钮上的最终决定权。

**权限模式(permission modes)**是 Harness 用来控制智能体自主程度的机制,通常分为几档:手动模式下每次文件编辑或命令执行都需人类确认;自动模式下智能体可在一定范围内自行操作;跳过模式则几乎不做拦截。文章提到 Claude Cowork 提供手动、自动、跳过三种模式,Copilot 和 Cursor 也有类似的审批与沙箱设置。合理使用权限模式的意义在于风险分级:探索性、只读的任务可以放开自主度以提高效率,而涉及生产配置、密钥或不可逆操作的任务则应留在手动确认档。配合消费上限和最小权限原则,权限模式构成了把“厂商安全警告”落到实处的操作抓手。

怎么选:按场景而非按排名

以下是视频给出的建议框架(原视频明确标注为主观意见):代码和pull request在GitHub上的,从Copilot应用及其云智能体开始;需要可脚本化并跑在CI里的,看Claude Code、Codex和Gemini CLI;以编辑器为中心的,试Cursor、Kiro或Anti-Gravity;需要开源、自有模型或自托管的,看OpenCode、Kilo和OpenHands;痛点在研究、文档和报告的,按文件与账户所在地在ChatGPT Work、Claude Cowork、Microsoft 365 Copilot或Gemini for Workspace中选;要搭建智能体平台的,从DeepSeek Harness、各家Agent SDK或Anti-Gravity SDK入手。

但不要相信任何排名,包括这个。更可靠的办法是做一场小规模实测:取一个真实的中等规模工单,带验证和测试,分给两三个工具各跑一个分支,然后测量真正重要的指标——到已验证pull request的时间、人工介入频率、测试通过率、评审中发现的缺陷数、总成本,以及每个工具从失败中恢复的能力。如果只保留一个数字,就用“每个被接受功能的成本”:AI、算力、评审和返工的总成本除以实际接受的功能数。这比任何基准图表都更有说服力。

这是一个时间点的快照。名称会变,项目会合并或归档,但六大阵营——编辑器、终端、驾驶舱、云端队友、围绕代码、自建——大概率会留存。下一个闪亮的新应用出现时,问同样的三个问题:智能体住在哪里?我的生命周期哪个阶段还没改善?它需要我提供什么才能被信任?

选对任务的Harness,用它构建,验证一切,安全交付。

分享:

相关推荐