Openclaw本地智能体运行时：从部署到自定义工作流实战

1. 项目概述：Openclaw不是“另一个AI工具”，而是本地化智能体工作流的底层引擎

Openclaw本地部署教程——这七个字背后，藏着当前AI工程落地最真实、也最被低估的一条技术路径。它不追求在网页端炫技式地调用某个大模型API，也不鼓吹“一键生成PPT”的消费级幻觉，而是直指一个硬核问题：如何让AI智能体真正扎根在你的物理机器上，像Excel或VS Code一样可控、可审计、可调试、可集成？我从2023年Q4开始深度跟进Openclaw项目，参与过三个企业级私有化部署案例，也踩过Windows服务注册失败、MacBook M系列芯片兼容性断层、Docker容器内GPU驱动不可见等典型坑。Openclaw的核心价值，从来不是“又一个能聊天的模型”，而是它把智能体（Agent）的规划（Planning）、工具调用（Tool Calling）、记忆管理（Memory）、状态持久化（State Persistence）这些原本分散在LangChain、LlamaIndex、AutoGen等框架中的能力，封装成一套轻量、模块化、可插拔的本地运行时环境。它默认不联网，所有推理、工具执行、文件读写都发生在本机；它不依赖云厂商的API密钥，规避了数据出域风险；它用YAML定义技能（Skill），用Python编写工具（Tool），对开发者友好度远超需要写大量胶水代码的传统方案。如果你正在评估“dify本地部署教程”“codex本地部署”“ollama部署本地大模型”这些关键词，那说明你已经意识到：真正的AI生产力，必须建立在“本地可控”这个地基之上。Openclaw正是为这个地基提供钢筋和混凝土的工程化方案。它适合三类人：一是企业IT管理员，需要将AI能力嵌入现有OA/ERP系统，要求审计日志完整、权限颗粒度细；二是独立开发者，想快速验证一个AI自动化流程（比如自动归档邮件附件+生成摘要+同步到Notion），拒绝被SaaS平台的功能墙限制；三是科研人员，需要在离线环境下复现实验、调试智能体决策链路，对每一步的输入输出、中间状态都有绝对掌控权。这不是一个玩具项目，它的设计哲学是“最小可行智能体运行时”（Minimal Viable Agent Runtime），所有功能都服务于一个目标：让AI智能体像一个本地服务进程一样，稳定、安静、可靠地为你工作。

2. Openclaw核心架构与本地化设计逻辑拆解

2.1 它为什么必须“本地”？——从架构根源理解部署必要性

Openclaw的“本地”属性，不是部署方式的选择题，而是其架构基因决定的必然结果。要真正理解为什么不能简单地把它当成一个Web应用去“部署到服务器”，必须拆开它的三层核心结构来看：

第一层是技能抽象层（Skill Abstraction Layer）。Openclaw不直接调用模型，而是通过Skill YAML文件定义“能力契约”。一个file_summary.yaml文件里，会明确声明输入参数（如file_path: str）、输出结构（如{"summary": "str", "keywords": ["str"]}）、所需工具（如- file_reader）、以及失败重试策略。这个YAML就是技能的“宪法”，它与具体模型解耦。这意味着，你在本地部署时，可以自由切换底层模型：用Ollama跑Qwen2-7B做摘要，用LM Studio加载Phi-3做代码分析，甚至用本地微调的LoRA权重。如果它是一个纯云端服务，这种模型热替换、本地模型权重调试就完全不可行。我曾在一个金融客户项目中，需要将敏感财报PDF的解析全程离线进行，Openclaw的Skill机制让我们只需修改YAML里的model_name字段，就能在不改动任何业务逻辑的前提下，把云端Claude调用切换为本地Ollama的Qwen2-7B，整个过程耗时不到5分钟。

第二层是工具执行沙箱（Tool Execution Sandbox）。Openclaw的每个Tool（工具）都是一个独立的Python函数，但关键在于它的执行环境。它默认在本地进程内启动一个受限的子进程（subprocess），并严格控制其可访问的文件路径、网络端口、环境变量。例如，一个send_email工具，在YAML里会配置allowed_hosts: ["smtp.company.internal"]和allowed_files: ["/tmp/email_attachments/"]。这种沙箱机制，只有在本地操作系统层面才能实现精细管控。放在公有云上，你无法阻止一个被注入恶意代码的Tool去读取整个服务器的/etc/shadow文件。我们曾用strace跟踪过Openclaw启动一个pandas_read_csv工具的过程，清晰看到它只打开了指定的CSV文件描述符，其他路径全部返回Permission denied。这种级别的隔离，是任何SaaS AI平台都无法提供的安全基线。

第三层是状态与记忆持久化（State & Memory Persistence）。Openclaw的智能体不是无状态的HTTP请求。它维护一个本地SQLite数据库（openclaw_state.db），存储每次会话的完整上下文、工具调用历史、中间缓存结果。更重要的是，它支持将长期记忆（Long-term Memory）序列化为本地JSON文件，并通过memory_backend: filesystem配置指向一个加密的本地目录。这意味着，一个用于法律合同审查的智能体，可以在数周内持续学习用户标注的“高风险条款”模式，而这些训练数据永远不会离开你的硬盘。对比Dify的“知识库”功能，后者虽然也支持上传文档，但其向量数据库（通常是Weaviate或Qdrant）默认部署在Dify服务容器内，数据物理位置仍受制于Dify自身的部署拓扑；而Openclaw的记忆文件，就是你电脑里一个带密码保护的.enc文件，你可以用gpg命令随时解密审计。这才是真正意义上的“数据主权”。

提示：Openclaw的“本地”不是指“只能在笔记本上跑”，而是指“计算、存储、控制平面三者合一”。它完全兼容在企业内网的物理服务器、VMware虚拟机、甚至群晖NAS的Docker环境中部署。只要满足硬件要求（见后文），它就是一个标准的、可管理的本地服务。

2.2 为什么不是Docker“一键部署”？——解析官方镜像的局限性与手动部署的不可替代性

搜索“openclaw本地docker部署教程”或“群晖 docker openclaw 下载哪个”，你会发现大量教程推荐拉取openclaw/openclaw:latest镜像。这看似省事，但在我经手的6个生产环境部署中，有4个最终都放弃了纯Docker方案，转而采用“Docker + 本地二进制混合部署”。原因很实在：Openclaw的核心价值点——对本地资源的深度控制——恰恰是标准Docker容器最难完美实现的。

Docker的默认安全模型是“隔离优先”，这与Openclaw“可控集成”的设计哲学存在天然张力。举几个真实案例：

• GPU加速困境：在Windows WSL2或MacBook M系列上，Docker Desktop对NVIDIA GPU或Apple Metal的直通支持极不稳定。我们曾为一个图像识别Skill配置nvidia/cuda:12.2.0-runtime-ubuntu22.04基础镜像，但在WSL2中，nvidia-smi命令始终返回NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver。最终解决方案是放弃容器，直接在WSL2的Ubuntu发行版中安装CUDA Toolkit 12.2，并用pip install openclaw[torch]安装带CUDA支持的Openclaw。实测下来，本地PyTorch推理速度比容器内快37%，且显存占用更稳定。

• 文件系统权限迷宫：Openclaw的Skill经常需要读写宿主机上的特定目录（如监控一个/home/user/downloads/文件夹）。Docker的-v挂载虽然能解决路径映射，但Linux UID/GID不匹配会导致权限错误。一个chmod 777的粗暴方案在生产环境是灾难性的。而本地部署时，我们直接用systemd服务单元文件（Linux）或Windows Service（Windows）来定义服务运行用户，确保Openclaw进程以user:users组身份启动，天然拥有对/home/user/目录的读写权，无需任何额外的chmod操作。

• 网络端口与防火墙博弈：Openclaw的Web UI（如果启用）默认监听localhost:8000，这是一个非常安全的设计。但一旦放进Docker，默认会暴露一个随机端口（如0.0.0.0:32768->8000/tcp），这迫使你必须在防火墙规则里额外放行一个动态端口，增加了攻击面。本地部署则完全规避此问题：服务只绑定127.0.0.1:8000，连netstat -tuln | grep 8000都看不到对外监听，彻底隐身。

因此，“openclaw安装教程”里强调的“手动安装”，本质上是在拥抱一种更底层、更透明的控制权。它要求你理解pip的依赖解析、venv的环境隔离、systemd的服务管理，但这恰恰是构建一个可信赖AI基础设施的必经之路。那些“一键部署”的便利，往往是以牺牲可观测性、可调试性和安全性为代价的。我的经验是：对于学习和PoC（概念验证），Docker镜像是个不错的起点；但对于任何需要进入生产环境的场景，我都会毫不犹豫地选择本地二进制部署，并亲手编写服务管理脚本。

2.3 Openclaw与Dify、Codex等热门方案的本质差异

当搜索“dify本地部署教程win10”或“codex本地部署”时，很多人会下意识地将Openclaw与它们归为一类——“本地AI平台”。这是一个危险的误解。它们解决的问题域、技术栈和适用场景，有着根本性的不同。用一个生活化的比喻：Dify是一个功能齐全的“AI应用商店”，Codex是一个强大的“AI编程助手”，而Openclaw则是一套“AI工厂的自动化流水线控制系统”。

这个表格揭示了一个关键事实：如果你的需求是“快速上线一个内部知识问答网站”，Dify是更优解；如果你的需求是“让AI自动帮我处理每天收到的50封邮件，提取关键信息，生成日报，并发给老板”，那么Openclaw才是那个能把你从重复劳动中解放出来的“数字员工”。它不提供花哨的UI，但它给你一把精准的手术刀，让你能切开AI智能体的每一个决策环节，进行调试、优化和审计。这也是为什么在“本地部署ai大模型”的搜索热词中，Openclaw能脱颖而出——它不是在部署一个模型，而是在部署一个能驾驭多个模型、连接多个系统的智能体操作系统。

3. Openclaw本地部署全流程详解：从零开始，覆盖Windows、macOS、Linux三大平台

3.1 硬件与环境准备：避开“无法找到来自源 nvlddmkm 的事件 id 153”这类Windows驱动陷阱

部署前的环境检查，是决定成败的80%。很多用户卡在第一步，不是因为Openclaw复杂，而是因为忽略了操作系统底层的兼容性细节。下面是我总结的、经过上百次部署验证的“黄金清单”。

通用硬件要求（最低）：

• CPU：Intel i5-8400 / AMD Ryzen 5 2600 或更高。Openclaw本身对CPU要求不高，但如果你计划在本地运行大模型（如Qwen2-7B），多核性能至关重要。
• 内存：16GB RAM 是硬性门槛。这是最容易被低估的一点。Openclaw服务进程自身约占用500MB，但一个7B参数的量化模型（GGUF格式）在Ollama中加载后，常驻内存约4.5GB；再加上Python环境、SQLite数据库、文件缓存，16GB是保证流畅运行的底线。我见过太多用户在8GB内存的旧笔记本上部署失败，错误日志里满屏MemoryError，却误以为是Openclaw bug。
• 存储：至少50GB可用空间。模型文件（尤其是未量化的FP16格式）动辄10GB+，Openclaw的state和memory目录也会随使用时间增长。

Windows平台专项检查（重点防坑）：

• 操作系统版本：必须是Windows 10 21H2 或 Windows 11 22H2 及以上。旧版本（如Win10 1909）缺少对现代Python包（如pydantic-core）的必要系统DLL支持，安装时会报ImportError: DLL load failed。升级系统是唯一解。
• WSL2（强烈推荐）：原生Windows部署虽可行，但会遇到大量路径分隔符（\vs/）、权限模型（NTFS ACL vs POSIX）的兼容性问题。我的标准做法是：在Windows上安装WSL2（Ubuntu 22.04），然后在WSL2中完成全部部署。这能规避90%的Windows特有问题。
• 显卡驱动陷阱（针对“nvlddmkm 事件ID 153”）：这个错误日志，本质是NVIDIA显卡驱动与Windows显示子系统（DDM）的通信故障，与Openclaw无直接关系，但会严重影响其GPU加速能力。解决方案不是重装Openclaw，而是：
  1. 访问 NVIDIA官网 ，下载并安装Game Ready Driver（非Studio Driver），版本号需匹配你的GPU（如RTX 3060对应536.67）。
  2. 在Windows设置 > 系统 > 显示 > 图形设置中，将wsl.exe添加为“硬件加速GPU计划”的例外，并设为“高性能”。
  3. 在WSL2中，运行nvidia-smi，确认能看到GPU列表。如果仍失败，执行wsl --shutdown后重启WSL2。

macOS平台专项检查（M系列芯片）：

• 芯片架构：M1/M2/M3芯片用户，请务必使用ARM64版本的Python和依赖包。不要用Rosetta 2转译的x86_64 Python，否则torch等包会因架构不匹配而崩溃。
• Homebrew与Xcode Command Line Tools：这是macOS部署的基石。先运行xcode-select --install安装命令行工具，再用/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"安装Homebrew。后续所有依赖（如openssl,sqlite3）都通过brew install安装，而非pip，能极大避免编译错误。
• Metal GPU加速：macOS的torch原生支持Metal。在安装PyTorch时，必须使用官方提供的Metal版本：pip3 install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/nightly/cpu（注意URL中的cpu是占位符，实际会自动选择Metal后端）。

Linux平台（Ubuntu/Debian）专项检查：

• 系统更新：sudo apt update && sudo apt upgrade -y。一个未更新的系统，其glibc版本可能过低，导致pip安装的二进制wheel包无法运行。
• 基础编译工具：sudo apt install -y build-essential python3-dev python3-venv libssl-dev libffi-dev。缺少python3-dev会导致cryptography等包编译失败。
• GPU支持（NVIDIA）：sudo apt install -y nvidia-cuda-toolkit，并确保nvidia-smi命令可用。对于AMD GPU，需额外安装ROCm，但Openclaw目前对ROCm支持有限，建议优先使用CPU或NVIDIA方案。

注意：所有平台，在开始安装前，请先执行python3 --version，确认Python版本为3.9、3.10或3.11。Openclaw不支持Python 3.12（因部分依赖尚未适配）和Python 3.8（因pydantic v2的类型提示要求）。

3.2 核心依赖安装：从Python环境到模型运行时的完整链条

环境准备就绪后，下一步是构建一个纯净、可复现的Python运行时。我坚持使用venv而非conda，因为venv是Python官方标准，依赖关系更透明，requirements.txt文件也更容易分享和审计。

步骤1：创建并激活虚拟环境

# Linux/macOS (WSL2) python3 -m venv ~/openclaw_env source ~/openclaw_env/bin/activate # Windows (PowerShell) python -m venv C:\openclaw_env C:\openclaw_env\Scripts\Activate.ps1

提示：venv路径请务必使用绝对路径，避免相对路径在服务化部署时引发问题。~/openclaw_env是Linux/macOS的标准位置，C:\openclaw_env是Windows的推荐位置。

步骤2：升级pip并安装核心依赖

# 升级到最新pip，避免旧版pip无法解析现代依赖 pip install --upgrade pip # 安装Openclaw核心包（带常用扩展） pip install openclaw[all]

[all]这个extras标记，会一并安装openclaw所需的所有可选依赖：pydantic,fastapi,uvicorn,sqlalchemy,pandas,pillow等。如果你确定不需要图像处理（PIL），可以用openclaw[core]来减小体积。

步骤3：安装并配置本地模型运行时（Ollama）Openclaw本身不包含大模型，它需要一个“模型供应商”。Ollama是目前最轻量、最易用的本地模型运行时，完美契合Openclaw的哲学。

• Linux/macOS：curl -fsSL https://ollama.com/install.sh | sh
• Windows (WSL2)：同上，或在WSL2中运行sudo apt install -y curl后执行。
• Windows (原生)：从 Ollama官网 下载Windows安装包，安装后需将C:\Users\<username>\AppData\Local\Programs\Ollama加入系统PATH。

安装完成后，立即测试：

ollama list # 应该为空 ollama run qwen2:1.5b # 下载并运行一个轻量模型，等待其完成 ollama list # 应该显示 qwen2:1.5b

这个qwen2:1.5b模型是Qwen2系列中最小的，仅1.5B参数，非常适合部署测试。它能在16GB内存的机器上流畅运行，是验证整个链路是否通畅的“黄金标准”。

步骤4：初始化Openclaw配置与数据目录Openclaw需要一个工作目录来存放配置、状态和记忆。我习惯将其放在用户主目录下，便于备份和管理。

mkdir -p ~/openclaw_config/{skills,tools,state,memory} cd ~/openclaw_config

然后，创建一个基础的config.yaml文件：

# ~/openclaw_config/config.yaml server: host: "127.0.0.1" port: 8000 reload: false # 生产环境必须为false model: provider: "ollama" # 支持 "ollama", "lmstudio", "openai" base_url: "http://localhost:11434" # Ollama默认地址 model_name: "qwen2:1.5b" storage: state_db: "./state/openclaw_state.db" memory_backend: "filesystem" memory_path: "./memory/" logging: level: "INFO" file: "./openclaw.log"

这个配置文件是Openclaw的“大脑”。model_name字段指定了默认使用的模型，storage部分定义了所有数据的落盘位置。请务必确保./state/和./memory/目录存在且当前用户有读写权限，否则服务启动时会静默失败。

3.3 启动与验证：从CLI到Web UI的完整链路打通

配置完成后，就是见证奇迹的时刻。启动Openclaw服务，并验证其是否健康运行。

步骤1：启动Openclaw服务

# 确保虚拟环境已激活 source ~/openclaw_env/bin/activate # Linux/macOS # 或 C:\openclaw_env\Scripts\Activate.ps1 # Windows PowerShell # 进入配置目录 cd ~/openclaw_config # 启动服务（前台运行，便于观察日志） openclaw serve --config config.yaml

如果一切顺利，你应该看到类似这样的日志输出：

INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)

步骤2：CLI命令行验证（最可靠的测试）打开另一个终端窗口，执行以下命令：

# 测试服务连通性 curl http://127.0.0.1:8000/health # 应该返回 {"status":"healthy","timestamp":"2024-05-20T10:30:45.123Z"} # 测试一个最简单的Skill（内置的echo） curl -X POST http://127.0.0.1:8000/v1/skills/echo \ -H "Content-Type: application/json" \ -d '{"input": "Hello from Openclaw!"}' # 应该返回 {"output": "Hello from Openclaw!", "status": "success"}

curl测试是检验服务是否真正“活”着的金标准。它绕过了所有前端框架的干扰，直接与Openclaw的FastAPI后端对话。如果这个测试失败，问题一定出在服务本身，而不是浏览器或网络。

步骤3：Web UI访问与基础操作在浏览器中打开http://127.0.0.1:8000。你会看到一个简洁的Web界面，顶部是导航栏，中间是“Skills”列表。点击任意一个Skill（如echo），右侧会显示其YAML定义和一个“Run”按钮。点击“Run”，在输入框中输入{"input": "Test Web UI"}，点击执行。如果看到绿色的成功提示和正确的输出，恭喜你，Openclaw的本地部署已经100%成功！

实操心得：我习惯在首次部署成功后，立即创建一个“部署快照”。方法是：将整个~/openclaw_config目录打包压缩，并记录下pip list的输出（pip list > requirements_snapshot.txt）。这样，当未来需要在另一台机器上复现，或者回滚到某个稳定版本时，只需解压、pip install -r requirements_snapshot.txt，即可一键还原。这比任何“教程”都可靠。

3.4 服务化与开机自启：让Openclaw像一个真正的系统服务一样运行

前台运行openclaw serve只适用于调试。在生产环境中，它必须作为一个后台服务（Daemon/Service）运行，并在系统启动时自动拉起。

Linux (systemd) 配置：创建服务单元文件/etc/systemd/system/openclaw.service：

[Unit] Description=Openclaw Agent Runtime After=network.target [Service] Type=simple User=your_username WorkingDirectory=/home/your_username/openclaw_config ExecStart=/home/your_username/openclaw_env/bin/openclaw serve --config /home/your_username/openclaw_config/config.yaml Restart=always RestartSec=10 Environment="PATH=/home/your_username/openclaw_env/bin:/usr/local/bin:/usr/bin:/bin" [Install] WantedBy=multi-user.target

将其中的your_username替换为你的实际用户名。然后执行：

sudo systemctl daemon-reload sudo systemctl enable openclaw.service sudo systemctl start openclaw.service sudo systemctl status openclaw.service # 检查状态

macOS (launchd) 配置：创建plist文件~/Library/LaunchAgents/com.openclaw.agent.plist：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.openclaw.agent</string> <key>ProgramArguments</key> <array> <string>/Users/your_username/openclaw_env/bin/openclaw</string> <string>serve</string> <string>--config</string> <string>/Users/your_username/openclaw_config/config.yaml</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>StandardOutPath</key> <string>/Users/your_username/openclaw_config/openclaw.log</string> <key>StandardErrorPath</key> <string>/Users/your_username/openclaw_config/openclaw_error.log</string> </dict> </plist>

同样替换your_username，然后执行：

launchctl load ~/Library/LaunchAgents/com.openclaw.agent.plist launchctl start com.openclaw.agent

Windows (Windows Service) 配置：Windows原生服务配置较复杂，我推荐一个更稳健的方案：使用nssm（Non-Sucking Service Manager）。

1. 从 nssm.cc 下载nssm-2.24.zip，解压。
2. 以管理员身份运行nssm.exe。
3. 在GUI中：
   • Service name:openclaw
   • Path:C:\openclaw_env\Scripts\openclaw.exe
   • Startup directory:C:\openclaw_config
   • Arguments:serve --config C:\openclaw_config\config.yaml
4. 点击Install service。

安装完成后，在“服务”管理器中找到openclaw服务，右键“启动”。它现在就是一个标准的Windows服务，可以在“服务”管理器中启停、设置启动类型（自动/手动）。

注意：服务化后，openclaw进程将以系统服务账户（Linux/macOS是your_username，Windows是LocalSystem）身份运行。这意味着它对文件系统的访问权限，完全取决于该账户的权限。务必确保/home/your_username/openclaw_config/（或C:\openclaw_config\）目录对该账户是可读写的，否则服务会因无法写入state或memory而崩溃。

4. Openclaw核心功能实战：从内置Skill到自定义Tool，打造你的第一个AI工作流

4.1 内置Skill速览与安全边界认知

Openclaw开箱即用，自带一批经过严格审计的内置Skill，它们是理解Openclaw能力边界的最佳入口。这些Skill不是玩具，而是生产级的、带有完善安全策略的工具。

• echo: 最基础的回声测试，用于验证服务连通性。它没有外部依赖，纯内存操作，是所有部署后的第一个测试项。
• file_reader: 能安全读取本地文本文件。其YAML定义中强制要求allowed_paths参数，例如allowed_paths: ["/home/user/documents/", "/tmp/"]。任何试图读取/etc/passwd的请求，都会被立即拦截并返回{"error": "Access denied to path: /etc/passwd"}。这体现了Openclaw“最小权限原则”的贯彻。
• web_search: 调用本地部署的duckduckgo-search库进行网络搜索。它不使用任何第三方API密钥，所有搜索流量都经过你的本地网络，结果也只返回纯文本摘要，不包含任何追踪像素或广告脚本。这对于需要合规审计的场景至关重要。
• calculator: 一个安全的数学表达式求值器。它不使用eval()，而是用ast.literal_eval()解析表达式树，杜绝了代码注入风险。1+1可以，__import__('os').system('rm -rf /')会被直接拒绝。

要查看所有内置Skill及其详细文档，访问http://127.0.0.1:8000/docs，这是Openclaw自动生成的Swagger API文档。在这里，你可以看到每个Skill的request body schema（输入格式）和response schema（输出格式），这是编写上游应用（如一个Python脚本或Node.js服务）调用Openclaw的权威依据。

提示：内置Skill的源码就在Openclaw的GitHub仓库的openclaw/skills/目录下。阅读这些代码，是学习如何编写安全、健壮Skill的最佳途径。你会发现，每一个Skill都遵循着严格的模板：输入验证（Pydantic模型）、权限检查（allowed_*参数）、异常捕获（统一的try...except块）、日志记录（logger.info()）。这并非巧合，而是Openclaw工程文化的体现。

4.2 创建你的第一个自定义Skill：一个“会议纪要生成器”

理论终须实践。现在，让我们动手创建一个真正有用的Skill：meeting_minutes。它的功能是：接收一段会议录音的文字稿（transcript），自动提取关键议题、决策项、待办事项（Action Items），并生成一份结构化的Markdown格式纪要。

步骤1：定义Skill YAML在~/openclaw_config/skills/目录下，创建文件meeting_minutes.yaml：

name: "meeting_minutes" description: "Generate structured meeting minutes from a transcript." input_schema: type: "object" properties: transcript: type: "string" description: "The full text transcript of the meeting." participants: type: "array" items: type: "string" description: "List of participant names." required: ["transcript"] output_schema: type: "object" properties: summary: type: "string" description: "A concise summary of the entire meeting." key_topics: type: "array" items: type: "string" description: "List of main discussion topics." decisions: type: "array" items: type: "object" properties: topic: type: "string" decision: type: "string" description: "List of formal decisions made." action_items: type: "array" items: type: "object" properties: task: type: "string" owner: type: "string" deadline: type: "string" description: "List of actionable tasks with owners and deadlines." tools: - "llm_invoke" # 这是我们将要编写的自定义Tool allowed_files: - "/tmp/meeting_transcripts/" # 限定只能读取此目录下的文件 # 定义一个简单的重试策略，防止LLM偶尔的超时 retry_policy: max_attempts: 3 backoff_factor: 1.0

这个YAML文件定义了Skill的契约。它明确了输入必须是一个包含transcript字符串的对象，输出必须是一个包含summary、key_topics等字段的结构化对象。allowed_files限定了它能访问的文件路径，retry_policy提供了容错能力。

步骤2：编写自定义Toolllm_invoke在~/openclaw_config/tools/目录下，创建Python文件llm_invoke.py：

# ~/openclaw_config/tools/llm_invoke.py import json import logging from typing import Dict, Any from openclaw.tools.base import BaseTool logger = logging.getLogger(__name__) class LLMInvokeTool(BaseTool): """ A tool that invokes the configured LLM to generate meeting minutes. This is a simple example; in production, you'd add more robust error handling, input sanitization, and rate limiting. """ name = "llm