【开源 Agent 框架的“工程性格”与闭坑指南】

LATASA

16人浏览 · 2026-06-11 11:04:59

LATASA · 2026-06-11 11:04:59 发布

前言：最近在学习极客时间黄佳老师的关于 Agent 设计模式的专栏，看到作者对市面上 8 个主流 Agent 框架的拆解，烟头都差点烫到手——简直说到了心坎里。

今天结合我个人的大模型开发视角，把这 8 个顶流框架的“工程性格”和源码逆向笔记做了一次深度复盘，分享给同样在做 AI Native 转型的兄弟们。

导读：为什么你写的Agent只能算“玩具”？

很多同学一听 Multi-Agent 或者个人助手，上去就是一把梭：调几个 LLM API，搞几个 Role-play（规划师、执行者、主编），让它们在终端里热热闹闹地聊天。结果一上线生产环境：

任务派出去收不回来；
没有隔离沙箱，Agent 执行高风险命令时差点把测试库给删了；
稍微长一点的任务，上下文直接爆掉，根本无法复盘。

聪明只是入场券，Harness（运行基础设施）稳不稳，才决定了Agent能不能真正落地。

本文不聊虚的概念，不做产品评测，直接带你“暴力拆解”当前最火的 8 个真实 Agent 框架。通过解答四个硬核问题：主要解决什么？工程关键点是什么？2026年新变化？源码从哪下手？ 帮你提炼出 8 种不同的工程性格！

一、 8大开源Agent框架：硬核解构矩阵

为了方便大家做技术选型，我将这 8 个框架的核心性格、痛点场景以及读源码的切入点整理成了这张大表：

框架名称	核心工程性格 (Harness 侧重点)	适用核心场景	2026年硬核演进趋势	源码逆向：第一步从哪下手？
Claude Code	Harness（基座）比模型本身更重要极致的开发者工具型。	代码仓库、终端、远程环境的工程化打通。	从 CLI 走向 IDE 和企业 CI/CD。入口越多，权限与工具协议越重。	看4条主线：工具注册执行、高风险拦截、上下文隔离、结果回流机制。
Codex CLI	协议层让 Agent 跨 Surface 统一运行高度解耦的中央 Runtime。	需要一套核心能力，同时适配终端、Web、IDE 多个入口。	Runtime 平台级协议化，协议层成为智能体系统的脊椎。	看2个核心：通信规则（消息统一组织）与执行边界（隔离环境限制）。
Aider	Git 是最小、最可靠的行动账本极度克制与务实。	轻量级、不破坏开发者现有 Git 工作流的辅助开发。	不盲目做大，抓住关键不变量（Git 状态）与 Repo Map（压缩地图）。	看两张底牌：Git Diff 的提交/回退机制，以及代码库地图的生成逻辑。
OpenCode	把语言服务器（LSP）接进 Agent 感知拒绝盲目的文本搜索。	深度代码语义理解，需要看清符号的真正指向。	升级智能体的感知器官，让 Agent 像编译器一样通过类型系统看代码。	看4个核心目录：`session`、`Agent`、`internal/lsp`、`permission`。
OpenClaw	个人助手的核心是统一控制面跨渠道、多设备的调度中枢。	联动日常系统（消息、日历、邮件、本地文件、多端设备）。	竞争点从“回复像人”转向 Voice / Canvas / 本地优先的统一控制面。	看控制中枢：Gateway 的消息分发机制与多端用户身份（Identity）绑定。
Hermes	会成长的程序性记忆（Procedural Skills）拒绝一次性对话。	需要长期伴随、越用越贴合用户习惯的助理系统。	记忆从事实检索演进为经验压缩，能把 Trace 里的失败转化为 Skill。	看4个入口：`skills hub`、`memory setup`、`state`、`gateway`。
DeerFlow	多 Agent 协作的重点是确定性边界工业级编排，拒绝无效聊天。	类似 Deep Research 的长链路复杂任务拆解与聚合。	任务、技能、上下文、执行环境必须切成可管理的强边界。	看测试驱动：直接逆向 `test_subagent_`、`test_sandbox*` 等测试文件。
OpenHands	事件流是软件 Agent 的黑匣子重度依赖沙箱安全。	自动化黑灯工厂，需要跑长时任务、自动改文件并跑测试。	执行型 Agent 的底线：没有事件账本无法复盘，没有沙箱不敢放权。	看沙箱与日志：Event System 的事件追加链，与 Sandbox Provider 切换。

二、避坑总结：穿透底层，任何 Agent 框架都绕不开的“5 大共同地基”

把这些框架的衣服扒光，你会发现无论上层是做代码还是做助手，底层都必须打通这 5 个硬核基础设施（Harness Core）：

1. 主循环 (Loop)

各个框架名字不同（有的叫 Loop，有的叫 Runtime），但都要把 用户输入 $→\rightarrow$ 模型调用 $→\rightarrow$ 工具结果 $→\rightarrow$ 状态更新 串起来。没有主循环，Agent 只是一次性 LLM call。

2. 上下文管理 (Context)

如何在 LLM 有限的 Context Window 里放最高效的东西？

Claude Code 靠上下文装配与子 Agent 隔离
Aider 靠 Repo Map 压缩地图
OpenCode 靠 LSP 编译器感知
Hermes 靠三层记忆系统

3. 工具注册与执行 (Action)

不管叫 tool、skill、runtime 还是 provider，本质都是把模型的文本意图（Schema）翻译成安全、可控的外部动作。

4. 状态账本 (Ledger)

长任务不可恢复，错误无法复盘，是因为你没有账本！

Aider 的账本是 Git；

OpenHands 的账本是 Event System (Append-only Log)；

OpenClaw 的账本是 Gateway Session。

5. 治理边界 (Governance)

Permission、Sandbox、Approval、Audit log。治理是一层穿过工具、状态、协作和执行环境的横切机制。 动作前控制能看啥，动作中控制需不需要确认，动作后控制错误怎么纠正。

三、选型指南：看懂这三类“工程性格”，少走半年弯路

在架构设计选型时，别指望有“万能架构”，根据你的业务场景，对号入座：

                    ┌──────────────────────────────┐
                    │      Agent 工程性格分类       │
                    └──────────────┬───────────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         ▼                         ▼                         ▼
【 开发者工具型 】          【 个人助手型 】           【 重执行/多Agent型 】
· 代表: Claude Code, Aider · 代表: OpenClaw, Hermes   · 代表: DeerFlow, OpenHands
· 痛点: 嵌入已有工作流     · 痛点: 长期伴随、跨设备状态 · 痛点: 复杂任务拆解不失控
· 重度: Perception/Action  · 重度: Memory/Governance  · 重度: Collaboration/Sandbox

如果你要做代码助手：别去学 OpenClaw 搞什么多渠道 Gateway，赶紧去学 Aider 的 Git-native 状态控制和 OpenCode 的 LSP 语义感知。怎么让 Agent 乖乖呆在现有的工作流里改代码，别让它自己去造新世界。
如果你要做企业级AI助理：认真研究 Hermes 的程序性记忆（Procedural Skills），把失败的 Trace 压缩成下一次行动的起点。
如果你要做自动化黑灯工厂（Agent代写代码/跑测试）：OpenHands 的 Sandbox 设计和 Event Replay 系统是你的必修课。