这两个月我把目前社区里讨论度最高的开源 Agent 挨个拆了一圈——OpenAI 的 Codex CLI、Cline、OpenHands、Aider、Goose、smolagents外加“祖师爷”AutoGPT。拆源码不是为了图新鲜而是想回答一个很现实的问题2025 年这个节点一个真正能拿来干活的开源 Agent工程上到底应该怎么搭哪些设计是花架子哪些设计是命根子结果有点打脸。按照我自己的评测标准打完分最高分不是热度最高的 Codex也不是方法论最漂亮的 OpenHands而是 Cline。这个结论发出来肯定有争议所以我先把选型思路、评分标准、七个项目的源码亮点、实测中的真实差异全部摊开写清楚结论放在最后让大家自己判断。文章适合三类人正在做 Agent 技术选型的人想基于开源项目做二次开发的工程师以及单纯想看懂 Agent 源码内部设计的学习者。全文不站队只说实测记录。1. 为什么拆这七个开源 Agent以及我的评分标准1.1 七个项目怎么选的流派比热度更重要市面上的开源 Agent 少说几十个我只挑了七个核心原因是它们的“流派”几乎没有重叠每个都代表一种不同的工程路线。Codex CLIOpenAI 出品的命令行 AgentTypeScript/Node 技术栈代表“官方把 Agent 循环做成了产品”的路线。ClineVS Code 插件型 AgentTypeScript React早期叫 Claude Dev代表“把 Agent 塞进 IDE 工作流”的路线。OpenHandsPython 为主的自治任务 Agent前身是 OpenDevin代表“给 Agent 一个沙箱让它自己折腾”的学院派路线。AiderPython 写的终端配对编程工具代表“git 第一公民、增量改代码”的实用主义路线。GooseBlock 公司开源的 Rust Agent主打本地自动化和 MCP 生态。smolagentsHugging Face 出品的轻量 Python 库代表“代码即行为”的极简路线。AutoGPT2023 年开源 Agent 浪潮的起点虽然现在看骨架过时但历史位置没法跳过。选这七个还有个私心它们的源码规模差异很大从几千行到几十万行都有。把它仨放一起拆能很直观地看出“同一个问题不同团队会因为目标用户不同做出完全相反的工程取舍”。1.2 拆解手段源码精读加真实任务实测我拆源码的方式比较笨但结果扎实。先把每个项目的 GitHub 仓库 clone 到本地用 ripgrep 过一遍核心目录结构再把主循环、工具调用、上下文管理、配置加载这几条主线代码通读一遍。通读之外每个项目我都实际跑了两类任务。第一类是“代码任务”让 Agent 把一个 Python 脚本改造成带 CLI 参数的工具再补上单元测试。第二类是“研究任务”让它去读一个陌生代码仓库写出一份带结论的 review 报告。跑完记录三个东西——任务完成质量、过程中需要人介入几次、出问题后能不能通过日志和配置快速定位。最后按六个维度打分安装体验10 分、代码可读与工程组织15 分、任务完成度25 分、上下文与记忆策略15 分、可控与调试体验15 分、扩展与生态20 分总分 100 分。这个权重不是随便拍的任务完成度最高是因为 Agent 存在的唯一意义就是干活可控与调试紧随其后是因为源码拆得再多不好调试的工具在真实开发里根本没法长期用。1.3 最终评分表先亮结论再展开项目安装体验10代码可读与工程组织15任务完成度25上下文与记忆策略15可控与调试体验15扩展与生态20总分Cline8132314141688Codex CLI9142213131586OpenHands7122212121984Aider8131913131480Goose7121711121877smolagents9131810131174AutoGPT6916982068Cline 拿第一Codex 拿第二OpenHands 第三。这个结果我自己拆之前也没想到因为单看代码质量Codex 和 OpenHands 都很能打。但把安装、调试、任务完成度、生态放一起看Cline 的综合分更稳。下面逐个展开。2. 逐个拆透每个项目源码的核心亮点与硬伤2.1 Codex CLIAgent 循环的教科书但门槛都在模型侧Codex CLI 的源码给我最大的感觉是“克制”。它没有堆一大堆抽象概念核心就是一条消息循环循环里依次做四件事把系统提示、仓库上下文、工具结果组装成消息发给模型等模型返回工具调用执行工具并回填结果。代码里对“工具”的抽象非常简洁内置工具包括执行 shell 命令、apply_patch 修改文件、网页搜索等每个工具的输入输出都用严格的 schema 约束。它的亮点是 AGENTS.md 机制。你可以在仓库根目录放一个 AGENTS.mdCodex 会在每次会话开始时把里面的规则注入到上下文里。包括“不要修改锁文件”“测试命令是什么”这类项目级约定实测下来对任务完成度的提升非常明显。另一个亮点是沙箱选项源码里对--sandbox参数做了三种模式无沙箱、读写工作区、完全只读安全边界设计得很清晰。硬伤也明显。Codex 默认绑定的模型是它自家那一套虽然支持通过配置切换到别的模型但很多细节比如wire_api的兼容层、部分端点行为的差异需要你自己去踩。它的调试入口只有终端日志对于不熟悉命令行工具的开发者来说排错成本比 Cline 高不少。2.2 Cline把 IDE 变成完整 Agent 工作台Cline 的源码规模比 Codex 大不少因为它首先是 VS Code 扩展包含 UI 层、Webview、消息协议再往下才是 Agent 核心逻辑。拆它源码时我最惊喜的是 plan/act 双模式。plan 模式下 Agent 只输出方案不动文件act 模式才真正执行修改。这个设计把“思考”和“动手”分开让你在放权之前有机会审查实际用起来能拦住大量无效修改。另一个细节是 checkpoint。Cline 的源码里有一套基于 git 分支的快照机制每次关键操作前自动创建一个分支出问题可以随时回滚。这在我实测里救了好几次——有一次 Agent 把测试文件改到一半状态乱了直接切回 checkpoint 重来。Cline 的硬伤是它的核心跑在 VS Code 里离开 IDE 环境就废了。CLI 重度用户会觉得很重。代码里还塞了很多模型厂商的适配层逻辑上不可避免会冗余加上 TypeScript 里类型层层嵌套读源码的体验没有 Codex 清爽。2.3 OpenHands自治 Agent 的学院派天花板OpenHands 是七个项目里架构分层最清晰的一个。它的源码围绕三件事展开事件流、运行时沙箱和 Microagent。事件流很好理解所有消息、工具结果、状态变更都走一个统一的事件总线沙箱默认用 Docker 隔离Agent 在里面执行代码、跑命令都不污染宿主机Microagent 则是一组在任务开始时自动加载的小型提示模块让 Agent 具备特定领域的背景知识。OpenHands 最值得学习的是它把“Agent 如何工作”这件事给学术化了。它的任务完成度在长周期任务上很能打因为我实测让它去分析一个不熟悉的项目并产出报告它能自己跑测试、生成图表、整理结论整个过程不需要我介入。开箱体验在七个项目里算麻烦的要装 Docker要配置沙箱镜像对小白不友好但如果你要做自治研究型 Agent它的源码足够你学很久。2.4 Aidergit 第一公民的实用性坚守Aider 的源码和它的产品定位一样纯粹终端、轻量、git 深度绑定。它最大的技术亮点是 repo map——基于 tree-sitter 解析代码结构为每次对话动态生成一个代码地图让模型在不把整个仓库塞进上下文的情况下也能知道函数定义在哪里。这个思路实现起来不复杂但效果很好因为它把“上下文压缩”做在了源头而不是靠事后截断。Aider 会自动 commit。每次 Agent 改完文件它都生成一次提交提交信息由模型根据 diff 自动生成。实测多文件重构时这个设计特别舒服你随时可以 git diff 看改动改坏了就 git reset。它的短板也很明显能力边界基本在“改代码”这一件事上让它去做网页浏览、多步研究、执行复杂运维动作就力不从心了。2.5 GooseMCP 原生的系统级自动化Goose 的代码底子是 Rust 写的这让它跟前面几个项目气质完全不同。它的核心思路是Agent 本身只是一个执行引擎所有能力都通过 MCP 服务器来提供。Git 操作是一个 MCP server锐读文件是一个 MCP server浏览器控制又是一个 MCP server。模块化程度很高因为任何团队都可以写新的 MCP server 来扩展能力不必改 Agent 主程序。Rust 带来的好处是启动快、单二进制分发简单不用装一堆运行时依赖。它的 recipes 机制也很好用相当于预置好的提示词模板比如“帮我做代码 review”“帮我处理日志”。硬伤是它默认的能力范围偏向系统操作代码生成和重构的精细度比 Cline、Codex 差一些更适合做“电脑上的自动化助手”而不是“结对编程搭档”。2.6 smolagents代码即行动轻量到极致smolagents 是 Hugging Face 出的一个 Python 库不是完整应用而是给你一组构建块。它的核心思想很有意思大多数 Agent 框架让模型输出 JSON 工具调用smolagents 反过来让模型直接输出一段 Python 代码框架负责在一个受控解释器里执行这段代码。参数就是代码片段工具函数就是库函数这让它在灵活度上碾压 JSON 式工具调用。源码里有两个核心类CodeAgent 和 ToolCallingAgent。CodeAgent 走代码执行路线ToolCallingAgent 走传统工具调用路线你按场景选。这个库几十行代码就能跑起来对想自己搭 Agent 原型的人非常友好。短板是它定位是库不是成品所有工程化的事你都要自己造比如日志、配置管理、权限控制等。2.7 AutoGPT骨架过时但历史价值极高AutoGPT 的源码放在今天看工程上是有点尴尬的。它的核心组织方式是“循环 命令列表”LLM 返回一个命令名称和参数框架执行命令把结果再塞回循环同时配合 Pinecone 做长期记忆外加任务队列和目标分解。这套设计在 2023 年很惊艳但它的问题是循环的每一步都不带兜底目标稍微模糊一点Agent 就开始无限循环执行无意义的命令。不过不能完全否定 AutoGPT。后来的 Agent 项目几乎都吸收了它的目标分解和记忆思路只是把它做得更收敛、更可控。如果你刚入门 Agent 源码阅读拿 AutoGPT 当反面教材也是一种学习你能直观看到“没有约束的自由发挥”会把 Agent 带到哪里去。3. 七份源码里反复出现的通用设计模式3.1 Agent 主循环的三种写法拆完七个项目我发现所谓 Agent 架构核心就是主循环怎么组织。目前主流有这三种写法。第一种是“轮询消息型”代表是 OpenHands。全局只有一个事件流LLM 回复、工具输出、用户消息全部灌进事件流再由循环统一消费。这种写法扩展性最好容易做并发和多 Agent 协作代价是理解成本高逻辑分散在事件处理里。第二种是“阻塞工具调用型”代表是 Codex 和 Cline。主循环按顺序执行调用 LLM解析输出里的工具调用执行工具循环回到 LLM。代码读起来像一篇线性流程排错非常直观代价是模型一次只能走一步复杂任务来回调用次数多延迟会累积。第三种是“代码解释器型”代表是 smolagents。主循环让 LLM 输出 Python 代码框架把代码丢进沙箱执行执行结果包括 stdout 和异常直接回填给模型。这种行为抽象最灵活因为你让模型“写代码”而不是“填参数”但安全风险也最大必须在沙箱里跑。实话说没有哪一种是绝对最优。项目规模小、场景固定选阻塞型最省心要做研究型自治任务事件流才是正确选择要快速验证想法直接抄 smolagents 的代码执行思路。3.2 上下文压缩与记忆决定长任务的生死拆源码时我专门对比了几个项目处理上下文膨胀的方式差异很大。Codex 的做法是 compaction当上下文接近窗口上限时让模型把前面的对话总结成一个精简版摘要再继续往下跑。Cline 做了自动压缩同时保留关键词索引方便回溯。Aider 的做法最聪明它从源头控制——只有 repo map 和用户明确加进来的文件会进上下文每次只提交必要的 diff。实测对比下来上下文策略直接决定了长任务的完成度。同一个“分析项目并写报告”的任务Codex 在对话超过一轮后明显变慢甚至有两次因为上下文超限直接报错Cline 压缩之后还会继续执行只是偶尔会把之前的关键信息总结丢Aider 因为上下文一直控制得很紧长任务里反而最稳定。这给我的启示是不要在 Agent 框架层死磕“压缩算法”更好的路线是在源头就控制好上下文。能只丢函数签名就不要丢整个文件能用 diff 就不要贴全文。3.3 工具调用的安全边界各家决策差异很大Agent 最危险的地方在于它手上能握工具。我拆的时候发现各家在安全设计上的尺度完全不同。Cline 默认所有操作要人工确认并且提供了 auto-approve 配置你可以按工具类型批准比如只自动允许读文件、写文件、执行测试。Codex 提供沙箱分级从只读到完全读写用参数就能切安全等级划分清晰。OpenHands 把执行环境整体隔离在 Docker 沙箱里宿主机和容器之间只开放少量挂载目录。Goose 靠 MCP 服务器的权限模型每个工具能力都由服务器自己声明。AutoGPT 最弱当年几乎没有安全边界随便一个 prompt 注入就能让 Agent 去执行危险命令。我的建议很明确任何面向生产环境的 Agent至少要有两层防护。第一层是沙箱隔离控制 Agent 能触达的文件和网络第二层是操作审批关键写操作或命令执行必须经过人。只靠模型自觉出事是早晚的。4. 落地实操从源码到能用的完整复现记录4.1 环境准备与第一坑版本锁拆完源码肯定要动手跑。第一件事是环境准备我踩了几个坑先帮大家扫掉。Node 环境建议 20 以上装 Codex CLInpm install -g openai/codex 或 brew install codex。Cline 不在命令行装直接从 VS Code 插件市场安装。OpenHands 需要 Docker安装后用 docker compose up 起服务。Aider 是 pip install aider-install。Goose 用官方安装脚本它会自动装 Rust 工具链。smolagents 是 pip install smolagents。AutoGPT 直接 clone 仓库按 README 跑。最大的坑是版本锁。Agent 项目迭代极快半个月前的教程可能就失效了。我复现时遇到过 Codex 配置项改名、OpenHands 大幅重构、Goose 的 recipes 路径调整这些问题。建议跑之前固定一个 release 版本不要直接用 main 分支。我这次统一固定在用记录里重要依赖也都写进了 requirements 或 lockfile。4.2 Codex CLI 接入 DeepSeek 的完整配置Codex CLI 默认的模型是 OpenAI 全家桶但我实测发现它支持通过 model_provider 配置兼容接口。以接入 DeepSeek 为例操作其实不复杂。先在~/.codex/config.toml或者当前项目下的.codex/config.toml里加上这段配置model deepseek/deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat然后把密钥放进环境变量或者用--env-file指定环境文件export DEEPSEEK_API_KEY你的密钥 codex --env-file .env配置完成后直接在项目目录里跑codex它就会用 DeepSeek 的模型执行 Agent 循环。实测下来日常代码补全、小范围重构、写单元测试这类任务完成度不错但在需要强推理的长链路任务上和原厂模型还是有差距。写这段配置时有两点要注意。第一密钥不要直接写进 config.toml用 env_key 引用环境变量是更稳的做法避免提交代码时把密钥带出去。第二wire_api 的类型要看模型服务商支持什么有些只支持 chat有些兼容 responses填错了会报 404 或 400。4.3 同一任务横评把七个 Agent 放在一个跑道上为了对比客观我设计了一个统一任务把仓库里的一个 Python 脚本改造成带命令行参数的工具新增至少五个参数补充单元测试最后输出一份变更说明。Cline 的表现最全程服务。它先进入 plan 模式输出了改造方案我点了确认之后它才开始动手改动过程里还能看到它每一步的操作。测试失败时它能根据报错自动修复整个任务只人工审批了三次。Codex CLI 的执行速度很快第一次就生成了完整代码和测试但中间的“审批”做得比较隐晦需要你盯着终端输出手动确认。而且它默认绑定原厂模型换模型之后行为不如默认模型稳定。OpenHands 是唯一一个“我不用管”的选手。我把任务丢进去它自己在 Docker 沙箱里装依赖、跑测试、改代码最后输出报告。但中间有一次依赖安装失败它自己重试了三轮才绕过去耗时最长。Aider 在增量修改上很省心它默认自动 commit每次改动都有 git 记录。缺点是它默认支持的任务模式是“改代码”遇到“生成完整测试文件并验证”这类偏工程化的任务需要你很明确地把要求拆成步骤。Goose 对这类代码任务完成度比较普通它更像“操作系统的自动化助手”跑命令、查日志、处理文件很顺手深入代码重构时则频繁需要人工纠正。smolagents 需要你亲手写 prompt 和工具函数。它的优势是灵活你可以定义任意 Python 函数作为工具。但它不是成品项目中还要自己补日志和异常处理。AutoGPT 在纯代码任务上表现最差容易把目标拆成一堆子任务后陷入循环经常看到它重复执行同一个命令。作为教学样本可以作为生产力工具我不推荐。5. 常见报错与避坑实录5.1 高频报错速查表报错信息出现场景排查思路Codex ran out of room in the models context上下文撑爆compaction 没来得及触发主动人工总结前置信息减少一上来就把全部文件塞进上下文的习惯cc switch local proxy failed while handling codex endpoint /responsesCodex 在处理 /responses 端点时连不上配置的网络转发层检查网络出口配置、自定义 endpoint 地址是否可达以及 TLS 证书是否有效agent execution terminated due to error工具执行环节抛异常后循环终止看后端日志里是工具返回报错还是模型输出格式非法以及对应的退出码Docker 沙箱创建失败用 OpenHands 时本地 Docker 未启动或端口被占先跑 docker ps 验证守护进程再检查 3000 端口是否被占用MCP server 连接超时用 Goose 或 Cline 接入外部 MCP 服务时优先本地起 MCP server 验证再排查网络可达性与鉴权 token这里特别提一下第二个错误。我实测中遇到这个报错最先怀疑的是配置写错了后来发现是自定义 endpoint 的地址在解析时走了本地网络转发层但转发层本身指向的目标不可达。排查时先把所有转发设置临时清掉直连目标服务如果通了再逐层加回来。改配置前记得备份 config.toml。5.2 长期踩坑后的三条心得第一条不要一股脑给 Agent 接十几个 MCP 服务器。工具越多模型越容易在工具选择上出错调用链越长故障点越多。我的经验是最多接三到五个核心工具聚焦当前任务。第二条别拿开源 Agent 直接接最贵的模型。框架不同模型适配差异很大同一个任务在 Aider 上表现好的模型换到 Codex 上可能效果很差。先拿便宜的模型跑通流程、看格式兼容再上强模型能省不少钱。第三条定期固定版本。Agent 项目迭代太快README 里的功能可能一周就变了。代码里最好锁定版本或者把配置文件和操作记录一并保留方便回滚复现。6. 选型方向与个人体会6.1 按场景选型一张表抄作业使用场景推荐方案理由VS Code 里写代码、想有可视化操作Clineplan/act 模式 checkpoint可控性和任务完成度最平衡命令行重度用户、快速改代码Aidergit 集成最好增量修改体验舒适研究型任务、需要 Agent 自主跑长流程OpenHands事件流 Docker 沙箱 Microagent自治能力最强系统自动化、操作文件和命令GooseRust 实现轻快MCP 生态扩展方便想自己从头搭 Agent 原型smolagents源码轻量几十行就能跑通核心循环学习 Agent 历史演进AutoGPT看它如何定义任务循环和记忆再对照今天的实现6.2 为什么最高分不是 Codex我的最终判断拆到最后我越来越清楚 Codex 的分数为什么会被 Cline 反超。Codex 的单点能力确实很强代码质量高、执行速度快、Agent 循环设计干净。但它在“可控性”和“生态适配”这两个维度上相对保守。默认绑定自家模型换来的是体验统一失去的是让用户按自己习惯换模型的自在感纯终端交互换来的是简洁失去的是图形化审阅带来的安全感。Cline 赢在执行链路完整。它有 plan/act 让用户先看方案再动手有 checkpoint 让危险操作能回滚有大量模型厂商的适配层让接入成本变低有图形界面让非终端用户也能介入。这些能力每一项都不是革命性的但组合起来让它在“真实项目里持续给开发者干活”这件事上比 Codex 更能兜底。我个人的体会是Agent 项目的源码拆到最后拼的不是谁的模型聪明而是谁能在模型犯傻时给你递上最顺手的刹车和方向盘。开源 Agent 的价值不在于那个循环代码本身而在于它把选择权和控制权还给了使用者。这也是我以后选型时最看重的一个标准。