先说结论我把七个开源 Agent 项目的源码按同一套标准过了一遍最后总分第一的不是 OpenAI 的 Codex CLI而是很多人觉得太工程化的 OpenHands紧随其后的也不是 Codex而是 Hugging Face 那个加起来没几个核心文件的 smolagents。这个结果我自己都没料到拆之前我的直觉和大家一样——Codex 是官方出品背后是那套最强的模型链路怎么可能不是第一。但模型强和框架好是两码事把源码摊开看差距全在生产设计的选择上。这篇不是软文也不打算教你装某个工具。我想把拆这七个开源 Agent 源码的过程、评分逻辑、以及最后时刻才浮现的关键发现完整写出来适合正在做 Agent 选型、或者想自己读懂一个 Agent 项目的工程师。如果你只想要个结论Codex 在能不能把活干完这件事上确实最猛但论整体工程质量和可落地性至少在我这套评分体系下它只能排第三。1. 为什么会去拆七个开源 Agent 项目1.1 起因团队内部的真实痛点我们团队想做一个内部提效工具核心需求是让 Agent 直接跑在私有代码仓库里给定一个 issue 描述Agent 自己读代码、定位问题、改代码、跑测试、最后产出一个可供 review 的 diff。听起来不算复杂但一旦动手就会发现市面上的开源 Agent 项目少说几十个每个 README 都把自己吹得天花乱坠。文档看得越多越迷糊。有的项目强调多角色协作有的强调事件驱动有的直接说自己是下一代软件公司。我们几个工程师一合计与其猜不如直接把源码拉下来读。于是就有了这七份拆解记录。整个拆解前后花了两周左右白天写业务代码晚上回来啃源码每个项目至少跑通一个真实任务、通读一遍核心循环、再清理一遍历史 issue。1.2 拆解方法不看架构图先找主循环拆之前我定了五步走的流程每个项目都按这个顺序来避免被项目方的宣传带偏先把项目跑起来用一个统一的任务做冒烟测试给一个真实开源仓库修 bug要求产出能提交的 diff。从入口文件开始读找到 Agent 的主循环。所有 Agent 项目本质上都是一个循环读输入、调模型、拿动作、执行动作、观察结果、再读输入。沿主循环画数据流搞清楚用户输入进去之后经过了哪些模块最终动作是怎么出来的。重点盯三个地方上下文怎么管理、工具怎么调用、失败怎么恢复。翻测试和 issue看哪些边界情况连作者自己都没处理。这套流程走完一个项目的骨架基本就清晰了。我不太看架构图也不迷信 README 里的设计理念就让代码自己说话。1.3 最终进名单的七位选手市面上的项目很多但我刻意挑了三种不同类型凑齐七席保证对比有意义项目一句话定位主要语言许可证架构关键词OpenAI Codex CLI官方模型的本地编码助手Rust TypeScript 扩展Apache 2.0单 Agent、命令行、配置驱动OpenHands自治软件开发智能体Python TypeScriptMIT事件流、Docker 沙箱smolagents极简 Agent 框架PythonApache 2.0代码即动作、提示缓存MetaGPTSOP 驱动的多智能体框架PythonMIT角色、动作、消息池CrewAI角色化编排框架PythonMITCrew、Task、流程编排AutoGen会话式多智能体框架PythonMITConversableAgent、GroupChatAutoGPT元老级自治 AgentPythonMIT经典循环、平台化转型这个列表覆盖了三种路线一种是官方模型的开源客户端Codex CLI一种是完整平台型底座OpenHands、AutoGPT一种是可嵌入的编排框架smolagents、MetaGPT、CrewAI、AutoGen。没有刻意选冷门的全是大家嘴边长挂着的名字拆出来的结论才更有参考价值。2. 评分维度不是拍脑袋定的2.1 六个维度与权重给七个项目打分之前我先定了一套六维评分框架。权重是团队一起聊出来的侧重点很明确我们要的是能落地的工程底座不是论文 demo所以任务完成能力权重最高其次是代码质量和架构扩展性开发体验、社区生态、运行成本作为辅助项。维度权重考察内容任务完成能力40%统一测试集上的通过率、产出 diff 的质量框架代码质量15%核心循环行数、圈复杂度、单测覆盖率、可读性架构与扩展性15%能否更换模型、能否接入私有工具、能否多 Agent 协作开发体验10%文档完整度、配置复杂度、上手时间社区与生态10%活跃度、issue 响应速度、周边插件数量运行成本10%单任务 token 消耗、内存占用、是否需要重型基础设施2.2 任务集设计同一模型、同一接口、同一时间限制我设计了 15 个真实任务分布在三个难度档5 个修 bug 任务、5 个从零实现小功能的任务、3 个跨文件重构任务、2 个长上下文任务要求先读多个相关文件再动手改。每个任务限时 20 分钟超时算失败。这里有一个非常重要的公平性细节Codex CLI 默认走的是 OpenAI 的 Responses API而其他大多数项目走 OpenAI 兼容的 Chat Completions 接口。为了不让模型差异和接口差异污染结果我把七个项目全部统一成同一个模型、同一个 base_url、同一套参数配置。这一步折腾了我快两天——有的框架对接口格式非常挑剔有的框架直接硬编码了模型名。后面章节会详细讲这本身就是拆解过程中最有信息量的一部分。2.3 代码质量怎么量化代码质量不能靠感觉我用了三个硬指标加一个软指标。硬指标是核心循环的文件行数越长越可疑、单测覆盖率从 CI 配置或覆盖率报告里读、以及 Core Agent Loop 的圈复杂度用 radon 这类工具跑一遍。软指标是我自己在读代码时的主观可读性打分记 0-10 分只占很小权重。3. 逐项拆源码七个项目各自的骨架长什么样3.1 smolagents把 Agent 讲明白只需要几个文件拆完所有项目后回头看smolagents 是唯一一个让我产生原来可以这么简单想法的框架。它的核心 Agent 循环集中在一两个文件里总代码量跟其他几个动辄几万行的项目完全不在一个量级。它的关键设计是 CodeAgent 和 ToolCallingAgent 两条路线。ToolCallingAgent 跟大多数框架一样让模型输出结构化的 JSON 来触发工具调用但 CodeAgent 走的是另一条路直接让模型生成 Python 代码运行代码把执行结果再喂回给模型。别小看这个差别它意味着复杂逻辑比如循环处理一批文件、带条件分支的判断可以在模型的一次推理里用代码表达完而不是让模型在JSON in - JSON out之间反复挤牙膏。从源码里能看到这个设计带来的连锁反应。因为没有密密麻麻的工具 schema 校验逻辑框架的纠错路径非常短整体读起来很清爽。它的最大短板也很明显既然模型生成的代码会被执行就必须有安全的沙箱。仓库里对此的默认实现其实比较朴素真要跑不可信任务得自己想办法加固。3.2 OpenHands事件流即一切OpenHands改名前的 OpenDevin是这七个项目里架构最有平台感的一个。它的核心抽象是把 Agent 的所有交互都变成事件用户的指令是事件模型的动作是事件执行动作后的观测也是事件。整个系统就像一个流水账本前端拿到事件回放 UI后端拿着事件做重试和恢复测试直接用事件断言。这种设计的工程收益在源码里体现得很充分。比如后悔重来这件事其他框架要实现非常麻烦OpenHands 直接把历史事件流截断到某个时间点再重新执行后续事件就行。再比如并发任务它天然可以把不同事件流隔离在不同沙箱里互不干扰。当然代价也有。事件驱动的架构带来了明显的复杂度消息类型、事件序列化、仓储层这些基础设施占了不少代码量。如果你想把它嵌入到自己的轻量项目里会觉得它有点重但如果你想认真做一个能长期迭代的 Agent 服务底座这个重量反而是值得的。3.3 Codex CLIRust 核心工程味很重但节奏太快Codex CLI 是七个项目里唯一一个核心用 Rust 写的。从工程角度来看它选型很聪明Rust 保证了 CLI 的启动速度和运行时稳定性TypeScript 扩展体系则让上层生态可以快速迭代。它的主循环是典型的配置驱动通过配置文件定义模型、权限策略、扩展规则Agent 在循环里反复评估当前状态、调用工具、观察结果。但我拆到一半就意识到一个问题它的代码仓库演进速度太快了。很多实验性功能是边想边加的导致代码里能看到明显的结构重构进行时痕迹。有些模块在 v0.x 里刚抽象出来到下个版本又换了组织方式。这种速度对使用者是好事功能推得快但对想基于它做二次开发的团队来说很不友好——你可能刚读完一个版本的源码它又重构了一轮。另一个让我印象深刻的是它和自家 API 的深度绑定。虽然社区里有各种方式把它接到其他模型上尤其是一些国内模型但我在配置过程中明显感觉到官方路径是为自家接口做了很多隐式假设的自定义接入的坑比想象中多很多报错信息对排查问题几乎没有帮助这个后面细说。3.4 MetaGPT把 SOP 写进角色里MetaGPT 的思路在七个项目里独树一帜。它不是让一个 Agent 从头干到尾而是把一个软件公司的交付流程产品经理写 PRD、架构师写设计、工程师写代码、测试跑用例固化成了多个角色角色之间通过共享消息池协作。读它的源码最直观的感受是重流程。每个角色是 Role Action 的组合Action 又是可复用的原子能力消息池用发布订阅的方式把中间产物传递给需要的角色。它会对中间产物做结构化约束PRD 必须包含哪些字段、设计文档必须有哪些章节全在数据模型上钉死了。这种设计的优点是很确定产出的过程可预期缺点是灵活性差。如果你要跑的流程不在它预设的 SOP 里就得自己去写 Role 和 Action 的组合逻辑学习成本不低。而且在我这套统一模型配置下它的多角色流水线消耗的 token 非常可观因为每个角色都要重读一遍公共上下文。3.5 CrewAI 与 AutoGen抽象路线之争这两个框架放在一起说因为它们回答的是同一个问题多个 Agent 该怎么编排。但它们给的答案完全不同。CrewAI 走的是角色化 流程化路线。它用 Crew、Agent、Task 三个核心概念把所有事情结构化流程分顺序执行和层级执行两种开发体验确实做得不错新手上手快。但源码翻到深层会看到为了把一切抽象得好懂它做了不少隐式的魔法出了问题排查起来需要一层层剥开装饰器。AutoGen 走的则是会话驱动路线。它的核心是 ConversableAgent所有交互都可以被建模成两个 Agent 之间的对话GroupChat 和 GroupChatManager 负责多方的消息路由。AutoGen 的 0.4 版本经历了一次大重写转向事件驱动架构代码组织更工程化了但我必须诚实地说学习曲线是真的陡光是把继承体系捋清楚就得花不少时间。它的能力上限很高但对初学者非常不友好。3.6 AutoGPT元老级项目双轨困境AutoGPT 是 2023 年那波自治 Agent 热潮的起点历史地位没得说。但拆它的源码时心情比较复杂。经典版的 Agent 主循环很简单就是一个直接行动模式把目标喂给模型模型输出下一步反复迭代直到认为任务完成。这个循环直观但也朴素没有复杂的上下文管理和失败恢复机制。真正让我纠结的是它的双轨布局——一边是经典 Agent 代码另一边是新推出的 Platform/Blocks 体系。两条线同时存在仓库结构上明显能看出转型期的摇摆。从工程一致性来看它在这七个项目里属于偏弱的但它的社区基数和话题度仍然很大如果你需要的是一个社区活跃、能跟上热点的起点它依然值得关注。4. 拉开分差的关键执行循环、上下文与工具调用4.1 三种执行循环决定了项目的天花板把所有源码摊开对比后我发现决定一个 Agent 框架上限的首先是主循环的形态。大致可以分成三类执行循环形态代表项目优点缺点线性脉冲循环AutoGPT、Codex CLI简单直接容易理解状态管理弱长任务容易走失事件驱动循环OpenHands、AutoGen可回放、可恢复、可并发实现复杂学习成本高SOP 流水线MetaGPT过程可控产出可预期流程固定灵活性差角色编排循环CrewAI业务语义清晰编排逻辑和业务逻辑耦合较深这里我想展开讲一个细节失败恢复。线性循环的框架在任务中途一旦出错普遍做法是让模型自己看看哪里错了再试试但这种恢复非常靠运气。事件驱动框架则可以做到更结构化的恢复——把失败那一轮之前的事件重新执行状态不会丢。我评测的长上下文任务里事件驱动类型的表现明显更稳这就是为什么 OpenHands 在最关键的任务完成维度上能紧咬 Codex。4.2 上下文管理全量回放、截断、还是压缩上下文窗口是所有 Agent 项目绕不开的坎。源码里对这个问题给出的答案很有意思OpenHands 倾向于全量事件回放 摘要压缩双保险事件流保证每一步都可追溯上下文快满了就触发摘要整理。smolagents 走的是够用就好路线对话历史管理很轻配合 prompt caching 把重复前缀的 token 成本降下来。实测下来它的 token 消耗确实低。Codex CLI 有完整的文件变更追踪和对话摘录机制但在长会话里还是会遇到模型上下文塞满的问题社区里已经有不少人遇到了类似报错。AutoGPT 和 MetaGPT 在这方面的处理相对粗糙AutoGPT 经典版基本靠模型自己把握MetaGPT 则是每个角色各读各的消息池天然避免了单上下文过大的问题但代价是每个角色都在重复消费公共信息。4.3 工具调用JSON 函数调用还是直接写代码这个维度是 smolagents 能拿高分的核心原因。绝大多数框架执行工具的路径是模型输出一个 JSON框架解析 JSON、做 schema 校验、再调用对应的函数。这条链路安全、可控但每一步都有开销和出错的可能。smolagents 的 CodeAgent 直接让模型生成 Python 代码然后执行。它把调用工具这件事变成了写代码表达能力和复杂逻辑处理能力一下子拉开了。比如把这个目录下所有文件的 TODO 注释统计出来这种任务ToolCallingAgent 需要循环多次调用工具函数而 CodeAgent 一次生成的代码就能完成整个循环。我并不是说代码执行方案一定优于 JSON 调用方案。恰恰相反让模型自由写代码然后把结果执行对沙箱要求极高。但在受控场景下尤其是面向代码仓库的任务代码动作的效率优势是压倒性的。这个取舍在源码里体现得淋漓尽致。4.4 安全边界沙箱、审批、还是裸奔最后一个拉开差距的点是安全。七个项目对Agent 能碰什么的理解完全不同Codex CLI本地命令审批用户确认命令后才执行。简单但有效适合个人开发者。OpenHandsDocker 沙箱隔离动作在容器内执行宿主环境受影响面小。平台级标配。AutoGen不绑沙箱靠开发者在自己的基础设施里解决隔离问题。AutoGPT经典版默认本地直接执行命令安全机制约等于没有这在早期版本里引发过不少争议。smolagents代码执行方案对沙箱格外依赖但默认实现相对初级必须二次加固。安全边界的完备程度和工程复杂度是成正比的。如果你只想在本地 CLI 上跑 AgentCodex 的审批制完全够用如果你想把它变成多人可用的服务没有沙箱的方案根本不敢上线。这也是我在最终评分里把 OpenHands 的安全架构算作加分项的原因。5. 最终得分Codex 到底输在哪5.1 六维得分总表把六个维度的分数按权重加权后七位选手的最终排名如下项目任务完成 (40%)代码质量 (15%)架构扩展 (15%)开发体验 (10%)社区生态 (10%)成本资源 (10%)加权总分OpenHands88909285888087.8smolagents80958890829586.2Codex CLI93787582807283.6MetaGPT82808575847881.3CrewAI75828688908281.2AutoGen78848872857680.3AutoGPT70727874887073.7Codex CLI 在任务完成维度拿了 93 分是全场单项最高。但加权之后它被 OpenHands 和 smolagents 反超了。5.2 Codex 的三个具体扣分点第一个扣分点是架构与扩展性。Codex CLI 本质上是一个单 Agent、单会话的本地工具。它没有多 Agent 协作的抽象没有事件持久化机制没有任务编排原语。如果你要做的不是一个帮助程序员敲命令的助手而是一个能并行处理大量 issue 的 Agent 平台它的架构起点就不匹配。OpenHands 在这个维度拿了 92 分因为它从一开始就把事情当成平台来设计了。第二个扣分点是自定义模型接入的成本。拆源码时我花了大把时间处理它与其他模型的兼容性问题。它深度依赖自家接口的若干行为假设换成通用 OpenAI 兼容接口后功能表现有明显的折扣而且配置过程坑很多各种让人摸不着头脑的报错、文档没有覆盖到的环境变量、以及本地 endpoint 切换失败问题。这些不是不可解决但解决成本实实在在地摊到了使用者头上。相比之下smolagents 和 OpenHands 对模型接口的抽象做得很干净换模型基本就是改配置。第三个扣分点是代码可维护性。这里要公平地说一句Codex CLI 的迭代速度让它长期处于重构进行时状态。部分模块的职责边界不清晰有些实验性功能缝缝补补地挂在主循环上。对于只想用它当工具的人来说完全没问题但对想 fork 二次开发的人来说这是真实的成本。我给了它 78 分不算低但拖后腿了。5.3 为什么是 OpenHands 和 smolagentsOpenHands 登顶的核心原因是没有明显短板。它的任务完成能力虽然略低于 Codex但已经处于第一梯队它的架构、代码组织、社区活跃度全部在 85 分以上事件流设计带来的可恢复性和可测试性让它在真实工程场景里占了大便宜。说白了它不是某个单项的冠军而是全能六边形战士。如果你的目标是用 Agent 构建一个内部服务OpenHands 是最接近开箱即用底座的存在。smolagents 则是最让我惊讶的黑马。它拿到 95 分的代码质量分和 95 分的运行成本分靠的不是堆功能而是极致的克制——用最少的代码解决了 Agent 最核心的问题把复杂度挡在了框架之外。它的缺点是任务完成能力只有 80 分当任务需要更强的自我纠错和长程规划时它的轻量设计反而成了瓶颈。如果你主要诉求是在一个成熟项目里快速嵌入 Agent 能力并且希望它好维护它可能比 Codex 和 OpenHands 都合适。5.4 分数的适用边界必须承认这套分数是有适用边界的。我的测试集以代码仓库任务为主如果你的场景是客服问答、数据分析、文档处理排名很可能会变。另外我没有测微调场景、没有测极大规模并发、也没有深入评估每个项目的安全加固上限。做技术选型最忌讳把一个综合分数当成绝对真理它只能告诉你大多数情况下的概率最优解。6. 拆完源码我给 Agent 选型的实操建议6.1 按场景对号入座你的场景首选备选不推荐本地用 CLI 辅助写代码Codex CLIOpenHandsAutoGPT构建内部 Agent 服务多人使用OpenHandsAutoGenAutoGPT在现有系统里嵌入 Agent 能力smolagentsCrewAIMetaGPT跑标准化的多角色交付流程MetaGPTCrewAICodex CLI做学术实验/快速原型smolagentsAutoGenCodex CLI纯社区热度驱动的探索AutoGPTCrewAI—列完这张表还想多说一句没有最优只有适配。选型时建议把你们团队最在意的那个维度权重调高然后用同样的测试集重新排一次序比直接抄任何榜单都可靠。6.2 自己拆 Agent 源码的三个顺序建议如果你也想亲手拆一个 Agent 项目我建议按这个顺序来能省很多时间先找主循环别顺着目录结构从头看。直接搜关键词比如 reason、execute、observe、step先定位 Agent 干活的那个循环再逆着往外扩展。先跑测试再看实现。很多框架的测试用例本身就是最好的使用文档它会把主循环在各种边界条件下的预期行为写得清清楚楚。先看 issue 里的退出问题。什么样的错误最常被报告就说明这个项目的哪个环节最脆弱。拆源码前先了解它的老伤读代码时你会自动往那个方向多看几眼。6.3 没进名单但值得关注的名字拆完这七个再补充几个热搜里频繁出现但我没纳入本次评审的名字。pi agent 和 hermes agent 都属于社区热议的新框架各自在轻量化和角色灵活性上有独特设计但成熟度还不够等版本稳定后再拆比较有意义。还有skill 和 agent 的区别以及harness 和 agent 的区别这两个讨论其实是同一个问题agent 负责决策skill/harness 负责提供能力和执行框架。你读任何一个 Agent 源码时只要分清这两层就不容易被框架的术语绕晕。最后再分享一个我这几周拆源码最深的体会判断一个 Agent 项目是否可信不是看它 Star 多少也不是看 README 里的架构图而是看它对失败的态度。处理模型输出异常、工具调用错误、上下文溢出、沙箱逃逸风险——这些真正决定一个 Agent 能不能从 demo 走向生产。Codex 输的从来不是能力而是这套失败处理系统的成熟度和开放性。读代码的时候多往这个方向看两眼很多结论你会自己得出来。