Agent 框架演进从 ReAct 循环到 Agent Runtime 的分层演进2024 年被称为“AI Agent 元年”而到了 2026 年整个开源 Agent 生态已经完成了第一轮大浪淘沙。行业的竞争焦点早已脱离“能否调用工具”的初级验证全面转向会话治理、上下文管理、权限沙箱、状态持久化、多 Agent 协同等工程化底层能力。如果我们仍把视野局限在 Python SDK 形态的“Agent 框架”里会错过一整个正在重塑开发者使用习惯的项目层级——终端 Agent 运行时Harness、常驻网关Gateway、状态编排引擎正在从不同维度重新定义 Agent 的架构范式。本文以2026 年 6 月 30 日为数据观测节点覆盖 GitHub 全局热度、代码生成 Agent、通用 Agent SDK、个人助理与多 Agent 运行时四条赛道拆解 10 个最具代表性的开源项目梳理 Agent 核心循环Loop的五类演化路径并提供场景化的选型参考。所有架构判断均基于截止日前的官方文档与源码实现Star 数据采用距离观测日最近的公开快照均为近似值。观测口径为什么我们不止谈“框架”本次统计采用了更宽泛的“Agent 技术栈”口径纳入的项目覆盖三个层级开发框架层LangGraph、OpenManus 这类提供基础抽象与 SDK 的项目运行时Harness层Pi、Codex CLI 这类负责驱动模型、执行工具、管理会话的终端运行时完整产品层OpenCode、OpenClaw 这类自带客户端、控制平面与生态扩展体系的完整项目。这种划分并非冗余。到 2026 年决定一个 Agent 项目落地上限的往往不是模型调用逻辑而是会话并发控制、上下文压缩策略、权限沙箱机制、故障恢复能力、多端接入方式这些“Loop 之外”的工程能力。只盯着传统 SDK 做选型很容易低估运行时与控制平面的工程价值——这也是 Pi、OpenCode 这类项目长期被低估的核心原因。为保证准确性我们对 OpenManus、OpenClaw、Pi、OpenCode、Codex CLI 五个项目做了强制源码核验并跟踪了项目组织迁移与更名历史例如 Pi 从badlogic/pi-mono迁至earendil-works/piOpenManus 转入 FoundationAgents 组织OpenClaw 则经历了 Clawdbot、Moltbot 等早期名称迭代。全景扫描10 个最具代表性的开源 Agent 项目我们从数百个相关项目中筛选出 10 个在生态位、架构设计或影响力上有标志性意义的项目覆盖从极简内核到全栈平台的不同形态。注榜单并非严格按 Star 数截取。同期 Cline 约 6.24 万 Star本可进入前十但我们最终保留了 OpenManus——它代表了经典的显式 ReAct 实现范式而代码生成 Agent 赛道已有 OpenCode、Codex CLI、Gemini CLI、Pi 四个差异化代表无需重复占位。项目2026 年 6 月热度Star 快照项目形态核心定位OpenClaw约 37.5 万个人 Agent 平台以常驻 Gateway 为核心统一管理 Agent 运行时、消息渠道与设备能力AutoGPT约 18.5 万经典自主 Agent / 商业平台自主 Agent 概念的启蒙者当前仓库为开源组件 商业平台混合体OpenCode约 18.1 万代码生成 Agent 运行时完整的 Agent Server 架构远不止是终端聊天工具Hermes Agent约 17.1 万自学习型个人 Agent在基础工具循环之上内置记忆、技能生成与长期在线能力LangChain / LangGraph约 13.8 万 / 3.3 万应用开发 SDK / 图运行时企业级业务 Agent 的标准编排方案主打持久状态与人工介入Gemini CLI约 10.5 万代码生成 Agent CLI / SDK事件驱动调度拥有相对完整的策略引擎、MCP 与 A2A 集成体系Codex CLI约 8.6–9.1 万代码生成 Agent 运行时Rust 实现的工业级 Runtime审批与沙箱是原生架构层能力OpenHands约 7.5 万软件工程 Agent 平台分层架构清晰Agent SDK、执行沙箱、控制平面各司其职Pi Agent Harness约 6.17 万极简 Agent 内核极致轻薄的 Agent Loop适合源码研读、二次开发与产品嵌入OpenManus约 5.6–5.8 万通用 ReAct 开发框架结构直白、易于理解的教科书式 ReAct 实现数据说明OpenCode 在 2026 年 7 月 1 日的公开记录为 181,115 StarPi 的 6 月快照约为 61,700。当前 GitHub 上看到的更高 Star 数是截止日后的自然增长。参考来源OpenCode 快照、Pi 项目调研核心分化Agent Loop 的五类演化路径第五类常驻 Gateway 范式Gateway 常驻服务接收多渠道任务IM/定时/设备事件执行 Agent 循环管理会话并发/权限/故障恢复第四类持久化状态图范式定义节点与边执行节点持久化状态快照支持中断恢复/人工介入第三类状态机 / 事件驱动型 Agent Runtime状态机初始化事件触发广播事件工具调用/流式输出/会话结束状态更新第二类结构化 Tool-Calling ReAct模型调用工具工具执行返回结果第一类显式 ReAct 范式模型思考 (think)模型行动 (act)环境反馈无论形态差异多大几乎所有 Agent 项目都保留着 ReAct 范式的核心骨架模型决策下一步动作 ↓ 执行工具或环境交互 ↓ 将执行结果回写上下文 ↓ 模型进入下一轮决策但在这个基础循环之外不同项目基于各自的定位演化出了完全不同的外层架构大致可以归为五类第一类显式 ReAct 范式以 OpenManus 为代表直接在代码层面定义ReActAgent抽象类将每一步执行明确拆分为think()思考与act()行动两个阶段。这是最贴近原始论文、最易于教学与阅读的实现方式。开发者能清晰地看到每一步的决策与执行边界适合理解 Agent 的基本原理也便于做定制化修改。第二类结构化 Tool-Calling ReActPi、OpenCode、Hermes 与 LangChain 等主流项目均已不再要求模型输出文本格式的Thought、Action、Observation而是直接利用大模型原生的tool_call/tool_result结构化接口驱动循环。名称从“思考-行动”变成了“工具调用”但底层控制流逻辑完全一致。这种方式大幅降低了提示词工程成本也减少了模型输出格式错误的概率是当前工业界的主流实现。第三类状态机 / 事件驱动型 Agent RuntimeCodex CLI、Gemini CLI、OpenCode 这类产品级运行时在基础的模型-工具循环之外还要处理大量工程化问题会话生命周期管理、流式事件推送、上下文自动压缩、运行中断与取消、权限审批、多客户端状态同步。它们的 Agent Loop 不再是简单的while循环而是一套完整的状态机与事件总线。每一个动作工具调用开始、工具执行中、模型流式输出、会话结束都会以事件的形式向外广播供上层 UI 或插件订阅。第四类持久化状态图范式LangGraph 是这类的代表。它让开发者显式定义节点、边与共享状态每一步执行都通过 Checkpointer 持久化状态快照。在这个架构里ReAct 循环可以退化为图中的一个普通节点而非整个系统的全部。这种设计天然支持中断恢复、人工介入、分支回溯适合复杂的企业级业务流程。但相应地其抽象层级更高对于简单的工具调用场景会显得笨重。第五类常驻 Gateway 范式OpenClaw 与 Hermes 走得更远——它们让 Agent 以后台服务Gateway的形式长期在线通过即时通讯、定时任务、设备事件等多种方式接收任务并触发执行。在这类架构中Tool Calling 已经不是核心难点真正的挑战是会话并发隔离、多租户权限边界、运行故障恢复、跨渠道消息一致性。它们本质上已经是一个完整的应用系统而非单纯的开发框架。此外OpenHands 代表了一种特殊的 CodeAct 范式模型直接生成代码或环境指令由隔离的运行时环境执行再将观测结果返回给 Agent。它更强调执行环境的隔离性与工程任务的完整性而非通用工具调用。重点项目深度解析1. OpenClaw个人 Agent 的全栈网关OpenClaw 是当前 Star 数最高的个人 Agent 项目其核心设计是一个常驻本地的Gateway网关统一管理所有会话、工具、消息渠道、事件流与客户端连接。Telegram、Slack、WhatsApp 等聊天渠道以及 TUI、Web UI 等交互端全部作为客户端挂载在这个网关之上。它的 Agent 循环采用单会话串行执行模型接收消息 → 组装上下文 → 调用模型 → 执行工具 → 持久化结果 → 判断是否继续。通过 Session Lane 机制防止多个并发任务修改同一份会话状态保证数据一致性。同时提供了丰富的钩子Hook系统允许插件在模型调用前后、工具执行前后注入自定义逻辑。适用场景需要长期在线、跨设备、跨聊天渠道的个人助理场景。注意事项主会话的工具默认拥有宿主机执行权限接入外部消息渠道前必须完成设备配对、沙箱隔离与工具权限配置避免安全风险。参考Agent Loop 官方文档、项目仓库2. AutoGPT自主 Agent 的启蒙者AutoGPT 是早期自主 Agent 的标志性项目经典的 Classic 版本采用目标驱动的循环模式分析目标 → 选择执行命令 → 执行并返回结果 → 模型继续决策。它第一次让大众看到了 Agent 自主完成复杂任务的可能性具有极高的历史地位。发展到 2026 年它的仓库已经成为一个混合体classic/目录与 Forge 等组件遵循 MIT 协议完全开源而autogpt_platform/目录下的平台部分采用 Polyform Shield 协议禁止用于搭建竞争性托管服务。选型提示18.5 万 Star 反映的是整个仓库的历史关注度不能直接等同于纯开源运行时的采用量。研究 Agent 演化历史它是必看样本但新项目选型时务必先明确自己使用的是 Classic、Forge 还是 Platform 版本。参考许可证说明3. OpenCode产品化最成熟的模型中立代码 Agent在所有模型中立的 Coding Agent 中OpenCode 的产品化完成度属于第一梯队。它最核心的设计是Client-Server 分离架构我们日常使用的终端 TUI 只是客户端真正的 Agent 运行逻辑全部在后台 Server 中。Server 对外提供标准化的 OpenAPI 与 SDK覆盖会话管理、消息、Agent、工具、事件流等全套接口。同一套运行时可以同时被终端、Web 界面、IDE 插件调用。其内部会话循环逻辑清晰完整加载会话历史与 Agent 配置 → 判断是否需要上下文压缩 → 注册可用工具 → 流式调用模型 → 解析并执行工具调用 → 将结果写回消息历史直到模型停止调用工具。相比极简的 PiOpenCode 更重但多出的重量全部是工程化刚需权限管控、LSP 集成、MCP 支持、会话分支Fork、差异对比、多客户端适配都是产品落地绕不开的能力。参考Server API 文档、Loop 核心源码4. Hermes Agent带学习闭环的自进化 AgentHermes 的基础 Agent 循环并不复杂调用模型检测到工具调用则执行并回填结果模型返回文本则保存会话。它真正的差异化在循环之外。Hermes 内置了跨会话的持久记忆体系可以检索历史对话具备技能生成与自我优化能力能在运行中生成、修改自身的技能网关层支持接入 Telegram、Discord、Slack 等多种渠道任务也可以通过 Cron 定时触发。这种“自我迭代”的学习闭环非常有吸引力但也带来了可审计性的挑战。如果一个 Agent 能够修改自己的技能团队必须配套建立严格的技能版本管理、来源追溯与权限审计机制否则 Agent 的行为会在长期运行中发生不可控的漂移。参考Agent Loop 开发文档5. LangChain LangGraph业务 Agent 的编排标准LangChain 提供了高层的 Agent 工厂 API其默认循环可以简化为模型节点 → 工具节点 → 模型节点的反复迭代直到模型不再产生工具调用。而 LangGraph 解决的是更外层的编排问题。它采用类似 Google Pregel 的批量同步并行执行模型将每一轮执行拆分为 Plan规划执行节点、Execution并行执行节点、Update更新通道状态三个阶段并通过 Checkpointer 机制持久化每一步的完整状态。适用场景任务需要中断恢复、人工审批、多 Agent 协作的复杂业务流程。比起手写 while 循环LangGraph 能提供更可靠的状态保证。反之如果只是实现一个轻量的工具调用 Agent这套抽象会显得过于厚重。参考Agent 工厂源码、Pregel 运行时、持久化机制6. Gemini CLIGoogle 生态的事件驱动 AgentGemini CLI 采用事件驱动的工具调度架构模型发出工具请求由调度器Scheduler负责执行并产生事件结果回流到会话后触发下一轮推理。2026 年上半年它快速迭代了 Agent 技能体系、事件调度器、计划模式Plan Mode、原生 SDK、策略引擎Policy Engine以及 A2AAgent-to-Agent远程 Agent 能力生态完善度提升很快。选型提示它最适合重度依赖 Gemini 模型与 Google 工具链的团队。需要注意的是项目发布节奏极快接口与产品方向变动频繁基于 SDK 做二次开发时建议锁定固定版本避免跟随最新发布导致兼容性问题。参考版本更新日志7. Codex CLIRust 打造的工业级安全 RuntimeCodex CLI 用一套非常严谨的状态模型来描述 Agent 运行Thread长期存续的会话Turn一次完整的 Agent 执行轮次Item会话中的最小单元包括模型消息、命令执行、文件修改、工具调用等。它的 App Server 会以流式方式推送turn/started、item/*、turn/completed等事件客户端可以实时看到命令执行、代码补丁、审批流程的每一步而非只能等待最终结果。安全是 Codex CLI 的核心设计原则工具执行必须经过权限检查根据策略选择不同级别的沙箱环境必要时中断并请求人工批准。相比模型中立性它更追求与 OpenAI 模型、产品生态的深度贴合与可靠性。参考App Server 协议文档8. OpenHands面向软件工程的 Agent 平台OpenHands 专门面向长周期软件工程任务设计。Agent 生成动作或工具调用后由隔离的运行时在沙箱中执行命令、运行代码、操作浏览器再将观测结果返回给 Agent 会话。它的架构分层非常清晰Software Agent SDKAgent 核心逻辑与基础能力Agent Server负责远程部署与并发运行管理Agent Canvas管理本地、Docker、虚拟机或云端的 Agent 实例。这套架构天然适合运行代码评测、长周期开发任务但部署重量也相对更高。对于普通的本地编码辅助场景它往往比实际需要的更复杂。参考主项目仓库、SDK 仓库9. Pi Agent Harness极致克制的极简内核Pi 的设计哲学可以用“克制”来形容核心只保留 4 个基础工具读、写、编辑、Bash拥有全行业最短的系统提示词所有额外能力全部通过 TypeScript 扩展实现。它由 libGDX 作者 Mario Zechner 创立2026 年 4 月正式加入由 Armin Ronacher 联合创立的 Earendil 公司仓库迁至earendil-works/pi核心代码仍保持 MIT 协议由全职团队持续迭代。项目采用模块化的包拆分设计pi-ai模型提供商适配层pi-agent-core状态管理、工具调用、核心 Looppi-coding-agent终端 Agent 实现pi-tui/pi-web-ui交互界面组件。Loop 本身分为两层内层处理模型推理与工具调用外层消费排队的引导或跟进消息整个执行过程通过事件流向上层暴露。对于想读懂 Agent 源码、做定制化改造或嵌入到自有产品的团队Pi 是极佳的选择。但它默认不提供完善的权限与沙箱体系生产环境落地需要自行补齐安全能力。参考核心 Loop 源码、项目仓库10. OpenManus教科书级的 ReAct 实现OpenManus 的代码结构最贴近教材里的 ReAct 范式BaseAgent基础循环抽象 └─ ReActAgentThink Act 分步执行 └─ ToolCallAgent工具调用执行 └─ Manus具体实现BaseAgent.run()提供带max_steps步数限制的主循环ReActAgent.step()明确拆分出think()与act()两个阶段ToolCallAgent负责具体工具执行与结果回写。项目自带浏览器、Python 执行、文件编辑、MCP 等常用工具拿来学习原理或快速二次改造非常合适。但短板也很明显Checkpoint、并发控制、故障恢复、权限体系、可观测性都比成熟的工业级 Runtime 简单很多。其实验性的多 Agent Flow 能力也不建议直接用于生产环境。参考BaseAgent 源码、ReActAgent 源码选型指南按需求匹配项目这些项目已经不在同一个维度上竞争——Pi 是底层内核OpenCode 是完整运行时OpenClaw 是常驻平台LangGraph 是持久化编排器。它们共享相似的模型-工具循环但解决的是完全不同层级的问题。核心需求优先考虑的项目研读 Agent Loop 原理、做深度定制改造Pi、OpenManus构建需要中断恢复、人工审批的业务流程 AgentLangGraph开发模型中立、产品级的代码生成 AgentOpenCode对本地审批、沙箱安全有极高要求Codex CLI部署与运行大规模软件工程 Agent 集群OpenHands搭建跨聊天渠道的个人助理 AgentOpenClaw、Hermes Agent深度使用 Gemini 生态、需要 MCP 与 A2A 能力Gemini CLI研究自主 Agent 的历史演进与早期实现AutoGPT Classic / Forge结语从两年前千篇一律的 ReAct 循环到今天内核、运行时、编排、平台的分层演化开源 Agent 生态正在从“Demo 导向”走向“工程导向”。没有所谓“最好”的 Agent 框架只有最匹配场景的架构选型。在动手之前先想清楚一个问题你需要的究竟是一个可嵌入的循环内核、一个开箱即用的终端运行时、一个业务流程编排器还是一套完整的常驻 Agent 平台答案不同最优选择也会天差地别。