最近大半年AI 编程圈的讨论重点彻底变了。以前大家争论的是 Copilot 还是 Tabnine谁的补全能更懂你的代码现在争论的是Claude Code 是不是比 Codex CLI 更适合做跨文件重构MCP 到底能把多少外部工具接进 Agent以及那些越传越玄乎的 Skills 到底是真能提效还是把 Prompt 换个目录结构重新发明了一遍。我自己的答案是这些新东西确实有用但前提是你得搞清楚它们各自解决的是哪一层问题。太多人被社交平台上的 Demo 带着走装上五个 Agent却不知道什么时候该用哪个下载了一百个 Skills写代码速度反而更慢。这篇文章我想把终端 AI 编程 Agent 的现状摊开讲一遍——5 个主流终端 Agent 的横评加上 Skills 和 MCP 两套生态的基本原理与实操。适合正在选型、或者已经在用但总觉得差点意思的开发者。1. 先搞清楚现状从补全到自治执行Agent 到底改了什么过去两年AI 编程工具的形态大致走过了三个阶段。第一个阶段是补全型代表是 GitHub Copilot 和早期的 Tabby本质是更懂上下文的自动完成帮你少敲几个字但代码逻辑还得自己负责。第二个阶段是对话型把代码粘进聊天框让模型给出建议你再复制回来比对效率有提升但和真实工程项目的距离依然很远。到了第三个阶段也就是现在这轮 Agent 热工具终于从回答者变成了执行者你给它一个任务它自己定位代码、修改文件、跑测试、看报错、再改形成了完整的闭环。终端是 Agent 最自然的落脚点这不是偶然。因为终端是唯一一个能同时操控文件系统、Git、Shell 命令、构建工具、测试框架的地方。编辑器插件的权限做得再大也大不过一个 Shell 进程反过来只要能在这个进程里自由执行命令Agent 就拥有了和人类开发者几乎对等的行动能力。所以你会看到真正在工程圈里口碑跑出来的 Agent几乎都是终端形态或者围绕终端的能力来设计而不是只在编辑器侧边栏弹个窗口。还有一个概念要先理清就是 Harness 和 Agent 的区别。Agent 不单单是一个模型而是模型 执行框架的组合体这个执行框架在英文生态里常被称为 Harness。它负责的任务包括把大目标拆成多步小计划循环调度工具调用决定什么时候任务算完成以及在执行危险操作前向用户申请确认。同一个底层模型套上不同的 Harness表现出来可能完全是两个工具。这也是为什么哪怕某些终端 Agent 用的模型系列相似实测体验依然天差地别。这篇文章后面要横评的五款工具其实是对终端场景这一层做了不同取舍的样本。它们里有纯命令行交互的有和编辑器深度绑定的也有偏终端助手定位的。它们互相之间不是简单的谁替代谁而是对应着不同的使用习惯和项目类型。接下来我们逐个拆开看。2. 五款主流终端 Agent 横评核心参数与真实体验先放一张总览表参数来自我近期实际使用的配置和官方文档方便你快速建立坐标系。Agent开发商主打模型上下文MCP 支持Skills 支持计费方式最合适的场景Claude CodeAnthropicClaude Sonnet / Opus 系列最高 200K 级别原生支持原生支持订阅 / API 用量复杂工程、跨文件重构OpenAI Codex CLIOpenAIGPT-5-Codex 等高支持支持持续完善中API 用量算法、脚本、代码原型Gemini CLIGoogleGemini 2.5 Pro / 3最高 1M 级别支持实验性支持免费额度大、廉价超大仓库、海量文档理解Cursor AgentAnysphere多模型可选视模型而定支持与编辑器流程绑定订阅制编辑器内快速迭代TabbyTabbyML本地模型 / 兼容 API视部署配置有限不适用免费 / 企业版终端日常、命令助手、自托管部署表里的参数只能当参考具体选型还得往下看每款工具的实际体感差异比参数表要大得多。2.1 Claude Code目前把自主干活做到最顺的终端 AgentClaude Code 是我现在的主力工具。安装很简单npm install -g anthropic-ai/claude-code装完在项目根目录执行claude就进入交互式终端。第一次用它会自动读取项目结构、Git 状态还会提示你用/init生成一个CLAUDE.md文件里面可以写项目架构、代码风格、常用命令相当于给 Agent 一份项目入职手册这个文件之后每次会话都会被自动读取。它最强的地方在于多文件任务的规划能力。比如把用户模块从函数组件迁移到类组件并补全单元测试这种任务它会先 grep 找出所有引用点再逐个文件修改改完跑测试测试挂了会自己看报错信息再回来修整个链路的连续性做得很平稳。相比其他工具它很少在中间迷失方向也不会频繁停下来问你下一步怎么办自主性和上下文保持能力确实领先一个身位。MCP 和 Skills 在 Claude Code 里都是原生支持claude mcp add可以接入各种外部服务技能则直接放到.claude/skills/目录下。缺点也明显一是价格不便宜重度使用的话 API 账单会涨得很快二是在超大仓库首次建索引时会比较慢。角色分工的话它适合当项目级主力 Agent不是用来顺手问个小问题的。2.2 OpenAI Codex CLI代码推理派的代表Codex CLI 是 OpenAI 官方发布的终端工具安装方式是npm install -g openai/codex然后在项目目录跑codex。它给我的第一感受是思路快、下手准尤其在算法题、脚本编写、数据处理这类涉及推理链的任务上给出的代码正确率很高。这可能和 Codex 模型的训练侧重有关系它更像是天生为编码深度优化的选手。Codex CLI 一个很有特色的设计是沙箱执行。它可以在隔离环境里运行命令避免 Agent 误操作破坏宿主机这点对安全意识强的团队很友好。不过沙箱也不是没有代价文件写入如果走隔离层有时候会感觉慢半拍。另外 Codex 的 Skills 体系也在快速补齐社区里已经出现了不少专门为 Codex 编写的 skill配置目录通常是~/.codex/skills。MCP 支持也有通过codex mcp add来管理。它的短板是长时间、多文件的复杂工程任务规划细腻度还是比 Claude Code 略逊一筹。偶尔会出现改完 A 文件忘了 B 文件的情况需要有人盯一下。我一般把它当作第二助手在需要快速验证一个算法思路、写点一次性脚本时效率非常高。2.3 Gemini CLI超长上下文的性价比之选Gemini CLI 最大的记忆点是超长上下文最高到 1M 级别。这听起来抽象放到实际场景里就是你可以把一个中大型仓库的关键文件分批喂给它它不会把前面的内容忘得一干二净。我曾经让它分析一个带大量历史遗留代码的项目它能比较准确地引用几十个文件之外的函数定义这种全局记忆在排查跨层 BUG 时特别有用。安装命令是npm install -g google/gemini-cli进入后是类似的 REPL 交互方式。它在 Google 生态内表现很好比如分析 Google Cloud 相关配置、Golang 项目时很顺手。另一个优点是免费额度和折合成本比前两家低不少入门门槛很低。MCP 它支持Skills 目前更多是实验性质社区内容没有前两家丰富。不足的地方也有对第三方生态、不够主流的框架规范有时理解不够细生成的代码看起来通顺但不符合你项目里的私有约定这类情况偏多一点。它更适合注册一个免费额度用来做大仓库阅读、文档分析、问题定位而不是直接当全天候的代码生成主力。2.4 Cursor Agent编辑器与终端之间的特殊存在严格来说 Cursor 不是终端 Agent它是编辑器但它的 Agent 能力已经足够强而且现在还提供了 CLI 相关的入口很多终端派和编辑器派的争论在 Cursor 这里变成了融合体验。Cursor 的核心优势是 Tab 补全和 Agent 模式深度绑定在编辑器里选中一段代码就能让 Agent 就地修改所见即所得这对前端、UI 类开发特别舒服。热词里有一条 get cursor pro for more agent usage, unlimited tab, and more其实反映的是 Cursor 的商业策略Agent 使用量和 Tab 补全次数是订阅的核心权益重度用户在高峰期确实会碰到配额限制。如果你已经深度依赖 Cursor 的补全和 Composer再加一个终端 Agent 可能有点多余但如果你想用它做那种完全脱离编辑器、纯命令行操作仓库的事它就不如 Claude Code 或 Codex CLI 纯粹。它更适合当交互式工作站快速原型、改样式、写小项目人机配合得很顺畅。2.5 Tabby终端侧的轻量 AI 帮办Tabby 和前面四个不是同一类东西严格说它是终端 AI 助手和补全工具不是自治执行型 Agent但它是很多人实际装进终端的第一个 AI 组件。它可以自托管支持接入本地模型或者 OpenAI 兼容 API数据可以不出内网这让它在运维、企业环境里有天然的吸引力。功能上覆盖代码补全、终端命令建议、聊天问答对我在 linux 终端里忘了某条命令怎么写这类场景很友好。还有一些终端使用习惯它也管比如终端复用、在长输出里快速跳转很多用户拿它当终端增强而不是编码 Agent。它的优点是好部署、便宜、私密性强缺点是它不会像 Claude Code 那样替你完成一个跨文件任务它更像是站在你旁边给你递工具的人。如果团队里有人主要负责服务器运维、脚本维护而不是高强度业务开发Tabby 的性价比反而很高。从这张横评你能看出没有哪款工具能通吃所有场景。下一节开始讲生态层的东西这部分才是让终端 Agent 从通用玩具变成团队生产力的关键。3. Skills 机制把经验装进 Agent 的标准姿势聊 Skills 之前先回答一个很多人问过的问题模型不是已经什么都会了吗为什么还需要 Skill答案是模型会的是通用知识但你项目的代码规范、团队约定、常见坑位、标准交付流程这些只存在于你自己的经验里模型不可能天然知道。你想让它每次写代码都符合你的习惯最粗暴的方法是每次对话都写一大段详细的 Prompt但这样既啰嗦又容易漏于是就有了 Skills。Skill 的本质是一套标准作业手册它不是普通的一次性提示词而是一个结构化的目录包含元信息、操作步骤、参考资料和可执行脚本。Agent 拿到任务后会根据任务内容自动判断该调用哪个 Skill再按照 Skill 里的标准流程去干活。你可以把它想成厨师出餐模型是厨师有基本功但不知道你店里每道菜的具体配方Skill 就是那本配方手册什么菜用什么料、什么火候、几号师傅负责什么全写在上面。不同店可以有不同手册同一道菜也能有不同的做法这就是经验标准化。很多热词里提到的superpower skills本质上就是社区里一个特别知名的手册合集把大量高频任务模板化。还有 codex skills、claude code skills 安装、前端开发skills 这些搜索词说明大家已经从要不要用 Skill进入怎么装、装哪些的阶段。这里要提醒一句不要盲目装一堆名气大的 SkillAgent 每次启动要根据描述匹配技能技能库太杂它反而会挑错或犹豫拖慢响应速度。3.1 Skill 的结构与 Agent 的区别一个标准 Skill 在项目里的组织方式大致是这样.claude/skills/ └── frontend-coder/ ├── SKILL.md └── references/ ├── component-patterns.md └── css-standards.md其中SKILL.md是入口里面用 YAML 头部写元信息和触发条件正文写角色定位、执行步骤、检查清单。下面是我实际用过的前端类 Skill 精简示例--- name: frontend-coder description: 当用户需要根据设计稿或需求说明生成 React 前端页面时使用。包含组件结构、样式规则和可访问性检查。 --- # 角色 你是一位熟悉 React 18 TypeScript 公司内部组件库的前端工程师。 # 标准流程 1. 先阅读需求说明如果是设计稿调用设计稿 MCP 获取节点信息。 2. 按组件拆分页面每个页面目录包含 index.tsx、style.ts、types.ts。 3. 样式优先使用 design token禁止硬编码颜色值。 4. 所有可交互元素补充 aria-label 和键盘事件。 # 完成检查 - 页面在 1280px 和 375px 宽度下无明显布局错位。 - 已运行 npm run lint 且无新增告警。 - 组件 props 已定义完整类型。这里顺便把 Skill 和 Agent 的区别说透。Agent 是那个干活的人负责理解目标、调用工具、迭代执行Skill 是干活时用的方法预案它自己不会动等着被 Agent 读取。同一个 Agent 可以挂多个 Skill同一个 Skill 也可以在不同 Agent 之间迁移使用。也可以换个类比Agent 是司机MCP 是油箱、轮胎和导航数据源而 Skill 是驾驶手册和路书——司机再厉害也得知道去哪个加油站、按什么路线跑。3.2 热门 Skills 生态与安装实操目前 Skills 生态热度最高的三个方向是前端页面生成、架构图/结构图输出以及个人工作流助手。superpower skills属于后者里面有很多针对个人助理、项目管理、文档写作的模板安装它本身也不复杂本质上是把仓库里的技能目录克隆到 Agent 能读取的位置。给 Claude Code 安装一个项目级技能只需要在项目根目录建目录和文件mkdir -p .claude/skills/frontend-coder/references # 然后手动创建 SKILL.md 和参考资料文件给 Codex CLI 装全局技能也是同理只是目录换成了~/.codex/skills。装好之后用一句话测试即可比如用前端技能帮我生成一个上传组件。Agent 应该能根据 frontmatter 里的描述自动加载对应技能。我自己踩过的坑是Skill 文件写得过长恨不得把整个团队的代码规范都塞进去。结果就是模型的注意力被稀释关键规则反而没有被执行。建议每个 Skill 只聚焦一个高频任务正文控制在 200 行左右把必须做和必须不做写清楚剩下让它自己发挥。这套标准化的经验沉淀才是 Skills 真正值钱的地方——不是把提示词换个目录而是把你会干活变成模型也会按你的方式干活。4. MCP 生态Agent 连接世界的统一接口如果说 Skills 解决的是怎么干活那么 MCP 解决的是能碰到哪些东西。MCP 的全称是 Model Context Protocol它是一套开放协议让 Agent 能够以统一方式调用外部工具、读取数据源、触发工作流。过去每接一个工具就要为 Agent 写一套专属集成有了 MCP工具方只要实现一个标准 Server所有兼容客户端就都能用。用 USB-C 来类比最合适以前每个设备一根专属线现在一个接口走天下。从架构上看MCP 有三类角色。Host 是 Agent 本身Client 是嵌入在 Host 里的连接器Server 是暴露能力的一方。通信底层基于 JSON-RPC传输方式常见的有 stdio本地子进程和 HTTP/SSE远程服务。它定义了三大原语Tools 是 Agent 可以调用的动作比如读取设计稿节点Resources 是 Agent 可以读取的数据比如当前项目的配置文件Prompts 是预定义的可复用提示模板。Agent 在对话过程中会拿到所有可用工具的描述自己判断该调用哪个调用完再把结果融入推理。这套机制对开发者的意义很直接。以前我想让 Agent 读一个设计稿得自己写脚本导出 JSON 再贴给模型现在只需要配置一个 Figma MCP ServerAgent 自己就能按需拉取图层结构。热词里那串 figma mcp token 在哪获取 的问题也说明工具不难得配置过程确实卡住不少人。Figma 的 token 在个人设置 - Security 页面生成名为 Personal Access Token生成后前面会带figd_前缀配置到 MCP Server 的 Authorization 头里即可。4.1 几类高频 MCP Server 盘点设计协作类Figma MCP、国内的蓝湖 MCP。适合设计稿生成代码、设计规范同步是前端 Agent 工作流里最刚需的一类。云端开发环境类DevSpace MCP 这类能把云端集群、开发容器的操作暴露给 Agent方便它直接操作远程环境。安全测试类Burp MCP 等工具能把接口扫描、流量分析能力接进 Agent用于安全测试和漏洞排查。本地数据类一些金融终端、数据库客户端也开始提供 MCP 接口让 Agent 能直接查行情或业务数据做分析实验。拿 Claude Code 配置 Figma MCP 举例实际操作是这样claude mcp add figma --transport http --url https://api.figma.com/mcp --headers {Authorization: Bearer figd_你的token}配置完成后可以用claude mcp list查看已连接的 Server再用一句话验证比如调一下 Figma MCP读取当前选中节点的名称。如果返回正常就说明链路通了。4.2 MCP 使用中容易踩的坑第一个坑是 Token 权限给得太大。很多 MCP Server 的 token 是全局权限可以读取、修改甚至删除全部资源。个人使用还好团队环境里我建议优先找支持只读模式或项目级授权的 Server把能碰到的东西收敛到最小范围。第二个坑是 MCP Server 返回的数据量超出模型上下文。设计稿节点可能动辄几万行 JSON直接灌给模型不仅慢还挤占上下文空间。解决办法是选那些支持按需抓取节点、能过滤属性的 MCP而不是一次性把整个文件塞进去。第三个坑是多个 MCP Server 提供的工具名冲突。比如两个 Server 都定义了get_fileAgent 可能就不知道调哪个甚至调错。遇到这种情况要么只保留必要的 Server要么在配置时考虑使用不同的入口和命名空间来隔离。总的来说MCP 是越统一越高效越堆叠越混乱它的正确用法是克制不是什么都往上接。5. 一个完整串联实战从设计稿到前端代码理论讲得再多不如跑一个完整的链路。这一节我把 Skills 和 MCP 都串起来用 Claude Code 作为执行 Agent用 Figma MCP 作为设计稿数据源用前端开发 Skill 约束代码风格最终把一张设计稿转成可运行的 React 页面。第一步是环境准备。在项目根目录先配置好 Figma MCP命令见上一节然后确认 Agent 能正常调用它。接着建立技能目录把frontend-coder的SKILL.md落到.claude/skills/frontend-coder/把团队规范写进 references 文件。最后别忘了让项目里有一个CLAUDE.md用自然语言描述项目技术栈和启动命令这样 Agent 在高强度工作时不会跑偏。第二步是给 Agent 下发任务。我建议不要只丢一句根据设计稿生成页面而是尽量把背景说清楚比如用 frontend-coder 技能读取 Figma 文件里名为 Dashboard 的页面生成对应的 React 组件日夜间模式都要适配。因为 Agent 会根据你的描述判断是否需要加载技能、是否需要调用 MCP指令里带关键词能明显提高命中率。第三步是观察它的执行链路。正常情况下Claude Code 会先查询 Figma MCP 里有哪些可用工具然后调用获取文件节点的工具拿到图层树后它会对照 Frontend Skill 里的规范开始搭建项目结构。整个过程中你可以看到它在终端里的每一步操作日志读取了哪些节点、创建了哪些文件、是否运行了 lint。中途如果它拿到的图层信息不全有的工具支持按节点 ID 二次补拉它也会自己尝试。这个流程跑通后最大的感受是人类从手写每一行代码变成了检查关键决策点。我不关心它怎么把样式写出来的只关心组件拆分是否合理、状态管理是否过度设计、有没有违反可访问性要求。原本两天的前端联调任务压缩到半天以内其中大部分时间还是花在细节调整上。如果你用的是蓝湖 MCP 或其他设计交付工具流程完全一样只是把数据源从 Figma 换成了对应的 MCP Server。这套组合不绑定具体厂商只要 Agent 支持 MCP 和 Skills同一套方法论就能平移过去。唯一需要重新调整的是各工具在上下文策略和 Skills 加载机制上的细微差别。6. 组合选型建议与踩坑记录横评做完、生态讲完最后聊一点真正影响日常效率的东西怎么组合使用以及哪些坑我替你踩过了。我目前的组合是Claude Code 承担主要工程任务Codex CLI 做代码级快速验证Tabby 长驻终端处理日常命令咨询和补全必要时把蓝湖或者 Figma 的 MCP 挂进 Claude Code。Cider 和 Gemini CLI 我更多是阶段性使用Gemini 用于超大仓库阅读Cursor 在需要和人高频交互的 UI 调试时顶上。这套组合不是固定的它对应的是重工程、快验证、轻终端三层需求。6.1 容易让效率翻车的四个问题第一个问题是权限失控。刚用终端 Agent 时很多人图省事直接把命令审批关掉结果 Agent 在调试依赖时顺手执行了清理命令差点删掉未提交的改动。现在我坚持保留危险命令审批普通文件编辑可以自动执行rm、git reset --hard、drop table这类高危操作必须过我这一关。第二个问题是 Skill 装置过多。前文提过技能太多会让模型在匹配阶段犹豫也可能读错技能。我现在每个项目只保留三到五个高频技能其余需要时再加。这跟整理工位一个道理工具放在顺手的位置才是效率堆满桌面只会让人找不到东西。第三个问题是 MCP Server 堆积。接一个 Server 简单但每次会话 Agent 都要把所有 Server 的可用工具列表过一遍数量一多响应明显变慢还会出现工具名冲突。我现在强制规矩是同时只挂两到三个必要的 MCP Server不用就移除配置而不是留在那里积灰。第四个问题是多个 Agent 共用同一仓库时产生的提交冲突。让 Claude Code 和 Codex CLI 同时操作一个分支很容易出现重复改文件、互相覆盖的问题。我的解决办法是给不同 Agent 分配不同的工作分支或者限定它们操作不同的子目录收工之后统一 code review 再合并冲突率能降下来一大半。6.2 怎么科学评估一个终端 Agent 适不适合你热词里有 agent evals这个词值得展开说。社区现在已经有不少公开的 Agent 评测集用来量化工具在真实任务上的完成率但评测集跑得好不代表适合你的团队。我更推荐自己建一个小型 eval 集选五到十个过去一个月里真实做过、且有明确验收标准的任务比如给用户模块加导出功能修复某个报错把日志系统从 A 框架换成 B 框架。然后在同一个仓库里给每个候选 Agent 跑一遍看完成率、耗时、是否需要人工干预结果一比谁更适合就一目了然。以我自己的实测为例在包含大量跨文件修改的历史项目里Claude Code 的完成率和少干预程度明显优于我用过的其他几款但换成纯算法实现任务Codex CLI 的速度反而更快。这种差异性说明市面上不存在最强大的 Agent只有最适合你的项目类型和协作习惯的 Agent。就算某个新版本发布后 Benchmark 数据再好看也不如直接用你自己的代码库跑一轮来得靠谱。如果只让我保留一套最简组合那就是一个支持 MCP 和 Skills 的终端 Agent一个刚需的 MCP Server再加一份精心维护的 Skill 目录。工具数量不贪多把这三样打磨顺了AI 编程的整体体验会立刻上一个台阶。