1. 这篇文章真正要解决的问题如果你做过机器人项目大概率遇到过这个场景机器人能准确识别出桌子上的杯子能规划出机械臂的抓取轨迹甚至能稳稳地把杯子端起来。但当你让它“把这几个杯子洗干净然后放到橱柜里再帮我泡一杯咖啡”时它就露馅了——洗到第二个杯子时忘了第一个放在哪厨房和客厅是两个空间它不知道咖啡粉放在哪个抽屉中途有人打断了一下它干脆不知道接下来要干什么。问题不在感知也不在控制。感知已经有了视觉语言模型和各类传感器控制已经有了成熟的轨迹规划算法。真正卡住机器人的是两件事一是“在物理世界里做推理”二是“把做过的事、看到的东西记住”。前者叫具身推理后者就是 Agent Memory。这篇文章想讲清楚几件事具身智能为什么需要“推理”而不是简单的“感知-执行”长程任务规划为什么绕不开记忆记忆在具身智能里到底长什么样和普通人理解的“缓存”有什么区别工程上怎么把记忆接入一个具身智能 Agent包括用 Redis、向量数据库做记忆存储的轻量实现实际项目中常见的坑和建议。如果你正在入门具身智能或者在做 Agent 类应用觉得“模型能力够了但落地效果很差”那这篇文章大概率能帮上忙。建议收藏备用尤其是第 6 节的工程实现和第 7 节的排查清单。2. 具身智能的基础概念感知、推理、规划、执行、记忆先把概念对齐后面才不会乱。2.1 具身智能具身智能Embodied Intelligence不是一个新的学科而是一种研究范式。它的核心观点是智能不能只存在于“大脑”里必须有一个物理身体去感知环境、执行动作并在交互中不断学习。扫地机器人是最朴素的具身智能人形机器人是更复杂的具身智能机械臂移动底盘也是。和纯语言模型相比具身智能多了一个“物理世界约束”物体有重量、有位置、会碎、会倒机器人在空间里有朝向、有可达范围、有电量限制。这些约束让“推理”变得必要。2.2 具身推理具身推理Embodied Reasoning可以通俗理解为让机器人在物理场景中做判断。传统物体识别回答的是“这是什么”具身推理回答的是“这个东西能做什么”“它现在在哪里”“我能不能拿到它”“拿了之后会发生什么”。比如看到地上有把椅子具身推理要考虑的是椅子当前是不是挡路了我能不能绕过它如果不能绕能不能推开它推的时候会不会碰到旁边的花瓶这种推理依赖多模态信息视觉、深度、触觉、位置甚至常识知识。比如“杯子通常是放在桌上的”“易碎品要轻拿轻放”这些常识不来自视觉传感器而是来自语义知识。2.3 Agent MemoryAgent Memory 就是智能体Agent的记忆系统负责保存任务状态、环境信息、历史经验、技能知识并在合适的时机取出来使用。很多开发者第一次接触 Agent Memory 是在大语言模型应用里解决“模型没有记忆”的问题。但在具身智能里记忆的形态更复杂因为它不再只是“对话上下文”还要包含空间地图、物体位置、任务进度、操作经验等多模态数据。2.4 传统方案和具身智能 Agent 的差异维度传统机器人具身智能 Agent任务定义人工编写流程固定步骤自然语言指令自动拆解感知传感器规则视觉语言模型多模态融合规划状态机、行为树大模型推理长程任务规划环境应对靠预设条件分支实时推理记忆回退知识来源人工写死的参数预训练知识在线记忆积累很多人把具身智能当成“机器人换了个大脑”但真正的变化是整个架构从“预编程”转向“自主推理”。而自主推理一旦面对真实环境就必须有记忆。3. 长程任务规划为什么难从“感知-执行”到“感知-推理-规划-执行”长程任务规划Long-Horizon Task Planning是具身智能里使用频率很高的一个词。它的意思是让机器人完成一个包含多个子步骤、跨越较长时间和空间的任务。举一个典型的“长程”例子把客厅收拾干净然后把脏衣服放进洗衣机再帮我把阳台上的花浇了。这个任务包含至少三个子任务每个子任务又有自己的步骤。“收拾干净”本身是模糊的需要推理出哪些东西算“脏乱”、应该放到哪里“把脏衣服放进洗衣机”需要先找到脏衣服、走到洗衣机前、打开盖子、放进去“浇花”需要找到水壶、接水、走到阳台、浇灌。这种任务为什么难有四个原因3.1 步骤数量大规划空间膨胀一个长任务往往有几十个甚至上百个原子动作。如果全部用人工规则穷举几乎不可能覆盖所有情况。行为树和状态机只能处理“预期内”的分支遇到一个没见过的场景系统直接不知道下一步怎么办。3.2 环境是部分可观察的机器人在某一时刻只能感知到当前视角内的信息。它看不到客厅全貌更看不到厨房柜子里的东西。要做出正确的长期规划它必须依赖“之前看过什么”也就是记忆。比如它必须记得“刚才在茶几上看到过遥控器”才能规划出“走到茶几旁拿遥控器”。3.3 意外和中断让规划失效真实环境充满意外门是关的、物体被挡住了、有人经过打断了导航。机器人需要能够“回退”到之前的某个状态重新规划。没有记忆它只能从头开始有记忆它至少知道“已经完成了哪几步还剩哪几步”。3.4 常识推理负担重“把脏衣服放进洗衣机”看起来简单但机器人需要知道脏衣服在洗衣篮里洗衣机在卫生间打开盖子之前要先把盖子按一下衣服不能塞太满不同颜色可能要分开洗。这些知识如果全部写死在代码里换一个家庭场景就全失效。大语言模型和视觉语言模型的介入解决了一部分常识推理的问题。模型见过大量“如何做家务”的语料知道任务的抽象流程。但模型本身没有记忆能力上下文窗口有限无法直接感知物理环境的变化。所以长程任务可行的路径是感知层负责看推理层负责想记忆层负责记规划层负责排执行层负责做。记忆位于中间承上启下是整个链路里最容易被忽视、却最关键的一环。4. 具身智能的记忆架构先分层再实现谈到 Agent Memory 的工程实现有一个最常见的误区把记忆当成一个大号的键值存储。实际上具身智能的记忆需要分层设计不同层承担不同职责。认知科学里有一个经典框架把记忆分成感觉记忆、工作记忆、长期记忆。工程上可以进一步简化成四层4.1 工作记忆当前任务的“便签纸”工作记忆保存的是当前任务立即需要使用的信息。比如当前正在执行第几步、手里拿的是什么物体、目标位置在哪里。它的特点是容量小、更新频繁、实时性要求高。在工程上工作记忆可以放在 Redis 等高速存储里设置过期时间。任务结束时工作记忆要么被清除要么提炼成长期记忆沉淀下来。4.2 情景记忆过去发生过什么情景记忆记录的是机器人过去的“经历”。比如上次任务中遥控器是在茶几上找到的上次擦桌子时抹布在厨房水槽旁边。这类记忆适合用向量数据库存储因为它需要按“语义相似度”检索。比如任务说“找一个能擦桌子的东西”机器人可以从情景记忆里检索出“上次用过抹布”这个经验。4.3 语义记忆世界是什么样的语义记忆保存的是相对稳定的知识杯子是易碎品、沙发是坐的、衣柜在卧室里。这些知识一部分来自预训练模型一部分来自长期积累。语义记忆不一定需要实时更新但需要和情景记忆联动。当模型的知识和机器人的实际观察冲突时通常以实际观察为准同时记录冲突。4.4 程序性记忆怎么做一件事程序性记忆对应的是“技能”。比如怎么抓取一个圆柱体、怎么绕过障碍物导航、怎么打开一扇门。这类记忆可以是策略网络、轨迹模板也可以是文本化的操作步骤。在工程实现中程序性记忆通常不是一个存储结构而是一个技能库由任务规划器按需调用。记忆类型核心问题典型内容工程载体工作记忆当前正在做什么任务步骤、物体 ID、状态Redis、内存对象情景记忆过去发生过什么任务经历、环境观察向量数据库语义记忆世界是什么样的常识、概念、空间拓扑向量库、知识图谱程序性记忆怎么做一件事技能、策略、轨迹技能库、模型权重这套分层设计的核心思想是不同类型的记忆有不同的读写频率和访问模式不能混在一个存储里。短期状态用快速存储长期经验用检索式存储技能和其他满足“不常变但需要随时调用”的需要独立管理。5. 记忆如何参与长程任务规划一个收拾客厅的例子理论说再多不如跟着一个例子走一遍。假设我们有一个移动机械臂机器人任务是把客厅里散落的杯子收集到厨房水槽然后把茶几擦干净。我们来拆解一下记忆在这个过程中的作用。5.1 任务开始写入工作记忆机器人收到任务后规划器把任务拆解为若干子步骤步骤1在客厅中搜索目标物体杯子 步骤2移动到目标物体位置 步骤3抓取杯子并放入收纳筐 步骤4移动到厨房水槽放下杯子 步骤5回到客厅找到抹布 步骤6擦拭茶几这些步骤会写入工作记忆。同时机器人开始“观察客厅”感知到三个杯子分别在茶几、书架、电视柜上。这个观察结果也写进工作记忆。5.2 执行中的选择性更新机器人先走到茶几抓取杯子放进收纳筐。此时工作记忆需要更新已完成步骤1茶几上的杯子步骤2步骤3 待完成收集书架上的杯子、电视柜上的杯子注意这里没有把所有信息都倒进一个“坐标系”里而是只记录了任务进度和当前状态。这叫“最小记忆原则”避免状态空间爆炸。5.3 遇到意外从记忆中回退机器人走到书架前发现杯子被一本书压住了。直接抓取可能会失败。这时具身推理开始工作推理书本压住杯子需要先移开书本查询语义记忆书本是轻物可以用机械臂推扫规划新增子步骤“移开书本”执行完成移开再抓取杯子更新把“书本压住杯子”这件事写入情景记忆作为本次任务的经验。这个过程中记忆让机器人不需要从零开始重新规划而是在已有状态基础上做局部调整。这是长程任务和短程任务最本质的区别。5.4 任务完成提炼长期经验所有杯子都放到水槽后机器人继续完成擦桌子。任务结束后工作记忆清空但情景记忆会写入一条摘要“客厅杯子通常出现在茶几、书架、电视柜日常摆放位置不固定茶几上可能有书本压物风险。”下次执行类似任务时机器人可以优先去这几个位置搜索杯子并且提前做好需要移开杂物的准备。5.5 从例子中提炼出的核心模式记忆在长程任务规划中的使用模式其实是一个闭环读取记忆 - 规划动作 - 执行动作 - 观察变化 - 更新记忆 - 再规划这个闭环直接决定了机器人是一个“每次开工都像第一天上班的新员工”还是一个“越用越熟练的老员工”。6. 工程落地Agent Memory 的轻量实现概念讲清楚之后很多读者会问那代码到底怎么写这一节给出一个可以改造成实际项目的轻量实现核心是四个部分记忆接口设计基于 Redis 的工作记忆实现基于向量数据库的长期记忆实现主循环集成。说明下面代码主要用于演示思路依赖库版本请以实际项目为准。生产环境中需要替换成项目实际使用的框架和模型接口。6.1 记忆管理接口设计先定义一个通用的记忆接口屏蔽底层存储差异。文件路径memory/base.pyfrom abc import ABC, abstractmethod from typing import Any, Dict, List, Optional class Memory(ABC): 记忆模块统一接口。 abstractmethod def write(self, key: str, value: Any, **kwargs) - None: 写入一条记忆。 ... abstractmethod def read(self, key: str) - Optional[Any]: 按 key 读取一条记忆。 ... abstractmethod def search(self, query: str, top_k: int 5, **kwargs) - List[Dict[str, Any]]: 按语义检索记忆返回记忆片段列表。 ... abstractmethod def delete(self, key: str) - None: 删除一条记忆。 ... abstractmethod def clear(self) - None: 清空该层记忆。 ...这个接口把“短期工作记忆”和“长期情景记忆”统一成一个抽象层上层规划器只依赖接口不关心底层是 Redis 还是向量数据库。新增一种存储实现只需要继承这个基类。6.2 用 Redis 实现工作记忆工作记忆的特点是高吞吐、短生命周期、支持过期。Redis 天然适合。文件路径memory/work_memory.pyimport json import redis class WorkMemory: 基于 Redis 的工作记忆实现。 每条记录设置过期时间避免状态无限堆积。 def __init__(self, host: str localhost, port: int 6379, db: int 0): self.client redis.Redis(hosthost, portport, dbdb, decode_responsesTrue) def write(self, key: str, value: dict, expire_seconds: int 600) - None: self.client.set(fwork:{key}, json.dumps(value, ensure_asciiFalse), exexpire_seconds) def read(self, key: str) - dict | None: raw self.client.get(fwork:{key}) if raw is None: return None return json.loads(raw) def delete(self, key: str) - None: self.client.delete(fwork:{key}) def clear(self) - None: keys self.client.keys(work:*) if keys: self.client.delete(*keys)为什么用 Redis 做工作记忆读写都在内存中时延低支持过期时间适合“任务结束就遗忘”的短期状态数据结构简单不需要复杂查询生产环境可以开启持久化避免机器人掉电丢失全部状态。注意事项开发时可以关闭持久化生产环境建议开启 RDB 或 AOF并确认 Redis 的高可用方案。6.3 用向量数据库实现长期情景记忆长期记忆需要支持“语义相似度检索”适合用向量数据库。这里以 Chroma 为例代码是示意写法实际 API 请以你安装的版本为准。文件路径memory/episodic_memory.pyfrom typing import Dict, List class EpisodicMemory: 基于向量数据库的长期情景记忆实现。 向量数据库负责把自然语言记忆片段转成向量 按语义相似度检索历史经验。 def __init__(self, collection_name: str episodic_memory): # 这里用伪代码示意不同版本 API 有差异 import chromadb self.client chromadb.Client() self.collection self.client.get_or_create_collection(collection_name) def add_memory(self, memory_id: str, text: str, metadata: Dict) - None: self.collection.upsert( ids[memory_id], documents[text], metadatas[metadata], ) def search(self, query: str, top_k: int 5) - List[Dict]: result self.collection.query( query_texts[query], n_resultstop_k, ) # 结果结构以当前安装的版本为准 return result.get(documents, [[]])[0] def delete(self, memory_id: str) - None: self.collection.delete(ids[memory_id]) def clear(self) - None: self.client.delete_collection(self.collection.name)核心点在于写入长期记忆时不只是写入一段文本还带上元数据时间、任务类型、成功与否检索时查询语句要尽量写得像一个“经验问题”例如“上次在客厅找杯子时有什么发现”效果会好于单纯检索“杯子”长期记忆里的条目应该有去重和淘汰策略不能无限增长。6.4 主循环集成示例有了两个记忆模块后把它们接入一个最小化的具身智能 Agent 主循环。文件路径agent/embodied_agent.pyclass EmbodiedAgent: def __init__(self, work_memory, episodic_memory): self.work_memory work_memory self.episodic_memory episodic_memory self.plan [] def build_plan(self, task: str): 根据任务和历史经验生成规划。 # 1. 检索历史经验 related_experience self.episodic_memory.search( queryf执行任务 {task} 时有哪些经验, top_k3, ) # 2. 把经验拼进 prompt交给规划模型生成步骤 prompt self._build_planning_prompt(task, related_experience) self.plan self._call_planner(prompt) # 3. 把整段规划写入工作记忆 self.work_memory.write(current_plan, {task: task, steps: self.plan}) def execute_step(self, step_index: int): 执行规划中的某一步。 step self.plan[step_index] # 调用底层感知、推理、控制模块 observation self._execute_action(step) # 更新工作记忆 self.work_memory.write(current_state, { step_index: step_index, step: step, observation: observation, }) return observation def recover_from_failure(self, failed_step_index: int): 从失败中恢复读取记忆调整计划。 state self.work_memory.read(current_state) history self.episodic_memory.search( queryf步骤 {self.plan[failed_step_index]} 执行失败如何恢复, top_k3, ) # 把当前状态和历史经验一起送给规划模型重新生成剩余步骤 self.plan self._repair_plan(state, history) def _execute_action(self, step): # 实际项目这里会调用视觉模型、路径规划和控制指令 return {status: ok} def _call_planner(self, prompt): # 实际项目这里会调用 LLM 或 VLM 接口 return [找到杯子, 抓起杯子, 放进水槽]这个主循环对应了第 5 节提到的记忆闭环先检索经验再规划执行过程中用工作记忆维护状态遇到失败时结合状态和长期记忆重新规划。这是目前社区里实现长程任务常用的基础结构。7. 常见问题与排查方法工程上接入 Agent Memory 之后暴露出来的问题往往不是“记忆存不进去”而是“记忆读不出来的不对”。下面列出几个高频问题。问题现象可能原因排查方式解决方案检索结果和当前任务无关长期记忆中噪音太多检索相似度阈值过低打印检索结果检查向量相似度分数增加元数据过滤提高阈值写入时做重要性筛选工作记忆频繁丢失Redis 缓存过期时间太短或未开启持久化查看 Redis 的expire配置和日志根据任务时长设置合理的 TTL生产环境开启持久化任务中断后无法恢复没有在失败时读取工作记忆和长期记忆检查recover_from_failure分支是否被触发明确失败检测逻辑把记忆读取放到异常处理入口同一任务出现互相冲突的记忆新旧经验优先级不明确检查记忆写入时的元数据是否记录了时间和任务ID检索时按时间排序相同场景以最新经验为准上下文窗口溢出把过多记忆片段一股脑塞进模型 prompt统计单次注入的 token 数量对检索结果做截断、摘要采用 RAG 的经典策略多机器人共享记忆导致混乱没有区分记忆的所有者检查记忆记录的元数据是否包含机器人 ID写入时加机器人 ID、场景 ID、任务 ID 等身份字段除了表格里的问题还有一个容易被忽视的坑记忆的写入时机。如果每一步执行完都往长期记忆里写一条长期记忆很快就会充满低价值信息。更合理的策略是关键节点写摘要异常事件写详细记录常规执行只更新工作记忆。8. 最佳实践与工程建议8.1 记忆分层不要混存坚持“工作记忆走 Redis、长期记忆走向量库、技能单独管理”的分层原则。短期状态混进向量库会导致检索噪音居高不下长期知识混进 Redis 又会导致内存爆掉。分层之后每层可以独立扩展也方便排查问题。8.2 用元数据支撑筛选长期记忆不能只存文本。每一条记忆至少包含记忆类型情景经验 / 环境知识 / 任务状态时间戳写入时间来源哪个任务、哪个机器人重要度是否属于异常事件或关键经验。有了这些字段检索时可以先用元数据过滤再做向量相似度排序能显著提高准确率。8.3 设计记忆清理策略记忆不是越多越好尤其是在物理机器人上。建议设计三类清理策略过期清理工作记忆必须有 TTL任务结束或超时后清除去重合并检索到相似度极高的两条记忆时自动合并成新条目并删除旧条目重要性淘汰当长期记忆超过容量上限时优先删除重要度低、时间久远、没有带来过成功经验的历史记录。8.4 提升可观测性记忆系统是最容易“黑盒化”的部分。建议在开发阶段就把每一次记忆读写都记录下来至少包括写入内容摘要检索 query 和 top_k 结果相似度分数最终被模型采纳了哪些记忆片段。没有可观测性你很难判断一个长程任务失败是因为模型推理能力不够还是记忆检索给错了素材。8.5 注意数据安全与隐私具身智能机器人会在真实家庭或办公环境中运行记忆里可能包含房间布局、物品照片、人员的活动轨迹等敏感数据。工程上要注意敏感信息脱敏后再写入长期记忆记忆数据加密存储多用户场景下做访问控制机器人不能无条件共享所有人的家庭经验需要支持用户主动清除历史记忆。8.6 评测要从长程任务出发不建议只评测“单步成功率高不高”而是设计端到端的长程任务评测指标比如任务完成率平均完成时间中断发生率与恢复成功率重复犯错的频率同一个坑踩了两次。这些指标才能真正反映记忆和推理模块的水平。9. 总结与后续学习方向具身智能正在从“能看会动”走向“能想会记”。具身推理让机器人能在物理世界里做判断Agent Memory 让这些判断可以跨时间、跨任务被复用二者共同支撑起长程任务规划。没有记忆的机器人每次开工都像第一天上班有了记忆它才可能越用越熟练。从工程角度看我给入门的读者的建议是先不要碰复杂的大模型设计先在一个仿真环境里把“读取记忆 - 规划 - 执行 - 更新记忆”这个闭环跑通工作记忆用 Redis长期记忆用向量库先用最主流的开源工具不要一开始就搭一套复杂的知识图谱找一个长程任务场景比如收拾客厅、做一顿简餐、仓库取货把任务拆细逐个记录记忆读写日志关注社区里的认知架构类工作例如如何把记忆分层和动作技能库统一管理以及记忆回放、记忆压缩这类新技术。具身智能是一个跨度很大的领域感知、控制、规划、记忆每个方向都能深挖很久。但如果你已经在这条路上请一定记住感知决定了机器人“看到什么”记忆决定了机器人“记住什么”推理和规划决定了机器人“做出什么”。这三者缺一不可而记忆恰恰是最容易被新手跳过、却最能拉开体验差距的一环。 具身智能Agent Memory：从记忆分层到长程任务规划的工程实现
1. 这篇文章真正要解决的问题如果你做过机器人项目大概率遇到过这个场景机器人能准确识别出桌子上的杯子能规划出机械臂的抓取轨迹甚至能稳稳地把杯子端起来。但当你让它“把这几个杯子洗干净然后放到橱柜里再帮我泡一杯咖啡”时它就露馅了——洗到第二个杯子时忘了第一个放在哪厨房和客厅是两个空间它不知道咖啡粉放在哪个抽屉中途有人打断了一下它干脆不知道接下来要干什么。问题不在感知也不在控制。感知已经有了视觉语言模型和各类传感器控制已经有了成熟的轨迹规划算法。真正卡住机器人的是两件事一是“在物理世界里做推理”二是“把做过的事、看到的东西记住”。前者叫具身推理后者就是 Agent Memory。这篇文章想讲清楚几件事具身智能为什么需要“推理”而不是简单的“感知-执行”长程任务规划为什么绕不开记忆记忆在具身智能里到底长什么样和普通人理解的“缓存”有什么区别工程上怎么把记忆接入一个具身智能 Agent包括用 Redis、向量数据库做记忆存储的轻量实现实际项目中常见的坑和建议。如果你正在入门具身智能或者在做 Agent 类应用觉得“模型能力够了但落地效果很差”那这篇文章大概率能帮上忙。建议收藏备用尤其是第 6 节的工程实现和第 7 节的排查清单。2. 具身智能的基础概念感知、推理、规划、执行、记忆先把概念对齐后面才不会乱。2.1 具身智能具身智能Embodied Intelligence不是一个新的学科而是一种研究范式。它的核心观点是智能不能只存在于“大脑”里必须有一个物理身体去感知环境、执行动作并在交互中不断学习。扫地机器人是最朴素的具身智能人形机器人是更复杂的具身智能机械臂移动底盘也是。和纯语言模型相比具身智能多了一个“物理世界约束”物体有重量、有位置、会碎、会倒机器人在空间里有朝向、有可达范围、有电量限制。这些约束让“推理”变得必要。2.2 具身推理具身推理Embodied Reasoning可以通俗理解为让机器人在物理场景中做判断。传统物体识别回答的是“这是什么”具身推理回答的是“这个东西能做什么”“它现在在哪里”“我能不能拿到它”“拿了之后会发生什么”。比如看到地上有把椅子具身推理要考虑的是椅子当前是不是挡路了我能不能绕过它如果不能绕能不能推开它推的时候会不会碰到旁边的花瓶这种推理依赖多模态信息视觉、深度、触觉、位置甚至常识知识。比如“杯子通常是放在桌上的”“易碎品要轻拿轻放”这些常识不来自视觉传感器而是来自语义知识。2.3 Agent MemoryAgent Memory 就是智能体Agent的记忆系统负责保存任务状态、环境信息、历史经验、技能知识并在合适的时机取出来使用。很多开发者第一次接触 Agent Memory 是在大语言模型应用里解决“模型没有记忆”的问题。但在具身智能里记忆的形态更复杂因为它不再只是“对话上下文”还要包含空间地图、物体位置、任务进度、操作经验等多模态数据。2.4 传统方案和具身智能 Agent 的差异维度传统机器人具身智能 Agent任务定义人工编写流程固定步骤自然语言指令自动拆解感知传感器规则视觉语言模型多模态融合规划状态机、行为树大模型推理长程任务规划环境应对靠预设条件分支实时推理记忆回退知识来源人工写死的参数预训练知识在线记忆积累很多人把具身智能当成“机器人换了个大脑”但真正的变化是整个架构从“预编程”转向“自主推理”。而自主推理一旦面对真实环境就必须有记忆。3. 长程任务规划为什么难从“感知-执行”到“感知-推理-规划-执行”长程任务规划Long-Horizon Task Planning是具身智能里使用频率很高的一个词。它的意思是让机器人完成一个包含多个子步骤、跨越较长时间和空间的任务。举一个典型的“长程”例子把客厅收拾干净然后把脏衣服放进洗衣机再帮我把阳台上的花浇了。这个任务包含至少三个子任务每个子任务又有自己的步骤。“收拾干净”本身是模糊的需要推理出哪些东西算“脏乱”、应该放到哪里“把脏衣服放进洗衣机”需要先找到脏衣服、走到洗衣机前、打开盖子、放进去“浇花”需要找到水壶、接水、走到阳台、浇灌。这种任务为什么难有四个原因3.1 步骤数量大规划空间膨胀一个长任务往往有几十个甚至上百个原子动作。如果全部用人工规则穷举几乎不可能覆盖所有情况。行为树和状态机只能处理“预期内”的分支遇到一个没见过的场景系统直接不知道下一步怎么办。3.2 环境是部分可观察的机器人在某一时刻只能感知到当前视角内的信息。它看不到客厅全貌更看不到厨房柜子里的东西。要做出正确的长期规划它必须依赖“之前看过什么”也就是记忆。比如它必须记得“刚才在茶几上看到过遥控器”才能规划出“走到茶几旁拿遥控器”。3.3 意外和中断让规划失效真实环境充满意外门是关的、物体被挡住了、有人经过打断了导航。机器人需要能够“回退”到之前的某个状态重新规划。没有记忆它只能从头开始有记忆它至少知道“已经完成了哪几步还剩哪几步”。3.4 常识推理负担重“把脏衣服放进洗衣机”看起来简单但机器人需要知道脏衣服在洗衣篮里洗衣机在卫生间打开盖子之前要先把盖子按一下衣服不能塞太满不同颜色可能要分开洗。这些知识如果全部写死在代码里换一个家庭场景就全失效。大语言模型和视觉语言模型的介入解决了一部分常识推理的问题。模型见过大量“如何做家务”的语料知道任务的抽象流程。但模型本身没有记忆能力上下文窗口有限无法直接感知物理环境的变化。所以长程任务可行的路径是感知层负责看推理层负责想记忆层负责记规划层负责排执行层负责做。记忆位于中间承上启下是整个链路里最容易被忽视、却最关键的一环。4. 具身智能的记忆架构先分层再实现谈到 Agent Memory 的工程实现有一个最常见的误区把记忆当成一个大号的键值存储。实际上具身智能的记忆需要分层设计不同层承担不同职责。认知科学里有一个经典框架把记忆分成感觉记忆、工作记忆、长期记忆。工程上可以进一步简化成四层4.1 工作记忆当前任务的“便签纸”工作记忆保存的是当前任务立即需要使用的信息。比如当前正在执行第几步、手里拿的是什么物体、目标位置在哪里。它的特点是容量小、更新频繁、实时性要求高。在工程上工作记忆可以放在 Redis 等高速存储里设置过期时间。任务结束时工作记忆要么被清除要么提炼成长期记忆沉淀下来。4.2 情景记忆过去发生过什么情景记忆记录的是机器人过去的“经历”。比如上次任务中遥控器是在茶几上找到的上次擦桌子时抹布在厨房水槽旁边。这类记忆适合用向量数据库存储因为它需要按“语义相似度”检索。比如任务说“找一个能擦桌子的东西”机器人可以从情景记忆里检索出“上次用过抹布”这个经验。4.3 语义记忆世界是什么样的语义记忆保存的是相对稳定的知识杯子是易碎品、沙发是坐的、衣柜在卧室里。这些知识一部分来自预训练模型一部分来自长期积累。语义记忆不一定需要实时更新但需要和情景记忆联动。当模型的知识和机器人的实际观察冲突时通常以实际观察为准同时记录冲突。4.4 程序性记忆怎么做一件事程序性记忆对应的是“技能”。比如怎么抓取一个圆柱体、怎么绕过障碍物导航、怎么打开一扇门。这类记忆可以是策略网络、轨迹模板也可以是文本化的操作步骤。在工程实现中程序性记忆通常不是一个存储结构而是一个技能库由任务规划器按需调用。记忆类型核心问题典型内容工程载体工作记忆当前正在做什么任务步骤、物体 ID、状态Redis、内存对象情景记忆过去发生过什么任务经历、环境观察向量数据库语义记忆世界是什么样的常识、概念、空间拓扑向量库、知识图谱程序性记忆怎么做一件事技能、策略、轨迹技能库、模型权重这套分层设计的核心思想是不同类型的记忆有不同的读写频率和访问模式不能混在一个存储里。短期状态用快速存储长期经验用检索式存储技能和其他满足“不常变但需要随时调用”的需要独立管理。5. 记忆如何参与长程任务规划一个收拾客厅的例子理论说再多不如跟着一个例子走一遍。假设我们有一个移动机械臂机器人任务是把客厅里散落的杯子收集到厨房水槽然后把茶几擦干净。我们来拆解一下记忆在这个过程中的作用。5.1 任务开始写入工作记忆机器人收到任务后规划器把任务拆解为若干子步骤步骤1在客厅中搜索目标物体杯子 步骤2移动到目标物体位置 步骤3抓取杯子并放入收纳筐 步骤4移动到厨房水槽放下杯子 步骤5回到客厅找到抹布 步骤6擦拭茶几这些步骤会写入工作记忆。同时机器人开始“观察客厅”感知到三个杯子分别在茶几、书架、电视柜上。这个观察结果也写进工作记忆。5.2 执行中的选择性更新机器人先走到茶几抓取杯子放进收纳筐。此时工作记忆需要更新已完成步骤1茶几上的杯子步骤2步骤3 待完成收集书架上的杯子、电视柜上的杯子注意这里没有把所有信息都倒进一个“坐标系”里而是只记录了任务进度和当前状态。这叫“最小记忆原则”避免状态空间爆炸。5.3 遇到意外从记忆中回退机器人走到书架前发现杯子被一本书压住了。直接抓取可能会失败。这时具身推理开始工作推理书本压住杯子需要先移开书本查询语义记忆书本是轻物可以用机械臂推扫规划新增子步骤“移开书本”执行完成移开再抓取杯子更新把“书本压住杯子”这件事写入情景记忆作为本次任务的经验。这个过程中记忆让机器人不需要从零开始重新规划而是在已有状态基础上做局部调整。这是长程任务和短程任务最本质的区别。5.4 任务完成提炼长期经验所有杯子都放到水槽后机器人继续完成擦桌子。任务结束后工作记忆清空但情景记忆会写入一条摘要“客厅杯子通常出现在茶几、书架、电视柜日常摆放位置不固定茶几上可能有书本压物风险。”下次执行类似任务时机器人可以优先去这几个位置搜索杯子并且提前做好需要移开杂物的准备。5.5 从例子中提炼出的核心模式记忆在长程任务规划中的使用模式其实是一个闭环读取记忆 - 规划动作 - 执行动作 - 观察变化 - 更新记忆 - 再规划这个闭环直接决定了机器人是一个“每次开工都像第一天上班的新员工”还是一个“越用越熟练的老员工”。6. 工程落地Agent Memory 的轻量实现概念讲清楚之后很多读者会问那代码到底怎么写这一节给出一个可以改造成实际项目的轻量实现核心是四个部分记忆接口设计基于 Redis 的工作记忆实现基于向量数据库的长期记忆实现主循环集成。说明下面代码主要用于演示思路依赖库版本请以实际项目为准。生产环境中需要替换成项目实际使用的框架和模型接口。6.1 记忆管理接口设计先定义一个通用的记忆接口屏蔽底层存储差异。文件路径memory/base.pyfrom abc import ABC, abstractmethod from typing import Any, Dict, List, Optional class Memory(ABC): 记忆模块统一接口。 abstractmethod def write(self, key: str, value: Any, **kwargs) - None: 写入一条记忆。 ... abstractmethod def read(self, key: str) - Optional[Any]: 按 key 读取一条记忆。 ... abstractmethod def search(self, query: str, top_k: int 5, **kwargs) - List[Dict[str, Any]]: 按语义检索记忆返回记忆片段列表。 ... abstractmethod def delete(self, key: str) - None: 删除一条记忆。 ... abstractmethod def clear(self) - None: 清空该层记忆。 ...这个接口把“短期工作记忆”和“长期情景记忆”统一成一个抽象层上层规划器只依赖接口不关心底层是 Redis 还是向量数据库。新增一种存储实现只需要继承这个基类。6.2 用 Redis 实现工作记忆工作记忆的特点是高吞吐、短生命周期、支持过期。Redis 天然适合。文件路径memory/work_memory.pyimport json import redis class WorkMemory: 基于 Redis 的工作记忆实现。 每条记录设置过期时间避免状态无限堆积。 def __init__(self, host: str localhost, port: int 6379, db: int 0): self.client redis.Redis(hosthost, portport, dbdb, decode_responsesTrue) def write(self, key: str, value: dict, expire_seconds: int 600) - None: self.client.set(fwork:{key}, json.dumps(value, ensure_asciiFalse), exexpire_seconds) def read(self, key: str) - dict | None: raw self.client.get(fwork:{key}) if raw is None: return None return json.loads(raw) def delete(self, key: str) - None: self.client.delete(fwork:{key}) def clear(self) - None: keys self.client.keys(work:*) if keys: self.client.delete(*keys)为什么用 Redis 做工作记忆读写都在内存中时延低支持过期时间适合“任务结束就遗忘”的短期状态数据结构简单不需要复杂查询生产环境可以开启持久化避免机器人掉电丢失全部状态。注意事项开发时可以关闭持久化生产环境建议开启 RDB 或 AOF并确认 Redis 的高可用方案。6.3 用向量数据库实现长期情景记忆长期记忆需要支持“语义相似度检索”适合用向量数据库。这里以 Chroma 为例代码是示意写法实际 API 请以你安装的版本为准。文件路径memory/episodic_memory.pyfrom typing import Dict, List class EpisodicMemory: 基于向量数据库的长期情景记忆实现。 向量数据库负责把自然语言记忆片段转成向量 按语义相似度检索历史经验。 def __init__(self, collection_name: str episodic_memory): # 这里用伪代码示意不同版本 API 有差异 import chromadb self.client chromadb.Client() self.collection self.client.get_or_create_collection(collection_name) def add_memory(self, memory_id: str, text: str, metadata: Dict) - None: self.collection.upsert( ids[memory_id], documents[text], metadatas[metadata], ) def search(self, query: str, top_k: int 5) - List[Dict]: result self.collection.query( query_texts[query], n_resultstop_k, ) # 结果结构以当前安装的版本为准 return result.get(documents, [[]])[0] def delete(self, memory_id: str) - None: self.collection.delete(ids[memory_id]) def clear(self) - None: self.client.delete_collection(self.collection.name)核心点在于写入长期记忆时不只是写入一段文本还带上元数据时间、任务类型、成功与否检索时查询语句要尽量写得像一个“经验问题”例如“上次在客厅找杯子时有什么发现”效果会好于单纯检索“杯子”长期记忆里的条目应该有去重和淘汰策略不能无限增长。6.4 主循环集成示例有了两个记忆模块后把它们接入一个最小化的具身智能 Agent 主循环。文件路径agent/embodied_agent.pyclass EmbodiedAgent: def __init__(self, work_memory, episodic_memory): self.work_memory work_memory self.episodic_memory episodic_memory self.plan [] def build_plan(self, task: str): 根据任务和历史经验生成规划。 # 1. 检索历史经验 related_experience self.episodic_memory.search( queryf执行任务 {task} 时有哪些经验, top_k3, ) # 2. 把经验拼进 prompt交给规划模型生成步骤 prompt self._build_planning_prompt(task, related_experience) self.plan self._call_planner(prompt) # 3. 把整段规划写入工作记忆 self.work_memory.write(current_plan, {task: task, steps: self.plan}) def execute_step(self, step_index: int): 执行规划中的某一步。 step self.plan[step_index] # 调用底层感知、推理、控制模块 observation self._execute_action(step) # 更新工作记忆 self.work_memory.write(current_state, { step_index: step_index, step: step, observation: observation, }) return observation def recover_from_failure(self, failed_step_index: int): 从失败中恢复读取记忆调整计划。 state self.work_memory.read(current_state) history self.episodic_memory.search( queryf步骤 {self.plan[failed_step_index]} 执行失败如何恢复, top_k3, ) # 把当前状态和历史经验一起送给规划模型重新生成剩余步骤 self.plan self._repair_plan(state, history) def _execute_action(self, step): # 实际项目这里会调用视觉模型、路径规划和控制指令 return {status: ok} def _call_planner(self, prompt): # 实际项目这里会调用 LLM 或 VLM 接口 return [找到杯子, 抓起杯子, 放进水槽]这个主循环对应了第 5 节提到的记忆闭环先检索经验再规划执行过程中用工作记忆维护状态遇到失败时结合状态和长期记忆重新规划。这是目前社区里实现长程任务常用的基础结构。7. 常见问题与排查方法工程上接入 Agent Memory 之后暴露出来的问题往往不是“记忆存不进去”而是“记忆读不出来的不对”。下面列出几个高频问题。问题现象可能原因排查方式解决方案检索结果和当前任务无关长期记忆中噪音太多检索相似度阈值过低打印检索结果检查向量相似度分数增加元数据过滤提高阈值写入时做重要性筛选工作记忆频繁丢失Redis 缓存过期时间太短或未开启持久化查看 Redis 的expire配置和日志根据任务时长设置合理的 TTL生产环境开启持久化任务中断后无法恢复没有在失败时读取工作记忆和长期记忆检查recover_from_failure分支是否被触发明确失败检测逻辑把记忆读取放到异常处理入口同一任务出现互相冲突的记忆新旧经验优先级不明确检查记忆写入时的元数据是否记录了时间和任务ID检索时按时间排序相同场景以最新经验为准上下文窗口溢出把过多记忆片段一股脑塞进模型 prompt统计单次注入的 token 数量对检索结果做截断、摘要采用 RAG 的经典策略多机器人共享记忆导致混乱没有区分记忆的所有者检查记忆记录的元数据是否包含机器人 ID写入时加机器人 ID、场景 ID、任务 ID 等身份字段除了表格里的问题还有一个容易被忽视的坑记忆的写入时机。如果每一步执行完都往长期记忆里写一条长期记忆很快就会充满低价值信息。更合理的策略是关键节点写摘要异常事件写详细记录常规执行只更新工作记忆。8. 最佳实践与工程建议8.1 记忆分层不要混存坚持“工作记忆走 Redis、长期记忆走向量库、技能单独管理”的分层原则。短期状态混进向量库会导致检索噪音居高不下长期知识混进 Redis 又会导致内存爆掉。分层之后每层可以独立扩展也方便排查问题。8.2 用元数据支撑筛选长期记忆不能只存文本。每一条记忆至少包含记忆类型情景经验 / 环境知识 / 任务状态时间戳写入时间来源哪个任务、哪个机器人重要度是否属于异常事件或关键经验。有了这些字段检索时可以先用元数据过滤再做向量相似度排序能显著提高准确率。8.3 设计记忆清理策略记忆不是越多越好尤其是在物理机器人上。建议设计三类清理策略过期清理工作记忆必须有 TTL任务结束或超时后清除去重合并检索到相似度极高的两条记忆时自动合并成新条目并删除旧条目重要性淘汰当长期记忆超过容量上限时优先删除重要度低、时间久远、没有带来过成功经验的历史记录。8.4 提升可观测性记忆系统是最容易“黑盒化”的部分。建议在开发阶段就把每一次记忆读写都记录下来至少包括写入内容摘要检索 query 和 top_k 结果相似度分数最终被模型采纳了哪些记忆片段。没有可观测性你很难判断一个长程任务失败是因为模型推理能力不够还是记忆检索给错了素材。8.5 注意数据安全与隐私具身智能机器人会在真实家庭或办公环境中运行记忆里可能包含房间布局、物品照片、人员的活动轨迹等敏感数据。工程上要注意敏感信息脱敏后再写入长期记忆记忆数据加密存储多用户场景下做访问控制机器人不能无条件共享所有人的家庭经验需要支持用户主动清除历史记忆。8.6 评测要从长程任务出发不建议只评测“单步成功率高不高”而是设计端到端的长程任务评测指标比如任务完成率平均完成时间中断发生率与恢复成功率重复犯错的频率同一个坑踩了两次。这些指标才能真正反映记忆和推理模块的水平。9. 总结与后续学习方向具身智能正在从“能看会动”走向“能想会记”。具身推理让机器人能在物理世界里做判断Agent Memory 让这些判断可以跨时间、跨任务被复用二者共同支撑起长程任务规划。没有记忆的机器人每次开工都像第一天上班有了记忆它才可能越用越熟练。从工程角度看我给入门的读者的建议是先不要碰复杂的大模型设计先在一个仿真环境里把“读取记忆 - 规划 - 执行 - 更新记忆”这个闭环跑通工作记忆用 Redis长期记忆用向量库先用最主流的开源工具不要一开始就搭一套复杂的知识图谱找一个长程任务场景比如收拾客厅、做一顿简餐、仓库取货把任务拆细逐个记录记忆读写日志关注社区里的认知架构类工作例如如何把记忆分层和动作技能库统一管理以及记忆回放、记忆压缩这类新技术。具身智能是一个跨度很大的领域感知、控制、规划、记忆每个方向都能深挖很久。但如果你已经在这条路上请一定记住感知决定了机器人“看到什么”记忆决定了机器人“记住什么”推理和规划决定了机器人“做出什么”。这三者缺一不可而记忆恰恰是最容易被新手跳过、却最能拉开体验差距的一环。