在同一仓库中运行 Claude Code、Codex 和 Gemini CLI 作为编码代理一周——它们各自的薄弱环节。
摘要
一位开发者在一周内对比了 Claude Code、Codex 和 Gemini CLI 三种编码代理,指出了它们在上下文处理、精确度和上下文大小方面的优势,以及在成本、模糊处理能力和一致性方面的不足。
我花了大约一周的时间,让这三款终端编码代理在同一个真实项目上执行相同的任务,以便在抛开演示阶段后,了解它们之间真正的差异。分享一些突出的发现,好奇是否其他人也有同样的感受。Claude Code 在跨多步骤任务时上下文保持能力最强。当某个更改涉及多个文件时,它能记住已经完成的工作,不会偏离主题。它的短板在于成本。如果让一次会话过于冗长,它会快速消耗预算;解决方法主要是自律:每个任务使用新会话、限定范围、在仓库根目录放置一个简短的上下文文件。Codex 最为字面化。它几乎完全按照我的描述执行,很少带来意外,这一点我很喜欢,尤其是在明确说明的更改中。它的短板在于模糊性。给它一个模糊的指令,它可能卡住或只做最小的事情,因此我需要在前期比使用其他工具时更精确地描述。Gemini CLI 在原始上下文大小上胜出。当任务需要同时处理大量文件时,它比另外两者表现更好,而且免费套餐使得尝试变得更容易。它的短板在于一致性。同一个提示在一次运行时可能给出清晰结果,下一次却可能给出混乱的结果,这种情况比其他工具更频繁。令我惊讶的是,无论使用哪种工具,差异归结为几个相同的习惯:维护上下文文件、分小步骤工作、在编辑前展示计划。这些习惯对每个工具的帮助都比在它们之间切换更大。对于那些将这些工具作为代理使用的人,你们遇到哪些问题?你们是固定使用一种,还是根据任务切换?
相似文章
我为 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稍逊一筹,但可与多种模型配合使用。
快速印象:一周使用 Codex 多于 Claude 的体验
作者分享了在编程任务中一周内更多使用 Codex 而非 Claude 的个人体验,着重介绍了输出风格、代码简洁性以及工作流程集成方面的不同之处。
@svpino:用Claude Code写代码,用Codex验证它。我遇到了一个团队,他们已经这样做了几个星期。我……
一位开发者分享了一种方法:团队使用Claude Code编写代码,使用Codex进行验证,并专注于详细的规格说明和隔夜AI代理运行。