Agent 框架全景对比：从 LangGraph 到 OpenHarness
摘要: 系统梳理并对比了当前四大主流Agent框架的设计理念与技术架构。LangChain/LangGraph以组件化积木思想和有状态图执行引擎为核心，为开发者提供精细的控制流编排能力。OpenClaw定位为Agent运行平台，通过Gateway中间执行层实现模型无关的统一Agent管理，其ClawHub技能市场降低了Agent构建门槛，Heartbeat心跳机制保障了系统可靠性。Hermes Agent以KEPA（Knowledge-Experience-Practice-Adaptation）自进化闭环和四级持久记忆为核心创新，致力于打造越用越聪明的长期数字助手。OpenHarness/NLAH则从学术视角建立了Agent框架的六大支柱评估体系，并揭示了在相同底层模型条件下不同框架间高达6倍的性能差异，为框架选型提供了重要基准。
核心思想
Agent 框架是把 Agent 的理论（ReAct、规划、记忆、工具调用）变成可运行的代码基础设施。不同框架有不同的设计哲学——有的强调组件化，有的追求极简执行，有的专注自我进化。
1. DeepAgents & LangChain & LangGraph
langchain 生态项目解读： https://www.insight-stack.cn/insight-labs/repo-insight/deepagents
1.1 DeepAgents
LangChain 推出的 DeepAgents 是一个非常具有突破性的开源框架（基于 LangGraph 构建）， DeepAgents 是在为大模型搭建一个“微型操作系统”，专门为了解决复杂、长周期的真实世界任务而设计。
它提取并开源了当前业界最顶尖的生产级系统（如 Claude Code、OpenAI Deep Research 和 Manus）背后的核心架构模式。1、核心理念：从“浅层”到“深度”
传统 Agent（浅层代理）的执行逻辑通常是简单的单轨循环：思考 -> 调用工具 -> 生成回答。这种模式在处理单步任务时表现很好，但一旦任务需要多个步骤、长时间运行，模型就容易忘记初衷、陷入死循环，或者因为上下文窗口被原始数据塞满而导致推理能力崩溃。
DeepAgents 的核心哲学是长线规划与状态管理。它不再把所有的信息都一股脑塞进同一个 Prompt 窗口里，而是通过任务拆解、上下文隔离和外部存储器，让系统能够像一个专业的人类团队那样分工协作。
2、架构设计与四大核心支柱
在 DeepAgents 的架构中，通常会有一个中心化的编排器 (Orchestrator) 作为主控大脑，它不直接干脏活累活，而是通过以下四个核心子系统来驱动整个工作流：
显式规划层 (Strategic Planning Layer)
DeepAgents 引入了一个非常巧妙的机制：Todo 清单工具（例如 write_todos）。
- 这个工具在底层代码中可能并不执行任何外部物理动作（类似 No-op），它的核心作用是上下文锚点 (Context Anchor)。
- 它强制主 Agent 在开始工作前，必须先将宏大的目标拆解为具体的步骤。在执行过程中，Agent 需要不断更新这个 Todo 清单的状态。这使得大模型在漫长的执行周期中，始终能保持战略方向的清晰，知道“我做到了哪一步”以及“下一步该干什么”。
代理与上下文隔离 (Sub-agents & Context Isolation)
当遇到具体的繁杂子任务时，主编排器不会亲自下场，而是会派发给专门的子代理 (Sub-agents)（例如：专职的资料检索 Agent、代码编写 Agent、质量审查 Agent）。
- 上下文隔离： 这是该架构最关键的设计。主 Agent 不需要看到子 Agent 搜索网页时返回的上万字网页源码。
- 子 Agent 在自己独立的上下文中完成工作，最后只把“干净、结构化”的分析结果返回给主 Agent。这极大地保护了主 Agent 的注意力（Attention），避免了上下文污染和 Token 浪费。
虚拟文件系统 (Virtual File System / Shared Workspace)
对于超长文本（如读取一份 100 页的财报或输出几万字的工程代码），硬塞进上下文窗口是灾难性的。
- DeepAgents 引入了“虚拟文件系统”作为 Agent 的共享工作区。
- Agent 可以将大型工具的中间输入/输出结果写入到这些“文件”中，按需读取。这彻底打破了 LLM 自身上下文窗口的物理限制，使其能够处理远超自身能力极限的数据量。
自动上下文管理与压缩 (Auto Context Management)
即使有了隔离和文件系统，多轮对话的历史记录依然会随着时间不断膨胀。
- 框架内置了状态和记忆压缩机制。当对话历史过长时，系统会在后台自动对其进行摘要汇总（Summarization），用简短的总结替换掉早期冗长的对话记录。
- 这保证了 Agent 可以持续运行几个小时甚至几天，而不会出现内存溢出（OOM）或 API 拒绝服务。
3、系统级提示词工程的转变
在 DeepAgents 架构中，系统提示词（System Prompt）不再是简单的“你是一个有用的助手”，而被升级为了一份极其精确的技术说明书 (Versioned Specification)。这份说明书会详细定义 Agent 的角色边界、工作流执行标准、子工具的 API 接口细节，以及它该在什么时候暂停并请求人类干预审核（Human-in-the-loop）。
总体而言，DeepAgents 的出现标志着开源 Agent 开发正在从“单兵作战的玩具”向“集团化作战的生产工具”迈进。 Tutorial on Building Hierarchical AI Systems with Deep Agents
1.2 LangChain：Agent 框架的"开山之作"
LangChain 是 Harrison Chase 于 2022 年创立的 Agent 开发框架，也是该领域最早、用户最多的框架之一（截至 2026 年 GitHub 97K+ stars）。
LangChain 的核心理念：组件化（Components） + 链式组合（Chains）。
LangChain 设计的核心哲学：
- 一切皆可组合：每个组件（Model、Tool、Prompt、Memory）都是可插拔的积木
- 链式思维：将多个组件串联成 Chain，Chain 再嵌套成更复杂的流程
- 多模型支持：不绑定任何 LLM 厂商，统一接口适配 OpenAI、Anthropic、开源模型等
- 丰富的集成：内置数百个第三方集成（向量库、文档加载器、工具API）
它的主要由 6 个核心组件构成：
┌─────────────────────────────────────────────────────────────┐
│ LangChain 组件 │
│ │
│ ┌──────────┐ ┌───────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Model │ │ Prompt │ │ Memory │ │ Retriever│ │
│ │ (LLM接口)│ │(模板管理) │ │(状态存储)│ │ (检索器) │ │
│ └────┬─────┘ └─────┬─────┘ └────┬─────┘ └─────┬─────┘ │
│ │ │ │ │ │
│ └──────────────┴─────────────┴──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Chain │ ← 组件串联成执行链 │
│ │ (管道) │ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
顶层抽象（从低到高）：
Model I/O ──> Retrieval ──> Chains ──> Agents ──> Callbacks
(模型交互) (数据获取) (组件组合) (智能决策) (钩子/监控)Model I/O（模型输入输出）
- Prompts（提示词）： 模板化管理用户的输入指令（Prompt Templates），支持根据上下文动态注入变量。
- Language Models（语言模型）： 提供统一的通用接口来调用市面上的各类大模型（如 OpenAI、AnthropicClaude、HuggingFace 上的开源模型等），让你能够随时低成本地切换底层模型。
- Output Parsers（输出解析器）： 将 LLM 返回的非结构化自然语言文本，精准地解析转化为结构化数据（如 JSON 对象、列表等），方便下游的代码逻辑继续处理。
Retrieval（检索系统）
针对模型上下文窗口有限且缺乏私有数据的问题，LangChain 提供了完整的检索增强生成（RAG，Retrieval-Augmented Generation）流水线
- Document Loaders（文档加载器）： 从 PDF、网页、Notion、数据库等多种来源提取文本数据。
- Text Splitters（文本分割器）： 将长文档切分为模型能够处理的片段（Chunks），以适应 Token 限制。
- Vector Stores（向量存储）： 存储文本片段及其对应的向量表示（Embeddings），方便后续的相似度检索。
- Retrievers（检索器）： 根据用户的查询问题，从向量数据库中极速检索出最相关的文本片段，作为背景知识“喂”给大模型。
Chains（链），“链”是 LangChain 中将多个组件按特定顺序连接起来的机制
- 最基础的链（如
LLMChain）会将 Prompt 模板、LLM 和 Output Parser 串联起来，完成一次端到端的调用。 - Sequential Chains（顺序链）： 可以将多个基础链首尾相连，前一个链的输出直接作为后一个链的输入，从而完成复杂的、需要多步推理和转换的任务。
Agents（代理）
大模型向“自主智能体”进化的核心组件。在普通的“链”中，代码执行的顺序是开发者硬编码写死的；而在 Agent 中，执行顺序由模型动态决定。
- Tools（工具）： 赋予大模型能力的函数接口，例如网络搜索引擎、Python 代码解释器、API 调用器等。
- Agent（代理机制）： LLM 根据用户的输入，自主判断需要调用工具箱中的哪个工具，提取工具返回的结果，并思考下一步行动，直到得出最终答案。
Memory（记忆）
大模型原本是无状态的（Stateless），每次对话都会遗忘前文。Memory 组件允许系统在多轮交互中保存、管理和提取对话的历史上下文。它可以是简单的缓冲记忆（保留最近的几轮对话），也可以是总结记忆（让模型对过往对话进行摘要归纳，以节省 Token 消耗）。
Callbacks（回调系统）
这是一个贯穿整个框架的基础设施，用于在应用运行的各个阶段进行监听、干预、日志记录和监控。例如，你可以通过回调机制来实现打字机效果的流式输出（Streaming），或者统计某次请求消耗了多少 Token 和费用。
LangChain 的局限性：
| 问题 | 说明 |
|---|---|
| 抽象过多 | "为了做个简单的 RAG 要理解 10 个类"——学习曲线陡峭 |
| 灵活性陷阱 | 太多抽象层，调试困难，性能开销大 |
| 不适合复杂 Agent | Chain 是 DAG（有向无环图），难以表达循环和条件分支 |
| 版本混乱 | 0.x 版本 API 变动频繁，迁移成本高 |
1.3 LangGraph：从"链"到"图"的跃迁
LangGraph 是 LangChain 团队意识到 Chain 的局限性后创建的下一代框架——用有状态图（Stateful Graph）代替链（Chain）。Chain vs Graph：根本区别
Chain（线性/DAG）： Graph（有状态图）：
A → B → C → D A ←────→ B
(只能单向流动) ↓ ↖ ↓
C ────→ D
(可以有循环和条件)LangGraph 的核心思想：把你的 Agent 逻辑建模为一个"状态机图"——节点是处理步骤，边是状态转换条件，图可以包含循环（这正是 Agent Loop 的本质）。
LangGraph 架构的核心要素：
1. State (状态)
├─ 在图中流转的共享数据结构
├─ 每个节点读取 State、返回更新
└─ 示例: {messages: [...], next_action: "search", findings: {}}
2. Nodes (节点)
├─ 处理函数：接收 State，返回 State 更新
├─ 可以是 LLM 调用、工具执行、条件判断
└─ 示例: call_model, execute_tool, should_continue
3. Edges (边)
├─ 普通边：A → B（无条件）
└─ 条件边：A → {B if x, C if y}（根据 State 决定下一步）
4. Graph (图)
├─ 节点和边的集合
└─ 编译后可以 .invoke() / .stream() 执行LangGraph 实现 ReAct Agent 的示例结构：
┌───────────────┐
│ START │
└───────┬───────┘
│
▼
┌───────────────┐
│ LLM │ ← 调用 LLM，获取决策
│ (call_model) │
└───────┬───────┘
│
▼
┌───────────────┐
│ should_ │ ← 条件判断节点
│ continue? │
└───┬───────┬───┘
│ │
tool_call │ │ no_tool_call
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ execute │ │ END │
│ tool │ └──────────┘
└────┬─────┘
│
└──→ 回到 LLM 节点（循环）
这就是 Agent Loop 的精确实现！LangGraph 代码示例：
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
# 定义状态
class AgentState(TypedDict):
messages: list
next_action: str
# 定义节点函数
def call_model(state: AgentState) -> AgentState:
"""调用 LLM 获取下一步决策"""
response = llm.invoke(state["messages"])
return {"messages": state["messages"] + [response]}
def should_continue(state: AgentState) -> str:
"""判断是否继续循环"""
last_message = state["messages"][-1]
if last_message.tool_calls:
return "execute_tool"
return "end"
# 构建图
graph = StateGraph(AgentState)
graph.add_node("llm", call_model)
graph.add_node("tool", execute_tool)
graph.add_conditional_edges("llm", should_continue, {
"execute_tool": "tool",
"end": END
})
graph.add_edge("tool", "llm") # 执行工具后回到 LLM (循环)
graph.set_entry_point("llm")
app = graph.compile()
result = app.invoke({"messages": [HumanMessage("查天气")]})LangGraph 的设计优势：
| vs LangChain | vs 其他框架 |
|---|---|
| 显式控制流（图比链灵活得多） | 状态管理有内置支持（checkpointing） |
| 天然支持循环和条件分支 | 支持人机交互（Human-in-the-Loop 中断点） |
| 可视化调试（图结构一目了然） | 流式执行（streaming）原生支持 |
LangGraph 的适用场景：
- 需要复杂控制流的 Agent（多轮、多分支）
- 需要 Human-in-the-Loop 的工作流
- 需要精确状态管理的长任务
1.3 LangChain 生态总览
Deep Agents (2025.3 开源，MIT 协议，当前 v0.6.8)
├─ "开箱即用"的 Agent 全栈框架，内部基于 LangGraph
├─ 内置子 Agent 委派、文件系统、上下文管理、Shell、持续记忆
├─ Human-in-the-loop、Skills、MCP 集成
└─ 适合：需要完整 Agent 能力的生产级应用
├─ Deep Agents Code：终端编程 Agent（类 Claude Code，可对接任意 LLM）
└─ Deep Agents Deploy：一键部署 30+ Agent 端点（含 MCP、A2A、人工审批）
LangChain (97K+ stars)
├─ 组件库：Models, Chains, Agents, Tools, Callbacks
├─ 第三方集成：700+ 集成
└─ 适合：原型开发、简单到中等复杂度的 Agent
LangGraph (9K+ stars)
├─ 有状态图执行引擎
├─ 精确控制流 + 状态管理
└─ 适合：复杂 Agent、多步骤工作流
LangSmith
├─ LLM 应用的可观测性平台
├─ 追踪、调试、评估、测试
└─ 商业产品（免费层+付费）
LangServe
├─ 将 LangChain 应用部署为 REST API
└─ 生产部署工具Deep Agents vs LangGraph vs LangChain create_agent 的决策指南：
| 组件 | 定位 | 什么时候选它 |
|---|---|---|
LangChain create_agent | 轻量 Agent 外壳，无内置中间件 | 快速原型、不想引入框架开销时 |
| LangGraph | 底层图执行引擎，自由定义状态流转 | 需要完全定制控制流和状态管理 |
| Deep Agents | 全栈 Agent 框架（基于 LangGraph），内置规划/上下文管理/委派等全套中间件 | 生产级 Agent 开发，需要子 Agent 委派、文件系统、持续记忆等完整能力 |
三者是递进关系——从 create_agent 到 LangGraph 到 Deep Agents，控制颗粒度越来越细，内置能力越来越全。Deep Agents 在 LangGraph 之上封装了一套 Agent 开发的最佳实践（上下文压缩、子 Agent 隔离、人机交互），让你不用从头造轮子。
2. OpenClaw（龙虾）
2.1 背景与定位
OpenClaw 由 Peter Steinberger 创建，截至 2026 年在 GitHub 上获得了 247K+ stars 的关注度（注：Steinberger 也是 PSPDFKit 的创始人）。
OpenClaw 的设计哲学：极简化 Agent 执行模型 + 社会化技能生态。
普通 Agent 框架让开发者写代码，OpenClaw 让普通用户也能创建 Agent 工作流——通过"技能"的组装。
2.2 核心架构：Gateway 中间执行层
OpenClaw 架构全景：
┌──────────────────────────────────────────────────────────┐
│ 用户交互层 │
│ │
│ Slack ─┐ │
│ Discord─┤ │
│ Web UI ─┼──→ 消息 │
│ API ─┘ │
└──────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ Gateway (中间执行层) │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent Loop Engine │ │
│ │ │ │
│ │ 感知 ──> 推理 ──> 行动 ──> 反馈 ──> 循环 │ │
│ │ │ │
│ │ 特点： │ │
│ │ • 与 LLM 无关（支持 OpenAI, Anthropic, 开源） │ │
│ │ • 技能热加载（无需重启） │ │
│ │ • 上下文窗口自动管理 │ │
│ │ • Heartbeat 心跳监控 │ │
│ └─────────────────────┬───────────────────────────┘ │
│ │ │
│ ┌─────────────────────┴───────────────────────────┐ │
│ │ Skill Manager (技能管理器) │ │
│ │ │ │
│ │ • 技能注册与发现 │ │
│ │ • 技能执行调度 │ │
│ │ • ClawHub 市场集成 │ │
│ └─────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘Gateway 的核心设计思想：
| 设计点 | 说明 |
|---|---|
| 模型无关 | Gateway 不绑定任何 LLM，通过适配器支持所有主流模型 |
| 协议统一 | 对外暴露统一的消息接口（Slack/Discord/API 都用同一套协议） |
| 技能隔离 | 每个技能独立运行，互不影响 |
| 自动上下文管理 | Gateway 自动裁剪、压缩对话历史，防止超出 token 限制 |
| 心跳监控 | 定期检测 Agent 是否"卡住"或崩溃 |
2.3 Agent Loop（Agent 执行循环）
while task_not_complete:
│
├── ① PERCEIVE (感知)
│ ├─ 接收用户消息
│ ├─ 读取上一次循环的结果
│ └─ 获取环境状态变化
│
├── ② THINK (推理)
│ ├─ LLM 分析当前状况
│ ├─ 决定下一步做什么
│ └─ 如果需要，生成 Tool Call
│
├── ③ ACT (行动)
│ ├─ 如果有 Tool Call → 执行对应的技能函数
│ ├─ 如果没有 → 生成回答文本
│ └─ 更新内部状态
│
├── ④ OBSERVE (反馈)
│ ├─ 评估行动结果
│ ├─ 判断任务是否完成
│ └─ 决定是否继续循环
│
└── → 回到 ①
关键创新：Heartbeat (心跳)
Gateway 定期检查：Agent 进展了吗？是否陷入死循环？是否需要干预？
如果 Agent 长时间无进展，Gateway 会：
1. 发送"催促"消息给 Agent
2. 如果仍无反应 → 重启 Agent Loop
3. 记录异常日志供后续排查2.4 ClawHub：技能市场生态
ClawHub 是 OpenClaw 的"应用商店"：用户可以分享、下载、安装各种 Agent 技能。
ClawHub 上的典型技能：
┌────────────────────────────────────────────────────────────┐
│ 技能类型 示例 │
├────────────────────────────────────────────────────────────┤
│ 生产力工具 Gmail管理、日历调度、文档写作 │
│ 开发工具 GitHub管理、代码审查、CI/CD触发 │
│ 数据分析 Excel处理、图表生成、数据清洗 │
│ 社交管理 Twitter/X发布、LinkedIn互动、内容策划 │
│ 研究助手 网络搜索、论文摘要、信息整理 │
│ 自动化 IFTTT式工作流、定时任务、条件触发 │
└────────────────────────────────────────────────────────────┘
技能定义（类似 Function Calling 但更"用户友好"）：
{
"name": "weekly_report",
"description": "自动生成周报，汇总本周工作内容",
"trigger": "用户说'写周报'或每周五下午5点",
"steps": [
"收集本周的 GitHub commits",
"收集本周的 Slack 消息摘要",
"收集本周的会议记录",
"按模板格式生成周报",
"发送到指定邮箱"
]
}2.5 Heartbeat 与安全风险
Heartbeat（心跳机制）：
OpenClaw 的心跳机制是其独特的可靠性保障，但也带来了潜在的安全考虑：
Gateway 每隔 N 秒检查 Agent 状态：
┌─────────────────────────────────────────────────────────┐
│ Agent 状态 Heartbeat 响应 Gateway 动作 │
├─────────────────────────────────────────────────────────┤
│ 正常运行 "processing step 3/5" 继续等待 │
│ 卡住/循环 "step 2 still running" 发送催促 │
│ (超过预期时间) 或重启Agent │
│ 无响应 timeout 重启Agent Loop│
│ 执行完毕 "task completed" 收集结果 │
└─────────────────────────────────────────────────────────┘安全风险考虑：
| 风险 | 说明 | 缓解措施 |
|---|---|---|
| 技能沙箱逃逸 | 恶意技能可能突破隔离访问系统 | 进程级隔离、权限最小化 |
| 供应链攻击 | ClawHub 上的技能可能含恶意代码 | 代码审查、社区评分、沙箱执行 |
| Agent 越权 | Agent 可能以不当方式使用赋予的工具 | 操作审批、操作范围限制 |
| 数据泄漏 | Agent 处理敏感数据时可能外泄 | 数据脱敏、本地处理优先 |
2.6 OpenClaw 的独特价值总结
| 维度 | OpenClaw 的特色 |
|---|---|
| 定位 | 从"开发框架"到"Agent 运行平台"的升级 |
| 设计哲学 | 让非开发者也能轻松创建 Agent（技能化思维、插件化设计） |
| 核心架构 | Gateway 中间执行层，统一管理所有 Agent |
| 生态 | ClawHub 技能市场，类似"Agent 的 App Store" |
| 接入方式 | Slack/Discord/Web/API 多通道统一接入 |
| 可靠性 | Heartbeat 心跳机制，Agent 不会无声崩溃 |
3. Hermes Agent
Hermes Agent 是由 Nous Research 开发的一款高度自治、支持自我进化的开源 AI 智能体框架。其核心设计理念是“与您共同成长”，旨在打造一个具备持久记忆、能自主复盘并自动沉淀工作技能的长期数字员工，而非一次性的对话机器人。
3.1 背景与定位
Hermes Agent 由 Nous Research 于 2026 年 2 月发布，截至当前（2026 年 6 月）已获得 110K+ stars。Nous Research 以开源大语言模型（Hermes 系列）闻名，Hermes Agent 是他们从"模型训练"向"Agent 运行时"的延伸。
Hermes 的设计哲学：Agent 应该能自己进化自己——KEPA 自进化闭环。
3.2 KEPA 自进化闭环
KEPA 是 Hermes 最核心的概念： Knowledge → Experience → Practice → Adaptation 的闭环，让 Agent 在使用过程中不断自我改进。
KEPA 自进化闭环：
┌──────────────────────────────────────────┐
│ │
▼ │
┌──────────┐ │
│Knowledge │ 知识层 │
│ (K) │ ├─ 基础模型知识 │
│ │ ├─ 外部检索知识（RAG） │
│ │ └─ 持久记忆中的领域知识 │
└────┬─────┘ │
│ │
▼ │
┌──────────┐ │
│Experience│ 经验层 │
│ (E) │ ├─ 任务执行记录 │
│ │ ├─ 成功/失败模式 │
│ │ └─ 用户反馈 │
└────┬─────┘ │
│ │
▼ │
┌──────────┐ │
│ Practice │ 实践层 │
│ (P) │ ├─ 新任务执行 │
│ │ ├─ 应用历史经验 │
│ │ └─ 尝试新策略 │
└────┬─────┘ │
│ │
▼ │
┌──────────┐ │
│Adaptation│ 适应层 │
│ (A) │ ├─ 从实践中提取教训 │
│ │ ├─ 更新知识库和策略 │
│ │ └─ 调整行为模式 │
└────┬─────┘ │
│ │
└──────────────────────────────────────────┘
↑ 循环迭代，持续进化
具体示例：
K: "用户偏好简洁的答案，不喜欢冗长的解释"
E: "上次对Python问题的2000字回答，用户回复说太长了"
P: "这次回答Python问题时，控制在500字以内"
A: "简洁回答得到用户好评 → 更新偏好：始终简洁回答编程问题"KEPA 与传统 Agent 的关键区别：
- 传统 Agent 每次执行都是"从零开始"——靠 Prompt 和检索结果来工作，不会从历史中学习。
- KEPA 让 Agent 越用越聪明——成功经验被强化，失败教训被避免。
3.3 四级持久记忆
Hermes 的记忆系统比传统 Agent 框架的"简单向量库"要复杂得多——它区分了四个层级的持久记忆。
Level 1: 工作记忆 (Working Memory)
┌───────────────────────────────────────────────────────────┐
│ 范围: 当前任务 │
│ 内容: 任务计划、中间结果、暂存变量 │
│ 存储: 内存（任务结束释放） │
│ 类比: 人脑中的"当前思考" │
└───────────────────────────────────────────────────────────┘
│
▼
Level 2: 会话记忆 (Session Memory)
┌───────────────────────────────────────────────────────────┐
│ 范围: 当前对话会话 │
│ 内容: 对话历史、用户表达的情绪、未完成的任务 │
│ 存储: 上下文窗口 + 会话摘要 │
│ 类比: 人脑中的"刚才发生了什么" │
└───────────────────────────────────────────────────────────┘
│
▼
Level 3: 情景记忆 (Episodic Memory)
┌───────────────────────────────────────────────────────────┐
│ 范围: 跨会话的历史交互 │
│ 内容: 过去的任务、用户反馈、成功/失败经验 │
│ 存储: 向量数据库 (时间加权检索) │
│ 类比: 人脑中的"回忆" │
└───────────────────────────────────────────────────────────┘
│
▼
Level 4: 语义记忆 (Semantic Memory)
┌───────────────────────────────────────────────────────────┐
│ 范围: 终身知识和行为模式 │
│ 内容: 用户画像、领域知识、经过验证的最佳实践、偏好 │
│ 存储: 结构化知识图谱 + 向量库 │
│ 类比: 人脑中的"知识和价值观" │
└───────────────────────────────────────────────────────────┘记忆升级机制（Memory Consolidation）：
从低层到高层的记忆升级
工作记忆 ──> 会话结束 ──> 提取关键信息 ──> 会话记忆
会话记忆 ──> 定期扫描 ──> 识别重复模式 ──> 情景记忆
情景记忆 ──> 抽象归纳 ──> 提炼通用知识 ──> 语义记忆
例：
工作记忆: "用户这次要求用Python写排序算法"
→ 会话记忆: "用户在讨论算法学习"
→ 情景记忆: "用户过去5次对话中4次涉及算法练习"
→ 语义记忆: "用户是算法初学者，偏好Python，正在系统学习"3.4 Hermes vs OpenClaw 对比
| 维度 | Hermes Agent | OpenClaw |
|---|---|---|
| 创建者 | Nous Research | Peter Steinberger |
| 发布时间 | 2026.02 | 2024 (持续迭代) |
| Stars | 110K+ | 247K+ |
| 核心哲学 | 自进化（KEPA闭环） | 技能化（ClawHub市场） |
| 记忆系统 | 四级持久记忆 | 基础对话记忆 |
| 独特创新 | KEPA自我改进 | Heartbeat心跳 + 技能市场 |
| 适用场景 | 需要长期学习和适应的 Agent | 需要快速组装技能的 Agent |
| 学习能力 | 强（从经验中进化） | 弱（主要靠技能更新） |
| 生态开放性 | 偏研究导向 | 偏应用生态 |
| 类比 | "会学习的学徒" | "技能齐全的工具箱" |
3.5 Hermes 的设计启示
Hermes 最大的启示在于：Agent 不应该只是"执行工具"，而应该是"学习系统"。
当前大多数 Agent 每次执行都是独立事件，不会成长。KEPA 闭环提出了一种让 Agent 从每次交互中积累经验、持续进化的路径。这可能是 Agent 从"有用"走向"不可或缺"的关键一步。
4. Harness Engineering / OpenHarness
4.1 背景与定位
OpenHarness 由清华大学沈阳团队提出，是一个学术驱动的 Agent 框架评估与设计方法。其核心贡献是提出了 NLAH (Natural Language Agent Harness) 论文，揭示了当前 Agent 框架的 6 倍性能差距。
4.2 六大支柱（Six Pillars）
OpenHarness 认为一个完整且高质量的 Agent 框架需要满足六大支柱：
┌─────────────────────────────────────────────────────────────┐
│ │
│ ① 模型无关性 (Model Agnostic) │
│ 不绑定特定 LLM，可以替换底层模型而无需重写 Agent 逻辑 │
│ ├─ 统一模型接口 │
│ ├─ 不同模型能力差异的适配层 │
│ └─ 意义：避免 vendor lock-in，利用模型迭代红利 │
│ │
│ ② 工具抽象 (Tool Abstraction) │
│ 统一的工具定义、发现和执行接口 │
│ ├─ 支持不同协议的工具 (MCP, REST, SDK) │
│ ├─ 工具能力自动发现和注册 │
│ └─ 意义：工具生态的互操作性 │
│ │
│ ③ 规划能力 (Planning) │
│ 任务分解、依赖分析、动态重规划 │
│ ├─ 层次化任务分解 (Goal → Sub-goals → Actions) │
│ ├─ 动态调整：环境变化时重新规划 │
│ └─ 意义：处理复杂多变任务的基础能力 │
│ │
│ ④ 记忆系统 (Memory) │
│ 多层次记忆：工作记忆、会话记忆、长期记忆 │
│ ├─ 记忆写入：选择性记忆重要信息 │
│ ├─ 记忆检索：根据当前任务检索最相关记忆 │
│ └─ 意义：Agent 的经验积累和个性化基础 │
│ │
│ ⑤ 自我改进 (Self-Improvement) │
│ 从执行结果中学习和优化策略 │
│ ├─ 错误分析和归因 │
│ ├─ 策略迭代和参数自动调优 │
│ └─ 意义：让 Agent 越用越好，而非一成不变 │
│ │
│ ⑥ 安全与对齐 (Safety & Alignment) │
│ 确保 Agent 行为可预测、可控制、符合人类价值观 │
│ ├─ 操作权限控制和审批 │
│ ├─ 行为边界定义和监控 │
│ └─ 意义：Agent 部署到生产环境的必要条件 │
│ │
└─────────────────────────────────────────────────────────────┘六大支柱的层次关系：
安全与对齐 ←── 横跨所有层级的约束
─────────────────────────────────────────────
自我改进 ←── 让 Agent 持续优化
─────────────────────────────────────────────
记忆系统 ←── 支持 Agent 积累和利用经验
─────────────────────────────────────────────
规划能力 ←── Agent 处理复杂任务的引擎
─────────────────────────────────────────────
工具抽象 ←── Agent 行动能力的基础设施
─────────────────────────────────────────────
模型无关性 ←── Agent 的底层智能来源可替换4.3 NLAH 论文：6 倍性能差距
NLAH（Natural Language Agent Harness）论文通过系统性的基准测试，揭示了当前 Agent 框架之间的巨大性能差距，核心发现具体如下：
测试方法：在相同任务集上，使用相同的底层 LLM，仅更换 Agent 框架
关键发现 — 6× 性能差距：
任务完成率
│
│ ██ 最佳框架
│ ██ ██ (6x)
│ ██ ██ ██
│ ██ ██ ██ ██
│ ██ ██ ██ ██ ██
│ ██ ██ ██ ██ ██ ██
│ ██ ██ ██ ██ ██ ██ ██
│ ██ ██ ██ ██ ██ ██ ██ ██
└──────────────────────────────────────────────
Naive Lang Auto Crew Open- Hermes
Agent Chain Gen AI Claw
(基础)
结论：框架设计对 Agent 性能的影响高达 6 倍！→ 相同 LLM + 不同框架 = 截然不同的表现性能差距根源分析：
| 差距来源 | 说明 | 影响 |
|---|---|---|
| 上下文管理 | 好的框架会智能压缩/管理上下文，差的框架让上下文膨胀 | 长任务完成率差异最明显 |
| 错误恢复 | 好的框架有重试和降级策略，差的框架直接失败 | 导致任务失败的主要原因 |
| 规划质量 | 任务分解的粒度、依赖识别准确性 | 复杂任务的完成效果 |
| 工具选择 | 什么时候用哪个工具的判断质量 | 工具调用的准确性 |
| 记忆利用 | 是否有效利用历史经验 | 重复任务的学习效果 |
4.4 OpenHarness 的设计启示
OpenHarness / NLAH 的最大贡献不在于提出又一个 Agent 框架，而在于建立了评估 Agent 框架的基准。
对 Agent 开发者的启示：
- 不要只关注 LLM 能力：框架设计对 Agent 性能的影响可能比模型选择还大
- 上下文管理是核心挑战：这是多数 Agent 框架表现差异的主要来源
- 错误恢复常被忽视：大多数框架的"快乐路径"表现不错，但边界情况差异巨大
- 评估应该系统化：需要标准的基准测试来比较不同框架，而非凭感觉选择
5. 总结
四大 Agent 框架核心对比：
| 维度 | LangChain/LangGraph | OpenClaw | Hermes | OpenHarness |
|---|---|---|---|---|
| 定位 | 开发框架 | 运行平台 | 自进化Agent | 评估框架 |
| 设计哲学 | 组件化+图执行 | 技能化+市场 | 自进化闭合 | 六大支柱 |
| 独特创新 | LangGraph的有状态图 | ClawHub+Heartbeat | KEPA闭环+四级记忆 | NLAH基准 |
| 适合人群 | 开发者 | 普通用户+Dev | 追求长期学习 | 研究者+评估 |
| 学习曲线 | 较陡（抽象多） | 较低（技能化） | 中等 | 学术性 |
| 生态成熟度 | 最成熟（700+集成） | 快速增长 | 新兴 | 新兴 |
| 核心弱点 | 抽象过多 | 安全风险 | 新鲜待验证 | 偏理论 |
核心要点总结：
LangChain / LangGraph：采用"模块化积木"设计理念，LangGraph 通过有状态图模型优雅地解决了复杂控制流的编排难题，适合需要精细控制执行流程的开发者。
OpenClaw：定位为"技能市场 + 运行平台"，通过 ClawHub 生态降低使用门槛，使非技术人员也能参与 Agent 构建；其独创的 Heartbeat 机制为系统稳定性提供了坚实保障。
Hermes Agent：秉持"Agent 应具备自我进化能力"的核心理念，通过 KEPA 闭环实现持续学习，配合四级记忆架构打造真正越用越聪明的长期数字助手。
OpenHarness / NLAH：以学术严谨性揭示了框架选型的重要性——在相同底层模型条件下，不同框架可导致高达 6 倍的性能差异，为 Agent 框架评估建立了重要基准。
选型建议：根据实际场景匹配工具——深度定制开发首选 LangGraph，快速业务组装推荐 OpenClaw，追求长期自适应能力则 Hermes 值得重点关注。