在同一仓库中运行 Claude Code、Codex 和 Gemini CLI 作为编码代理一周——它们各自的薄弱环节。
摘要
一位开发者在一周内对比了 Claude Code、Codex 和 Gemini CLI 三种编码代理,指出了它们在上下文处理、精确度和上下文大小方面的优势,以及在成本、模糊处理能力和一致性方面的不足。
我花了大约一周的时间,让这三款终端编码代理在同一个真实项目上执行相同的任务,以便在抛开演示阶段后,了解它们之间真正的差异。分享一些突出的发现,好奇是否其他人也有同样的感受。Claude Code 在跨多步骤任务时上下文保持能力最强。当某个更改涉及多个文件时,它能记住已经完成的工作,不会偏离主题。它的短板在于成本。如果让一次会话过于冗长,它会快速消耗预算;解决方法主要是自律:每个任务使用新会话、限定范围、在仓库根目录放置一个简短的上下文文件。Codex 最为字面化。它几乎完全按照我的描述执行,很少带来意外,这一点我很喜欢,尤其是在明确说明的更改中。它的短板在于模糊性。给它一个模糊的指令,它可能卡住或只做最小的事情,因此我需要在前期比使用其他工具时更精确地描述。Gemini CLI 在原始上下文大小上胜出。当任务需要同时处理大量文件时,它比另外两者表现更好,而且免费套餐使得尝试变得更容易。它的短板在于一致性。同一个提示在一次运行时可能给出清晰结果,下一次却可能给出混乱的结果,这种情况比其他工具更频繁。令我惊讶的是,无论使用哪种工具,差异归结为几个相同的习惯:维护上下文文件、分小步骤工作、在编辑前展示计划。这些习惯对每个工具的帮助都比在它们之间切换更大。对于那些将这些工具作为代理使用的人,你们遇到哪些问题?你们是固定使用一种,还是根据任务切换?
相似文章
在同一个真实代码库上测试了三个 coding agent,最大的意外是你的环境配置有多大程度会跟着你在它们之间迁移
一次对 Cursor、Codex 和 Claude Code 跑在同一份真实 SaaS 代码库上的实测对比。结果显示,共享的 home 目录配置(插件、skills、MCP 服务器)会悄悄跟着 agent 在不同工具之间迁移;而三者之间的差异,更多来自职责范围的不同,而非模型能力的高低。
我为 Claude Code、Codex 和 Gemini 构建了一个本地 CLI,利用现有的认证机制来互相审查彼此的 GitHub PR
作者介绍了 `coding-review-agent-loop`,这是一个开源的本地 CLI 工具,它协调多个编码代理(Claude Code、Codex、Gemini)使用现有的本地身份验证相互审查彼此的 GitHub PR,从而避免额外的 API 成本。
我并行运行 Claude Code 和 Codex 15天。以下是我的发现。
作者在使用 Tutti 与 Claude Code 和 Codex 15天后,对这个共享多代理工作区进行了评测,强调了诸如 @ 系统和代理借用等流程改进,以及一些缺点。
CLI编码代理现状,2026年中(37分钟阅读)
详细比较了CLI编码代理,包括Claude Code、Codex CLI、Omp和OpenCode,指出前三者生成的结果质量相似,而OpenCode稍逊一筹,但可与多种模型配合使用。
Gemini Code 对比 Claude Code——一次警示性的事后复盘(12 小时花费 800 美元)
一篇警示性的事后复盘,对比了 Gemini Code 和 Claude Code,详细讲述了使用费用如何在短短 12 小时内飙升至 800 美元,以及在实际使用智能体的过程中出了哪些问题。