OpenClaw Agent界面深度解读:6大模块与实操配置

很多人第一次打开 OpenClaw 的 Agent 界面，会觉得它很“直观”：

• • 有 Overview
• • 有 Files
• • 有 Tools
• • 有 Skills
• • 有 Channels
• • 有 Cron Jobs

看起来像一套很常见的控制台。

但真正开始用之后，问题往往就来了。

比如：

• • Overview 里看到的这些字段，实际上对应哪段配置？
• • Files 面板展示的是“工作区文件”，还是“运行时状态”？
• • Tools 到底是单纯的工具列表，还是权限系统的一部分？
• • Skills 和 Tools 的边界到底在哪？
• • Skills 到底应该装到哪里？按 Agent 配置时最稳的方式是什么？
• • Channels 面板改完以后，到底影响的是入口、权限，还是路由？
• • Cron Jobs 到底是一个“提醒器”，还是一个完整的任务调度系统？

如果这些问题没有搞清楚，Agent 界面就很容易被误用成“一个好看的 UI”，而不是“一个真正可运维、可扩展、可调试的控制平面”。

所以这篇文章，我不打算只做“面板说明书”，而是要把 OpenClaw Agent 界面的这 6 个模块，放回到系统架构里讲清楚：

它们各自到底管什么、背后对应哪类配置、最常见的落地方式是什么，以及你应该按什么顺序去真正把一个 Agent 配起来。

文章会重点覆盖：

1. 1. Overview：Agent 运行摘要到底在看什么
2. 2. Files：工作区文件、引导文件、记忆文件和会话文件的关系
3. 3. Tools：工具目录、权限策略、运行时限制与按 Agent 控制
4. 4. Skills：技能系统、加载优先级、安装方式、按 Agent 配置方式
5. 5. Channels：接入渠道、访问控制、分组策略、按渠道差异化配置
6. 6. Cron Jobs：定时任务、调度模型、主会话与隔离会话、投递方式

尤其是 Skills 这一节，我会把几种常见安装方式都拆开讲，包括：

• • ClawHub
• • openclaw skills 检查与排障
• • npx skills add
• • 本地 workspace/skills
• • ~/.openclaw/skills
• • skills.load.extraDirs

并专门讲清楚：

如果你有多个 Agent，到底应该装成“单 Agent 可见”，还是“全局共享可见”。

如果你把这篇文章真正看完，收获不会只是“会点配置”，而是会对 OpenClaw 的 Agent 组织方式建立一个比较完整的技术模型。

一、先建立一个总认知：Agent 界面不是 6 个独立面板，而是 6 个控制面

从工程视角看，OpenClaw Agent 界面里的这 6 个模块，其实分别对应着 6 类控制面：

所以一个更准确的理解方式是：

Agent 界面并不是“配置展示页”，而是 OpenClaw 对角色、文件、能力、渠道和自动化的统一控制面。

这点非常重要。

因为你后面会看到，很多看似属于某个单独面板的事情，实际上会影响另外两个面板。

举个例子：

• • 你给 Agent 装了一个 Skill，不只是 Skills 面板多了一项
• • 它还会影响 Tools 的可用能力
• • 还会影响模型提示词里注入的可用 Skills 列表
• • 如果 Skill 依赖环境变量，还会影响 agent run 的注入环境
• • 如果 Skill 要求二进制存在，还会影响 eligibility（可用性）状态

也就是说，这 6 个模块是联动的。

二、Overview：它不是“简介页”，而是 Agent 的运行摘要页

官方文档没有把 /agents 里的 Overview 面板逐字段单独写成一篇文档，但结合配置参考、Control UI 能力以及 Agent 运行模型，可以把它理解为：

当前 Agent 的角色定义、默认运行方式、关键运行参数的摘要视图。

它通常回答的是 5 个问题：

1. 1. 这个 Agent 叫什么、身份是什么？
2. 2. 它的工作区在哪里？
3. 3. 它默认用哪个模型？
4. 4. 它有没有特殊运行时，例如 ACP？
5. 5. 它有没有单独的工具、沙箱、子 Agent、身份配置？

1. Overview 背后最核心的配置块：agents.list[]

在 OpenClaw 里，最关键的 Agent 定义基本都在这里：

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        name: "Main Agent",
        workspace: "~/.openclaw/workspace",
        agentDir: "~/.openclaw/agents/main/agent",
        model: "anthropic/claude-opus-4-6",
        identity: {
          name: "Samantha",
          emoji: "🦥",
          avatar: "avatars/samantha.png"
        },
        sandbox: { mode: "off" },
        subagents: { allowAgents: ["researcher", "scraper"] },
        tools: {
          profile: "coding",
          allow: ["browser"],
          deny: ["canvas"]
        }
      }
    ]
  }
}

2. Overview 最值得关注的字段

id

Agent 的稳定标识。

这是系统级 ID，不只是 UI 名称。很多配置、绑定、子 Agent 授权、Session 路径，都靠它识别。

default

是否为默认 Agent。

如果没有更具体的绑定规则命中，消息就会进默认 Agent。

workspace

Agent 的工作区。

这是 Files 面板背后的根目录，也是这个 Agent 的“人格文件、记忆文件、技能文件”最常见的落点。

agentDir

Agent 的状态目录。

它通常放：

• • auth profiles
• • per-agent models
• • agent 级状态文件

model

默认模型。

可以是字符串，也可以是对象：

model: "openai/gpt-4.1"

或者：

model: {
  primary: "zai/glm-5",
  fallbacks: ["moonshot/kimi-k2.5"]
}

runtime

如果这个 Agent 默认不是普通对话 Agent，而是 ACP harness，会在这里定义。

例如：

runtime: {
  type: "acp",
  acp: {
    agent: "codex",
    backend: "acpx",
    mode: "persistent",
    cwd: "/workspace/openclaw"
  }
}

identity

控制 UI 头像、名称、主题等角色展示。

这在 Overview 里通常会被汇总为 Agent 身份信息。

sandbox

这个 Agent 是否跑在沙箱里，以及沙箱的访问范围。

subagents

这个 Agent 是否允许调用哪些子 Agent。

3. 实际操作建议：Overview 先配什么？

如果你要新建一个 Agent，我建议先完成这 4 项：

1. 1. id
2. 2. workspace
3. 3. agentDir
4. 4. model

然后再逐步追加：

• • identity
• • tools
• • sandbox
• • subagents
• • runtime

不要一开始什么都堆进去。Agent 的基础运行摘要越简单，后面越好维护。

三、Files：它不是普通“文件浏览器”，而是 Agent 的上下文底座

很多人看到 Files 面板，会下意识把它理解成“工作区目录”。

这没错，但不完整。

在 OpenClaw 里，Files 背后真正控制的是：

这个 Agent 启动时会读哪些 bootstrap 文件、长期记忆怎么组织、会话文件怎么落盘、以及技能和本地资源从哪里加载。

所以 Files 本质上是这个 Agent 的上下文底座。

四、Files 面板背后的 3 类文件

1. Workspace bootstrap 文件

默认工作区会自动创建这些文件：

• • AGENTS.md
• • SOUL.md
• • TOOLS.md
• • IDENTITY.md
• • USER.md
• • HEARTBEAT.md
• • BOOTSTRAP.md（仅 brand-new workspace）
• • MEMORY.md（可选，不自动创建）

它们不是普通说明文档，而是 Agent 的启动上下文组成部分。

2. Memory / 日志类文件

比如：

• • MEMORY.md
• • memory/YYYY-MM-DD.md

这些用于做长期记忆与日常笔记。

3. Session / 运行状态文件

这类文件通常不在 workspace 根目录下，而在 OpenClaw 状态目录里：

• • ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl
• • ~/.openclaw/agents/<agentId>/sessions/sessions.json

所以要注意：

Files 面板看到的工作区文件，不等于全部运行状态。

真正的会话记录、路由元数据、last route 等，很多是在 state dir 里。

五、Files 相关配置，最关键的是 workspace

1. 默认工作区

OpenClaw 默认会使用：

~/.openclaw/workspace

2. 按 Agent 自定义工作区

在多 Agent 场景里，最常见做法是每个 Agent 单独一个 workspace：

{
  agents: {
    list: [
      {
        id: "research",
        workspace: "~/.openclaw/workspace-research"
      },
      {
        id: "ops",
        workspace: "~/.openclaw/workspace-ops"
      }
    ]
  }
}

3. 是否跳过 bootstrap 文件生成

如果你自己已经维护了一套工作区文件，可以关闭自动生成：

{
  agent: {
    skipBootstrap: true
  }
}

六、Files 实操上最重要的 4 个结论

结论 1：人格与行为，不写在 UI 里，写在文件里

真正定义 Agent 风格与边界的，很多并不在 openclaw.json 里，而是在：

• • SOUL.md
• • AGENTS.md
• • USER.md
• • TOOLS.md

结论 2：多 Agent 最好不要共用一个 workspace

因为会带来：

• • 记忆污染
• • 技能覆盖冲突
• • 文件上下文混杂

结论 3：Subagent 注入的 bootstrap 文件更少

子 Agent 并不会自动得到与主会话完全一样的 bootstrap 注入。

结论 4：远程 Gateway 时，Files 的真实源头在 Gateway 主机

如果 Gateway 跑在另一台机器上，你本地改文件，不一定影响实际 Agent。

七、Tools：它不是“功能菜单”，而是 Agent 的能力边界系统

Tools 面板最容易被误解。

很多人会把它看成：

“这个 Agent 能用哪些工具。”

但更准确的说法其实是：

这个 Agent 的工具目录 + 工具权限 + 工具运行策略。

OpenClaw 里的 Tools 不只是列出有哪些工具，还会受到以下几层因素共同控制：

1. 1. tools.profile
2. 2. tools.allow / tools.deny
3. 3. tools.byProvider
4. 4. per-agent 工具覆盖
5. 5. sandbox 限制
6. 6. elevated 策略
7. 7. session visibility / agentToAgent 可见性

Control UI 的 /agents Tools 面板会通过 tools.catalog 获取运行时工具目录，并给每个工具标注 core / plugin 等信息；但最终是否真的能调用成功，仍然取决于配置优先级和运行时策略。

八、Tools 的核心配置方式

1. tools.profile

它相当于一个基础工具包。

{
  tools: {
    profile: "coding"
  }
}

常见 profile：

• • minimal
• • coding
• • messaging
• • full

比如 coding 大致会包含：

• • 文件系统工具
• • runtime 工具
• • session 工具
• • memory 工具

2. tools.allow / tools.deny

deny 优先。

{
  tools: {
    profile: "coding",
    deny: ["browser", "canvas"]
  }
}

3. tools.byProvider

按模型或 provider 单独收紧/放宽。

{
  tools: {
    profile: "coding",
    byProvider: {
      "openai/gpt-5.2": {
        allow: ["group:fs", "sessions_list"]
      },
      "google-antigravity": {
        profile: "minimal"
      }
    }
  }
}

4. per-agent 工具覆盖

你可以在单个 Agent 上继续覆盖：

{
  agents: {
    list: [
      {
        id: "reporter",
        tools: {
          profile: "coding",
          deny: ["exec", "process", "browser", "canvas"]
        }
      }
    ]
  }
}

这特别适合角色分工型 Agent。

九、Tools 里最值得重点理解的几个子项

1. tools.elevated

控制 host elevated exec。

{
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: ["123456789"]
      }
    }
  }
}

如果不理解这个配置，就容易误以为“开了 exec 就等于什么都能执行”。

其实 elevated host exec 是额外一层。

2. tools.sessions

控制 session 工具能看多大范围：

{
  tools: {
    sessions: {
      visibility: "tree"
    }
  }
}

可选：

• • self
• • tree
• • agent
• • all

3. tools.agentToAgent

控制是否允许跨 Agent 会话操作：

{
  tools: {
    agentToAgent: {
      enabled: true,
      allow: ["research", "ops"]
    }
  }
}

4. tools.exec

控制 exec 生命周期：

{
  tools: {
    exec: {
      backgroundMs: 10000,
      timeoutSec: 1800,
      cleanupMs: 1800000,
      notifyOnExit: true
    }
  }
}

5. tools.web

控制 web_search / web_fetch：

{
  tools: {
    web: {
      search: {
        enabled: true,
        maxResults: 5,
        timeoutSeconds: 30
      },
      fetch: {
        enabled: true,
        maxChars: 50000,
        timeoutSeconds: 30
      }
    }
  }
}

十、Tools 面板的实际配置策略：别先追求全开，先按角色授权

如果你有多 Agent，我更推荐这样配：

researcher

• • read
• • web_fetch
• • browser
• • 少量 sessions 能力

scraper

• • read
• • write
• • edit
• • exec
• • process
• • browser

cleaner

• • read
• • write
• • edit
• • 不给 browser

reporter

• • read
• • write
• • edit
• • 不给 exec/process/browser

也就是说：

Tools 面板最重要的不是“能不能多”，而是“边界清不清晰”。

十一、Skills：这是 Agent 界面里最容易低估、但最值得认真配置的一块

OpenClaw 的 Skills 不是“插件列表”的简单翻版。

它本质上是一套 AgentSkills-compatible 能力包系统。

一个 Skill 通常就是一个目录，里面最关键的文件是：

SKILL.md

它包含：

• • YAML frontmatter
• • 描述
• • 使用说明
• • 环境要求
• • 可选安装元数据
• • 让模型在需要时读取和遵循的操作规则

也就是说，Skill 不是“给 UI 看”的，而是“给 Agent 学”的。

十二、Skills 的加载位置与优先级

OpenClaw Skills 的加载优先级非常关键：

1. 1. <workspace>/skills（最高）
2. 2. ~/.openclaw/skills
3. 3. bundled skills（内置）
4. 4. skills.load.extraDirs（最低）

这意味着：

• • workspace skills 适合单 Agent / 单工作区定制
• • managed skills 适合全局共享
• • bundled skills 是系统自带
• • extraDirs 适合挂外部公共技能包目录

这一点一旦搞清楚，很多“为什么这个 Agent 有那个 Skill、另一个没有”的问题就很容易解释了。

十三、按 Agent 配置 Skills，最核心的是先搞清“范围”

方式 A：只给某一个 Agent 用

最稳的方式：装到这个 Agent 的工作区里。

例如：

~/.openclaw/workspace-research/skills/my-skill/SKILL.md

这样只有 research 这个 Agent 看得到。

方式 B：给所有 Agent 共用

放到：

~/.openclaw/skills/my-skill/SKILL.md

这样同一台机器上的多个 Agent 都能看到。

方式 C：挂共享目录

{
  skills: {
    load: {
      extraDirs: ["~/Projects/shared-skills"]
    }
  }
}

这样适合团队统一维护一套技能包。

十四、Skills 的几种安装方式，应该怎么选？

这是很多人最关心的部分。

我建议你把它们理解成 3 条主线 + 2 条辅助线。

主线 1：ClawHub（OpenClaw 原生、最推荐）

ClawHub 是 OpenClaw 的公共 Skills 注册中心。

最常用命令：

npm i -g clawhub

搜索：

clawhub search "calendar"

安装：

clawhub install <skill-slug>

更新：

clawhub update --all

同步：

clawhub sync --all

ClawHub 按 Agent 安装，最关键的是 --workdir

ClawHub 默认安装到当前工作目录下的 ./skills，如果 OpenClaw workspace 已配置，也会回退到该 workspace。

所以如果你想明确装到某个 Agent 的工作区，最稳的方式有两种：

方法 1：进入目标 Agent 的 workspace 再装

cd ~/.openclaw/workspace-research
clawhub install my-skill-pack

方法 2：直接指定 --workdir

clawhub install my-skill-pack --workdir ~/.openclaw/workspace-research

这样落地后，Skill 会进入：

~/.openclaw/workspace-research/skills/

也就是这个 Agent 独享。

如果你想做“多 Agent 共用”怎么办？

ClawHub 默认更适合工作区级安装。

如果要共享，通常更稳的办法不是让多个 Agent 都各装一份，而是：

• • 把 Skill 放到 ~/.openclaw/skills
• • 或者维护一个公共目录，再用 skills.load.extraDirs

主线 2：本地手工创建 workspace/skills

这是最朴素、最可控的方式。

比如：

mkdir -p ~/.openclaw/workspace-research/skills/my-skill

创建：

~/.openclaw/workspace-research/skills/my-skill/SKILL.md

最小示例：

---
name: my-skill
description: Do one specific workflow well
---

# My Skill

Use this skill when...

这条路线最适合：

• • 自己写 Skill
• • 做内部专用 Skill
• • 单 Agent 定制

主线 3：~/.openclaw/skills 托管覆盖

如果你不想改 bundled skill，又想做本地覆盖或共享，可以用：

~/.openclaw/skills/<name>/SKILL.md

这是官方推荐的 managed override 思路。

它特别适合：

• • 覆盖内置 Skill
• • 本机多个 Agent 共用
• • 不碰仓库源文件

辅助线 1：skills.load.extraDirs

这更像“挂载外部技能包目录”。

{
  skills: {
    load: {
      extraDirs: [
        "~/Projects/agent-scripts/skills",
        "~/Projects/oss/some-skill-pack/skills"
      ]
    }
  }
}

它的优点是：

• • 易于统一维护
• • 适合团队共享技能包
• • 不污染 workspace

缺点是优先级最低。

辅助线 2：npx skills add

这是很多人会提到的一条路。

先说结论：

npx skills add 属于更通用的 AgentSkills 生态管理方式，不是 OpenClaw Control UI 唯一的官方原生安装入口，但在很多场景下非常实用。

它支持的命令大致包括：

npx skills add <source>
npx skills list
npx skills check
npx skills update

帮助信息里常见的安装选项包括：

• • -g, --global
• • -a, --agent <agents>
• • -s, --skill <skills>
• • --copy
• • -y, --yes

例如：

npx skills add vercel-labs/agent-skills -y

或：

npx skills add vercel-labs/agent-skills -g -y

怎么理解这条路线？

更稳妥的理解方式是：

• • ClawHub 更像 OpenClaw 的原生技能注册与安装路径
• • npx skills 更像通用 AgentSkills 包管理路线

所以在 OpenClaw 环境里，如果你打算用 npx skills add，最务实的建议是：

场景 1：你只想给某个工作区 / 某个 Agent 用

进入目标 workspace 再执行，或把安装结果整理到该 workspace 的 skills/ 下。

场景 2：你想全局共享

使用 -g，然后再根据你的 OpenClaw 技能加载策略决定是否通过：

• • ~/.openclaw/skills
• • skills.load.extraDirs

来统一暴露给 OpenClaw。

场景 3：你本来就在多代理工具链里（不止 OpenClaw）

这时 --agent 会更有用，因为它能按该生态支持的 agent host 分发技能。

一个重要提醒

如果你的目标是 OpenClaw 内稳定、可控、可解释地按 Agent 管理 Skills，我更推荐优先顺序是：

1. 1. workspace/skills
2. 2. ~/.openclaw/skills
3. 3. skills.load.extraDirs
4. 4. ClawHub
5. 5. npx skills add

不是因为 npx skills add 不好，而是因为对 OpenClaw 来说，前面几种路径的“归属关系”更清楚。

十五、Skills 的 eligibility（可用性）不是“装了就能用”

Skill 会在加载时根据 metadata 做过滤。

常见 gating 条件包括：

• • requires.bins
• • requires.anyBins
• • requires.env
• • requires.config
• • os

示例：

---
name: gemini
description: Use Gemini CLI for coding assistance.
metadata:
  {
    "openclaw": {
      "requires": { "bins": ["gemini"] },
      "primaryEnv": "GEMINI_API_KEY"
    }
  }
---

这意味着即使你把 Skill 放对了目录，它也可能因为：

• • 缺 CLI
• • 缺 env
• • 缺 config
• • OS 不匹配

而不 eligible。

怎么检查？

用：

openclaw skills list
openclaw skills list --eligible
openclaw skills info <name>
openclaw skills check

这一步非常适合用来排查 Skills 面板里“为什么看不到 / 为什么不可用”。

十六、skills.entries：这是 Skills 面板背后最实用的配置块

你可以在 openclaw.json 里对某个 Skill 做启停、env 注入、apiKey 注入。

{
  skills: {
    entries: {
      "nano-banana-pro": {
        enabled: true,
        apiKey: { source: "env", provider: "default", id: "GEMINI_API_KEY" },
        env: {
          GEMINI_API_KEY: "GEMINI_KEY_HERE"
        }
      },
      peekaboo: { enabled: true },
      sag: { enabled: false }
    }
  }
}

常见用途

• • 临时禁用某个 Skill
• • 给某个 Skill 注入 API key
• • 给 Skill 提供运行参数 env

注意点

• • skill 名含连字符时，建议加引号
• • 如果定义了 metadata.openclaw.skillKey，那这里要用 skillKey，而不是目录名

十七、Channels：它不是“聊天接入页”，而是 Agent 的消息入口控制面

Channels 面板并不只是显示“已接入 Telegram / WhatsApp / Discord”。

它真正控制的是：

1. 1. 这个 Agent 从哪里收消息
2. 2. 谁可以联系它
3. 3. 群和私聊的规则是否不同
4. 4. 是否需要 mention 才触发
5. 5. 消息历史保留多少
6. 6. 是否支持 reaction / streaming / webhook 等渠道特性

所以 Channels 实际上是 入口控制 + 渠道行为配置 + 一部分路由策略。

十八、Channels 的通用配置骨架

OpenClaw 的 channels 配置总体上长这样：

{
  channels: {
    defaults: {
      groupPolicy: "allowlist"
    },
    telegram: {
      enabled: true,
      botToken: "your-bot-token",
      dmPolicy: "pairing"
    },
    whatsapp: {
      dmPolicy: "pairing"
    }
  }
}

几个最关键的通用概念

dmPolicy

控制私聊访问。

可选：

• • pairing
• • allowlist
• • open
• • disabled

groupPolicy

控制群消息访问。

可选：

• • allowlist
• • open
• • disabled

allowFrom

私聊允许用户。

groupAllowFrom

群内允许触发者。

groups

允许哪些群，以及每个群的细粒度规则。

十九、以 Telegram 为例，Channels 最常见的实战配置

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "your-bot-token",
      dmPolicy: "allowlist",
      allowFrom: ["tg:123456789"],
      groups: {
        "*": { requireMention: true },
        "-1001234567890": {
          requireMention: false,
          allowFrom: ["123456789", "987654321"],
          topics: {
            "99": {
              requireMention: false,
              skills: ["search"],
              systemPrompt: "Stay on topic."
            }
          }
        }
      },
      historyLimit: 50,
      replyToMode: "first",
      linkPreview: true,
      streaming: "partial",
      actions: {
        reactions: true,
        sendMessage: true
      },
      mediaMaxMb: 100
    }
  }
}

这段配置里最容易踩的坑

坑 1：把群 ID 填进 groupAllowFrom

错。

• • 群 ID 放 groups
• • 用户 ID 放 groupAllowFrom / allowFrom

坑 2：把 allowFrom 当群白名单

错。

它是用户白名单，不是群白名单。

坑 3：以为 requireMention: false 就等于所有人都能用

不一定。

还要看：

• • group 是否在 allowlist 内
• • sender 是否在 allowFrom / groupAllowFrom 内
• • groupPolicy 是 open 还是 allowlist

二十、Channels 面板真正值得做的，是“渠道分工”而不是“渠道堆叠”

很多人一上来接：

• • Telegram
• • WhatsApp
• • Discord
• • Slack

但没有想清楚每个渠道给谁用。

更稳的做法是：

• • Telegram：自己和工作群
• • Discord：团队协作
• • WhatsApp：个人入口
• • Slack：企业内部

再配合 bindings 做 Agent 路由。

比如：

{
  bindings: [
    {
      agentId: "ops",
      match: {
        channel: "telegram",
        peer: { kind: "group", id: "-1001234567890" }
      }
    },
    {
      agentId: "main",
      match: {
        channel: "telegram"
      }
    }
  ]
}

这时候 Channels 和 Agent 路由才真正联动起来。

二十一、Cron Jobs：这不是“定时提醒”，而是 Gateway 内建调度器

如果你只把 Cron Jobs 理解成“提醒”，就太小看它了。

OpenClaw 的 Cron 是 Gateway 内建 scheduler，可以：

• • 持久化任务
• • 定时唤醒 Agent
• • 在主会话中触发 system event
• • 在隔离会话中跑独立 agent turn
• • 选择 announce / webhook / none 三种投递模式
• • 保留 run logs
• • 做定时自动化

也就是说，Cron Jobs 面板本质上是：

Agent 自动化与后台任务控制面。

二十二、Cron 的 2 种核心执行模式

1. Main session job

把任务塞进主会话，通常通过 heartbeat 跑。

适合：

• • 提醒
• • 给主 Agent 补一个 system event
• • 需要沿用主上下文的任务

2. Isolated job

跑独立 agent turn，在：

cron:<jobId>

这样的独立 session 里执行。

适合：

• • 后台巡检
• • 定时报表
• • 定时抓取
• • 不想污染主会话的工作

这两者的差别，决定了 Cron Jobs 面板到底是“轻提醒”，还是“真正的自动任务系统”。

二十三、Cron 的关键配置块

1. 顶层 cron

{
  cron: {
    enabled: true,
    maxConcurrentRuns: 2,
    webhookToken: "replace-with-dedicated-token",
    sessionRetention: "24h",
    runLog: {
      maxBytes: "2mb",
      keepLines: 2000
    }
  }
}

这个部分控制的是调度系统本身。

2. 单个 job 的核心要素

一个 cron job 本质上是：

• • schedule
• • sessionTarget
• • wakeMode
• • payload
• • delivery
• • deleteAfterRun
• • 可选 agentId / model / thinking 覆盖

二十四、最常见的 Cron 实战例子

例子 1：一次性提醒

openclaw cron add \
  --name "Reminder" \
  --at "2026-02-01T16:00:00Z" \
  --session main \
  --system-event "Reminder: check the cron docs draft" \
  --wake now \
  --delete-after-run

例子 2：每天早上 7 点自动简报

openclaw cron add \
  --name "Morning brief" \
  --cron "0 7 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "Summarize overnight updates." \
  --announce \
  --channel telegram \
  --to "tg:123456789"

例子 3：JSON 方式定义隔离任务

{
  "name": "Morning brief",
  "schedule": { "kind": "cron", "expr": "0 7 * * *", "tz": "Asia/Shanghai" },
  "sessionTarget": "isolated",
  "wakeMode": "next-heartbeat",
  "payload": {
    "kind": "agentTurn",
    "message": "Summarize overnight updates.",
    "lightContext": true
  },
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "to": "tg:123456789",
    "bestEffort": true
  }
}

二十五、Cron Jobs 面板里最该理解的 5 个字段

1. schedule.kind

可选：

• • at
• • every
• • cron

2. sessionTarget

可选：

• • main
• • isolated

3. wakeMode

可选：

• • now
• • next-heartbeat

4. delivery.mode

可选：

• • announce
• • webhook
• • none

5. lightContext

适合不需要完整 bootstrap 注入的定时杂务。

二十六、Cron vs Heartbeat：别混用概念

一个非常常见的误区是：

“反正都能定时唤醒 Agent，Cron 和 Heartbeat 差不多。”

其实不是。

Heartbeat 更适合：

• • 主会话周期性检查
• • 轻量巡查
• • 批量检查多个事项
• • 需要保留“主人格连续感”的任务

Cron 更适合：

• • 精确时间
• • 一次性提醒
• • 独立后台任务
• • 明确 delivery 目标
• • 指定 agent turn 的自动化

一句话：

Heartbeat 更像“日常心跳”，Cron 更像“调度系统”。

二十七、把这 6 个面板串起来，才是正确的 Agent 配置流程

如果你真要从零把一个 Agent 配好，我推荐按下面顺序操作。

第一步：先配 Overview

确定：

• • id
• • workspace
• • agentDir
• • model
• • identity

第二步：再整理 Files

准备：

• • AGENTS.md
• • SOUL.md
• • USER.md
• • TOOLS.md
• • HEARTBEAT.md
• • 可选 MEMORY.md

第三步：再配 Tools

先选一个 profile，再按角色做 allow / deny。

第四步：再装 Skills

问自己 3 个问题：

1. 1. 这个 Skill 是单 Agent 用，还是多 Agent 共用？
2. 2. 用 ClawHub 装，还是本地手工维护？
3. 3. 是否需要 env / apiKey / config 注入？

第五步：再接 Channels

决定：

• • 谁能联系它
• • 从哪个渠道进来
• • 群里是否 requireMention
• • 是否需要绑定到某些 group/topic

第六步：最后再加 Cron Jobs

因为自动化是最容易“跑起来之后才发现乱”的部分。

先把角色、工具、技能、入口都理顺，再上调度最稳。

二十八、给你 3 套最实用的 Skills 安装策略

策略 A：单 Agent 专属技能

适合：researcher / scraper / reporter 这种强分工角色。

做法：

clawhub install my-skill --workdir ~/.openclaw/workspace-research

或者手工放：

~/.openclaw/workspace-research/skills/my-skill/

策略 B：本机所有 Agent 共用

适合：通用能力，例如 image、browser 辅助、通用工具 Skill。

做法：

~/.openclaw/skills/my-skill/

策略 C：团队共享技能包

适合多人维护、多项目复用。

{
  skills: {
    load: {
      extraDirs: ["~/company-openclaw-skills"]
    }
  }
}

二十九、最常见的 8 个坑

1. 以为 Skills 装了就一定可用

不对。还要过 eligibility 检查。

2. 以为 Files 面板 = 全部状态

不对。sessions 和 auth 很多在 ~/.openclaw/agents/<agentId>/...

3. 多个 Agent 共用同一个 workspace

很容易污染。

4. Tools 一开始全开

后面很难收。

5. allowFrom、groupAllowFrom、groups 混用

这是渠道配置里最常见的错。

6. ClawHub 不指定 workdir 就装错 Agent

如果你有多个 workspace，这事非常容易发生。

7. 用 npx skills add，但没想清 OpenClaw 实际从哪里加载

结果“看上去装了，Agent 实际没看到”。

8. 把 Cron 当 Heartbeat 用，或者把 Heartbeat 当 Cron 用

最后不是调度太重，就是行为不够精确。

三十、结语：真正看懂 Agent 界面，等于看懂 OpenClaw 的一半

很多产品的 UI 只是“方便点点按钮”。

但 OpenClaw 的 Agent 界面不是。

它背后其实对应了一整套非常清晰的系统分层：

• • Overview 管角色定义
• • Files 管上下文底座
• • Tools 管能力边界
• • Skills 管专长加载
• • Channels 管入口与出口
• • Cron Jobs 管自动化调度

当你真正把这 6 块放到一个统一的技术模型里，你会发现 OpenClaw 的 Agent 不再只是“一个聊天机器人配置页”，而更像一个：

可定义人格、可管理文件、可约束能力、可扩展技能、可接入渠道、可自动运行的智能工作节点。

而一旦你开始用“节点”的眼光去看它，你就不会再把 Agent 界面当成 UI，而会把它当成一套控制平面。

这时很多配置问题自然就清楚了：

• • 该把 Skill 装在哪里
• • 该按 Agent 还是全局共享
• • 该给哪些 Tools
• • 该不该接某个 Channel
• • 该用 Heartbeat 还是 Cron
• • 该怎么做多 Agent 分工

如果你只打算记住一句话，我会建议记这句：

先把 Agent 的角色、文件、工具、技能、渠道、调度顺序理顺，再去追求复杂能力。

因为 OpenClaw 真正强的地方，从来不是“选项很多”，而是：

这些选项背后，其实是一套非常适合做长期自动化系统的结构化设计。