1. 项目概述这次的评测是怎么来的最近社区里聊 Agent 框架的声音明显多了起来主要原因是 OpenAI 在 2025 年把 Codex 开放出来之后大家突然意识到原来 CLI 形态的 AI 编程助手可以这么丝滑。紧接着各家开源项目跟进什么 Claude Code、OpenHands、AutoGen、CrewAI 全冒出来了。我手头正好攒了一批开源项目要调研索性就干了一件比较费时间的事——把七大主流开源 Agent 的源码全部拉下来逐个拆解阅读从架构设计、核心循环、工具调用、上下文管理、生态扩展这几个维度做了横向评测。这个项目标题里的“最高分竟然不是 Codex”是结果不是噱头。我评测的七个项目分别是OpenAI Codex CLI、Claude Code开源版、OpenHands原 OpenDevin、AutoGenMicrosoft 出品、CrewAI、LangGraph、Dify。这些都是 GitHub 上 star 数高、社区活跃度强、在各自赛道里具有代表性的项目。适合谁看如果你正在选型 Agent 框架、想理解主流 Agent 的底层实现思路或者准备在自己项目里集成 Agent 能力这篇文章能帮你省掉大量的源码阅读时间。有一点需要提前说明这篇评测不是简单跑一下 demo 然后打分而是直接对着源码目录结构、核心类、关键函数做逐行分析顺便跑起来了典型场景做验证。所以结论会更偏向工程实践而不是“哪个模型跑分高”这种维度。2. 整体设计与评测维度拆解2.1 为什么选择这七个项目选型是一个挺纠结的过程。市面上的 Agent 框架没有一百也有八十我筛选的标准有三条一是 GitHub 活跃度要够不能是那种几年不更新的死项目二是架构要有代表性不能七个小项目长一个样那就没有了横向对比的意义三是社区应用足够广有问题能查得到不会卡住就完蛋。最终确定的七个项目其实可以分成三个梯队。第一梯队是“AI 编程助手类”包括 Codex CLI、Claude Code 和 OpenHands它们的核心使用场景就是帮你在终端里完成编程任务强调人机协作和代码操作能力。第二梯队是“Agent 应用开发框架类”包括 AutoGen、CrewAI 和 LangGraph它们主要服务开发者搭建自定义的 Agent 应用本质上是给 Agent 提供了组织编排的骨架。第三梯队是“工作流平台类”Dify 是代表它把 Agent 能力和工作流编排封装成更偏向产品化的形态。分开看这三个阵营你会发现它们对“Agent 应该怎么做”的理解其实很不一样这也是后面得分拉开差距的主要原因。编程助手类追求的是单轮任务的执行深度框架类追求的是多智能体协作的编排灵活度平台类追求的是把复杂能力封装得足够简单。2.2 评测维度怎么定的定了项目之后最关键的工作是定义评测维度。如果维度设计得不好评测结果就是各说各话没有可比性。我最终确定了六个维度每个维度满分 10 分评测维度考察内容权重代码质量与工程规范类型覆盖、测试覆盖率、目录组织结构、依赖管理20%核心循环设计Agent 主循环的实现方式、状态管理、任务分解能力25%工具调用与扩展性Tool 定义规范、MCP 支持、自定义工具接入成本20%上下文管理上下文裁剪、压缩策略、长任务记忆机制15%生态与社区活跃度star 数量、PR 处理速度、文档完善程度、周边工具链10%实际体验与易用性安装成本、使用门槛、出错提示友好度、上手时间10%权重分配是有讲究的。我把核心循环设计和工具调用扩展性放在最高权重因为这两个维度直接决定了 Agent 的“上限”——你能不能把一个复杂任务交给它去拆解执行以及在执行过程中遇到新场景时能不能低成本地扩展能力。上下文管理紧随其后这是实际使用中最容易出问题的地方很多 Agent 跑着跑着就“失忆”了本质上是上下文管理策略太粗糙。2.3 评分标准的校准问题这里有一个必须单独拿出来说的事情——评分标准的“校准”。刚开始我给自己录分数的时候随手给 Codex 的代码质量打了 9 分给 Claude Code 打了 8 分但这个分数在没有统一校准之前是完全主观的。后来我做了一件事把每个项目的核心文件列表打印出来先数代码行数、测试文件数、类型标注覆盖率再去看具体实现最后才给分数。这种做法让评分有据可循避免了一个常见偏差名气偏好。你对一个项目越熟悉就越容易不自觉地给它打高分。Codex 我平时用得多拆它源码的时候我特别注意压制这种偏好。后来的结果也确实证明了这种校准的必要——Codex 的整体得分并没有排到第一。3. 七大开源 Agent 源码核心细节拆解3.1 Codex CLI干净的架构偏窄的视野Codex CLI 是 OpenAI 开源的终端编程助手用 Rust 写的。说实话第一次打开它的源码目录时我是有些意外的——结构非常干净crates目录下分好了codex-rs、core、cli几个子 crate依赖关系清晰编译速度快。从工程规范角度来说这应该是七个项目里最“科班”的一个。Codex CLI 的核心循环设计得很朴素用户在终端里输入问题或指令Codex 将指令交给大模型模型返回结构化结果再通过 App 接口层调用工具执行。整个循环的核心文件是core/src/agent.rs里面包含了主循环结构。有意思的是Codex 的主循环是一个有限状态机状态包括Idle、WaitingForModel、Executing、Done等几种每次切换状态都会触发对应的事件回调。但这里也有一个问题Codex 的工具调用方式高度绑定在编程场景里。它支持的工具主要是读写文件、执行命令、搜索代码某种程度上这是一个“升级版的 shell”。如果你想把它改造成一个通用 Agent 框架比如接入自己的业务工具或数据源改造的工程量不小。它的定位决定了它的边界——这不是一个通用 Agent 框架而是一个专注编程场景的高效率助手。换言之Codex 是一把打磨得很锋利的小刀适合做精细的活儿但不是瑞士军刀。3.2 Claude Code体验优先工程次之Anthropic 开源的 Claude Code 评测排第二但它和 Codex 的优点正好相反——体验真的是第一梯队的工程结构却稍显松散。Claude Code 的核心是 TypeScript 写的代码量比 Codex 大得多。它的核心循环不在一个单独文件里而是分散在src/services/和src/commands/下面。主循环通过AgenticEvent事件总线来驱动模型的每次输出都会被包装成事件然后由对应的事件处理器决定是调用工具、更新对话状态还是向用户请求输入。Claude Code 在上下文处理上花了很多心思。它有一个ContextManager会把历史对话按重要性分层核心指令永不淘汰关键文件内容在窗口紧张时优先保留次要内容会被摘要化压缩。这种分级策略让它在长时间任务中的表现比较稳定这是它实际体验分最高的原因之一。工程规范的短板在于测试覆盖。Codex 的 Rust 代码测试覆盖率很高而 Claude Code 的测试相对薄弱很多核心路径比如权限确认流程、插件加载机制测试用例并不完整。文档方面也有点跟不上代码迭代速度有些配置项写了但没说明场景只能去翻源码确认行为。3.3 OpenHands学术基因最重野心也最大OpenHands 的前身是 OpenDevin是七个项目里背景最特别的一个——它出生于大学实验室。这让它的代码有鲜明的两面一面是研究驱动的创新思路另一面是工程的糙。OpenHands 的技术栈是 Python React代码分agenthubAgent 实现、openhands框架核心、frontendWeb 界面三大部分。最值得拆解的创新点是它的Agent 分层架构底层是 EventStream所有行为都是事件中间层是 Agent Controller负责调度顶层是具体的 Agent 实现比如 CodeActAgent、GeneralAgent。这种设计抽象层级清晰理论上可以支持任意类型的 Agent 实现扩展性极强。但实际跑起来发现代码抽象层级太高带来的问题是调试困难。你很难从一次失败的调用里快速判断是模型问题、工具问题还是事件流断掉了。它的错误信息做得也比较学术化经常抛出一个堆栈就没了对新手非常不友好。还有一个工程上的硬伤依赖相当重装完环境差不多要 3GB 磁盘空间在轻量级使用场景下有点杀鸡用牛刀。3.4 AutoGen框架先驱但版本割裂AutoGen 是 Microsoft 出的多智能体对话框架Python 生态里提到 Agent 绕不开它。源码拆下来看AutoGen 的设计思路是“对话即协作”——多个 Agent 之间通过对话消息来协调任务每个 Agent 都可以订阅或发布消息形成松耦合的协作网络。AutoGen 的ConversableAgent基类设计得不错它把模型调用、工具执行、人机交互封装成一个统一的对话循环。子类可以方便地覆盖特定方法实现自定义行为。这种设计给了开发者很大的自由度。最大的问题是版本割裂。AutoGen 0.x 和 1.x 之间的 API 变化非常大网上教程大部分还在用 0.x 的写法新项目建议直接用 1.x 或者迁移到 Microsoft 后来主推的 Semantic Kernel但迁移过程中很多概念对不上社区里求助帖特别多。这导致 AutoGen 在实际落地时候的学习成本很高不只是学框架本身还得甄别网上的旧教程。3.5 CrewAI做产品的人写的框架CrewAI 提供了“角色扮演”式的 Agent 协作模型。你定义一个 Crew团队里面设多个 Agent每个 Agent 有角色、目标、背景故事通过 Task 对象来分配工作。这种设计非常贴近真实的团队协作产品化程度很高上手几乎是零门槛。源码层面CrewAI 的核心是Crew类和AgentExecutor。AgentExecutor控制单个 Agent 的执行循环Crew负责任务分配和结果汇聚。工具调用是通过 LangChain 的 Tool 标准实现的——你能无缝使用 LangChain 生态里的几百个现成工具这是它生态分高的关键。但也正因为重度依赖 LangChain抽象层变厚了。出问题排查的时候就比较痛苦错误信息经常从 LangChain 底层抛上来一层一层封装之后原始原因很模糊。性能上也有开销CrewAI 的循环内部做了大量数据验证和转换在小任务上延迟偏高不是追求极致性能的选择。3.6 LangGraph把 Agent 当图来写LangGraph 的架构思路比较新颖整个 Agent 运行流程被建模成一张图节点是执行单元边是状态转移条件状态存到一个全局的StateGraph里。这种设计大大提升了复杂流程的可控性你可以清晰看到每一步处理什么、在什么条件下跳到下一步。LangGraph 的StateGraph用 TypeScript 和 Python 双语言实现核心状态管理逻辑做得非常整洁。节点之间的状态传递是显式的不会出现“为什么这个数据跑到这里来了”的玄学问题。它还内置了持久化层支持将图状态存到数据库重启后能从断点恢复这对长时间运行的任务非常关键。但 LangGraph 的缺点也很明显概念抽象层级高。对于只需要“给模型挂个工具然后循环执行”的简单场景用 LangGraph 反而引入不必要的复杂度。它的图形化心智模型适合做复杂编排但学习曲线是全项目里最陡的之一从入门到真正能设计出高效的工作流需要一段时间。3.7 Dify产品化程度最高但自由度受限于平台Dify 严格意义上不完全是一个 Agent 框架它更像是一个 LLMOps 平台把模型管理、RAG、Agent、工作流、API 发布都整合到了一起。但从源码拆解和实际使用看它的 Agent 工作流引擎确实有值得学习的地方。Dify 的 Workflow 引擎设计核心是用GraphNode描述流程每种节点类型对应一个执行器通过NodeRunner统一调度。但这个引擎的设计目标是为了在 UI 上拖拽配置而不是给开发者用代码自由编排。所以你在代码层面做复杂控制的时候会很别扭——它的抽象是为了视觉化操作服务的而不是为了写代码。Dify 的生态也很特殊因为它是平台型产品源码仓库里还包含大量服务端、数据库等非 Agent 部分的代码如果你只是想研究 Agent 循环会被大量 schema 定义和 API 代码淹没。它的价值在于快速搭建产品原型——如果目标是做一个带后台管理的 LLM 应用Dify 效率无与伦比如果你想深度定制自己的 Agent 逻辑它就是那个最重、最不灵活的选项。4. 核心对比与结论为什么最高分不是 Codex4.1 总分与分维度对比经过两周的源码拆解和实际场景验证最终评分如下项目代码质量核心循环工具扩展上下文生态实际体验加权总分Claude Code7.59.09.09.58.59.08.70Codex CLI9.58.57.58.09.08.58.50OpenHands7.09.08.58.58.06.58.15LangGraph8.58.08.58.58.57.08.20CrewAI7.57.58.07.08.58.57.80AutoGen7.08.08.07.57.56.57.50Dify7.57.07.07.58.07.57.35最终总分排名是Claude Code8.70 Codex CLI8.50 LangGraph8.20 OpenHands8.15 CrewAI7.80 AutoGen7.50 Dify7.35。看到这个排名相信很多人第一反应是为什么 Codex 丢了第一理由在下面的对比分析里。4.2 决定排名的关键差异点第一个关键差异是核心循环的通用性。Codex 的核心循环实现很漂亮代码质量确实无可挑剔——类型安全、状态清晰、分支明确。但它的循环是专门为“命令行编程助手”这个场景高度优化的。它假设了输入是终端指令、输出是代码操作、错误处理是权限确认。这个假设在编程场景下非常高效但一旦跳出去就成了一种束缚。Claude Code 的循环设计则更像一个“通用 Agent 调度器”。它的 AgenticEvent 机制把模型输出、工具结果、权限请求、用户反馈全部拉通成统一事件流不同的事件可以被不同的处理器响应。这种设计带来的好处是你可以轻易地在里面加新类型的工具、新类型的交互方式、新类型的上下文来源而不用修改主循环结构。从可扩展性角度看Claude Code 的主循环比 Codex 更接近一个通用 Agent 框架应有的样子。第二个关键差异是上下文管理策略。Codex 的上下文管理方式是线性裁剪——窗口不够了就丢最早的历史。这在短任务里很够用但长任务里容易出现“模型忘了前面做了什么”的问题。Claude Code 的 ContextManager 则是分优先级管理的核心指令和关键文件内容会被保护非关键上下文会被摘要化压缩。这个差异在实际使用感受上是天壤之别——跑一个 30 分钟以上的任务Claude Code 对上下文的“记忆”要可靠得多。第三个关键差异是工具生态接入方式。这里必须提到 MCPModel Context Protocol。Claude Code 对 MCP 的支持非常到位可以直接通过 MCP 服务器接入丰富的第三方工具。而 Codex 的工具集基本以内置为主虽然也有插件接口但设计之初就不是为 MCP 这种通用工具协议准备的。当前 Agent 生态的发展方向就是“模型无关协议通用”谁能更好地接入开放的协议生态谁在长期演进中就更占优。MCP 正好是 Claude Code 出生的 Anthropic 提出的协议它天然具备先发优势。当然这不是说 Codex 不好。恰恰相反Codex 是我日常工作中实际使用频率最高的工具因为它在“写代码”这个垂直场景里做得极致优秀。但这次评测的是一般 Agent 的通用能力而不是“谁最适合当编程助手”。这两个问题的答案不一样。我这篇文章的结论是综合通用性、扩展性、上手成本、生态丰富度之后的加权结果。如果你只关心编程助手的体验Codex 完全有可能在你个人的评价体系里排第一。5. 实践过程中的踩坑记录与排查思路5.1 环境搭建阶段的典型问题第一批坑出现在环境搭建阶段。AutoGen 的版本割裂问题是最让人头疼的——pip 默认安装的是 0.4.x但网上大量教程和示例代码还停留在 0.2.x 的 API。安装完跑第一个多 Agent 示例发现ConversableAgent直接导入失败打开文档发现对应类的路径早就变了。排查思路是先用pip show autogen-agent确认版本再打开官方文档的 Migration Guide对照新版 API 逐个改导入路径。如果干脆不用 AutoGen 0.x直接上autogen-agent这个新包能少走很多弯路。OpenHands 的环境依赖也值得单独提醒。它需要 Docker 来运行沙箱环境这个依赖本身不难但 Docker 镜像动不动几个 GB首次构建时间非常长。如果网络环境不好拉镜像失败的概率很高。建议预先设置 Docker 国内镜像源或在 CI 环境里预构建镜像缓存。5.2 运行过程中遇到的问题跑实际 Agent 任务时LangGraph 的调试体验差点让我放弃。初期写一个简单的 ReAct 循环回调函数 - 条件边的逻辑一直不对任务反复进入死循环。排查过程里发现 LangGraph 的递归限制默认值是 25 步Python 版本可配置调试时很容易触顶。解决办法是先将recursion_limit调高到 100同时在条件边里加日志观察每一步的状态快照。Claude Code 的权限确认机制比较“啰嗦”——每执行一次命令都要确认一次权限批量操作时非常打断节奏。后来发现可以在设置里配置自动允许列表把高频命令或特定文件路径加进去体验顺畅很多。但有一点不建议大家图省事开全局自动允许遇到rm -rf之类的危险命令时权限确认是最后一道保险。CrewAI 遇到最多的是工具传递异常。任务里声明了工具但 Agent 执行时拿不到原因一般是Task对象里的工具列表和Agent对象里的工具列表不一致。这种问题光看报错信息很难发现排查思路是直接打印 Agent 初始化后的最终工具注册表确认它实际绑定了哪些工具。5.3 常见问题速查表问题现象可能原因排查方向AutoGen 导入失败版本割裂新旧 API 不兼容检查版本按 Migration Guide 修改OpenHands 启动慢Docker 镜像过大预先拉取镜像配置加速LangGraph 任务死循环条件边逻辑错误或递归上限过低调高 recursion_limit加状态日志Claude Code 权限频繁打断默认权限策略严格配置自动允许列表CrewAI 工具不生效Agent 与 Task 工具列表不一致打印工具注册表确认绑定Codex 长任务失忆上下文裁剪策略简单切分任务避免单轮过长这个速查表是我实际踩过坑之后的记录个人经验仅供参考不同版本可能表现略有差异。6. 选型策略什么场景该选哪个框架评测不是终点选型落地才是。以下是根据使用场景给出的框架选型建议。如果你是以编程助手定位为核心诉求日常就是在终端里写代码、改 bug、做代码审查那我会直接推荐 Codex CLI。它在这个场景下是最稳的选择工具链紧凑、代码质量高出错率低。虽然 Claude Code 综合分更高但在“特化编程”这个垂直赛道Codex 的特化优势还是能压过通用性优势。如果你是要构建一个自己产品的 Agent 功能场景不太固定需要接自己的业务工具和数据源Claude Code 或 LangGraph 会是更好的底子。Claude Code 胜在开箱即用、MCP 生态成熟LangGraph 胜在流程可控、状态可持久化适合需要精确控制 Agent 行为的场景。两条路线各有取舍——要快就用 Claude Code要精就用 LangGraph。如果你是做多智能体协作研究或原型验证OpenHands 的 Agent 分层架构最值得参考事件驱动的设计能让你快速验证新想法。但注意 OpenHands 的资源消耗和学习成本都偏高不太适合作为轻量业务系统的核心依赖。如果你是做产品原型验证、快速给客户演示Dify 是最优解。它把模型管理、提示词编排、知识库、工作流、API 发布全包了从零到可演示原型的周期可以压缩到一周以内。代价是后续做深度定制时会受限如果产品验证通过后想进一步精细化可能会面临二次开发的成本。如果你已经深度使用 LangChain那 CrewAI 基本无缝衔接学习成本最低。如果你的项目数据库中已经存了大量业务数据准备在上面做智能体应用LangGraph 的持久化状态设计优势比较大。个人的倾向性建议是——不要把选型想成“找一个最好的框架”然后一劳永逸。做技术选型的正确姿势是先明确你的第一场景是什么然后选那个在该场景下最切合的项目同时预留框架替换的抽象层。Agent 领域还处于快速演进期今天的最优解可能半年后就过时了给未来留出退路比现在一步到位更重要。7. 项目后续的扩展方向源码拆完、评测出结果之后这个项目本身其实还有几个值得延续的方向。一个方向是跟踪 MCP 协议的进化。我这次拆解时明显感觉到MCP 正在成为 Agent 工具调用的“通用接口层”。后续可以做一个更垂直的调研MCP 协议在不同框架里的实现差异哪些框架支持得好哪些是“半吊子支持”这直接关系到你的项目接入第三方工具时的兼容成本。另一个方向是做一个插件抽象层的标杆实现。从源码拆解来看Claude Code 是集成 MCP 最顺滑的LangGraph 是状态管理最清晰的如果把两者优点结合起来设计一套框架无关的“Agent 工具注册与调用规范”对开源社区会很有价值。还可以做性能基准测试。把同样一组任务比如代码生成、信息抽取、多步骤工具调用跑在七个框架上对比响应延迟、token 消耗和准确率。这类数据实际项目选型时很稀缺大多是感性经验或官方博客的“自卖自夸”。下次拆源码回顾这些项目时我个人最大的体会是框架的通用性往往和它在特定场景上的极致表现互相矛盾。Codex 之所以在编程场景里体验好恰恰是因为它不需要考虑其他场景的需求而 Claude Code 综合分最高是因为它在通用 Agent 能力上的设计更完善。作为开发者与其追求“面面俱到”的万能框架不如认清楚自己的核心场景在“顺手”和“可扩展”之间找到一个真正适合自己的平衡点。
