一、全文速览图
AI圈又冒出一个新词：Vibe Coding。这词儿是Andrej Karpathy在2025年2月的一条推文里提出来的，原话是：“There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
推文一出，迅速炸开。不是因为它有多精准，而是因为它击中了一大批人——那些能想清楚要做什么，但一直被“不会写代码”卡住的产品、运营、设计。它给了这件事一个名字，顺手把一个感受变成了行动的许可。
到了2026年，Karpathy自己补了一句：Vibe Coding只是抬高了地板。地板一高，入场的人自然就多了。接下来的问题，就不是“要不要用”，而是“用什么、怎么用”。
二、落地现状：工具爆发与选型困境
Vibe Coding正在公司里落地。大厂的设计师开始自己写前端组件，不用等工程师排期；PM直接搭交互原型，省掉无数轮口头需求沟通；运营用Agent做数据脚本，不再等人。这不是替代岗位，而是每个岗位多了一种以前没有的动手能力。独立开发者这边更直接，一个人从0到1做完一个完整的APP和Web端产品——这些都是已经真实发生的事。
但问题也跟着来了。
Vibe Coding的工具现在太多了。Claude Code、Codex算是头部，国产这边豆包、Work Buddy、Kimi Code也都在跑；还有各种开源Agent框架，数量仍在增加。对刚入场的人来说，选择眼花缭乱，不知道从哪里下手。
拿豆包、Kimi Code、Work Buddy这类国产工具举例，提示词写得不够精细，它就给你跑偏，投入的精力反而比手写代码还多。这种情况出现时，问题不一定出在AI本身，很可能是工具选错了。工具能力上限不够，或者搭配方式不对，就只能靠越来越精细的提示词来补，越来越累，也越来越低效。
市面上这么多Vibe Coding工具，根本原因在于这些框架各自的定位不同，没有哪个Agent能放之四海而皆准。选型没做好，工具再多也是负担。所以，第一个要搞清楚的问题是：这些Agent框架到底有什么差别？
三、工具盘点：主流Agent概览
按生态位分，市面上的Agent产品其实只有两大阵营。
第一阵营是模型厂商的嫡系：Anthropic的Claude Code、OpenAI的Codex。这些Agent产品，模型、Agent、订阅一体化，Agent是模型的分发入口，所以全平台铺开，VS Code插件只是标配。
第二阵营是模型中立的开源工具，谁的模型都能接，靠社区生态活着，形态各不相同：Pi是终端编码Harness，Open Claw和Hermes Agent是个人助理网关，挂在消息平台上用，Maka是本地优先的桌面工作空间。
这个阵营内部已经卷起来了：Open Claw跑在Pi的SDK上，Hermes Agent内置了一键从OpenClaw迁移的命令。
1. Claude Code
从零搭一个项目，Claude Code是目前最顺手的选择。相当于出厂预装了一个经验丰富的项目经理，帮你想架构、定规范、查安全，什么都安排好了，开箱即用。告诉它做一个用户管理系统，它会自己想路径、拆模块、写文件，不用手把手喂每一步。适合从0到1的阶段，因为它会主动思考，能在没有明确指令的地方自己做判断。
2. Codex
指哪打哪。给它明确指令，它按边界执行，不多做，不少做。你说把这个函数的返回类型改一下，它就只动那一块，不会顺手改周围的代码。它有多模态能力，能生成图片。适合从1到N已有稳定基底的项目，做定点修改、局部重构、单文件精调。但从零搭一个中大型项目基本搭不起来，它需要先有一个架构撑着，不能让它从地基开始想。
3. Pi Agent
像一张极度空白的画布。什么都能接，模型随意换，规则自己定，还能挂上Claude Code那套Skill体系。开源不锁定模型，把自由度完全还给用户。适合已经有自己工作流、想要灵活控制权的用户。新手慎入，没有一套配置好的工作流，就是一堆零件摆在那里。
4. Open Claw
本地高权限执行，能看屏幕、操作本地应用，不只是写代码。技能市场ClawHub里有覆盖开发、设计、市场的现成Skill。但有两个缺点：Token消耗极高，跑起来成本远比其他Agent贵；真正好用需要先“养好”它，做SFT微调，开箱即用体验不突出。适合隐私敏感场景、需要自动化本地任务的场景，接受高门槛才值得上手。
5. Hermes Agent
越用越懂你的私人助手。核心是任务做完后会把这套操作路径自动记成Skill，下次同类任务直接调用，不用重新教。开箱带了不少现成能力，终端和飞书里说的话是同一个大脑在接。越用越顺手是真的，适合想要长期稳定伴侣型工具、不愿意每次都从头教Agent的场景。
6. Maka Agent
由jakevin7个人开发的轻量编程Agent，跑在本地，代码不出机器。极简是它的哲学，提示词能少就少，反而跑得更准。搭配Kimi K3跑过一次编程自主完成率的评测，比官方Kimi Code高了10个点。Anthropic自己也做过类似的删减实验，结论指向同一个方向。适合代码隐私敏感、想要极简工作流的用户。
四、Agent框架选型：Benchmark
聊了这么多Agent各自的优点，接下来该说选型的方法论了。选型走四步：定场景、定维度、跑测试、算成本。顺序不能乱。
这里我们挑两个顶级模型厂商的Agent和一个最典型的开源Agent来说——Claude Code、Codex和Pi Agent。选型思路分四步，顺序不能乱。
第一步，定场景，也是最容易被跳过的。先搞清楚自己的核心场景：是从零搭一个新项目，还是在已有代码库里做修改？是一个人干，还是和团队一起开发？场景没搞清楚，后面看再多数据都是白搭。
第二步，定维度。对个人开发者来说，三个维度最值得看。
一是任务完成率，也就是Agent解决真实编程问题的能力。目前最接近真实开发场景的公开评测有两套：SWE-bench Verified，拿真实的GitHub bug单子考Agent，看它能解决多少，相当于用真实工作任务给Agent打分；Terminal Bench，看Agent在命令行里能独立干多少任务，不需要你手把手操作。跑下来是这样：写代码能力两者基本打平，SWE-bench上Claude Code是88.6%，Codex是88.7%，差0.1个百分点。命令行操作上差距就拉开了，Terminal Bench 2.0上Codex是82%，Claude Code是69.4%，涉及终端操作Codex明显更稳。写代码打平，自动化操作Codex占优。
Pi Agent没有独立成绩，因为它是工具框架，不绑定任何模型，成绩取决于你接的底层模型。这是设计选择，不是缺陷。
二是上下文效率，可以简单理解成Agent一次能记住多少项目背景。窗口越大，能同时处理的代码量越多。Claude Code和Codex量级差不多，关键差异在内置系统指令。Pi Agent这块只占了极少量的400 Token的提示词，把几乎所有空间都留给了项目代码。Anthropic刚好在前不久砍掉了80%的系统提示词，和Pi的方向不谋而合。
三是成本效率比。Codex完成相同任务的Token消耗大约是Claude Code的四分之一；Pi Agent完全不绑定模型，哪个便宜好用就接哪个，成本弹性最高。
第三步，跑测试。把自己真实的任务类型拿去跑，比看任何评测数据都直接。冷启动任务、精修任务、跨文件重构任务分开测，每类场景下三个Agent的行为差异会很明显。
第四步，算成本。把日常使用频率乘上单次Token消耗，换算成月度费用，再比订阅价格。算清楚再选，不要靠感觉。
按这四步走下来，结论是：终端密集型任务Codex占优；代码理解任务Claude Code和Codex两者打平；上下文效率Pi Agent最轻，给项目代码留的空间最多；成本弹性Pi Agent最灵活，Codex Token效率最高。答案很明显：没有一个选项能够通吃。
实际选法往往是：从0到1规划的冷启动用Claude Code，从1到N的精修和终端密集型任务切Codex，个性化工作流走Pi。不是选最好的，是按任务类型分工。
五、多Agent协作：VS Code工作区搭建
有没有可能把这些Agent都集成起来，更好地发挥它们的优势？最后测了很多工具，发现VS Code + 多Agent合作，是最舒服的。
先说VS Code是什么。它是微软开源的代码编辑器，本质是一个容器，里面的Extension市场里有几万个插件可以接进来，语言支持、调试工具、AI助手全部通过插件形式运行。Claude Code、Codex、Pi Agent等等都在这个市场里有对应的插件，装进同一个编辑器，三个Agent共享同一份项目文件和工单，不需要在多个窗口之间来回切换。
整套工作台搭建分五步。
第一步，安装VS Code。去code.visualstudio.com下载对应系统的安装包。装好之后打开扩展市场（快捷键Ctrl+Shift+X，Mac上是Cmd+Shift+X），搜“Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code”安装，重启一遍，界面就切成中文了。
第二步，接入Claude Code。在扩展市场搜“Claude Code for VS Code”，点安装。安装完成后按引导用claude.ai账号登录授权。左侧边栏会出现Claude Code的入口，点进去是聊天面板，可以直接对话，也可以在编辑器里选中代码后唤起它。
第三步，接入Codex。在扩展市场搜“Codex – OpenAI’s coding agent”，点安装。用ChatGPT Plus及以上的账号登录，侧边栏有对应入口，点开直接用。
第四步，接入Pi Agent。Pi Agent本来是在终端用的，但既然用VS Code作为容器，我也尝试搜索了官方插件，可惜没有原生的。不过找到了两个独立开发者做的插件，对比测试后推荐：Pendant。这个UI和基础功能还是比较完备和丝滑的。在扩展市场搜“Pendant”，选“Pendant – Pi Agent for VS Code”，这是个人开发的Pi Agent的VS Code插件。如果没在终端下载过Pi Agent框架，点开插件，选“内置Pi Agent”，这个插件里内置了。如果之前在终端下载过，选择“外部”即可。关于模型，首次使用点击对话框里的登录，会弹出让你选择配置，里面有各大模型厂商的接入方式，可以直接搭配Kimi 3模型。
第五步，打通三个Agent的上下文——“最高指令软链接法”。三个Agent都装进了VS Code，但它们各读各的配置，Claude Code读CLAUDE.md，Codex读AGENTS.md，Pi Agent两个MD文件都能读。它们读取的项目及指令都不一样，都有固定的项目MD文件。但这里有一个骚操作——把统一管理和必须遵守的原则、框架等统一新建一个MD文件，命名随意，比如定义为COLLABORATION.md（协作）。
以之前搭建的Vibe Motion工作区为例：
既然它们在执行任务时都会去看项目及指令，那就以软链接的形式，在它们所遵守的指令中先限定必须读COLLABORATION.md。曲线引导一波，变相地变成了该项目空间内最高级指令。这种方法，可以称之为“最高指令软链接法”。软链接就是，软连到别的Agent的MD文件，简单理解为电脑桌面上的快捷方式——创建了一个关联别的文件的快捷方式。只需存一份文件或说明，就能让多个AI工具访问它，无缝衔接和切换。
在项目根目录建一个COLLABORATION.md，把所有Agent都必须遵守的共识写进去：技术栈约定、文件命名规范、哪些文件不能动、管理方式。然后在CLAUDE.md的首句引入这份文件，在AGENTS.md的首句也引入。Claude Code支持在CLAUDE.md里用@文件路径引用其他文件，Codex对AGENTS.md有类似机制。三个Agent启动时，都会先读一遍最高指令COLLABORATION.md，再读各自的专属项目文件MD。
实际操作流是：新项目用Claude Code搭架构，同时落好最高指令COLLABORATION.md和CLAUDE.md。项目有了基础之后，精细微调切Codex，自定义工作流走Pi Agent。至此，项目空间整个协作链路和框架就搭建好了。
六、风险复盘：生产资料的所有权
VS Code（容器）+ 多Agent协作，是目前Vibe Coding的最佳姿态。就在写这篇文章时，Claude又发布了一个新模型Opus 5。毋庸置疑，每次发模型之前都会有一波大封号……这几乎成了规律。
已经有不少用户被封了3个账号，现在只能靠中转站接API继续用。但通过这几次封号，也意识到一个问题：过去把工作流、经验甚至项目全部押宝在Claude Code这个工具上，以至于在初次迁移生产资料时非常痛苦。几个月积累的工作经验、工作流程、Skill全部都在Claude Code里面。还好聊天记录和Skill都存储在本地的，但也会后怕——如果这些生产资料所积累的资产跟随着封号消失了，不知会有多崩溃。所以，现在虽然也能用，但也会下意识地去做备份和兜底手段。
于是开始反思一个问题：现在所积累的跟AI的协作，不管是Skill也好，Memory也好，还是之前的工作流程、输出的文章、项目甚至产品，如果让AI来接管和开发，丧失了资产主导权，那这个生产资料，或者说命脉，就被把握在了某个平台、某个工具、某家公司上，这是不合理的。
所以应该做到的是：不管工具如何迭代，平台如何变，账号怎么出现意外，生产资料或项目主导权一定在自己手里握着。因此，工具或AI本质上来说，应该把它作为一种媒介。在这个时代，虽然用AI能很轻松地解决很多问题，甚至效率翻倍，但要时刻停下脚步复盘或沉淀。吾日三省吾身：
- 在这段时间所开发的项目，有多少节点是人为把关和审核？
- 脱离了这个工具，随便换一个，当前工作流是否还能跑得通？
- 通过这段时间的开发，个人的某个能力是否有所提升？
