OpenClaw本地AI工作流引擎：Windows安装与深度配置指南

1. OpenClaw 是什么？它不是“另一个聊天窗口”，而是一台可编程的AI执行引擎

很多人第一次看到“OpenClaw”这个词，下意识会把它和豆包、Coze、扣子这类拖拽式智能体平台划等号——点几下鼠标，选个模板，填个提示词，就能生成一个能回微信消息的AI小助手。这种理解不能说错，但严重低估了它的底层定位。OpenClaw 的本质，是一个面向开发者与高级用户设计的本地化AI工作流执行框架，它的核心价值不在于“对话界面有多漂亮”，而在于“你能否用代码精确控制AI在什么时候、以什么方式、调用什么工具、处理什么数据、最终输出什么结果”。

你可以把它想象成一台装在你Windows电脑里的“AI数控机床”。豆包、Coze是预设好程序的全自动咖啡机——你按“美式”按钮，它就出美式；而OpenClaw是你手边那台带G代码编辑器、可换刀具、能接传感器、能读取Excel表格并据此调整加工参数的CNC铣床。它不提供现成的“美式咖啡配方”，但它给你全套的指令集、校准工具和安全锁，让你自己写一段逻辑：当检测到邮箱里有新发票（输入），自动OCR识别金额（工具调用），比对上月支出阈值（条件判断），若超支则生成预警摘要并邮件发给财务（输出）。这个过程里，AI模型（GPT、Gemini）只是它调用的一个“智能刀具”，而不是整台机器。

这直接决定了它的安装逻辑与使用门槛。它不依赖云端服务器渲染UI，所有计算、调度、状态管理都在你本地完成；它不把API Key藏在某个加密的Web后台里，而是明文（但受系统权限保护）存放在C:\Users\你的用户名\.openclaw\config.json中，因为它的设计哲学是“透明可控”而非“黑盒封装”。这也是为什么它的安装脚本必须以管理员身份运行——它要写入系统服务、配置防火墙规则、安装WSL子系统、设置环境变量，这些操作都直指Windows操作系统内核层，而不是在某个沙盒浏览器里开个新标签页。

所以，当你看到“一键部署”四个字时，请先放下对“点一下就完事”的期待。这里的“一键”，指的是将原本需要手动执行27个独立命令、排查13类环境冲突、调试5轮依赖版本的复杂流程，压缩成一条PowerShell指令。它省掉的是重复劳动，不是思考过程。就像汽车的“一键启动”按钮，并不意味着你不需要懂交通规则、不用踩油门、不用看后视镜。OpenClaw的“一键”，是给已经明确知道“我要造一台能自动分拣快递的机器人”的人，省去从零焊接电路板的时间，而不是教一个从未见过螺丝刀的人如何造车。

这也解释了为什么网络上大量搜索“openclaw安装”“openclaw无法识别命令”的问题集中爆发。绝大多数失败案例，根源不在脚本本身，而在于用户误判了它的适用场景：一个刚学会用Word插入图片的人，拿着CNC铣床的操作手册，第一反应是“这说明书怎么没有‘新建文档’按钮？”——他没意识到，自己手里的根本不是Word，而是一台需要读懂G代码的工业设备。我们接下来要做的，就是把这台“AI数控机床”的控制面板、刀具库、校准流程，一项一项拆开，让你看清每个旋钮背后连接的是什么线路。

2. 为什么必须用 PowerShell（管理员）？这不是形式主义，而是Windows权限模型的硬性约束

如果你跳过这一步，直接双击运行.ps1脚本，或者用普通用户权限打开CMD，那么无论你复制粘贴多少遍iwr -useb https://openclaw.ai/install.ps1 | iex，得到的结果几乎一定是那句令人抓狂的红色报错：

无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

这不是脚本写错了，也不是你的网络有问题，这是Windows操作系统在向你发出一个清晰、不容置疑的声明：你当前的执行环境，不具备运行此任务所需的最低权限基座。要理解这一点，我们必须暂时放下“安装软件”的惯性思维，转而审视OpenClaw在Windows上究竟要构建一个什么样的运行基座。

它要做的第一件事，是安装并初始化Windows Subsystem for Linux (WSL)。OpenClaw的核心服务（尤其是其网关gateway和技能执行引擎）默认运行在Linux环境下，因为它重度依赖Node.js生态中大量仅在POSIX系统上稳定工作的异步I/O库、进程管理工具（如pm2）以及Docker容器运行时。WSL不是虚拟机，而是Windows内核直接提供的Linux兼容层，它的安装需要修改系统引导配置、分配磁盘空间、注册内核模块。这些操作，普通用户账户连“查看”权限都没有，更别说执行。wsl --install这条命令，本质上是在调用Windows Update的底层服务，下载并集成一个全新的操作系统子系统。

第二件事，是创建并注册一个Windows系统服务（Windows Service）。OpenClaw被设计为“守护进程”（daemon），这意味着它需要在你关闭PowerShell窗口、甚至重启电脑后，依然能在后台持续运行，监听端口（如localhost:3000的控制面板）、接收微信消息、执行定时任务。在Windows中，只有以LocalSystem或NetworkService身份运行的系统服务，才能获得这种级别的持久化能力。普通用户进程一旦终端关闭就会被系统回收，这是Windows安全模型的基石。openclaw gateway start命令的背后，是调用sc.exe create创建服务、sc.exe start启动服务、sc.exe config设置启动类型为auto。这些sc.exe操作，没有管理员令牌（token），连命令行都打不开。

第三件事，是修改系统级环境变量与防火墙规则。OpenClaw需要确保openclaw命令能在任何路径下被识别，这就要求将它的可执行文件路径（例如C:\Users\你的用户名\.openclaw\bin）永久添加到系统的PATH环境变量中。同时，为了让浏览器能访问http://localhost:3000，它必须确保Windows Defender防火墙允许该端口的入站连接。这两项操作，前者需要写入注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment，后者需要调用netsh advfirewall firewall add rule。它们都属于典型的“需要提升权限才能修改”的系统配置。

因此，“以管理员身份运行PowerShell”绝非可选项，而是整个安装流程的唯一合法入口。它为你申请到了一把“系统总钥匙”，让你有权打开上述所有上锁的抽屉。如果你跳过这一步，脚本会在第一步wsl --install就卡死，或者在尝试写入PATH时静默失败，最终导致后续所有命令都无法被识别——因为你根本没有把“钥匙孔”对准“锁芯”。

提示：在Windows 11中，右键开始菜单选择“终端(管理员)”比“Windows PowerShell(管理员)”更可靠，因为新版终端已深度集成PowerShell 7+，对现代脚本语法（如iex的管道执行）兼容性更好。如果遇到iwr命令报错，可以先手动运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser来临时允许本地脚本执行，这是PowerShell的安全策略，与OpenClaw无关。

3. 一键脚本iwr -useb ... | iex的真实工作流解剖：它到底在你电脑里做了什么？

那条看似轻巧的命令iwr -useb https://openclaw.ai/install.ps1 | iex，是整个安装过程的“总开关”。但它的魔力不在于神秘，而在于其背后精心编排的、覆盖Windows全栈环境的自动化流水线。我们可以把它拆解成五个阶段，每个阶段都对应着一个关键的系统改造动作，而这些动作，正是你手动安装时最易出错、最耗时间的环节。

3.1 阶段一：环境探针与前置检查（约15秒）

脚本启动后的第一件事，不是急着安装，而是对你当前的Windows环境进行一次“CT扫描”。它会依次检查：

• Windows版本与架构：通过Get-ComputerInfo获取OsName和OsArchitecture，确认是否为 Windows 10/11 64位。如果是Windows 7或32位系统，脚本会立即终止并给出明确错误：“OpenClaw requires Windows 10/11 64-bit. Your system is not supported.” 这避免了后续所有无效劳动。
• 网络连通性：使用Test-NetConnection github.com -Port 443验证能否访问GitHub（OpenClaw的二进制文件和依赖包主要托管于此）。如果失败，它不会盲目下载，而是提示“Failed to connect to GitHub. Please check your internet connection and proxy settings.”。
• PowerShell执行策略：检查Get-ExecutionPolicy的返回值。如果当前策略是AllSigned或Undefined，它会建议你运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，并说明这是PowerShell自身的安全机制，与OpenClaw无关。
• 现有WSL状态：运行wsl -l -v列出已安装的发行版。如果发现已有WSL2（如Ubuntu），它会跳过WSL安装步骤，直接进入下一步；如果未安装，则标记为待办事项。

这个阶段的意义在于“止损”。它把那些注定失败的安装尝试，扼杀在摇篮里，把宝贵的15分钟调试时间，转化成了15秒的明确诊断。

3.2 阶段二：WSL2与核心运行时安装（约3-5分钟）

这是耗时最长、也最关键的阶段。脚本会执行以下原子操作：

1. 启用WSL功能：运行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart和dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart。这两条命令启用了Windows内核的Linux子系统支持和虚拟化平台，是WSL2运行的硬件基础。
2. 下载并安装WSL2内核更新包：从https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi下载官方内核安装包，并静默安装（msiexec /i wsl_update_x64.msi /quiet）。
3. 设置WSL2为默认版本：运行wsl --set-default-version 2。
4. 安装Ubuntu-22.04发行版：这是OpenClaw官方指定的、经过充分测试的Linux环境。脚本会调用wsl --install -d Ubuntu-22.04，并自动处理所有交互式提示（如设置用户名和密码）。
5. 在WSL内安装Node.js 22.x：进入Ubuntu环境后，脚本会自动执行curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -和sudo apt-get install -y nodejs。选择Node.js 22而非更常见的18.x，是因为OpenClaw的最新版（2.7.5）利用了V8引擎的--max-old-space-size=8192内存优化参数，该参数在Node.js 22中才被完全稳定支持。

注意：这个阶段的“静默安装”并非真的无声。它会在PowerShell窗口中实时打印每一步的进度，例如Installing WSL kernel... [OK]、Setting WSL2 as default... [OK]。如果你看到某一步卡住超过2分钟，大概率是网络问题——此时应检查是否因国内网络原因无法访问wslstorestorage.blob.core.windows.net。解决方案是手动下载该.msi包，然后在脚本同目录下创建一个skip_wsl_kernel_install.txt空文件，脚本检测到该文件后会跳过内核安装，直接进行下一步。

3.3 阶段三：OpenClaw主程序与CLI工具链部署（约45秒）

当WSL环境准备就绪，脚本会切换到Windows主机环境，执行：

• 创建主目录结构：在C:\Users\你的用户名\.openclaw下建立bin/,config/,logs/,skills/等标准目录。
• 下载并解压OpenClaw CLI：从https://github.com/miaoxworld/openclaw-cli/releases/download/v2.7.5/openclaw-cli-win-x64.zip下载预编译的二进制包，解压到bin/目录。
• 注册全局命令：将C:\Users\你的用户名\.openclaw\bin添加到系统PATH环境变量，并通过refreshenv命令刷新当前会话的环境变量。这是openclaw命令能在任意位置被识别的根本原因。
• 初始化配置文件：生成一个空的config.json，并设置好默认的gateway.port为3000，log.level为info。

3.4 阶段四：向导式配置（约2分钟，用户交互主导）

这是唯一需要你主动参与的阶段。脚本会启动一个基于inquirer库的纯文本交互式菜单。它的精妙之处在于，所有选项都经过了严格的逻辑校验：

• 当你选择QuickStart模式时，它会自动禁用所有高级选项（如自定义Docker镜像、多模型路由），只保留最简路径。
• 当你选择Gemini作为模型时，它会自动将api.base_url设置为https://generativelanguage.googleapis.com/v1beta，并提示你“国内网络推荐使用Gemini，因其无需额外代理”。
• 当你输入API Key时，脚本会进行基础格式校验（如OpenAI Key必须以sk-开头，长度为51位），如果格式错误，会立即提示“Invalid API Key format. Please check and re-enter.”，而不是等到启动时才报错。

3.5 阶段五：服务注册与首次启动（约30秒）

最后一步，脚本会：

• 在WSL中启动OpenClaw Gateway服务，并将其作为后台进程守护。
• 在Windows主机上，使用New-ServicePowerShell cmdlet 创建一个名为OpenClawGateway的系统服务，指向WSL中的启动脚本。
• 执行Start-Service OpenClawGateway，让服务立即运行。
• 最终，打印出绿色的成功信息：“✅ Installation complete! Your dashboard is ready at http://localhost:3000”。

整个过程，就是一次从Windows内核层（WSL）、到系统服务层（Windows Service）、再到应用层（Node.js CLI）的垂直贯通。它不是魔法，而是一套被反复验证、高度可靠的自动化运维脚本。

4. 安装成功后，你真正拥有的是什么？——从openclaw doctor到openclaw dashboard的全链路验证

安装脚本的最后一行绿色文字，只是万里长征的第一步。真正的价值，始于你敲下openclaw doctor这条命令的那一刻。这条命令，是OpenClaw为你量身定制的“健康体检仪”，它会逐层扫描整个技术栈，告诉你每一环是否真正咬合到位。我们来完整走一遍这个验证链路，看看一个健康的OpenClaw本地环境，其内部究竟是怎样协同工作的。

4.1 第一层：CLI工具链自检（openclaw doctor）

在PowerShell中输入openclaw doctor，你会看到类似这样的输出：

🔍 Running diagnostics... ✅ CLI Version: v2.7.5 ✅ WSL Status: Running (Ubuntu-22.04, WSL2) ✅ Node.js Version: v22.14.1 (within required range: >=22.0.0) ✅ Gateway Process: Running (PID: 12345) ✅ Dashboard Port: 3000 (Listening) ✅ Config File: C:\Users\zhangsan\.openclaw\config.json (Valid JSON) ✅ API Key: Configured (OpenAI) ✅ Skills Directory: C:\Users\zhangsan\.openclaw\skills (Exists)

这个输出，每一行都对应一个关键节点：

• CLI Version：确认你本地安装的openclaw.exe是2.7.5版本，而非旧版缓存。
• WSL Status：它不是简单地检查wsl -l是否有输出，而是深入到WSL实例内部，运行wsl -u root -e sh -c "ps aux | grep gateway"来确认OpenClaw的网关进程确实在Ubuntu中运行。
• Node.js Version：它会进入WSL，执行node --version，并严格比对版本号。如果你手动安装了Node.js 20.x，这里就会报红，提示你升级。
• Gateway Process：这是最核心的检查。它通过wsl -u root -e pgrep -f 'openclaw-gateway'获取进程ID，证明AI服务引擎已在Linux环境中启动。
• Dashboard Port：它会调用netstat -ano | findstr :3000，确认Windows主机上的3000端口已被openclaw.exe占用，并且状态为LISTENING。这证明了Windows与WSL之间的端口转发（由WSL2的默认NAT机制实现）是通畅的。

注意：如果Gateway Process显示Not Running，但WSL Status是Running，这通常意味着WSL内的服务启动失败。此时应运行wsl -u root -e tail -n 20 /var/log/openclaw/gateway.log查看详细错误日志。最常见的原因是API Key格式错误或网络超时，日志里会清晰地写着Error: Request failed with status code 401或Error: connect ETIMEDOUT。

4.2 第二层：服务状态管理（openclaw gateway status/start/stop）

doctor告诉你“一切正常”，而gateway子命令则赋予你对这个“生命体”的完全控制权：

• openclaw gateway status：返回一个JSON对象，包含state（running/stopped）、uptime（已运行秒数）、memoryUsage（内存占用MB）、cpuUsage（CPU百分比）。这是一个实时的“生命体征监测仪”。
• openclaw gateway start：如果服务意外停止，这条命令会重新触发WSL内的启动脚本，它比单纯wsl -u root -e systemctl start openclaw-gateway更智能，因为它会先检查配置文件是否有变更，如有，则自动重载。
• openclaw gateway stop：优雅地终止服务。它会向网关进程发送SIGTERM信号，等待所有正在处理的请求完成后再退出，而不是粗暴的kill -9。

这个设计体现了OpenClaw对生产环境的敬畏。它不假设你永远在线，而是提供了随时“重启心脏”的能力。

4.3 第三层：可视化控制中心（openclaw dashboard）

当你在PowerShell中输入openclaw dashboard，它会做三件事：

1. 检查http://localhost:3000是否可达（通过HTTP HEAD请求）。
2. 如果不可达，它会自动尝试openclaw gateway start并等待5秒。
3. 最后，调用Start-Process "http://localhost:3000"，在你的默认浏览器中打开控制面板。

这个控制面板，才是你与OpenClaw交互的“驾驶舱”。它不是一个静态网页，而是一个由React构建的、与后端实时通信的单页应用（SPA）。它的核心功能区包括：

• 模型管理：你可以在这里动态切换当前使用的AI模型（GPT-4o-mini, gemini-pro, claude-3-haiku），无需重启服务。背后的原理是，前端会向/api/config/model发送PATCH请求，后端收到后，会热重载模型客户端，整个过程毫秒级完成。
• 技能中心：这里列出了所有已安装的“技能”（Skill），比如web_search（联网搜索）、file_reader（读取本地PDF）、code_executor（安全沙箱内执行Python代码）。每个技能都有一个“启用/禁用”开关，开关状态会实时写入config.json的skills数组。
• 日志流：一个实时滚动的终端式日志窗口，显示网关接收到的每一条请求、调用的每一个工具、AI生成的每一段响应。这是你调试工作流的“X光片”。例如，当你配置了一个“自动总结PDF”的工作流，却得不到结果，日志里会清晰地显示INFO: Skill 'file_reader' executed successfully. Output length: 1248 chars，或者ERROR: Skill 'code_executor' failed: Permission denied to access file 'C:\temp\report.pdf'。

实操心得：我曾在一个客户现场遇到“控制面板打不开”的问题。doctor显示一切正常，status显示服务在运行，但浏览器就是白屏。最终发现，是客户的公司防火墙策略阻止了localhost的HTTP请求（认为这是“内部威胁”）。解决方案是，在config.json中将dashboard.host改为0.0.0.0，然后在浏览器中访问http://127.0.0.1:3000。这个细节，官方文档里不会写，但却是企业内网部署时的高频坑。

5. 从“能跑”到“好用”：三个必做的深度配置与避坑指南

安装成功、控制面板能打开，只是拿到了一把能发动的车钥匙。要让它真正成为你生产力的延伸，还需要完成三个关键的“深度配置”。这些配置，往往决定了OpenClaw是沦为一个玩具，还是成为你日常工作的“AI副驾驶”。

5.1 配置项一：为国内网络优化的API路由（解决Gemini/GPT超时）

这是所有国内用户绕不开的第一道坎。OpenClaw默认的API请求，是直连api.openai.com或generativelanguage.googleapis.com。但在实际网络环境中，这两个域名的DNS解析和TCP连接，常常遭遇不同程度的延迟或丢包。openclaw doctor可能显示API Key: Configured，但当你在控制面板里点击“测试模型”时，却卡在“Loading…”长达30秒，最终报错Request timeout。

解决方案不是换代理，而是利用OpenClaw内置的API Base URL 重写机制。你需要编辑C:\Users\你的用户名\.openclaw\config.json文件，找到model对象，为其添加base_url字段：

{ "model": { "provider": "openai", "name": "gpt-4o-mini", "api_key": "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "base_url": "https://api.aigc2d.com/v1" } }

这个api.aigc2d.com是一个由国内社区维护的、专为AI API加速的反向代理服务（注意：它只是一个公开的、非商业的加速节点，不存储任何用户数据）。它的原理是，你的请求先发到这个国内服务器，再由它代为转发到OpenAI，从而规避了跨境网络的不稳定因素。对于Gemini，可以使用https://gemini-api-proxy.vercel.app/v1beta。

关键技巧：不要在控制面板的UI里修改这个字段！UI界面对base_url的支持不完善，有时会将其错误地拼接到api_key后面。务必手动编辑config.json，保存后运行openclaw gateway restart使配置生效。实测下来，这个配置能将GPT模型的平均响应时间从15秒降至2秒以内。

5.2 配置项二：为个人微信接入配置wechaty技能（高风险操作的合规路径）

网络上大量搜索“openclaw接入微信”，但官方文档对此讳莫如深，原因只有一个：微信的《运营规范》明确禁止任何形式的自动化群控、消息群发、账号矩阵等行为，违规者将面临永久封号。OpenClaw的wechaty技能，本质上是通过Puppeteer控制一个真实的微信Web版客户端，这与微信官方的“小程序”、“公众号”、“企业微信”等合规渠道有本质区别。

如果你仍决定尝试，必须遵循一条铁律：只用于个人学习、单点测试，且必须使用一个完全隔离、无任何社交关系、无支付功能的“实验号”。配置步骤如下：

1. 在控制面板的“技能中心”，启用wechaty技能。
2. 编辑C:\Users\你的用户名\.openclaw\skills\wechaty\config.json，将puppet设置为wechaty-puppet-wechat（对应微信Web版）。
3. 运行openclaw skill wechaty start，它会自动打开一个Chrome浏览器窗口，显示微信的二维码。
4. 用你的“实验号”手机微信扫码登录。切记，不要用主号！不要用工作号！

血泪教训：我曾帮一位朋友配置，他坚持要用自己的主号。结果在测试“自动回复‘你好’”功能时，微信后台检测到异常的登录频率（同一IP短时间内多次扫码），当天就冻结了账号，申诉无果。后来我们改用gewechat（基于安卓模拟器的方案），虽然更复杂，但因其运行在独立的安卓虚拟机中，行为模式更接近真实手机，被风控的概率大大降低。这再次印证了那句话：在AI世界里，合规性不是束缚，而是长期可用的基石。

5.3 配置项三：为长期运行加固的守护进程（防止意外崩溃）

openclaw gateway start启动的服务，是一个前台进程。如果你不小心关闭了PowerShell窗口，或者Windows进行了计划更新并重启，服务就会随之终止。这对于一个需要7x24小时待命的AI助手来说，是不可接受的。

真正的解决方案，是将其注册为Windows的“自动恢复服务”。这需要两步：

1. 创建恢复策略：在PowerShell（管理员）中，运行：

   sc.exe failure "OpenClawGateway" reset= 0 actions= restart/60000/restart/60000/restart/60000

   这条命令的意思是：如果服务在60秒内崩溃，就自动重启；如果连续三次在60秒内崩溃，则保持停止状态并记录事件日志。
2. 设置服务登录账户：默认情况下，服务以LocalSystem身份运行，这可能导致它无法访问你用户目录下的某些文件（如C:\Users\你的用户名\.openclaw\skills\）。运行：

   sc.exe config "OpenClawGateway" obj= ".\你的用户名" password= "你的密码"

   将服务的运行身份，改为你当前的用户账户。这样，它就能拥有与你在PowerShell中完全一致的文件系统权限。

完成这两步后，你的OpenClaw就真正具备了“服务器级”的健壮性。即使你关机、重启、甚至拔掉网线再插上，它都会在后台默默恢复，等待你的下一条指令。

6. 一个真实的工作流案例：用OpenClaw自动整理每日会议纪要

理论讲得再多，不如一个能立刻上手的实战案例。下面，我将带你完整复现一个我在实际工作中每天都在用的、基于OpenClaw的自动化工作流：将Teams会议的原始录音转录文本，自动提取关键决策、待办事项和负责人，并生成一份结构化的Markdown纪要，最后通过邮件发送给所有参会者。

这个案例之所以经典，是因为它完美融合了OpenClaw的三大核心能力：多模态输入处理（音频转文本）、结构化信息抽取（LLM推理）、外部系统集成（邮件发送）。整个流程，无需一行Python代码，全部通过OpenClaw的配置和技能组合完成。

6.1 步骤一：准备原材料与前置技能

首先，你需要准备好“原材料”：

• 一个.wav或.mp3格式的会议录音文件（例如meeting_20240520.wav）。
• 一个已配置好的、能稳定调用GPT-4o-mini的OpenClaw环境（已完成前述所有配置）。

然后，确保以下两个技能已启用：

• audio_transcriber：这是一个基于Whisper.cpp的本地语音转文字技能，它不依赖网络，所有计算都在你本地GPU/CPU上完成，隐私性极佳。
• email_sender：这是一个基于Nodemailer的邮件发送技能，需要你预先在config.json中配置好SMTP服务器（如Gmail的smtp.gmail.com）和邮箱凭据。

6.2 步骤二：编写工作流定义（YAML格式）

OpenClaw的工作流，是用YAML编写的。将以下内容保存为meeting_summary.yaml：

name: "Daily Meeting Summary" description: "Auto-generate structured minutes from audio recording" # 输入：指定音频文件路径 input: type: "file" path: "C:/Users/zhangsan/Documents/meeting_20240520.wav" # 工作流步骤 steps: # 步骤1：转录音频 - name: "Transcribe Audio" skill: "audio_transcriber" input: "{{ input.path }}" output: "transcript.txt" # 步骤2：用AI提取结构化信息 - name: "Extract Key Points" skill: "llm" model: "gpt-4o-mini" prompt: | 你是一位专业的会议秘书。请仔细阅读以下会议转录文本，然后严格按照以下JSON Schema输出结果： { "decisions": [ { "topic": "string", "summary": "string" } ], "action_items": [ { "task": "string", "owner": "string", "deadline": "string (YYYY-MM-DD)" } ], "next_steps": ["string"] } 转录文本： {{ steps[0].output }} # 步骤3：将JSON结果渲染为Markdown - name: "Render to Markdown" skill: "template_renderer" template: | # 会议纪要 - {{ now | date('YYYY-MM-DD') }} ## 🎯 关键决策 {% for d in steps[1].output.decisions %} - **{{ d.topic }}**: {{ d.summary }} {% endfor %} ## 📋 待办事项 {% for a in steps[1].output.action_items %} - [ ] **{{ a.task }}** — @{{ a.owner }} (截止: {{ a.deadline }}) {% endfor %} ## ➡️ 下一步 {% for n in steps[1].output.next_steps %} - {{ n }} {% endfor %} # 步骤4：发送邮件 - name: "Send Email" skill: "email_sender" to: "team@company.com" subject: "【会议纪要】{{ now | date('YYYY-MM-DD') }} 项目例会" body: "{{ steps[2].output }}"

这个YAML文件，就是整个工作流的“蓝图”。它定义了数据从哪里来（input.path），经过哪些处理环节（steps），每个环节的输入输出如何连接（{{ input.path }},{{ steps[0].output }}），以及最终如何呈现（template_renderer）和分发（email_sender）。

6.3 步骤三：执行与验证

在PowerShell中，导航到meeting_summary.yaml所在目录，然后运行：

openclaw workflow run --file meeting_summary.yaml

几秒钟后，你会在控制面板的日志流中看到：

INFO: Workflow 'Daily Meeting Summary' started. INFO: Step 'Transcribe Audio': Completed in 42s. Output saved to 'transcript.txt'. INFO: Step 'Extract Key Points': LLM call succeeded. Output parsed as JSON. INFO: Step 'Render to Markdown': Template rendered successfully. INFO: Step 'Send Email': Email sent to team@company.com. INFO: Workflow completed successfully.

同时，你的收件箱里，会收到一封格式工整、重点突出的会议纪要邮件。整个过程，从你敲下回车，到邮件发出，全程无人工干预。

经验分享：这个工作流的威力，在于它的可扩展性。上周，我只需要在steps数组末尾，增加一个调用notion_uploader技能的步骤，就能让生成的Markdown纪要，自动同步到我们的Notion项目数据库中。这就是OpenClaw的魅力——它不绑定任何特定的工具或平台，它只是一个强大的“胶水”，把你散落在各处的数字资产，粘合成一个高效运转的有机体。你不需要成为全栈工程师，只需要理解数据的流向，就能指挥AI为你打工。