终端AI编码Agent五杀局：Claude Code、Gemini CLI、Aider、OpenCode、Codex CLI谁能活到最后

IDE里的AI辅助写代码已经不够用了。越来越多开发者把编码Agent搬到了终端——不是为了装逼，而是终端Agent能读整个项目、跑shell命令、自己commit代码，干的活比IDE插件多了一个量级。

2026年3月这个赛道突然加速：Google给Gemini CLI加了Plan Mode，OpenCode的GitHub Star冲到12万，Aider持续迭代多Provider支持。再加上Anthropic的Claude Code和OpenAI的Codex CLI，五个终端Agent摆在面前，到底该选哪个？

我花了一周把这五个全装上跑了一遍，用同一个任务测，直接说结论。

测试环境和任务

测试机器：Ubuntu 22.04，16GB内存，i5-12400。不用Mac测是因为大部分开发者日常环境就是Linux或WSL。

测试任务：给一个中等规模的Express+TypeScript项目（约50个文件，8000行代码）做三件事：

1. 代码理解：解释项目的认证流程，找出所有中间件的调用链
2. Bug修复：修复一个跨文件的类型错误（interface定义和实际使用不一致）
3. 功能新增：添加一个rate limiter中间件，集成到现有路由

三个任务从简到难，覆盖”读代码→改代码→写代码”三个核心场景。

安装体验

# Claude Code
npm install -g @anthropic-ai/claude-code

# Codex CLI
npm install -g @openai/codex

# Gemini CLI
npm install -g @anthropic-ai/gemini-cli  # 错了，实际是：
npm install -g @google/gemini-cli

# Aider
pip install aider-chat

# OpenCode
curl -fsSL https://opencode.ai/install | bash
# 或者直接下载Go二进制

安装这一步已经能看出差异。OpenCode是Go写的单二进制文件，下载即用，没有node_modules也没有Python依赖，启动速度秒杀其他四个。Aider需要Python环境，pip install有时候会撞到依赖冲突。Claude Code和Codex CLI都走npm，中规中矩。

启动速度实测：

任务一：代码理解——谁能把认证流程讲清楚

Prompt统一用：Explain the authentication flow in this project, trace all middleware calls from login to protected routes.

Claude Code拿到这个任务后，先用find扫了项目目录结构，然后逐个读了auth/目录下的文件，再顺着import链找到了路由文件和中间件注册。最终输出了一个完整的调用链，从POST /login到JWT签发到verifyToken中间件到各个protected route，每一步都标注了文件名和行号。

100万token的上下文窗口在这种任务上是碾压级优势——它能一次性把整个项目吃进去，不需要反复切换文件。

Gemini CLI（Plan Mode）的表现出乎意料。开了Plan Mode后，它先进入只读状态分析项目，用ask_user工具问了我一个问题：”项目用的是session-based还是token-based认证？”——这个反问很聪明，说明它在分析之前先确认方向。最终输出质量和Claude Code接近，调用链完整，但少了几个edge case的中间件。

Aider的分析最快，因为它走的是diff-aware的上下文管理，不会把整个项目都塞进prompt。但也因此漏掉了一个嵌套在utils/目录里的helper函数。

Codex CLI的结果中规中矩，结构清晰但深度不如Claude Code。OpenCode的分析能力取决于你接的是哪个模型，用Claude Sonnet时接近Claude Code的水平，用本地模型就差了一截。

代码理解评分：

任务二：跨文件Bug修复——真刀真枪改代码

制造了一个典型bug：types/user.ts里的UserProfile interface有个avatar字段是string | null，但services/user.service.ts里直接当string用了，没做null check。这个错误会在controllers/profile.controller.ts里触发运行时错误。

// types/user.ts
interface UserProfile {
  id: string;
  name: string;
  avatar: string | null;  // 这里定义是nullable
}

// services/user.service.ts
function getAvatarUrl(user: UserProfile): string {
  return user.avatar.replace(http://, https://);  // 没处理null
}

Claude Code不仅找到了这个bug，还顺手发现了另外两处类似的null check缺失。修复方案用了optional chaining加fallback，改了3个文件，每个改动都用git diff展示。

Gemini CLI在Plan Mode下先列出了修复方案：”1. 在UserProfile的avatar字段添加null check 2. 在service层统一处理nullable字段 3. 更新相关测试”。确认方案后切换到执行模式，一气呵成改完。这种”先规划再执行”的流程，做复杂修改时心里踏实很多。

Aider的Git集成在这个场景下发光了。改完代码后自动创建了一个commit，message写的是fix: handle nullable avatar in UserProfile，格式规范，直接能push。其他几个虽然也能auto-commit，但Aider的commit message质量明显最高。

Codex CLI的沙箱执行在这里是个优势——它在隔离环境里跑了tsc --noEmit验证修复是否引入新的类型错误，其他工具都没做这步。

# Codex CLI的沙箱验证输出
$ codex "fix the nullable avatar bug in user service"
[sandbox] Running: tsc --noEmit
[sandbox] ✓ No errors found
[sandbox] Running: npm test -- --filter=user
[sandbox] ✓ 12 tests passed

Bug修复评分：

任务三：新增Feature——Rate Limiter中间件

这个任务最能拉开差距。要求：写一个基于sliding window的rate limiter，支持按IP和按用户ID限流，集成到现有的Express路由中，写单元测试。

Claude Code的方案最完整：用Redis做存储、sliding window算法、独立的配置文件、完整的测试用例。问题是它假设项目已经有Redis，但实际项目用的是内存缓存。改了两轮才对。

Gemini CLI的Plan Mode在这种复杂任务上价值最大。它先输出了一份Markdown计划文件：

# Rate Limiter Implementation Plan

## Analysis
- Project uses in-memory caching (no Redis)
- Existing middleware pattern: function factory returning RequestHandler
- Test framework: Jest with supertest

## Implementation Steps
1. Create `middleware/rateLimiter.ts` - sliding window with Map storage
2. Create `config/rateLimit.config.ts` - configurable limits
3. Update `routes/index.ts` - apply to API routes
4. Create `__tests__/rateLimiter.test.ts` - unit + integration tests

## Trade-offs
- Map storage: simple but no cross-process sharing
- Alternative: could use the existing cache module in utils/cache.ts

看到这个计划我直接把”用utils/cache.ts”这条反馈回去了，它改完计划后执行，一次成功。这种先看计划再执行的工作流，比让Agent直接写代码靠谱得多。

Aider写了一版能跑但相对简陋的实现——固定窗口而不是sliding window，没有按用户ID限流，测试只有3个case。不过它的优势是速度快，从提问到commit完成只用了40秒。

Codex CLI在沙箱里完整跑了一遍npm test确认没有regression，这点很加分。但生成的代码风格和项目现有风格不太统一，用了很多any类型。

OpenCode接Claude Sonnet时表现不错，但MCP集成还比较新，调用外部工具时偶尔会卡住。

费用对比——钱包最关心的部分

三个任务跑完的总花费：

Gemini CLI的免费额度在这里是杀手级优势。60次/分钟的免费Gemini 2.5 Pro，日常开发完全够用，不需要掏一分钱。Claude Code最贵但效果最好——经典的”一分钱一分货”。

踩坑记录

Gemini CLI的Plan Mode不能在YOLO模式下用。如果你设了--approval-mode=yolo让它自动执行所有操作，Plan Mode的enter_plan_mode工具会被禁用。这两个模式是互斥的，文档里没写清楚，我摸索了半天。

Aider在monorepo里会迷路。如果项目是monorepo结构，Aider的文件选择器有时候会选错package下的同名文件。解决办法是用--file参数手动指定要编辑的文件。

OpenCode的MCP Server配置比较折腾。虽然支持MCP协议，但配置文件格式和Claude Code的不完全兼容，需要手动改。

Codex CLI的沙箱在某些场景下太严格。它默认不允许访问网络，如果你的项目有外部依赖需要resolve，得手动放行。

Claude Code在大项目上容易撞token限制。虽然有100万token上下文，但一个大型monorepo很容易就超了。实际使用中需要用.claudeignore排除不相关的目录。

选择建议

别纠结”哪个最好”，根据你的情况选：

预算为零 → Gemini CLI。免费额度 + Plan Mode，日常开发足够了。Plan Mode是真正有用的功能，不是噱头。

要改大项目 → Claude Code。100万上下文窗口在复杂重构和跨文件修改上没有对手，但得准备好钱包。

不想被厂商绑架 → Aider。支持所有Provider，今天用Claude明天换GPT后天跑本地模型，随便切。Git集成是五个里面最好的。

想要最快的启动体验 → OpenCode。Go单文件二进制，0.2秒启动，12万Star不是白来的。但生态还在早期，遇到问题可能要翻源码。

OpenAI全家桶用户 → Codex CLI。沙箱执行是独家优势，让Agent跑测试、装依赖都不怕搞坏本地环境。

我自己日常的组合是：小改动用Gemini CLI（免费快速）、复杂重构用Claude Code（贵但准）、需要切模型时用Aider。三个工具覆盖90%的场景。

终端AI Agent这个赛道才刚开始。去年这个时候大家还在讨论”AI能不能写代码”，今年的问题已经变成”用哪个Agent写代码效率最高”。工具选型永远没有标准答案，但至少现在你有五个靠谱的选择了。