企业级 LangGraph Agent 设计

某种意义上，OpenClaw 和 Hermes 也只不过是提示词工程。

OpenClaw

OpenClaw 的架构中心其实是 Gateway + Channels + Skills + Agents。官方列出的渠道覆盖 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Teams、飞书、Mattermost、微信、QQ 等大量平台。

适合让它操作服务器、查资料、执行脚本、处理文件、调用 API，再把结果发回来。

Hermes

Nous Research 把它明确定位为自我改进的 AI agent（self-improving AI agent）。Hermes 会从过去的执行经验中创建 Skill、改进 Skill、持久化知识，并搜索自己的历史对话，从而逐渐形成对用户的长期模型。 第一次它可能需要探索很多东西；之后可以把这套过程沉淀成 Skill。再遇到类似任务时，Hermes 就不完全是从零开始。这个「经验 → Skill → 再利用」循环是 Hermes 最强调的差异。

另外，Hermes 并不是 OpenClaw 的更强版本。OpenClaw 更像基础设施和个人 Agent 平台；Hermes 更像强调持续学习的 Agent runtime。

LangGraph

LangGraph 官方定义为面向长期运行（long-running）、有状态的工作流 / Agent（stateful workflow/agent）的低层次编排框架（orchestration framework）。 可以理解成，LangGraph 是设计制造 Agent 的框架。

记忆设计

OpenClaw 默认记忆是文件优先（file-first）。没有隐藏状态，真正记住的东西都会写到 agent workspace 里的 Markdown 文件。

核心分为四层：

• USER.md 保存稳定用户偏好和用户模型
• MEMORY.md 保存长期事实和决策
• memory/YYYY-MM-DD.md 保存每天较详细的工作记录和观察
• DREAMS.md 用于 dreaming/consolidation 的整理结果。

它的关键点是：USER.md 和 MEMORY.md 会进入新 session 的启动上下文，而大量日常记录不会全部塞进 prompt，而是进入索引，通过 memory_search / memory_get 按需找回来。

OpenClaw 的 dreaming 机制会把 daily notes 里长期有价值的内容逐渐提炼进 MEMORY.md。

Hermes 默认则更克制。只有两个核心文件：

• MEMORY.md，上限 2200 字符，大约 800 token；
• USER.md，上限 1375 字符，大约 500 token。

这两个文件放在 ~/.hermes/memories/，每个 session 开始时作为冻结快照（frozen snapshot）注入 system prompt。

Agent 通过 memory tool 自己 add / replace / remove。

Hermes 默认记忆是受限的精选记忆（bounded curated memory）。也就是故意只允许非常小的一块核心记忆。如果满了，不会偷偷裁剪，而是 memory tool 返回错误，让 Agent 自己合并、删除、压缩旧信息。

企业级记忆设计

作为公司级别的 Agent 方案，建议采取混合方案。参考 Hermes，把用户画像控制得很小；借鉴 OpenClaw，把项目经验、任务历史、每日/阶段性记录放在大容量存储里，通过按需召回，而不是全部注入 prompt。

工作记忆

当前会话状态，适合使用 LangGraph 的 Checkpoint，不应该使用 pgvector 等进行召回。

例如：

用户：
帮我比较 Qwen 和 DeepSeek

Assistant：
...

用户：
那前者部署需要多少显存？

第二句话里的「前者」属于当前 thread 上下文，不应该依赖 pgvector 找回来。这一层不需要 embedding。

核心记忆

这是少量、非常稳定的信息，例如：

• 用户角色
• 技术背景
• 长期偏好
• 当前主要项目
• 重要约束

控制在大约 500~1500 tokens，直接进入 Agent context。

长期记忆

这部分将使用 PostgreSQL + pgvector。

• 用户曾经做过什么决定
• 用户项目背景
• 任务历史
• 历史技术选型
• 重要事实
• 用户偏好变化
• 会议结论

先做权限和 namespace 过滤，否则记忆泄露的风险会增加。

记忆类型：

• Profile
• Preference
• Fact
• Decision
• Task
• Observation
• Summary

裁剪方案

模型的上下文大小并不是无限的，保存多少历史和每次发给模型多少上下文需要分开控制。

Checkpoint 可以持续持久化，但模型输入必须设置独立预算。

一个实用的裁剪顺序是：

1. 保留最近几轮原始对话，保证指代、语气和当前任务连续；
2. 把更早的对话压缩为结构化摘要；
3. 工具返回的大段内容只保留结论和引用，原文放到外部存储；
4. 与当前任务无关的历史消息不进入模型上下文；
5. 核心记忆和召回记忆分别设置上限，不能挤占当前任务需要的空间。

不要只按消息条数裁剪。一次数据库查询结果可能比几十轮短对话更长，所以预算最终应该按照 token 计算。

摘要也不应该只有一段自然语言。至少保留当前目标、已完成事项、未解决问题、关键约束、工具执行结果和用户确认过的决定。这样即使原始消息被裁掉，Agent 仍然可以继续执行任务。

记忆写入

不是每一句对话都值得进入长期记忆。长期记忆写入应该经过一个独立的提取步骤，只保存未来可能复用的信息。

建议给每条记忆增加以下字段：

• tenant_id、user_id、project_id
• memory_type
• content
• source_thread_id
• importance
• confidence
• created_at、updated_at、expires_at
• status 和版本号

写入时还要处理重复和冲突。例如「用户偏好 Python」和「这个项目必须使用 Java」并不冲突，因为一个是全局偏好，一个是项目约束；而用户明确说「以后不要再使用 Python」时，旧偏好就应该失效，而不是让两条互相矛盾的记忆同时参与召回。

核心记忆可以同步更新，因为下一轮对话马上可能用到。任务摘要、观察和低优先级事实更适合异步写入，避免增加主链路延迟。

记忆召回

pgvector 只是召回能力的一部分，不应该把「向量相似」直接等同于「应该进入上下文」。

推荐的召回顺序是：

1. 先根据租户、用户、项目和记忆类型做硬过滤；
2. 再进行关键词和向量混合检索；
3. 根据相关性、时间、重要性和可信度重新排序；
4. 做去重和冲突处理；
5. 最后按照 token 预算注入少量记忆。

召回结果应该带上来源和时间。模型需要知道一条信息是用户刚刚确认的决定，还是几个月前自动提取的观察。低于阈值时宁可不召回，也不要为了凑满数量塞入弱相关内容。

另外，外部文档和历史工具输出可能包含提示词注入内容。召回文本只能作为数据，不能获得 system prompt 或工具指令同等的优先级。

Namespace 和权限

企业记忆的第一原则不是召回效果，而是隔离。

可以使用类似下面的 namespace：

(tenant_id, user_id, project_id, memory_type)

但 namespace 不能代替数据库权限。服务端仍然需要从已经认证的身份生成过滤条件，使用 PostgreSQL Row Level Security 或等价机制做二次约束。不能接受模型或前端直接传入一个任意 user_id，然后据此查询记忆。

工具权限也必须独立于模型。模型可以提出「发送邮件」或「修改订单」，但真正执行前还要经过权限校验、参数校验和审计。删除、付款、对外发送、生产环境变更等不可逆操作应该使用 LangGraph interrupt 暂停执行，让用户选择批准、修改或拒绝。

Checkpoint 和副作用

Checkpoint 可以让图从上一个成功状态恢复，但不能自动保证外部副作用只执行一次。

假设 Agent 已经调用支付接口，随后在写入下一个 checkpoint 前进程崩溃。恢复后如果直接重试，就可能重复支付。因此所有有副作用的工具都应该尽量支持幂等键，并记录请求状态和外部系统返回的业务 ID。必要时使用 outbox、状态机或补偿操作。

这也是为什么工具节点需要区分：

• 纯读取工具，可以安全重试；
• 幂等写入工具，可以带相同幂等键重试；
• 非幂等操作，恢复前必须查询外部状态或由人工确认。

Graph 设计

企业 Agent 不建议从一个可以调用所有工具的 ReAct 循环开始。更稳妥的图可以拆成：

身份与权限加载
  -> 意图识别
  -> 记忆召回
  -> 计划或路由
  -> 工具权限检查
  -> 工具执行
  -> 结果校验
  -> 回复生成
  -> 记忆提取

简单问答可以跳过计划和工具节点；高风险操作进入人工审批分支；工具失败则进入有限重试、降级或人工处理分支。每个节点只承担一种职责，状态中保存结构化结果，不要让所有节点都反复解析完整聊天记录。

状态也不应该只有 messages。可以显式定义：

• request_context
• user_profile
• retrieved_memories
• plan
• tool_results
• approval_status
• final_response
• errors

这样更容易限制每个节点能读写的数据，也更容易测试和审计。

可观测性和评估

企业级 Agent 必须能回答：它为什么调用这个工具、使用了哪些记忆、在哪个节点失败、一次任务花了多少时间和 token。

至少记录：

• graph、node、模型和 prompt 版本
• 每个节点的输入输出摘要
• 工具名称、参数摘要、耗时和结果状态
• 召回到的 memory ID 和分数
• token、成本、首 token 延迟和总延迟
• interrupt、重试、异常和最终状态

日志里不应该直接保存密码、访问令牌和完整敏感数据。用于观测的内容也要经过脱敏，并设置访问权限和保留期限。

评估不能只看最终回复。至少需要分别评估：最终答案是否完成任务、单个步骤是否选择了正确工具、整个执行轨迹是否合理。上线前使用固定数据集做离线回归，上线后对真实流量采样做在线评估，再把失败案例沉淀回测试集。

推荐的存储分工

• PostgreSQL Checkpointer：保存 thread 内的 graph state 和恢复点；
• PostgreSQL + pgvector：保存跨 thread 的长期记忆和语义索引；
• 对象存储：保存大文件、原始工具输出和附件；
• Redis：用于短期缓存、限流和分布式协调，不作为唯一事实来源；
• 审计库：保存高风险工具调用、审批和状态变化。

这些存储可以共用基础设施，但逻辑上要分开。会话状态、用户记忆、业务数据和审计记录有不同的生命周期、权限和删除要求。

落地顺序

第一阶段只做有边界的问答和只读工具，验证状态设计、召回质量和观测链路。

第二阶段加入核心记忆和长期记忆，但先让用户可以查看、修改和删除自己的记忆。

第三阶段接入低风险写工具，补齐幂等、重试和审计。

第四阶段再开放高风险操作，并加入细粒度权限和人工审批。

最后才考虑让 Agent 自动总结经验、生成流程或者改进 Skill。自我改进必须经过评估和版本控制，不能让线上 Agent 直接修改自己的核心规则。

总结

OpenClaw 和 Hermes 提供了很有价值的产品思路：一个展示了文件化工作空间和多渠道 Agent 的实用性，另一个展示了受限核心记忆和经验沉淀的价值。

LangGraph 的优势不是默认就比它们更聪明，而是允许团队把状态、记忆、权限、审批、恢复和评估显式建模。对企业系统来说，可控、可恢复、可审计通常比 Agent 表面上的自主性更重要。