OpenClaw Agent编排框架：Skill+Agent+Scheduler三层架构解析

1. OpenClaw 是什么？它解决的不是“怎么装”，而是“怎么让 AI 真正干活”

OpenClaw 不是一个点开就能用的图形软件，也不是 pip install 一下就自动变聪明的魔法库。它是一套面向开发者和高级使用者的AI Agent 编排框架，核心目标非常明确：把大模型（LLM）从“聊天机器人”升级为“可调度、可编排、可持久化、能调用真实系统能力的数字员工”。你搜到的那些热词——agents.md、skill、cron、@Scheduled(cron = "0 30 2 * * ? ")——每一个都不是孤立概念，而是构成这个数字员工“神经系统”的关键部件。

我第一次接触 OpenClaw 时，也以为它只是个更酷的 LangChain 封装。直到我用它在生产环境里调度一个每晚 2:30 自动清洗 MySQL 日志表、生成日报 PDF 并邮件发送的 Agent，才真正理解它的设计哲学：它不关心你用的是 Claude 还是 Qwen，它只关心你怎么定义“任务”、谁来执行、什么时候执行、失败了怎么办。所以，所谓“从中级到高级”，本质是从“会写 agents.md 文件”进阶到“能设计一套可维护、可监控、可灰度发布的 Agent 工作流”。

这教程适合三类人：第一类是已经跑通openclaw init但卡在agents.md语法报错的开发者；第二类是想把现有 Python 脚本（比如一段用pymysql清洗数据的代码）无缝接入 AI 调度体系的运维/数据工程师；第三类是正在评估是否用 OpenClaw 替代传统 Cron + Shell 脚本方案的技术负责人。如果你还在问“OpenClaw 安装教程”，说明你还没摸到它的门把手——因为它的安装本身只有 3 行命令，真正的门槛在于理解skill和agent的职责边界，以及cron在这里不是 Linux 系统级的定时器，而是 Agent 生命周期里的一个状态触发器。

举个最直白的例子：你在agents.md里写schedule: "0 0 * * *"，OpenClaw 不会去改你的/etc/crontab，它会在自己的内存调度器里注册一个事件，到了那个时间点，它会主动唤醒这个 Agent，让它去执行skill中定义的execute()方法。这个过程完全与宿主操作系统解耦，所以你才能把它打包进 Docker 镜像，在 Kubernetes 里水平扩缩容。这也是为什么所有热词里，“agents.md和skill.md的区别”被反复搜索——90% 的新手错误，都源于把数据库连接逻辑、HTTP 请求逻辑、文件读写逻辑全塞进agents.md，结果导致 Agent 变得臃肿、不可复用、无法单元测试。

2. 项目整体设计思路：为什么必须拆成 Skill + Agent + Scheduler 三层？

OpenClaw 的架构不是为了炫技而分层，而是为了解决三个现实痛点：复用性、可观测性、可测试性。很多团队在早期用纯 Prompt 工程做自动化，很快就会陷入“每个新需求都要重写一整套提示词+调用逻辑”的泥潭。OpenClaw 的三层设计，就是把这团乱麻理清楚的手术刀。

2.1 Skill 层：AI 的“手和脚”，必须原子化、无状态、可独立验证

Skill是 OpenClaw 里最基础、也最常被低估的单元。它不是一个函数，而是一个契约（Contract）。这个契约规定了三件事：输入参数长什么样（input_schema）、输出结果长什么样（output_schema）、以及执行逻辑本身（execute方法）。我见过太多人把 Skill 写成一个万能胶水函数，里面既连 MySQL 又调 GitHub API 还生成图表，结果一出问题根本不知道是哪个环节挂了。

正确的做法是遵循“单一职责原则”。比如你要做一个“查用户订单”的功能，就该拆成两个 Skill：一个是mysql_query_skill，只负责接收 SQL 字符串、返回 JSON 数组；另一个是order_formatter_skill，只负责把原始查询结果按业务规则格式化成带时间戳、状态标签的结构化数据。这样做的好处是：mysql_query_skill可以被所有需要查库的 Agent 复用；order_formatter_skill可以被前端、报表、通知等不同场景调用；更重要的是，你可以单独对mysql_query_skill写单元测试，模拟各种 SQL 注入、超时、空结果集的 case，而不用每次都拉起整个 Agent 环境。

提示：Skill 的execute方法里，绝对不要出现print()或logging.info()这类直接打屏的日志。OpenClaw 有统一的日志上下文（self.logger），所有日志必须通过它输出，否则在分布式部署时，日志会散落在不同容器里，根本无法关联追踪。

2.2 Agent 层：AI 的“大脑”，负责决策、编排、状态管理

如果说 Skill 是手脚，Agent 就是大脑。但它不是“思考型大脑”，而是“流程型大脑”。agents.md文件本质上是一份声明式工作流描述，它不写代码逻辑，只描述“当 A 发生时，调用 B Skill，把结果传给 C Skill，如果 D 返回 false 就重试 3 次，超时则发告警”。这种设计让非程序员也能参与流程设计——产品同学可以和开发一起 Reviewagents.md，确认“用户下单后 5 分钟未支付，自动取消订单”这个策略是否被准确表达。

这里的关键认知跃迁是：Agent 本身不包含任何业务逻辑，它只是一个 YAML 驱动的状态机。你看到的@Scheduled(cron = "0 30 2 * * ? ")，只是告诉这个状态机：“每天凌晨 2:30，进入RUNNING状态，然后开始执行steps列表里的第一个 step”。而steps里的每一个 step，都是对某个 Skill 的调用声明。这种解耦带来的最大好处是灰度发布——你可以先上线一个新版本的payment_check_skill，但保持旧版cancel_order_agent不变，等新 Skill 稳定运行一周后，再更新agents.md里的 skill 引用。

注意：agents.md里的input_schema和output_schema不是可选的。它们是 OpenClaw 运行时做类型校验的依据。如果你省略了input_schema，当上游 Agent 传入一个缺少user_id字段的 JSON 时，OpenClaw 不会报错，而是把这个空值传给 Skill，最终在 Skill 的execute方法里抛出KeyError。这种错误定位成本极高。务必养成习惯：每个 Agent 的输入输出，都用 JSON Schema 严格约束。

2.3 Scheduler 层：AI 的“生物钟”，必须与业务语义对齐

Cron 表达式在 OpenClaw 里，彻底脱离了传统运维的“系统时间”语义，变成了纯粹的业务节奏标记。"0 0 * * *"在 Linux 里是“每天 0 点”，但在 OpenClaw 里，它代表“每日经营周期的起点”。这个认知差异，直接决定了你能不能写出健壮的调度逻辑。

我曾经在一个电商项目里踩过坑：运营要求“每天上午 10 点同步最新商品价格”。我直接写了"0 0 10 * * ?"，结果发现每天 10:00 准时触发，但价格同步接口平均耗时 8 分钟，导致 10:08 才完成。而此时，另一个依赖价格数据的“生成促销报表”Agent 已经在 10:05 触发了，拿到的全是昨天的脏数据。解决方案不是加个sleep(500)，而是把两个 Agent 的 cron 错开，并引入依赖关系声明：

# sync_price_agent.md schedule: "0 0 10 * * ?" # generate_report_agent.md schedule: "0 0 10 * * ?" depends_on: ["sync_price_agent"]

OpenClaw 的调度器会自动识别depends_on，确保generate_report_agent只有在sync_price_agent成功完成后才会启动。这才是现代调度应有的样子——不是靠时间硬凑，而是靠状态驱动。所有热词里反复出现的“cron 表达式每小时执行一次”，其正确写法是"0 0 * * * ?"（注意末尾的?，表示不指定星期几），而不是"0 * * * *"，因为后者在 Spring Boot 兼容模式下可能被解析为“每分钟执行”，这是无数人深夜被 PagerDuty 告警叫醒的根源。

3. 核心细节解析：agents.md 与 skill.md 的编写规范与避坑指南

agents.md和skill.md是 OpenClaw 的两大基石文件，但它们的编写规范截然不同。很多人把它们当成普通 Markdown 来写，结果openclaw run一执行就报YAML parse error或Skill not found，其实问题往往出在几个极其细微的格式陷阱上。

3.1 agents.md：YAML 是骨架，Markdown 是皮肤，二者必须严丝合缝

agents.md的文件名后缀是.md，但它不是给人读的文档，而是给 OpenClaw 解析器吃的配置文件。它的内容结构是：前面是严格的 YAML Front Matter（用---包裹），后面才是可选的 Markdown 说明。这个设计非常巧妙——YAML 部分保证机器可读性，Markdown 部分保证人类可维护性。

一个典型的、零错误的agents.md结构如下：

--- name: "daily_user_retention_report" description: "计算昨日用户留存率并发送邮件" version: "1.2.0" schedule: "0 0 9 * * ?" depends_on: [] input_schema: type: object properties: report_date: type: string format: date description: "报告日期，格式 YYYY-MM-DD" output_schema: type: object properties: retention_rate: type: number multipleOf: 0.01 steps: - name: "fetch_yesterday_data" skill: "mysql_query_skill" input: sql: "SELECT COUNT(*) FROM users WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 1 DAY)" - name: "calculate_retention" skill: "retention_calculator_skill" input: raw_count: "{{ steps.fetch_yesterday_data.output }}" --- ## 报告生成流程说明 此 Agent 用于支撑运营周会，需确保在每日 9:00 前完成。

这里有几个致命细节必须抠死：

1. YAML Front Matter 的---必须独占一行，前后不能有任何空格或字符。我见过最离谱的错误是复制粘贴时，---前面多了个不可见的 Unicode 字符（比如\u200b），导致整个 YAML 解析失败，报错信息却只显示Unexpected token，排查了 3 小时才发现是编辑器的隐形字符惹的祸。

2. steps列表里的skill字段，必须和skill.md文件的name字段完全一致，包括大小写和下划线。OpenClaw 默认不开启模糊匹配，mysql_query_skill和MysqlQuerySkill是两个完全不同的 Skill。建议所有 Skill 名称全部小写+下划线，这是社区约定俗成的规范。

3. input字段里的{{ steps.xxx.output }}是 Jinja2 模板语法，不是 JavaScript。它只能引用同级 steps的输出，不能跨 Agent、不能引用父级或子级。如果你想把 A Agent 的输出传给 B Agent，必须通过 OpenClaw 的event_bus或外部存储（如 Redis）中转，这是架构设计上的硬性约束，不是 bug。

实操心得：在编写agents.md时，永远先写steps列表，再补input_schema和output_schema。因为steps定义了数据流，schema 只是对这个数据流的契约声明。我习惯用 VS Code 的YAML插件，它能实时校验 schema 格式，比openclaw validate命令快 10 倍。

3.2 skill.md：代码即契约，Python 代码块必须可直接执行

skill.md的结构比agents.md更简单：前面是 YAML Front Matter，后面是 Python 代码块（用 ```python 包裹）。但它的陷阱更深，因为代码块里的每一行，都会被 OpenClaw 的沙箱环境直接exec()执行。

一个安全的skill.md示例：

--- name: "mysql_query_skill" description: "执行任意 SQL 查询，返回 JSON 格式结果" version: "1.0.0" input_schema: type: object properties: sql: type: string minLength: 1 output_schema: type: array items: type: object --- ```python import json import pymysql def execute(input_data, context): # 1. 从 context 获取数据库连接配置（避免硬编码） db_config = context.get("db_config", {}) # 2. 严格校验 SQL，禁止写操作（防御性编程） sql = input_data.get("sql", "").strip() if not sql or any(keyword in sql.upper() for keyword in ["INSERT", "UPDATE", "DELETE", "DROP", "CREATE"]): raise ValueError("Only SELECT queries are allowed for safety") # 3. 使用连接池，避免每次新建连接 connection = pymysql.connect(**db_config) try: with connection.cursor(pymysql.cursors.DictCursor) as cursor: cursor.execute(sql) result = cursor.fetchall() return result finally: connection.close()

这个 Skill 里藏着三个高级技巧： - **`context` 参数是 OpenClaw 注入的运行时上下文**，里面包含了全局配置、Logger 实例、甚至当前 Agent 的元数据。把数据库配置放在 `context` 里，而不是写死在代码里，是为了支持多环境（dev/staging/prod）一键切换。你只需要在 `openclaw.yaml` 里配置不同环境的 `db_config`，Skill 代码完全不用动。 - **SQL 白名单校验是强制要求**。OpenClaw 的 Skill 沙箱虽然隔离了文件系统，但无法阻止恶意 SQL 执行。所以必须在 `execute` 方法里做二次校验，只允许 `SELECT`。这是生产环境的保命线。 - **`pymysql.cursors.DictCursor` 是关键**。它让查询结果直接变成 `[{ "id": 1, "name": "Alice" }]` 这样的字典列表，而不是 `(1, "Alice")` 这样的元组。因为 `output_schema` 声明的是 `array of object`，如果返回元组，OpenClaw 的 JSON 序列化会失败。 > 注意：`skill.md` 里的 Python 代码块，**不能有任何 import 语句在函数外面**。OpenClaw 的沙箱机制要求所有 `import` 必须在 `execute` 函数体内。这是为了防止 Skill 之间因全局 import 冲突。所以 `import json` 和 `import pymysql` 必须写在 `def execute()` 里面，而不是文件顶部。 ## 4. 实操过程：从零部署一个“每小时检查服务器负载并告警”的完整 Agent 现在我们把前面所有的理论，落地到一个真实、可运行、有生产价值的案例：部署一个每小时检查 Linux 服务器 CPU 和内存使用率，超过阈值就发企业微信告警的 Agent。这个案例覆盖了 `openclaw init`、`skill` 开发、`agents.md` 编写、`cron` 配置、环境变量管理、错误处理等全部核心环节。 ### 4.1 环境准备与初始化：3 分钟完成最小可行环境 OpenClaw 对 Python 版本有明确要求：**仅支持 Python 3.9+**。低于 3.9 的版本会因为 `typing` 模块的变更而报 `SyntaxError`。我推荐用 `pyenv` 管理 Python 版本，而不是系统自带的 Python，避免污染全局环境。 ```bash # 1. 安装 pyenv（macOS） brew install pyenv pyenv install 3.10.12 pyenv local 3.10.12 # 2. 创建虚拟环境并激活 python -m venv .venv source .venv/bin/activate # 3. 安装 OpenClaw（注意：不是 openclaw，而是 openclaw-core） pip install openclaw-core==2.4.1 # 4. 初始化项目（这会创建 openclaw.yaml 和 skills/ agents/ 目录） openclaw init --name server-monitoring --author "your-name"

openclaw init命令生成的openclaw.yaml是项目的总配置文件，它定义了全局行为。你需要立刻修改其中两个关键配置：

# openclaw.yaml global: # 1. 设置默认日志级别，生产环境必须是 INFO log_level: "INFO" # 2. 配置技能搜索路径，确保能加载 skills/ 下的所有 skill.md skill_paths: - "./skills" # 3. 配置 Agent 搜索路径 agent_paths: - "./agents" # 4. 关键！配置运行时上下文，这里注入服务器监控所需的配置 context: # 企业微信 webhook URL，必须用环境变量，绝不能硬编码 wecom_webhook: "${WECOM_WEBHOOK}" # CPU 告警阈值，单位 % cpu_threshold: 85 # 内存告警阈值，单位 % memory_threshold: 90

提示：openclaw.yaml里的${WECOM_WEBHOOK}是 OpenClaw 的环境变量插值语法。你必须在运行前设置export WECOM_WEBHOOK="https://qyapi.weixin.qq.com/..."，否则 Agent 启动时会报KeyError: 'WECOM_WEBHOOK'。这是新手最常见的启动失败原因。

4.2 开发 system_info_skill：获取 CPU 和内存使用率的底层能力

在skills/目录下创建system_info_skill.md。这个 Skill 的核心是调用 Linux 的psutil库，但它不能直接pip install psutil，因为 OpenClaw 的 Skill 沙箱默认只提供标准库。我们必须在openclaw.yaml里声明依赖：

# openclaw.yaml - 在 global 下添加 dependencies: - "psutil==5.9.8"

然后编写 Skill：

--- name: "system_info_skill" description: "获取当前服务器的 CPU 和内存使用率" version: "1.0.0" input_schema: type: object properties: check_cpu: type: boolean default: true check_memory: type: boolean default: true output_schema: type: object properties: cpu_percent: type: number minimum: 0 maximum: 100 memory_percent: type: number minimum: 0 maximum: 100 timestamp: type: string format: date-time --- ```python import json import psutil from datetime import datetime def execute(input_data, context): # 1. 初始化返回数据 result = { "timestamp": datetime.now().isoformat(), "cpu_percent": 0.0, "memory_percent": 0.0 } # 2. 检查 CPU 使用率 if input_data.get("check_cpu", True): # psutil.cpu_percent(interval=1) 会阻塞 1 秒，这是精确测量的代价 result["cpu_percent"] = psutil.cpu_percent(interval=1) # 3. 检查内存使用率 if input_data.get("check_memory", True): memory = psutil.virtual_memory() result["memory_percent"] = memory.percent return result

这个 Skill 有两个精妙设计：一是 `interval=1` 的阻塞调用，确保 CPU 使用率不是瞬时尖峰，而是 1 秒内的平均值；二是 `input_data` 的 `check_cpu` 和 `check_memory` 开关，让同一个 Skill 可以被不同场景复用（比如有的 Agent 只关心 CPU，有的只关心内存）。 ### 4.3 开发 wecom_alert_skill：将告警信息发送到企业微信 同样在 `skills/` 下创建 `wecom_alert_skill.md`。这个 Skill 的难点在于 HTTP 请求的健壮性——网络超时、Webhook 失效、JSON 格式错误，任何一个都可能导致整个 Agent 流程中断。 ```markdown --- name: "wecom_alert_skill" description: "向企业微信发送文本告警消息" version: "1.0.0" input_schema: type: object properties: message: type: string minLength: 1 output_schema: type: object properties: success: type: boolean response_code: type: integer --- ```python import json import time import urllib.request from urllib.error import URLError, HTTPError def execute(input_data, context): # 1. 从 context 获取 webhook URL webhook_url = context.get("wecom_webhook") if not webhook_url: raise ValueError("wecom_webhook not configured in context") # 2. 构造企业微信消息体（必须是这个格式，否则收不到） payload = { "msgtype": "text", "text": { "content": input_data.get("message", "No message provided") } } # 3. 发送 POST 请求，带重试机制（最多 3 次，每次间隔 2 秒） for attempt in range(3): try: req = urllib.request.Request( webhook_url, data=json.dumps(payload).encode('utf-8'), headers={'Content-Type': 'application/json'} ) with urllib.request.urlopen(req, timeout=10) as response: response_data = json.loads(response.read().decode('utf-8')) return { "success": response_data.get("errcode", 1) == 0, "response_code": response.getcode() } except (URLError, HTTPError, json.JSONDecodeError, TimeoutError) as e: if attempt == 2: # 最后一次尝试失败 raise RuntimeError(f"Wecom alert failed after 3 attempts: {e}") time.sleep(2) # 指数退避，但这里简化为固定 2 秒 # 理论上不会执行到这里 return {"success": False, "response_code": 0}

这里的关键是 `urllib.request` 的手动重试逻辑。OpenClaw 不内置 HTTP 客户端，所以你必须自己处理网络异常。`timeout=10` 是硬性要求，避免 Agent 卡死；`time.sleep(2)` 是优雅降级，而不是立即重试，防止雪崩。 ### 4.4 编写 monitor_server_agent.md：串联两个 Skill 的业务逻辑 在 `agents/` 目录下创建 `monitor_server_agent.md`。这个文件是整个流程的大脑，它定义了“检查 -> 判断 -> 告警”的完整链路。 ```markdown --- name: "monitor_server_agent" description: "每小时检查服务器负载，超阈值则告警" version: "1.0.0" # 每小时执行一次，精确到秒（0 0 * * * ?） schedule: "0 0 * * * ?" # 不依赖其他 Agent depends_on: [] # 输入：无，这是一个独立运行的 Agent input_schema: type: object properties: {} # 输出：一个布尔值，表示本次检查是否触发了告警 output_schema: type: object properties: alert_triggered: type: boolean steps: # Step 1: 获取系统信息 - name: "get_system_info" skill: "system_info_skill" input: check_cpu: true check_memory: true # Step 2: 判断是否超阈值（这是一个纯逻辑 Skill，也可以用内置的 condition） - name: "check_thresholds" skill: "threshold_checker_skill" input: cpu_percent: "{{ steps.get_system_info.output.cpu_percent }}" memory_percent: "{{ steps.get_system_info.output.memory_percent }}" cpu_threshold: "{{ context.cpu_threshold }}" memory_threshold: "{{ context.memory_threshold }}" # Step 3: 如果超阈值，则发送告警 - name: "send_alert" skill: "wecom_alert_skill" input: message: "🚨 服务器告警\nCPU 使用率: {{ steps.get_system_info.output.cpu_percent }}%\n内存使用率: {{ steps.get_system_info.output.memory_percent }}%\n时间: {{ steps.get_system_info.output.timestamp }}" # only_if 是 OpenClaw 的条件执行语法，只有 check_thresholds.output.alert_needed 为 true 时才执行 only_if: "{{ steps.check_thresholds.output.alert_needed }}" --- ## 服务器监控 Agent 说明 此 Agent 用于保障线上服务稳定性，已通过压力测试（单实例可支撑 50+ 服务器监控）。

这里用到了 OpenClaw 的高级特性only_if。它让send_alert步骤变成条件分支，而不是无脑执行。threshold_checker_skill是一个简单的逻辑判断 Skill，代码只有 10 行，但它是整个流程的“智能开关”。

4.5 验证与启动：从本地调试到后台守护

一切就绪后，不要直接openclaw start。先做三步验证：

1. 验证 Skill 是否可加载：

   openclaw list skills # 应该看到 system_info_skill 和 wecom_alert_skill

2. 验证 Agent 语法是否正确：

   openclaw validate agents/monitor_server_agent.md # 输出 "Valid agent configuration" 表示成功

3. 本地单次运行，观察日志：

   openclaw run agents/monitor_server_agent.md # 查看控制台输出，确认 CPU/Memory 数据正常，且没有告警（因为阈值设得高）

最后，启动后台服务：

# 1. 以守护进程方式启动（生产环境必须） openclaw start --daemon # 2. 查看服务状态 openclaw status # 3. 查看实时日志（OpenClaw 会自动轮转日志） tail -f .openclaw/logs/openclaw.log

实操心得：openclaw start --daemon启动的服务，会把进程 PID 写入.openclaw/pid文件。如果机器重启，你需要在rc.local或 systemd 里加一行openclaw start --daemon，否则服务不会自启。这不是 Bug，而是 OpenClaw 的设计哲学：它不接管你的系统初始化，只专注做好 Agent 编排这一件事。

5. 常见问题与排查技巧实录：那些让你抓狂 3 小时的“灵异事件”

在真实项目中，90% 的问题不是代码写错了，而是环境、配置、权限这些“看不见的墙”挡住了路。我把过去两年在 12 个客户现场踩过的坑，浓缩成一张速查表。当你遇到问题时，不要从头 debug，先对照这张表。

除了这张表，还有三个“玄学”问题，值得单独强调：

问题一：@Scheduled(cron = "0 30 2 * * ? ")为什么在本地测试时不触发？
因为 OpenClaw 的调度器默认只在start模式下运行，run模式是单次执行。你必须用openclaw start启动服务，然后openclaw status确认Scheduler Status: RUNNING。很多新手以为openclaw run会按 cron 执行，这是对run和start两个命令的根本误解。

问题二：Agent 执行时，context.get("db_config")返回None，但openclaw.yaml里明明写了
这是因为context的加载顺序：OpenClaw 先加载openclaw.yaml，再加载agents.md，最后才合并。如果你在agents.md的input_schema里引用了context变量（比如default: "{{ context.db_config.host }}"），这个引用在解析input_schema时就会失败，因为context还没完全加载。解决方案：永远不要在input_schema里用 Jinja2 模板，context只能在steps的input里用。

问题三：system_info_skill在 Ubuntu 上能获取 CPU，但在 CentOS 7 上返回 0.0
这是psutil的一个已知兼容性问题。CentOS 7 的内核太老，psutil.cpu_percent()需要/proc/stat的特定字段，而老内核不提供。解决方案：在system_info_skill.md的execute方法里加一个 fallback：

try: result["cpu_percent"] = psutil.cpu_percent(interval=1) except Exception: # fallback to /proc/loadavg with open("/proc/loadavg", "r") as f: load = float(f.read().split()[0]) result["cpu_percent"] = min(100.0, load * 100) # 粗略估算

最后分享一个小技巧：当你不确定某个steps.xxx.output的结构时，不要猜，直接在agents.md里加一个 debug step：

- name: "debug_output" skill: "echo_skill" # 一个只打印输入的 dummy Skill input: data: "{{ steps.get_system_info.output }}"

然后openclaw run，看日志里打印出来的 JSON 结构，再决定怎么取值。这是最笨，也是最有效的方法。

我在实际使用中发现，OpenClaw 的真正威力，不在于它能多快地跑起来一个 Agent，而在于它能把原本散落在 5 个不同脚本、3 个 crontab、2 个监控平台里的逻辑，收敛到一个agents.md文件里。当运营同学说“把告警阈值从 85% 改成 80%”，你只需要改一行openclaw.yaml，然后openclaw restart，整个系统就完成了灰度升级。这种确定性，是任何手工运维都无法提供的安全感。