Langgraph 16. OpenClaw 的 Goal Setting and Monitoring 机制深度解析

摘要本文在前文 LangGraph 15. Goal Setting and Monitoring 的基础上深入剖析 OpenClaw开源个人 AI 助手如何实现 Goal Setting目标设定与 Monitoring监控。OpenClaw 不依赖显式的图结构与条件边循环而是通过文件优先的认知架构——HEARTBEAT.md周期性任务、MEMORY.md长期目标与即时目标、AGENTS.md操作指南——将目标与监控融入 Agent 的每次 wake-up 与工具执行中。本文系统梳理 OpenClaw 的 Goal Setting and Monitoring 机制并与 LangGraph 的「图 状态 条件边」方案进行对比为读者在自建 Agent 时提供选型与落地的参考。关键词OpenClawGoal SettingMonitoringHEARTBEAT.mdMEMORY.mdAGENTS.mdLangGraph文件驱动条件边1 引言从 LangGraph 的「图 条件边」到 OpenClaw 的「文件操作系统」在第 15 章中我们用一个 LangGraph 示例展示了 Goal Setting and Monitoring 的最小闭环目标设定用户提供use_case和goals智能体以之为质量标准生成generate_code节点根据需求与反馈产出代码监控get_feedback节点对代码评审check_goals_met判断是否达标循环条件边根据goals_met或iteration max_iterations决定走向save_code或回到generate_code。整个流程是单次请求内的显式图循环状态在CodeAgentState中流转节点顺序执行条件边实现分支。OpenClaw 的 Goal Setting and Monitoring 在思想上与之高度一致但实现方式截然不同它不依赖「图 节点 条件边」的编程模型而是将目标与监控分散到八类 Markdown 文件中通过每次 Agent wake-up 时加载这些文件、Agent 执行工具后更新文件形成一种松耦合、跨会话、人机协作的目标与监控范式。2 OpenClaw 的 Goal Setting 机制目标从哪里来想象一下你是一个项目经理每天到岗第一件事是看待办清单HEARTBEAT知道今天要完成什么同时回顾当前情境MEMORY 的 Active Context明确「此刻正在做什么、下一步要达到什么」最后遵循操作规范AGENTS 的 How I Work知道「何时检查、何时汇报」。OpenClaw 的 Goal Setting 正是这种「清单 情境 规范」的混合体。2.1 HEARTBEAT.md周期性任务清单HEARTBEAT.md是 OpenClaw 中最显式的「目标」载体一份 Markdown 格式的待办清单采用- [ ]/- [x]语法。- [ ] check if the deploy finished - [ ] summarize yesterdays slack threads - [x] update the README ← done at 14:30谁设定目标人类或系统在 HEARTBEAT.md 中写入待办Agent 在完成任务后将- [ ]改为- [x]并标记完成时间。何时生效AGENTS.md中约定「Check HEARTBEAT.md on every wake-up」因此每次 Agent 被唤醒时都会在 system prompt 中看到这份清单从而知道「今天要做什么」。理解要点HEARTBEAT 是任务级的 Goal Setting——离散、可勾选、可追溯。与 LangGraph 的goals列表「简单易懂、功能正确」不同HEARTBEAT 更偏向「具体待办事项」而非「质量准则」。2.2 MEMORY.md长期目标与即时目标在 ClawCityOpenClaw 驱动的 AI MMO等场景中MEMORY.md承载了更细粒度的目标# Memory ## Active Context Current situation: exploring forest cluster near (120, 80). Immediate goal: build wood reserves above 50 before claiming territory. ## Durable Facts - home_terrain: forest near (120, 80) - best_market: (150, 250) - wood_rich_zone: (100-140, 60-100) ## Constraints - Do not overclaim territory --- upkeep costs 5 food/hr per tileActive Context当前情境与Immediate goal即时目标如「木材储备达到 50 以上再占领领土」Durable Facts长期事实为决策提供背景Constraints约束条件相当于「不可违反的边界」。谁设定目标Agent 在运行中根据环境与用户指令更新 MEMORY.md 的 Active Context 与 Immediate goal人类也可直接编辑。何时生效MEMORY.md 在每次 Agent run 时被注入 system promptAgent 据此知道「此刻要达成什么」。实际例子在 ClawCity 中Agent 的 Immediate goal 可能是「木材 50」「占领某块地」等当目标达成时Agent 会更新 MEMORY写入新的情境与下一阶段目标。2.3 AGENTS.md操作规范与「何时检查」AGENTS.md定义「我如何工作」其中包含何时检查目标的约定# Agent Instructions ## How I Work - Check HEARTBEAT.md on every wake-up - Use workspace/skills/ for persistent tools - Save important findings to MEMORY.md before context gets long「Check HEARTBEAT.md on every wake-up」即每次 Agent 被唤醒时必须读取 HEARTBEAT将其中的待办视为当前要执行的目标。这种约定将「目标」与「监控节奏」绑定在一起。2.4 SOUL.md边界与约束SOUL.md定义人格、边界与价值观如「Never share user data」「Always ask before irreversible actions」。这些约束相当于不可违背的元目标Agent 在追求 HEARTBEAT 或 MEMORY 中的目标时必须同时满足 SOUL 的边界。3 OpenClaw 的 Monitoring 机制如何知道目标是否达成LangGraph 的 Monitoring 是显式的get_feedback节点调用 LLM 评审代码check_goals_met节点调用 LLM 返回 True/False条件边根据结果路由。OpenClaw 的 Monitoring 则是隐式的没有专门的「评审节点」而是通过文件读取 工具执行 文件更新来体现。3.1 每次 wake-up目标与约束被注入每次 Agent 运行decision call时OpenClaw 按固定顺序将人格文件组装进 system prompt1. SOUL.md ← 边界与约束 2. IDENTITY.md ← 名称与形象 3. USER.md ← 用户上下文 4. AGENTS.md ← 操作指令含「Check HEARTBEAT」 5. TOOLS.md ← 工具说明 6. MEMORY.md ← 长期记忆、Active Context、Immediate goal 7. Active skills ← 技能元数据HEARTBEAT.md通常由 AGENTS.md 或单独配置指定在 wake-up 时加载。Agent 看到这些内容后自然知道「有哪些待办」「当前情境是什么」「下一步要达到什么」。理解要点Monitoring 的「输入」——目标与约束——在每次推理前就已就绪Agent 的推理与工具调用本质上是在「对照这些目标做决策」。3.2 工具执行结果即监控信号OpenClaw 的 Agent 通过read、write、edit、bash等工具执行任务。工具的输出会进入对话上下文Agent 据此判断「任务是否完成」若任务是「检查部署是否完成」Agent 调用bash执行部署检查脚本根据返回结果判断若任务是「更新 README」Agent 调用edit修改文件完成后在 HEARTBEAT 中勾选- [x]。没有显式的「评审 LLM 调用」监控依赖的是工具执行结果与Agent 的自主判断是否勾选、是否更新 MEMORY。3.3 Memory Flush在遗忘前「抢救」进展当会话接近auto-compaction阈值时OpenClaw 会触发Memory Flush发起一次静默的 Agent 轮提示模型「把重要内容写入 memory/YYYY-MM-DD.md 或 MEMORY.md」。从 Goal Setting and Monitoring 的视角看Memory Flush 相当于「在遗忘发生前让 Agent 把当前进展与目标状态写回持久化存储」。这样即使后续对话被压缩Agent 仍能在 MEMORY 中保留「做到了哪一步、下一步要做什么」。3.4 HEARTBEAT 勾选目标达成的显式标记当 Agent 完成 HEARTBEAT 中的某项任务时它会将- [ ]改为- [x]并可选地添加完成时间。这一文件更新是 OpenClaw 中最显式的「目标达成」标记相当于 LangGraph 中goals_met True的持久化版本。4 典型流程OpenClaw 的 Goal Setting and Monitoring 在运行中如何工作每次 Agent wake-up ↓ 按顺序加载人格文件含 HEARTBEAT、MEMORY、AGENTS ↓ AGENTS.md 要求Check HEARTBEAT.md on every wake-up ↓ Agent 读取 HEARTBEAT看到未完成任务读取 MEMORY 的 Active Context / Immediate goal ↓ Agent 选择要执行的任务基于 LLM 推理 ↓ 调用工具执行如 bash、edit、read ↓ 根据工具输出判断任务是否完成 ↓ 若完成在 HEARTBEAT 中勾选 - [x]可选更新 MEMORY 的 Active Context ↓ 可选Memory Flush 时把重要进展写入 MEMORY.md ↓ 下次 wake-up 重复上述流程与 LangGraph 的「单次请求内循环」不同OpenClaw 的循环是跨 wake-up、跨会话的每次 Agent 被唤醒都是一次新的「读取目标 → 执行 → 更新状态」的迭代。5 与 LangGraph 方案的对照两种范式的对比维度LangGraph 方案OpenClaw目标形式单次请求中的goals列表如「简单易懂、功能正确」持久化文件HEARTBEAT待办、MEMORYActive Context / Immediate goal、AGENTSHow I Work目标粒度质量准则可抽象、可复用任务级具体待办 情境级即时目标 约束级SOUL 边界监控方式显式节点get_feedbackLLM 评审→check_goals_metLLM 判定 True/False隐式文件加载 工具执行结果 Agent 自主判断是否勾选、是否更新 MEMORY达标判定LLM 返回goals_metTrue/False条件边路由Agent 在 HEARTBEAT 中勾选- [x]更新 MEMORY 的 Active Context循环结构条件边未达标 → 回到generate_code单次请求内多轮迭代无显式图循环依赖多次 wake-up 文件更新时间粒度单次请求内秒级、分钟级跨会话、跨 wake-up小时级、天级适用场景单任务质量闭环如代码生成、文案评审多任务、长期运行、人机协作如日常助理、游戏 Agent共同点都有明确的目标LangGraph 的 goals vs OpenClaw 的 HEARTBEAT MEMORY都有监控机制LangGraph 的评审节点 vs OpenClaw 的文件加载 工具执行都有反馈驱动LangGraph 的 revise 循环 vs OpenClaw 的勾选 MEMORY 更新。差异点LangGraph 的监控是显式的 LLM 调用评审 判定OpenClaw 的监控是隐式的工具执行 文件更新LangGraph 的循环是编程式的图结构 条件边OpenClaw 的循环是事件驱动的每次 wake-up 重新加载LangGraph 适合单次请求内的高质量迭代OpenClaw 适合跨会话的长期任务管理。6 选型建议何时用 LangGraph何时借鉴 OpenClaw场景推荐方案理由单次请求内的高质量产出如代码生成、文案打磨LangGraph显式图 条件边便于实现「生成 → 评审 → 修订」的闭环。多任务、长期待办管理如日常助理、项目管理OpenClaw 范式HEARTBEAT MEMORY 的文件驱动天然支持跨会话、人机协作。需要 LLM 做「达标判定」如代码是否满足质量标准LangGraph专门的check_goals_met节点可显式调用 LLM 判定。需要人类可读、可编辑的目标如待办清单OpenClaw 范式HEARTBEAT.md 为 Markdown人类可直接编辑。需要快速迭代、可观测的调试LangGraph图结构可视化节点执行顺序清晰便于调试。理解要点两种范式并非互斥。可以在 LangGraph 中引入「HEARTBEAT 式」的状态从文件加载待办在 OpenClaw 中为特定任务引入「LangGraph 式」的子图如 skill-creator 的「构思 → 编写 → 评测 → 迭代」。选型时需结合任务粒度、时间跨度、人机协作程度综合考量。7 小结与落地建议7.1 OpenClaw Goal Setting and Monitoring 核心要点HEARTBEAT.md周期性任务清单Agent 每次 wake-up 读取完成后勾选- [x]。MEMORY.mdActive Context Immediate goal承载情境级目标与即时目标。AGENTS.mdHow I Work 约定「何时检查 HEARTBEAT」将目标与监控节奏绑定。SOUL.md边界与约束相当于不可违背的元目标。监控方式文件加载 工具执行 Memory Flush HEARTBEAT 勾选无显式「评审 LLM 调用」。循环方式跨 wake-up、跨会话依赖每次 wake-up 重新加载文件。7.2 若借鉴 OpenClaw 设计到自建 Agent显式拆分「任务级」与「质量级」目标任务级用 HEARTBEAT 式清单质量级用 LangGraph 的 goals 或评审节点在 wake-up 时加载目标确保每次推理前Agent 都知道「要做什么」用文件更新替代状态变量若需跨会话持久化可考虑用 Markdown 文件存储目标与进展结合 LangGraph 的显式循环对单次请求内的高质量迭代仍用图 条件边对跨会话任务用文件驱动。8 参考资料OpenClaw GitHubOpenClaw 官方文档 - MemoryOpenClaw 官方文档 - Agent LoopClawCity: AI Agent Memory That Actually WorksStarkslab: OpenClaw Self-ModificationLangGraph 15. Goal Setting and Monitoring