企业官网建设流程全解析

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 技术栈”口径，纳入的项目覆盖三个层级：

1. 开发框架层：LangGraph、OpenManus 这类提供基础抽象与 SDK 的项目；
2. 运行时（Harness）层：Pi、Codex CLI 这类负责驱动模型、执行工具、管理会话的终端运行时；
3. 完整产品层：OpenCode、OpenClaw 这类自带客户端、控制平面与生态扩展体系的完整项目。

这种划分并非冗余。到 2026 年，决定一个 Agent 项目落地上限的，往往不是模型调用逻辑，而是会话并发控制、上下文压缩策略、权限沙箱机制、故障恢复能力、多端接入方式这些“Loop 之外”的工程能力。只盯着传统 SDK 做选型，很容易低估运行时与控制平面的工程价值——这也是 Pi、OpenCode 这类项目长期被低估的核心原因。

为保证准确性，我们对 OpenManus、OpenClaw、Pi、OpenCode、Codex CLI 五个项目做了强制源码核验，并跟踪了项目组织迁移与更名历史：例如 Pi 从badlogic/pi-mono迁至earendil-works/pi，OpenManus 转入 FoundationAgents 组织，OpenClaw 则经历了 Clawdbot、Moltbot 等早期名称迭代。

全景扫描：10 个最具代表性的开源 Agent 项目

我们从数百个相关项目中筛选出 10 个在生态位、架构设计或影响力上有标志性意义的项目，覆盖从极简内核到全栈平台的不同形态。

注：榜单并非严格按 Star 数截取。同期 Cline 约 6.24 万 Star，本可进入前十，但我们最终保留了 OpenManus——它代表了经典的显式 ReAct 实现范式，而代码生成 Agent 赛道已有 OpenCode、Codex CLI、Gemini CLI、Pi 四个差异化代表，无需重复占位。

数据说明：OpenCode 在 2026 年 7 月 1 日的公开记录为 181,115 Star；Pi 的 6 月快照约为 61,700。当前 GitHub 上看到的更高 Star 数，是截止日后的自然增长。
参考来源：OpenCode 快照、Pi 项目调研

核心分化：Agent Loop 的五类演化路径

无论形态差异多大，几乎所有 Agent 项目都保留着 ReAct 范式的核心骨架：

模型决策下一步动作 ↓ 执行工具或环境交互 ↓ 将执行结果回写上下文 ↓ 模型进入下一轮决策

但在这个基础循环之外，不同项目基于各自的定位，演化出了完全不同的外层架构，大致可以归为五类：

第一类：显式 ReAct 范式

以 OpenManus 为代表，直接在代码层面定义ReActAgent抽象类，将每一步执行明确拆分为think()（思考）与act()（行动）两个阶段。

这是最贴近原始论文、最易于教学与阅读的实现方式。开发者能清晰地看到每一步的决策与执行边界，适合理解 Agent 的基本原理，也便于做定制化修改。

第二类：结构化 Tool-Calling ReAct

Pi、OpenCode、Hermes 与 LangChain 等主流项目，均已不再要求模型输出文本格式的Thought、Action、Observation，而是直接利用大模型原生的tool_call/tool_result结构化接口驱动循环。

名称从“思考-行动”变成了“工具调用”，但底层控制流逻辑完全一致。这种方式大幅降低了提示词工程成本，也减少了模型输出格式错误的概率，是当前工业界的主流实现。

第三类：状态机 / 事件驱动型 Agent Runtime

Codex 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 配置 → 判断是否需要上下文压缩 → 注册可用工具 → 流式调用模型 → 解析并执行工具调用 → 将结果写回消息历史，直到模型停止调用工具。

相比极简的 Pi，OpenCode 更重，但多出的重量全部是工程化刚需：权限管控、LSP 集成、MCP 支持、会话分支（Fork）、差异对比、多客户端适配，都是产品落地绕不开的能力。
参考：Server API 文档、Loop 核心源码

4. Hermes Agent：带学习闭环的自进化 Agent

Hermes 的基础 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 CLI：Google 生态的事件驱动 Agent

Gemini CLI 采用事件驱动的工具调度架构：模型发出工具请求，由调度器（Scheduler）负责执行并产生事件，结果回流到会话后触发下一轮推理。

2026 年上半年，它快速迭代了 Agent 技能体系、事件调度器、计划模式（Plan Mode）、原生 SDK、策略引擎（Policy Engine）以及 A2A（Agent-to-Agent）远程 Agent 能力，生态完善度提升很快。

选型提示：它最适合重度依赖 Gemini 模型与 Google 工具链的团队。需要注意的是，项目发布节奏极快，接口与产品方向变动频繁，基于 SDK 做二次开发时建议锁定固定版本，避免跟随最新发布导致兼容性问题。
参考：版本更新日志

7. Codex CLI：Rust 打造的工业级安全 Runtime

Codex 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 SDK：Agent 核心逻辑与基础能力；
• 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：状态管理、工具调用、核心 Loop；
• pi-coding-agent：终端 Agent 实现；
• pi-tui/pi-web-ui：交互界面组件。

Loop 本身分为两层：内层处理模型推理与工具调用，外层消费排队的引导或跟进消息，整个执行过程通过事件流向上层暴露。

对于想读懂 Agent 源码、做定制化改造或嵌入到自有产品的团队，Pi 是极佳的选择。但它默认不提供完善的权限与沙箱体系，生产环境落地需要自行补齐安全能力。
参考：核心 Loop 源码、项目仓库

10. OpenManus：教科书级的 ReAct 实现

OpenManus 的代码结构最贴近教材里的 ReAct 范式：

BaseAgent（基础循环抽象） └─ ReActAgent（Think + Act 分步执行） └─ ToolCallAgent（工具调用执行） └─ Manus（具体实现）

BaseAgent.run()提供带max_steps步数限制的主循环，ReActAgent.step()明确拆分出think()与act()两个阶段，ToolCallAgent负责具体工具执行与结果回写。

项目自带浏览器、Python 执行、文件编辑、MCP 等常用工具，拿来学习原理或快速二次改造非常合适。但短板也很明显：Checkpoint、并发控制、故障恢复、权限体系、可观测性，都比成熟的工业级 Runtime 简单很多。其实验性的多 Agent Flow 能力，也不建议直接用于生产环境。
参考：BaseAgent 源码、ReActAgent 源码

选型指南：按需求匹配项目

这些项目已经不在同一个维度上竞争——Pi 是底层内核，OpenCode 是完整运行时，OpenClaw 是常驻平台，LangGraph 是持久化编排器。它们共享相似的模型-工具循环，但解决的是完全不同层级的问题。

结语

从两年前千篇一律的 ReAct 循环，到今天内核、运行时、编排、平台的分层演化，开源 Agent 生态正在从“Demo 导向”走向“工程导向”。

没有所谓“最好”的 Agent 框架，只有最匹配场景的架构选型。在动手之前，先想清楚一个问题：你需要的究竟是一个可嵌入的循环内核、一个开箱即用的终端运行时、一个业务流程编排器，还是一套完整的常驻 Agent 平台？答案不同，最优选择也会天差地别。