在这里插入图片描述

文章目录

上一节课，你已经掌握了自定义Skill开发的基础——从脚手架创建到TypeScript实现，从参数校验到本地测试，还亲手完成了一个能用的货币汇率转换技能。

但你可能遇到了一连串的新问题：每次调用API都要重新获取，能不能把结果缓存起来？用户问“这次转换和上次的汇率有什么区别”——跨会话的数据该怎么记住？API Key明文写在代码里，会不会被恶意Skill偷走？对方服务偶尔宕机，整个对话中断了怎么办？

如果这些问题没解决，你的Skill永远停留在“技术Demo”阶段——能用，但不够可靠、不够安全、不够聪明。本节课将系统解决这四座大山：状态持久化让Skill有记忆，外部API调用遵循规范化范式，密钥安全存储为敏感凭证筑起专业防线，异常处理与重试策略让Skill从“一次成功就成功、失败就彻底没戏”升级为“遇到问题自动恢复”。

最后，我们将用“天气查询+主动推送”这一贴近真实生产需求的技能串联所有知识点——它支持缓存天气结果减少API消耗，能从对话中记住用户的城市偏好，在未来某一天推送长期天气预报。

17.1 技能中的状态持久化机制

一句话概括：OpenClaw默认不支持Skill内建持久化存储，需要Skill开发者自行实现状态保存——标准的解决路径包括调用Agent Memory API写入MEMORY.md和Daily Logs、利用Skill自带的文件系统读写，或通过Skill SDK/插件集成外部数据库实现跨会话状态共享。

在第9课中，我们已经系统学习了OpenClaw的三级记忆存储体系。当时关注的是User→Agent方向的记忆——用户告诉Agent的信息如何被跨会话记住。现在，我们要解决的是相反方向：Skill执行过程中产生的中间数据，如何在多次调用之间持续存在。

OpenClaw的“文件优先”哲学为什么会影响Skill状态？

OpenClaw的记忆系统采用“文件优先（File-First）”与“本地优先（Local-First）”的分层架构，通过Markdown文档作为唯一的“事实来源（Source of Truth）”。这种设计为用户数据提供了极好的可审计性和可迁移性，但也带来了一个显而易见的后果：OpenClaw官方没有提供内置的Skill状态存储API——这不是框架缺陷，而是设计哲学的必然延伸。

这意味着Skill开发者必须自己决定把“这次缓存了汇率数据”“上次查询的城市是北京”这类跨会话信息放在哪里。这是个Feature，不是Bug：不同的Skill对状态存储的需求差异太大——汇率转换的缓存几分钟就能过时，用户的城市偏好需要记住几个月，自定义仪表板的配置最好用独立的JSON文件管理。一刀切的内置方案反而会限制灵活度。

三种经过实战检验的持久化方案

方案一：调用Agent Memory API（推荐用于需要长期保留的用户偏好）

这是最贴合OpenClaw原生设计理念的方式。Agent通过内置的memory_search和memory_get工具读取记忆，通过write工具写入MEMORY.md和Daily Logs。

当你开发一个天气查询技能时，用户说“我喜欢看摄氏度的温度，不要华氏度”，Agent可以通过在MEMORY.md中追加一条记录来记住这个偏好。关键约束在于：必须在AGENTS.md中明确指导Agent将重要信息写入MEMORY.md——不是口头告诉AI，而是在配置文件里用“Memory Rules”强制规定。

基于Markdown文件的默认方案确实会面临扩展瓶颈：文档体量过大时，文本分块检索效率会降低，且缺乏对事实动态更新的识别能力（如用户从“住在北京”变成“住在上海”）。对于轻量级状态（偏好、最近查询记录），Markdown方案完全够用。

方案二：直接读写Skill目录下的文件

这是最直接的实现方式。在Skill目录下创建.cache.json或.state.json文件，用Node.js的fs模块读写。这种方式代码直观，调试方便，尤其适合存储与Skill本身强耦合的内部状态（如API速率限制器的计数、临时缓存）。

方案三：集成外部数据库（适合企业级Skill）

当Skill需要支持多用户、需要毫秒级检索、需要自动更新冲突消解能力时，基于文件的方案就捉襟见肘了。PolarDB Mem0提供了一套“自我演进”的记忆逻辑——能够从对话中提取、更新并固化事实（Facts），而非简单的文本切分。核心优势包括智能事实演进（自动更新与冲突消解）、海量毫秒级检索（依托云原生分布式架构）和跨端全局同步。

最佳实践：状态分层管理

状态类型 存储位置 更新时间 示例
跨会话长期偏好 MEMORY.md（Agent Memory） 用户明确改变时 “我喜欢摄氏度”、“默认城市”
短期会话上下文 会话转录（Daily Logs） 每次会话 “刚才看到的那个天气”
Skill内部缓存 Skill目录JSON文件 按需更新 API响应缓存、速率限制计数
企业级共享事实 PolarDB / Mem0 自动演进 跨设备/跨Agent的用户画像

避坑指南：不要把临时凭证（API Key、Token）写进任何持久化文件，无论文件是明文还是“看似加密”的SQLite。此类内容只能通过环境变量注入或专用密钥管理服务存储。同时，在AGENTS.md的Memory Rules中声明状态写入策略，确保Agent在必要时主动保存。

17.2 跨会话数据的读取与写入

一句话概括：跨会话数据共享的实质是让不同对话窗口中的Agent访问同一份持久化存储——这可以通过Agent Memory的自然流动、Skill SDK的显式读写以及多用户维度隔离三套独立路径来实现，它们互不冲突、各有侧重。

路径一：通过Agent Memory让状态“自然流动”

当用户在一个会话中告诉Agent“我喜欢摄氏度，不喜欢华氏度”，Agent通过write操作将这条信息追加到MEMORY.md。下一次会话启动时，系统会自动加载MEMORY.md。从Skill的角度看，这意味着代码不需要改变——Skill只需正常读取用户输入，Agent会在系统层面自动注入记忆。

但有一个重要的时序细节：MEMORY.md的写入不会自动触发。开发者必须在AGENTS.md中明确写入行为。例如：

## Memory Rules
- 用户明确说"记住我偏好摄氏度"时，更新MEMORY.md

用清晰、可执行的指令告诉Agent何时该动手写入，而不是指望它“学到”这种行为模式。

路径二：通过Skill SDK显式读写

Skill Action通过context对象获得memory服务，可以主动查询和写入记忆。这种方式适用于Skill需要主动检索跨会话信息、而不依赖Agent自动加载的场景。

同理，Skill在完成某项关键操作后，无需等待下一次会话，可以立即调用memory.update强制刷新持久化缓存。

路径三：用户级与Skill级数据的隔离策略

Skill处理跨会话数据时必须考虑多用户场景。区分两种隔离策略：

策略 适用场景 典型实现
用户级数据 每个用户的独立偏好 在数据中存储userId字段，读取时过滤
Skill级数据 全用户共享的全局缓存 全局缓存文件，不区分用户

多用户场景下，必须在数据写入时清楚地标记来源。若一个天气查询Skill将用户A的“偏好摄氏度”存储为全局配置，会导致用户B得到错误的结果。

理解“跨会话”的含义

跨会话不等于“各个Skill之间随意互通”，而是在多次用户交互中保持对核心数据的一致访问。如果多个Skill需共享同一份数据，将数据放在统一的共享目录或专用数据库中，而非各自维护独立副本。多个Skill同时读写时，还需要额外的锁或事务机制来保证一致性——简单的文件覆盖就可能造成数据丢失。

17.3 调用外部HTTP API的标准范式

一句话概括：OpenClaw Skill调用外部API的最佳实践包括五个标准化动作——判断适合哪个内置Tool、定义清晰的参数Schema、实现优雅降级的错误处理、设计可感知的速率限制并强制使用超时中断，缺一不可。

第一步：判断该用哪个内置Tool

构建对外API调用的Skill时，首先判断是让Agent使用OpenClaw内置的通用HTTP工具有效，还是自己实现专用HTTP调用。如果API需要复杂的认证流程、二进制数据或特定的Header组合，自己实现更稳妥。

OpenClaw有两套能力可供“借用”，因此开发者无需在每个Skill中重写Fetch逻辑：

  • web_fetch：内置的轻量HTTP GET，自带内容提取和重定向处理，适合静态或半动态页面的大批量提取。
  • Playwright Skill：用于需要JavaScript渲染的页面，支持简单模式与隐身反爬模式。

第二步：参数定义与客户端配置

调用外部API时需要定义清晰的请求参数，并通过参数校验确保调用安全。Skill SDK的SkillAction允许声明参数Schema，包括枚举值、默认值和安全校验。

第三步：实现优雅降级

当API因为网络抖动、认证失败或配额不足而返回错误时，应保留上一次成功获取的数据作为缓存，确保Agent不因为某次API调用瞬间失败而整体罢工。

async function fetchWeatherWithFallback(location: string) {
  try {
    const fresh = await fetchFromAPI(location);
    await cacheWeather(location, fresh);  // 更新缓存
    return fresh;
  } catch (error) {
    const cached = await getCachedWeather(location);
    if (cached) {
      console.warn(`API调用失败，使用上次缓存: ${error.message}`);
      return { ...cached, fromCache: true };
    }
    throw error;
  }
}

第四步：实现速率感知

Rate Limit（速率限制）可能在任何时候出现。实现一个令牌桶算法或滑动窗口计数器、确保请求频率在限制范围内，是生产级API集成的基础素养。跟踪”剩余限额（x-ratelimit-remaining）并在接近归零时主动降级或暂停调用，是负责任的API消费者行为。

第五步：设置超时中断

网络请求不是无限的。Skill必须在合理时间内得到响应，否则应中断操作并向用户报告超时。避免在Skill Action内部长时间挂起使整个对话卡住。

第六步：通用与实践的平衡

OpenClaw的工具调用难题在于：“API怎么连”不是问题，“连完以后怎么不乱”才是。编写Skill时，需要规划调用顺序、边界条件和失败处理，工具越多，代理的行为越复杂。清晰的编排逻辑本身就是对API生态负责。

17.4 API密钥的安全存储与加密

一句话概括：OpenClaw的密钥管理在个人场景可以保持现状，但在多用户生产环境中必须升级到三层防护——从明文的.env文件迁移到系统密钥链，再配合独立的加密Vault（如Vault-0的AES-256-GCM+Argon2id方案），实现分权管理和审计追溯。

当前状态：所有人都知道但很多人不愿面对的现实

OpenClaw默认将API密钥和Bot令牌存储在明文文件中——在.env文件或openclaw.json中，几乎所有API密钥静静躺着，可被任意进程读取。2026年2月的ClawHavoc恶意技能事件清晰地呈现了这个现实：攻击者在ClawHub上发布了超过800个恶意技能，专门从配置文件中窃取明文凭证。

威胁模型：密钥是如何泄露的？

安全分析揭示了多种真实的泄露途径：

  1. Git提交：~/.openclaw/被误提交到仓库，即使私有仓库也可能因权限配置错误而暴露
  2. 备份归档：未加密的tar包一旦被上传到云存储，里面所有的Token都暴露了
  3. 调试日志：启动Gateway时的Debug日志可能将环境变量解析内容写入日志文件
  4. MEMORY.md意外写入：Prompt注入攻击可能诱使Agent将配置中的Token写入记忆文件
  5. 世界可读文件：多用户服务器上Linux安装可能留下777或755权限，任何用户都能读取

分层防护方案

经过社区验证的推荐方案分为三个层级：

Level 1：从明文到环境变量（最低要求）

# 在 ~/.openclaw/.env 中存储
WEATHER_API_KEY=your_api_key_here
OPENAI_API_KEY=sk-...

在openclaw.json中使用${VAR}引用：

{
  "env": {
    "WEATHER_API_KEY": "${WEATHER_API_KEY}"
  }
}

环境变量的加载优先级是：进程环境 → 当前目录.env → ~/.openclaw/.env → 配置内联env。即使迁移到环境变量，明文密钥仍然存在于磁盘上。这只是第一道防线，不是最终解。

Level 2：操作系统密钥链集成（中等安全）

Secret Manager Skill利用GNOME Keyring和libsecret，确保敏感令牌永远不会以明文形式存储。然而，一旦凭证被解密，任何一个获得文件系统访问权限的Skill都可能读取它们。

Level 3：加密Vault + 短暂解密窗口（企业级最佳实践）

Vault-0方案提供了一套更完整的解决方案：密钥使用AES-256-GCM算法加密存储，通过Argon2id密钥派生函数从用户主密码推导出加密密钥。当Agent启动时，Vault-0解密内存中的密钥，写入一个临时.env文件，OpenClaw守护进程读取后立即将文件内容清零——密钥存在磁盘上的时间窗口只有大约2秒。

分权管理是根本出路

Auth0的安全分析指出，密钥管理问题的根本原因不在于加密，而在于OpenClaw代理层缺少OAuth式的委托模型——所有Skill读取同一个明文文件，没有作用域、没有按Skill划分的权限边界。你无法告诉系统“这个Skill可以读取天气API，但不能发送邮件”。根本性的修复需要框架层面的委托模型变革。在此之前，Skill开发者只能在Skill层面缩小攻击面。

17.5 异常处理与重试策略设计

一句话概括：OpenClaw推荐在Skill层面实现三层韧性网络——为自身感知的临时故障实现指数退避重试，依靠Gateway内置的自动故障转移处理模型认证层故障，并保留终止路径防止无限循环——三条防线分工协作，缺一不可。

第一层：Skill层的重试策略（感知网络故障）

网络请求的性质决定了失败是常态而非异常。为Skill添加指数退避重试机制是衡量Skill成熟度的指标之一。

OpenClaw官方文档明确了内置的Retry Policy标准：重试触发条件包括瞬态错误（429、超时、连接重置/关闭、临时不可用）；优先使用服务端返回的retry_after，否则使用指数退避算法；最大延迟上限30000ms，Jitter 0.1（10%）。Skill应遵循这一标准，而非实现完全不同的重试逻辑。

实现原则：

  • 只重试应该重试的错误（5xx、网络中断、超时），绝不重试4xx（尤其是401、403）
  • 清晰记录每次重试，包含当前尝试次数和延迟时间
  • 累积一定次数仍失败后，必须优雅地放弃并向用户上报

第二层：Gateway层的自动故障转移（开发者免配置）

OpenClaw的核心运行时内置了多级故障恢复。runAgentTurnWithFallback函数负责模型认证层的故障处理：当检测到超时错误或上下文溢出时，自动轮换到下一个可用的认证配置文件或回退模型。这一层对Skill开发者完全透明，无需额外编码。

第三层：终止路径设计（防无限循环）

重试不是无限的。必须为Skill设置明确的终止条件，包括最大重试次数和超时上限。当超过限制后，向用户返回清晰的错误提示，并提供可能的补救建议（如“手动检查API Key是否过期”）。重试是为偶发故障准备的逃生通道，不是为持续性问题准备的解决方案。

异常处理清单

异常类型 OpenClaw原生行为 Skill额外处理建议
网络超时 Skill层自定义重试 指数退避重试，记录到日志
API返回429 遵循retry_after 在SKILL.md中要求设置x-ratelimit-remaining监控
认证失败401/403 不自动重试 提示用户检查API Key
数据格式异常 不重试 解析前做schema校验，失败时返回明确错误
上下文溢出 Gateway自动压缩/故障转移 免处理

17.6 异步任务与长耗时操作处理

一句话概括：OpenClaw Skill本质上在Agent执行循环中运行，其execute函数必须在合理时间内返回——对于需要等待外部响应的长耗时操作，推荐采用“快速返回确认 + 后续状态由Agent轮询”模式，而不是试图在单次请求中完成全部流程。

事实上，OpenClaw的执行设计中没有专门的“异步任务”通道，也没有内置的队列机制让Skill在后台“慢慢跑”。因为OpenClaw的Agent执行循环是基于Lane队列机制的同步模型——每次用户输入都会触发一次Agent运行，Skill必须在这一轮中完成操作或显式告知需要继续等待。

策略一：“快速返回+Agent轮询”

这是最符合当前OpenClaw执行模型的方式。当用户发起一个耗时操作时（如等待天气警报推送），Skill立即返回一个确认消息，同时在后台启动实际任务（通过系统进程、独立Promise或外部Webhook）。用户可以通过定期询问“任务完成了吗？”来触发Agent再次调用Skill检查进度。这种模式特别适合需要用户感知进度的场景。

策略二：Cron/Heartbeat定期执行（适合主动推送场景）

当Skill的功能是主动定期获取数据时（如每日天气推送），不应该在用户消息触发时执行，而应该使用第14课学到的Cron任务或Heartbeat机制来驱动。从Skill的实现角度看，这意味着Skill只需要暴露一个fetchLatestAndCheck的函数，由定时调度器按计划发起调用，而不是依赖用户的“催问”。Skill的职责可以保持纯粹：无论被谁调用，都做同一件事——获取最新数据和检查条件，然后返回通知。

策略三：拆分原子Skill

将长时间操作拆分为多个短动作组成的原子Skill。每个动作在Agent单轮执行中作为原子工具暴露，Agent执行循环可以按顺序调用；失败时能回滚到最近的成功状态，而不是让用户在“任务卡住了”的状态下不知所措。

长耗时操作的设计原则

原则 说明
确认先行 任何长耗时操作，Skill必须先返回“已收到请求，正在处理”
可查询性 提供状态查询接口，用户可以随时询问进度
超时声明 在SKILL.md中明示操作预计耗时范围，避免用户预期偏差
结果持久化 最终结果应写入用户可访问的存储（通知Channel或Memory文件），而不是只留在“运行现场”

17.7 实战：开发一个天气查询+推送技能

通过一个真实项目——天气查询与主动推送技能，将本节课的核心知识点串联起来。该Skill支持实时天气查询、城市偏好记忆和定时天气推送三大功能。

完整项目结构

weather-assistant/
├── SKILL.md
├── src/
│   └── index.ts
├── package.json
├── tsconfig.json
└── .env (本地测试用)

Step 1：SKILL.md定义

---
name: weather-assistant
description: 当用户询问天气、天气预报、温度查询时使用。支持记住用户偏好的城市和温度单位。
author: your-name
version: 1.0.0
license: MIT
user-invocable: true
metadata:
  openclaw:
    emoji: "🌤️"
    requires:
      env: ["WEATHER_API_KEY"]
---

# 天气预报助手

## 触发条件
当用户说"查天气""今天天气怎么样""需要带伞吗"时使用。

## 执行步骤
1. 识别用户提到的城市/地点，如未提及则从MEMORY.md读取"默认城市"
2. 识别温度单位偏好（摄氏度/华氏度），优先使用用户偏好
3. 调用实时天气API获取数据
4. 格式化结果并返回
5. 若用户明确说"记住我住在{城市}"，Agent需将城市写入MEMORY.md

## API配置
- 接口：`https://api.weatherapi.com/v1/current.json`
- 认证方式：`key`参数传递API Key（从环境变量WEATHER_API_KEY读取）

Step 2：TypeScript核心实现

import { SkillDefinition } from '@openclaw/skills-core';

// 缓存策略：简单内存缓存，5分钟有效期
let weatherCache: Map<string, { data: any; timestamp: number }> = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5分钟

// 指数退避重试函数
async function fetchWithRetry(url: string, maxRetries = 3): Promise<any> {
  let lastError: Error | null = null;
  
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      const controller = new AbortController();
      const timeoutId = setTimeout(() => controller.abort(), 10000); // 10秒超时
      
      const response = await fetch(url, { signal: controller.signal });
      clearTimeout(timeoutId);
      
      if (!response.ok) {
        // 401/403/429 不要自动重试所有错误
        if (response.status === 401 || response.status === 403) {
          throw new Error(`API认证失败：请检查WEATHER_API_KEY环境变量`);
        }
        if (response.status === 429) {
          // Rate limit - 等待后重试
          await new Promise(resolve => setTimeout(resolve, 2000 * attempt));
          continue;
        }
        throw new Error(`API返回错误: ${response.status}`);
      }
      
      return await response.json();
    } catch (error: any) {
      lastError = error;
      if (attempt < maxRetries) {
        // 指数退避：1s, 2s, 4s
        await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, attempt - 1)));
      }
    }
  }
  throw lastError;
}

// 从缓存或API获取天气
async function getWeather(location: string) {
  // 检查缓存
  const cached = weatherCache.get(location);
  if (cached && (Date.now() - cached.timestamp) < CACHE_TTL) {
    return { ...cached.data, fromCache: true };
  }
  
  // 调用API
  const apiKey = process.env.WEATHER_API_KEY;
  if (!apiKey) {
    throw new Error('WEATHER_API_KEY环境变量未配置');
  }
  
  const url = `https://api.weatherapi.com/v1/current.json?key=${apiKey}&q=${encodeURIComponent(location)}`;
  const data = await fetchWithRetry(url);
  
  // 更新缓存
  weatherCache.set(location, { data, timestamp: Date.now() });
  
  return { ...data, fromCache: false };
}

const weatherSkill: SkillDefinition = {
  id: "weather-assistant",
  name: "天气预报助手",
  description: "查询实时天气，支持记忆用户偏好城市",
  version: "1.0.0",
  
  parameters: {
    type: "object",
    properties: {
      location: { type: "string", description: "城市名称（如北京）" },
      unit: { type: "string", enum: ["celsius", "fahrenheit"], default: "celsius" }
    },
    required: ["location"]
  },
  
  execute: async (args, context) => {
    const location = args.location as string;
    const unit = (args.unit as string) || "celsius";
    
    try {
      const weatherData = await getWeather(location);
      const temp = unit === "celsius" 
        ? weatherData.current.temp_c 
        : weatherData.current.temp_f;
      const condition = weatherData.current.condition.text;
      const humidity = weatherData.current.humidity;
      
      const result = {
        success: true,
        data: {
          location: weatherData.location.name,
          temperature: temp,
          condition,
          humidity,
          unit,
          timestamp: new Date().toISOString(),
          fromCache: weatherData.fromCache
        },
        summary: `${location}当前天气：${temp}°${unit === "celsius" ? "C" : "F"}，${condition}，湿度${humidity}%`
      };
      
      // 记录调用日志（生产环境可发送到结构化日志系统）
      context.logger?.info("天气查询完成", { location, unit, fromCache: weatherData.fromCache });
      
      return result;
    } catch (error: any) {
      context.logger?.error("天气查询失败", { location, error: error.message });
      return {
        success: false,
        error: error.message
      };
    }
  }
};

export default weatherSkill;

Step 3：配置与测试

# 安装依赖并编译
npm install
npm run build

# 将技能链接到OpenClaw工作区
ln -s $(pwd) ~/.openclaw/workspace/skills/weather-assistant

# 配置环境变量
echo "WEATHER_API_KEY=your_api_key_here" >> ~/.openclaw/.env

# 重启Agent
openclaw gateway restart

# 测试查询
openclaw skills run weather-assistant --params '{"location":"上海"}'

Step 4：Cron定时推送集成

在HEARTBEAT.md中添加每日推送任务：

## 每日早晨7:30任务
- 读取MEMORY.md获取用户默认城市
- 调用weather-assistant技能查询当日天气
- 如果预测有雨，通过配置的Channel飞书推送“今日有雨，记得带伞”

配置完成后，Skill会自动在用户偏好的城市执行每日天气检查，达到阈值时主动通知。

17.8 本节小结

本节课完整覆盖了高阶Skill开发的四个核心支柱：

  • 状态持久化：基于OpenClaw“文件优先”哲学，Skill开发有三种可靠的持久化方案——Agent Memory（写入MEMORY.md/Daily Logs）、Skill目录下JSON文件自存储（适合轻量内部缓存）和外部数据库集成（PolarDB Mem0等企业级方案，支持事实演进和海量检索）

  • 外部API集成：标准范式包含五步——选择合适的内置Tool、定义清晰的参数Schema、实现优雅降级（缓存让API故障时不至于整体罢工）、设计速率感知（跟踪余额限制）、强制设置超时中断

  • 密钥安全存储：最短的生命周期路径——从明文.env到环境变量变量替换，再到GNOME Keyring操作系统密钥链集成，最后到Vault-0的AES-256-GCM+Argon2id加密临时窗口方案，层层递进、步步防渗

  • 异常处理和重试策略：三层韧性网络结构——Skill层实现指数退避重试（捕获网络层和API响应层错误），Gateway层的自动故障转移处理模型认证层故障，保留明确终止路径避免无限循环

  • 异步与长耗时操作：OpenClaw的执行模型中没有内置的后台任务通道，最佳实践是“快速返回确认响应 + Agent轮询进度”模式。严格区分Skill的触发时机——用户主动查询用对话触发，定期检查推送到Cron/Heartbeat调度器触发

实战中的天气查询+推送技能将这些知识点融为了一体——从API调用和缓存策略，到何时写入MEMORY.md、何时在HEARTBEAT.md中触发主动推送，再到用环境变量保管API Key，为高级Skill的开发提供了可复用的模板。

17.9 课后习题

1. 状态持久化实验

为16.6节的汇率转换技能添加跨会话缓存：用户首次查询后，“默认来源货币为USD”应被持久化到MEMORY.md。在之后的会话中，当用户只说“转换成CNY”时，Agent应默认使用USD作为来源货币进行转换。在代码实现和AGENTS.md的内存规则中各需要做什么修改？

2. 密钥安全管理实践

将天气查询Skill的API Key从硬编码改成通过~/.openclaw/.env注入。然后尝试安装Vault-0或Secret Manager Skill，将同一个密钥迁移到加密Vault中。记录两种方案在磁盘上留下密钥痕迹的时间差异，并说明为什么前者在共享服务器上不够安全。

3. 重试策略与降级设计

修改天气查询Skill的fetchWithRetry函数，实现以下增强：第一，区分网络错误和API 4xx错误（401/403不重试，直接返回建议用户检查API Key）；第二，添加“熔断”逻辑——连续失败5次后，后续1小时内直接走缓存模式，不再发起真实请求。测试你的实现能否正确识别不同的错误类型。

4. 跨会话记忆综合实现

假设一个用户在飞书上说“我住在北京，帮我查天气”，次日又在钉钉上说“我搬家到上海了”。要实现“第二天Agent自动在新会话中记住上海为新居住地”，需要在MEMORY.md的结构、AGENTS.md的Memory Rules以及天气Skill的代码逻辑上分别做哪些设计？写出关键配置片段和代码片段。

5. 轮询模式实现（选做）

设计一个“文件处理状态监控”Skill：用户触发“处理这个大文件”，Skill立即返回Processing started (job_id: abc123)；用户稍后问“处理完成了吗”，Skill查询后台状态并返回结果。你需要设计后台状态的存储方式和轮询查询逻辑。写出状态存储方案的核心伪代码。

🔗《30节课精通 OpenClaw》系列课程导航

去订阅

第一部分（第1-5课）：基础认知与入门部署——解决“这是什么、怎么搭建”的问题。
第二部分（第6-10课）：核心原理深度剖析——解决“底层怎么工作”的问题。
第三部分（第11-15课） ：应用场景与平台集成——解决“能用来做什么”的问题。
第四部分（第16-21课） ：技能开发与定制扩展——解决“如何自己扩能力”的问题。
第五部分（第22-26课）：高级特性与性能优化——解决“怎么用得更好”的问题。
第六部分（第27-30课） ：安全、运维与生态进阶——解决“如何安全可靠地规模化”的问题。

🌟 感谢您耐心阅读到这里！
💡 如果本文对您有所启发欢迎：
👍 点赞📌 收藏 📤 分享给更多需要的伙伴。
🗣️ 期待在评论区看到您的想法, 共同进步。
🔔 关注我，持续获取更多干货内容～
🤗 我们下篇文章见～

# 人工智能
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

工具调用管线断点续跑难题：状态机设计如何平衡开发与运维视角

avatar 龙虾开发者社区
cover

OpenClaw 生产可观测性实践：为什么我们最终选择分级 Trace 方案

avatar 龙虾开发者社区
cover

ClawOS 作为 Agent 宿主：不可变根文件系统下的风险隔离实践

avatar 龙虾开发者社区