1. 项目概述：一个人如何真正跑通 OpenClaw 自动化工作流

OpenClaw 不是又一个“调 API 的前端界面”，它是一套把大模型能力真正焊进业务毛细血管里的本地优先 AI 代理系统。标题里那句“一个人=一支团队”，不是营销话术，而是我用三台不同配置的阿里云轻量服务器、一台本地 Rocky Linux 工作站、外加一台 NAS 设备实测出来的结果——从零部署到跑通钉钉自动审批、飞书日报生成、微信客户分层打标、甚至自动抓取竞品官网更新并生成摘要报告，全程没写一行 Python 脚本，全靠 OpenClaw 内置的 Skill 编排和 Web UI 配置完成。核心关键词就三个： 阿里云轻量应用服务器、OpenClaw、自动化工作流 。它解决的不是“能不能调模型”的问题，而是“调完之后，模型怎么持续、可靠、可审计地替你干活”的问题。适合谁？第一类是中小企业的技术负责人，手头没专职 AI 工程师，但急需把客服、运营、IT 运维这些重复性高、规则明确的活交给 AI；第二类是独立开发者或自由职业者，想用一套系统同时接多个客户的自动化需求，比如给 A 客户做电商订单同步，给 B 客户做 CRM 数据清洗，不用每次重搭环境；第三类是技术爱好者，想在本地摸清大模型 Agent 的真实运行逻辑，而不是只停留在 Chat UI 层面。它不依赖公网模型服务（虽然支持），所有记忆、技能、工作流定义都存在你自己的服务器上，这才是“本地优先”的真正含义——不是指“装在你电脑上”，而是指“你的数据主权和执行控制权，始终在你手里”。

2. 核心思路拆解：为什么必须放弃“手动 Docker 部署”老路

很多人看到“OpenClaw 部署”，第一反应就是翻 GitHub README，抄一串 docker run 命令，再配个 docker-compose.yml 。我试过，也踩过坑，最后删了重来。原因很简单：OpenClaw 的核心价值不在“启动”，而在“持续运行”和“可维护性”。一个靠 docker-compose up -d 启起来的服务，当它内存爆满、日志塞满磁盘、模型切换失败、或者某个 Skill 的 Python 依赖版本冲突时，你得 ssh 进去一条条查，而 OpenClaw 的官方镜像，是把整个运维生命周期都封装进去了。这背后是三个关键设计选择：

第一， 操作系统层深度定制 。阿里云提供的 OpenClaw 镜像基于 Alibaba Cloud Linux，而不是通用 Ubuntu 或 CentOS。这不是为了“国产化”噱头，而是因为 Alibaba Cloud Linux 内核针对云服务器做了大量优化，比如更激进的内存回收策略、更低的 I/O 延迟、以及对轻量服务器硬件（如 ESSD 云盘）的原生支持。我对比过，在同样 2 核 2G 的轻量服务器上，用官方镜像跑 Qwen3.5-7B 模型，首次响应时间比 Ubuntu + 手动 Docker 快 1.8 秒，这个差距在高频调用的工作流里，就是每天多处理 200+ 个任务的差别。

第二， 端口与防火墙的“动态绑定”机制 。旧版文档里提到“端口放通”，新版直接升级为“随机端口自动生成+一键放通”。这背后是安全工程思维：固定端口（比如默认 3000）等于给扫描器发邀请函。官方镜像在初始化时，会调用阿里云的元数据服务，生成一个 49152–65535 范围内的随机端口，并自动调用 aliyuncli 命令更新安全组规则。你看到的“执行命令”按钮，本质是触发了一个预编译的 Shell 脚本，它完成了 firewall-cmd --permanent --add-port=XXXX/tcp 和 firewall-cmd --reload 全流程。手动部署时，你得自己写脚本、自己配安全组、自己处理重启后端口变化，而官方镜像把这个过程压缩成了一次点击。

第三， 模型配置与工作流的“声明式分离” 。很多教程教你改 .env 文件或 config.yaml ，但 OpenClaw 的 Web UI 初始化向导，其实是把模型配置（API Key、地域、模型名）和工作流配置（Agent 行为、Skill 触发条件）彻底分开。模型配置属于“基础设施层”，一旦配好，除非换厂商，否则基本不动；而工作流配置属于“业务层”，可以随时在 Web UI 里拖拽修改。这种分离，让一个非开发背景的运营同事，也能在不碰代码的前提下，把“每日 9 点自动汇总销售数据”这个需求，从需求文档变成可执行的自动化流程。我见过最典型的案例，是一家跨境电商公司，老板让助理用 OpenClaw 接入飞书，配置了“收到新订单消息 → 自动查询物流单号 → 抓取最新物流状态 → 发送飞书卡片给客服主管”，整个过程花了不到 40 分钟，而之前他们用 Excel 手动查，平均每人每天要花 2.5 小时。

所以，“保姆级教程”的核心，不是教你怎么敲命令，而是教你怎么理解这套系统的设计哲学：它把运维的复杂性藏在镜像里，把业务的灵活性留给 Web UI。你只需要学会“什么时候该点哪个按钮”，而不是“为什么要敲这行命令”。

3. 阿里云部署全流程：从购买到第一个自动化任务上线

3.1 实例选购与镜像选择：避开配置陷阱的实操细节

阿里云轻量应用服务器（SAS）是部署 OpenClaw 最省心的选择，但选购时有三个极易被忽略的“坑”，我用红字标出来，你一定要看：

提示： 不要选“按量付费”实例用于生产环境 。轻量服务器的按量计费是按小时结算，但 OpenClaw 是 7x24 小时常驻服务，按量付费一个月下来，费用可能比包年包月高出 30%。而且，按量实例在资源紧张时可能被自动释放，导致你的自动化工作流中断。

提示： 内存必须选 2GiB 及以上，且强烈建议选 4GiB 。官方文档说“2GiB 适合单个 Agent”，这是理论值。实测中，Qwen3.5-7B 模型加载后基础内存占用约 1.2GiB，OpenClaw 网关服务约 0.4GiB，再加上系统缓存、日志缓冲区，2GiB 实例在运行 3 个以上 Skill 时，Swap 分区会频繁触发，导致响应延迟飙升。我用 2GiB 实例跑一个“微信消息自动回复 + 飞书日报生成”的双任务流，平均延迟从 1.2 秒涨到 4.7 秒。换成 4GiB 后，稳定在 1.3 秒内。

提示： 地域选择必须和你的主要模型服务商匹配 。如果你主用阿里云百炼，就选“华北2（北京）”；如果主用 DeepSeek 或 Kimi，它们在国内的接入点集中在“华东1（杭州）”，那就选杭州。别图便宜选“中国（香港）”，虽然价格低，但内地访问香港节点的网络延迟平均增加 80ms，对于需要实时响应的客服场景，这就是用户投诉的源头。

具体操作步骤（以 2024 年 10 月阿里云控制台为准）：

1. 进入 阿里云轻量应用服务器购买页 ，点击“立即购买”。
2. 在“实例配置”区域， 地域 选择与你模型服务商匹配的节点（如华北2）； 实例套餐 ，我推荐直接选“4核8G”起步，这是性价比最高的甜点配置，能稳稳跑 5-8 个并发 Agent； 镜像 ，在“应用镜像”分类下，找到“OpenClaw”，选择最新版本（当前是 OpenClaw 2026.5.19 ）。注意，这里显示的“应用镜像”是阿里云预装好 OpenClaw、Docker、Nginx、以及所有依赖的完整系统，不是 Docker Hub 上那个裸镜像。
3. “购买时长”选“12个月”，享受最大折扣；“登录凭证”选“设置密码”，并输入一个强密码（至少 12 位，含大小写字母、数字、符号）。
4. 点击“立即购买”，完成支付。

支付成功后，你不会立刻看到服务器列表。因为阿里云需要 1-2 分钟来为你部署预装镜像。此时，你可以去喝杯咖啡，回来刷新页面，就能看到新购的服务器了。

3.2 初始化向导：三步完成模型接入与 Web UI 访问

服务器创建成功后，进入“轻量应用服务器控制台”，找到你的新实例，点击实例 ID 进入详情页。这里的关键是找到“应用详情”页签，而不是“服务器概览”或“远程连接”。在“应用详情”页，你会看到一个醒目的蓝色按钮：“ 初始化 ”。点击它，就进入了 OpenClaw 的核心配置向导。

步骤 1：模型配置 这是最关键的一步，决定了你的 AI 助理“智商”上限。向导会列出所有支持的模型厂商，包括阿里云百炼（Token Plan、Coding Plan）、DeepSeek、Kimi、GLM、智谱等。我强烈建议新手从 百炼 Coding Plan 开始，原因有三：第一，它是固定月费（比如 99 元/月），包含 100 万 tokens 的额度，不用担心调用一次模型就扣几十块；第二，它支持的模型质量高，Qwen3.5-plus、Kimi-k2.5 都是当前 SOTA 级别；第三，它的 API Key 是“地域绑定”的，你在华北2 服务器上配华北2 的 Key，几乎不会出错。

操作细节：

• 在“大模型平台”下拉框，选择“阿里云百炼 Coding Plan”。
• 在“API Key”输入框，粘贴你从 百炼控制台 获取的 Coding Plan Key。 注意：这个 Key 必须是你在“华北2（北京）”地域创建的，否则会报错“Invalid region” 。
• 在“模型”下拉框，选择 qwen3.5-plus 。这是目前综合能力最强的开源模型之一，中文理解、代码生成、逻辑推理都很稳。
• 点击“立即配置”。

步骤 2：Web UI 访问配置 配置完模型，向导会自动跳转到第二步。这里只有一个动作：点击“ 确定放通 ”按钮。这个按钮背后，是阿里云自动调用 aliyuncli 更新你的安全组规则，开放刚才随机生成的那个端口（比如 52187）。完成后，页面会显示一个绿色的 URL，格式是 http://<你的服务器公网IP>:<端口号> 。 请立刻复制这个 URL，并在浏览器新标签页中打开它 。如果看到 OpenClaw 的登录页面，恭喜，第一步成功！

注意：这个 URL 里包含一个 token= 参数，这是管理员 Token。 绝对不要截图、不要发群、不要保存在明文笔记里 。任何拿到这个链接的人，都能直接获得最高权限。我建议你打开后，立刻在地址栏删掉 ?token=xxx 这段，然后按回车，系统会自动跳转到登录页，让你用初始化时设置的密码登录。

步骤 3：验证与测试 登录后，你会看到一个简洁的 Web UI。点击左上角的“+ New Chat”，输入“你好，你是谁？”，如果 AI 能流畅回答，并且提到“我是由 OpenClaw 驱动的 AI 助理”，说明模型调用链路完全打通。此时，你已经拥有了一个可对话的 AI 助理，但它还不会“主动干活”，下一步才是真正的自动化。

3.3 配置第一个自动化工作流：钉钉审批单自动归档

OpenClaw 的威力，体现在它能把“被动对话”变成“主动执行”。我们以最常见的企业场景为例：员工在钉钉提交请假申请，审批通过后，系统自动将审批单 PDF 下载、重命名（格式： [姓名]_[日期]_请假单.pdf ）、并上传到指定的 NAS 共享文件夹。整个过程，无需人工干预。

第一步：在钉钉侧创建机器人

1. 登录钉钉管理后台，进入“工作台” > “应用管理” > “自建应用”。
2. 创建一个“群机器人”，获取 Webhook 地址（格式： https://oapi.dingtalk.com/robot/send?access_token=xxx ）。
3. 记下这个地址，稍后要用。

第二步：在 OpenClaw 中添加钉钉 Channel

1. 回到 OpenClaw Web UI，点击左侧导航栏的“Channels”（通道）。
2. 点击右上角“+ Add Channel”，选择“DingTalk”。
3. 在弹出的表单中：
   • “Channel Name”：填 DingTalk-Approval （方便识别）。
   • “Webhook URL”：粘贴你刚获取的钉钉 Webhook 地址。
   • “Verification Token”：留空（钉钉机器人默认不开启加签）。
   • 点击“Save”。

第三步：创建核心 Skill（技能）

1. 点击左侧导航栏的“Skills”（技能）。
2. 点击“+ Create Skill”，选择“From Template”，然后搜索并选择“DingTalk Approval Auto-Archive”模板（这是阿里云预置的常用模板）。
3. 在模板编辑页，你需要修改几个关键参数：
   • “DingTalk Channel”：下拉选择你刚创建的 DingTalk-Approval 。
   • “Target Folder Path”：填写你的 NAS 共享路径，例如 /mnt/nas/HR/Leave_Approvals/ 。 注意：这个路径必须是 OpenClaw 服务器上已挂载好的，你需要先用 mount -t cifs //nas-ip/share /mnt/nas -o username=user,password=pass 命令挂载好 。
   • “File Naming Rule”：输入 {{user.name}}_{{approval.date}}_请假单.pdf 。这里的 {{ }} 是 Jinja2 模板语法，OpenClaw 会自动从钉钉传来的 JSON 数据里提取 user.name 和 approval.date 字段。
4. 点击“Save & Enable”。

第四步：发布并测试

1. 点击左上角的“Publish”按钮，将这个 Skill 发布到生产环境。
2. 现在，你只需要在钉钉群里 @ 你的机器人，发送一条模拟审批消息（格式： @机器人 请假申请已通过，申请人：张三，日期：2024-10-27 ）。
3. 几秒钟后，打开你的 NAS 共享文件夹，你应该能看到一个名为 张三_2024-10-27_请假单.pdf 的文件。整个流程，从消息接收到文件落地，耗时通常在 3-5 秒。

这个例子看似简单，但它展示了 OpenClaw 自动化工作流的完整闭环： 消息渠道（DingTalk）→ 事件触发（收到特定格式消息）→ 数据解析（提取姓名、日期）→ 工具调用（下载、重命名、上传）→ 结果反馈（可选） 。你后续所有的自动化需求，无论是飞书日报、微信客户打标，还是自动抓取网页，都是在这个模式上叠加。

4. 本地部署详解：Rocky Linux 环境下的全手动掌控

阿里云部署是“开箱即用”，而本地部署则是“亲手造轮子”。我之所以坚持在 Rocky Linux 上做一次全手动部署，是因为只有亲手走一遍，你才能真正理解 OpenClaw 的每个组件是如何咬合在一起的。这对你排查线上问题、定制化开发、或者迁移到其他私有云环境，至关重要。

4.1 环境准备：Rocky Linux 9 的最小化安装与源替换

我选择 Rocky Linux 9，是因为它和 Alibaba Cloud Linux 同源（都基于 RHEL），兼容性最好。安装时，务必选择“Minimal Install”，不要装 GNOME 或 KDE 桌面环境，服务器不需要图形界面，徒增资源消耗和安全风险。

安装完成后，第一件事就是更换为阿里云的国内镜像源，否则 dnf update 会慢到怀疑人生：

# 备份原始 repo 文件
sudo cp -r /etc/yum.repos.d/ /etc/yum.repos.d.backup

# 下载阿里云 Rocky Linux 9 镜像源配置
sudo curl -o /etc/yum.repos.d/rocky.repo https://mirrors.aliyun.com/rockylinux/rocky.repo

# 清理并生成缓存
sudo dnf clean all
sudo dnf makecache

验证是否成功：运行 dnf repolist ，你应该能看到 baseos , appstream , crb 等仓库的 URL 都指向 mirrors.aliyun.com 。如果还是 mirrorlist.centos.org ，说明配置没生效，需要检查 /etc/yum.repos.d/rocky.repo 文件里的 baseurl 是否正确。

4.2 Docker 与 Docker Compose 的安装：为什么不能用 dnf install docker-ce

Rocky Linux 9 默认的 dnf install docker 安装的是 podman ，这是一个容器运行时，但 OpenClaw 的官方 docker-compose.yml 是为 Docker Engine 设计的。所以，我们必须安装 Docker CE（社区版）。

官方推荐的方式是使用 Docker 的官方安装脚本，但这个脚本在国内经常超时。我的实测方案是：

# 1. 安装必要依赖
sudo dnf install -y dnf-plugins-core

# 2. 添加 Docker 的稳定版仓库（使用清华源加速）
sudo dnf config-manager \
    --add-repo \
    https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/centos/docker-ce.repo

# 3. 安装 Docker Engine
sudo dnf install -y docker-ce docker-ce-cli containerd.io

# 4. 启动并设置开机自启
sudo systemctl start docker
sudo systemctl enable docker

# 5. 验证
sudo docker run hello-world

注意： docker-compose 在较新版本中已集成进 docker CLI，但 OpenClaw 的文档仍要求 docker-compose 命令。所以，我们还需要单独安装 docker-compose-plugin ：

sudo dnf install -y docker-compose-plugin
# 验证
docker compose version

4.3 OpenClaw 源码拉取与配置： .env 文件的每一个参数都关乎成败

OpenClaw 的 GitHub 仓库（ openclaw/openclaw ）是公开的。我们不直接 git clone ，而是用 curl 下载最新的 docker-compose.yml 和 .env.example ，因为这是最稳定的部署方式：

# 创建项目目录
mkdir -p ~/openclaw && cd ~/openclaw

# 下载 docker-compose.yml (使用 GitHub Raw 链接)
curl -L https://raw.githubusercontent.com/openclaw/openclaw/main/docker-compose.yml -o docker-compose.yml

# 下载 .env.example 并重命名为 .env
curl -L https://raw.githubusercontent.com/openclaw/openclaw/main/.env.example -o .env

现在，打开 .env 文件，这是整个部署的“心脏”，每一行都必须精确配置：

# 这是你的 OpenClaw 实例的唯一标识，随便起，但要记住
OPENCLAW_INSTANCE_ID=my-local-openclaw

# Web UI 监听的端口，本地部署建议用 3000，避免和系统服务冲突
OPENCLAW_PORT=3000

# 模型服务地址，这里我们用阿里云百炼的公网地址
MODEL_PROVIDER_URL=https://dashscope.aliyuncs.com/api/v1

# 百炼的 API Key，必须是有效的
MODEL_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# 模型名称，必须和百炼控制台里的一致
MODEL_NAME=qwen3.5-plus

# 模型调用的地域，必须和你的 API Key 匹配
MODEL_REGION=cn-beijing

# 数据存储路径，非常重要！所有记忆、Skill、配置都存在这里
DATA_DIR=/home/your-username/openclaw-data

# 日志级别，调试时设为 DEBUG，生产环境用 INFO
LOG_LEVEL=INFO

最关键的 DATA_DIR 参数：它必须是一个 绝对路径 ，并且 OpenClaw 的 Docker 容器必须有读写权限。所以，在保存 .env 后，立即执行：

# 创建数据目录
mkdir -p /home/your-username/openclaw-data

# 更改所有权，让 docker 容器能写入
sudo chown -R 1001:1001 /home/your-username/openclaw-data

这里的 1001:1001 是 OpenClaw 容器内默认的非 root 用户 UID/GID，硬编码在它的 Dockerfile 里。如果你不改权限，容器启动后会报错 Permission denied ，日志里全是 chown: changing ownership of '/data': Operation not permitted 。

4.4 启动与调试：如何读懂 docker compose logs 里的关键信息

一切就绪，启动：

docker compose up -d

等待 30 秒，然后检查状态：

docker compose ps
# 应该看到 openclaw-web, openclaw-gateway, openclaw-db 三个服务都是 "running"

docker compose logs -f openclaw-gateway
# 这是网关服务的日志，重点关注是否有 "Server started on port 3000" 或 "Model provider initialized successfully"

如果日志里出现 Connection refused 或 Invalid API key ，说明模型配置错了；如果出现 Failed to connect to database ，说明 DATA_DIR 权限没设对；如果 openclaw-web 服务一直 restarting，大概率是 openclaw-gateway 没起来，要先解决 gateway 的问题。

成功启动后，在浏览器访问 http://localhost:3000 ，你应该能看到和阿里云部署一模一样的 Web UI。此时，你已经拥有了一个完全可控、完全透明的本地 OpenClaw 实例。你可以随意修改 AGENTS.md 、 SOUL.md ，甚至直接进容器里 docker exec -it openclaw-web bash ，去调试 Python Skill 的代码。这种掌控感，是云服务永远无法提供的。

5. 核心配置深度解析：从 SOUL.md 到 AGENTS.md 的行为编程

OpenClaw 的“个性化配置”，本质上是一种面向业务的低代码行为编程。它用 Markdown 文件代替了传统编程语言，让非技术人员也能定义 AI 的“灵魂”、“身份”和“工作方式”。这三份文件，就是 OpenClaw 的“宪法”。

5.1 SOUL.md ：定义 AI 的价值观与对话风格

SOUL.md 不是写作文，而是写一份“行为契约”。它告诉 AI：“在什么情况下，你必须怎么做”。我给你一个经过实战检验的、用于企业客服场景的 SOUL.md 片段：

## 核心价值观
- **准确第一**：所有回答必须基于知识库或已知事实，不确定的信息，必须明确告知“我无法确认，请联系人工客服”。
- **尊重为本**：禁止使用任何带有评判、指责、或居高临下语气的词汇。例如，不说“你错了”，而说“可能是我理解有偏差，让我再帮您确认一下”。
- **效率至上**：单次回复长度不超过 200 字，关键信息（如订单号、时间、金额）必须加粗。

## 对话风格
- **语气**：专业、温和、略带亲和力，像一位经验丰富的资深客服经理。
- **节奏**：响应延迟必须 < 2 秒。如果需要查询数据库，先回复“正在为您查询订单信息...”，再返回结果。
- **禁忌**：绝不主动询问用户隐私信息（身份证号、银行卡号）；绝不承诺超出公司政策范围的服务。

注意： SOUL.md 里的每一条，都会被 OpenClaw 的内部 LLM 解析器转换成一系列约束规则（Constraints），在每次生成回复前进行校验。比如“单次回复长度不超过 200 字”，系统会在生成后自动截断；“关键信息必须加粗”，系统会用正则表达式匹配订单号、时间戳等模式，并自动包裹 <strong> 标签。这不是简单的文本替换，而是深度的语义理解。

5.2 IDENTITY.md ：塑造 AI 的人格与角色定位

如果说 SOUL.md 是“道”，那么 IDENTITY.md 就是“术”。它定义了 AI 的“人设”，直接影响用户的信任感。一个模糊的 IDENTITY.md 会让 AI 显得像一个没有感情的机器，而一个精准的 IDENTITY.md ，能让用户产生“我在和一个真人对话”的错觉。

以下是我为一家 SaaS 公司的销售助手写的 IDENTITY.md ：

## 基本信息
- **姓名**：小智（Sales Assistant）
- **职位**：XX SaaS 公司首席销售顾问
- **入职时间**：2024年1月1日
- **直属领导**：销售总监 张伟

## 背景设定
- 我熟悉公司所有产品线（CRM、ERP、BI）的详细功能、定价策略、以及与竞品（如 Salesforce、用友）的核心差异。
- 我的数据库截止日期是 2024年10月25日，所有关于产品更新、价格调整的信息，均以此为准。
- 我的主要工作目标是：帮助潜在客户快速了解产品价值，解答技术疑问，并引导其预约产品演示。

## 交互原则
- 当客户询问价格时，我不会直接报价，而是先询问：“请问您是想了解标准版、专业版，还是企业定制版的方案？”
- 当客户提出技术问题时，我会先判断问题复杂度：简单问题（如“如何导出报表？”）直接给出步骤；复杂问题（如“如何实现多组织架构下的权限隔离？”）则回复：“这是一个需要结合您具体业务场景的深度配置，我已为您预约了我们的高级架构师，他将在 1 小时内与您电话沟通。”

这个 IDENTITY.md 的精妙之处在于，它把销售流程中的“资格审查”（Qualification）环节，完全自动化了。AI 不再是被动回答，而是主动引导对话走向，这正是“一个人=一支团队”的体现——它把销售经理的思考框架，固化进了 AI 的行为逻辑里。

5.3 AGENTS.md ：编排自动化工作流的“乐谱”

AGENTS.md 是三者中最技术性的，它用 YAML 格式定义了 AI 如何调用工具（Tools）、如何处理输入（Input）、以及如何生成输出（Output）。它就像一首乐谱， SOUL.md 和 IDENTITY.md 是演奏家的修养和气质，而 AGENTS.md 则规定了每一个音符何时响起。

以下是一个用于“自动抓取竞品官网更新”的 AGENTS.md 示例：

agents:
  - name: "Competitor News Scraper"
    description: "监控指定竞品官网的新闻/博客板块，抓取最新发布的文章标题和摘要"
    input_schema:
      type: object
      properties:
        competitor_url:
          type: string
          description: "竞品官网的 URL，例如 https://competitor.com/blog"
    tools:
      - name: "web_scraper"
        description: "一个强大的网页内容提取工具，支持 CSS 选择器"
        parameters:
          url: "{{input.competitor_url}}"
          selector: "article h2, article p"
    output_schema:
      type: object
      properties:
        latest_news:
          type: array
          items:
            type: object
            properties:
              title:
                type: string
              summary:
                type: string
    # 这是关键！定义了这个 Agent 的触发条件
    triggers:
      - type: "schedule"
        cron: "0 0 * * *" # 每天凌晨 0 点执行
      - type: "channel_message"
        channel: "dingtalk"
        pattern: "抓取竞品新闻"

这个配置的意思是：创建一个叫 Competitor News Scraper 的 Agent，它接受一个 competitor_url 输入，调用 web_scraper 工具去抓取网页，然后把结果整理成一个包含 title 和 summary 的数组。最重要的是 triggers 部分，它定义了这个 Agent 何时会被激活：既可以是定时任务（每天凌晨），也可以是当有人在钉钉群里发消息“抓取竞品新闻”时。

AGENTS.md 的强大之处在于，你可以把多个 Agent 串联起来。比如， Competitor News Scraper 的输出，可以作为下一个 Agent News Summarizer 的输入，后者再调用 qwen3.5-plus 模型，把抓取到的 10 篇文章，浓缩成一篇 300 字的行业简报。这种“Agent 链”（Agent Chain），就是 OpenClaw 构建复杂自动化工作流的基石。

6. 常见问题与独家避坑指南：那些文档里不会写的血泪教训

6.1 “无法将‘openclaw’项识别为 cmdlet” 错误的终极解决方案

这个错误，99% 的情况发生在 Windows 用户试图在 PowerShell 里直接运行 openclaw 命令时。根本原因在于： OpenClaw 本身不是一个可执行的 Windows 程序，它是一个基于 Node.js 的 Web 应用，必须通过 Docker 或 npm 启动 。网上流传的“下载 exe 文件”、“配置 PATH”等方案，全是误导。

正确的做法只有两种：

• 方案一（推荐）：用 Docker Desktop for Windows 。安装 Docker Desktop，然后在 WSL2 或 PowerShell 里，cd 到你的 openclaw 项目目录，运行 docker compose up -d 。这是最标准、最可靠的方案。
• 方案二（仅限开发）：用 npm 全局安装 。但这需要你先安装 Node.js 18+，然后运行 npm install -g openclaw-cli 。但请注意，这个 openclaw-cli 只是一个命令行工具，用来管理本地开发环境，它本身不运行 OpenClaw 服务，最终还是要靠 docker compose 。

实操心得：我曾经花了整整一天，试图在 Windows 上用 nvm 切换 Node 版本、用 npm link 建立软链接，最后发现全是白费力气。Windows 的文件权限、路径分隔符（ \ vs / ）、以及 PowerShell 的执行策略，和 OpenClaw 的 Linux 原生设计存在根本性冲突。 结论：放弃在 Windows 原生系统上直接运行 OpenClaw 的念头，拥抱 Docker，这是唯一的正道 。

6.2 模型切换失败的三大元凶与排查顺序

当你在 Web UI 里切换模型，却看到“Model not found”或“Connection timeout”时，不要慌。按照以下顺序排查，90% 的问题都能秒解：

1. 检查 API Key 的地域匹配性 。这是最高频的错误。打开你的百炼控制台，确认你复制的 API Key，是在哪个地域创建的。然后，回到 OpenClaw 的“模型配置”页，确认“模型地域”下拉框里选中的，是否和 Key 的地域完全一致。哪怕只是“华北2”和“北京”这种细微差别，也会失败。

2. 检查模型名称的拼写与大小写 。 qwen3.5-plus 和 Qwen3.5-Plus 是两个不同的字符串。OpenClaw 的模型路由是严格区分大小写的。你可以在百炼控制台的“模型列表”里，找到你要用的模型， 右键点击模型名称，选择“复制”，然后粘贴到 OpenClaw 的模型输入框里 ，确保 100% 一致。

3. 检查服务器的网络出口 。如果你的服务器在阿里云 VPC 内网，且没有配置 SNAT 或公网 IP，那么它根本无法访问百炼的公网地址 https://dashscope.aliyuncs.com 。此时，你需要：

   • 方案 A：给服务器分配一个弹性公网 IP（EIP）。
   • 方案 B：在 VPC 路由表里，添加一条指向 NAT 网关的路由。
   • 方案 C：最优雅的方案，使用阿里云的“云解析 PrivateZone”，将 dashscope.aliyuncs.com 解析到百炼的内网 VIP（如果你的百炼服务开通了内网访问权限）。

实操心得：我第一次遇到这个问题时，以为是 Key 过期了，反复生成了 5 次新 Key，最后才发现是地域选错了。所以，我的排查清单第一条，永远是“打开百炼控制台，截图对比”。

6.3 性能瓶颈诊断：当 OpenClaw 变慢时，你该看哪里？

OpenClaw 变慢，通常不是模型本身的问题，而是基础设施的瓶颈。我有一套标准化的“三分钟诊断法”：

第一步：看 CPU 和内存

# 在服务器上运行
top -c

观察 dockerd 进程和 openclaw-gateway 进程的 CPU 占用。如果 dockerd 占用超过 80%，说明 Docker daemon 本身过载，可能是你同时运行了太多容器；如果 openclaw-gateway 占用高，说明是模型推理或 Skill 执行太耗 CPU。

第二步：看磁盘 I/O

# 查看磁盘读写延迟
iostat -x 1 3

重点关注 await （平均 I/O 等待时间）和 %util （设备利用率）。如果 await > 10ms 或 %util > 90%，说明磁盘是瓶颈。此时， DATA_DIR 所在的磁盘（通常是系统盘）性能不足。解决方案：将 DATA_DIR 挂载到一块独立的、更高性能的云盘（如 ESSD PL2）上。

第三步：看网络延迟

# 测试到百炼 API 的延迟