Agent 与 Skills 系统

🦞 Agent 如何工作、Skills 如何扩展能力、聊天命令如何控制行为——这一篇，把 OpenClaw 里“模型为什么会这样回答、为什么会这样行动”讲清楚。

Agent 与 Skills 系统

flowchart LR
  A["Agent 与 Skills 系统"]
  A --> B["分类：OpenClaw"]
  A --> C["关键词：OpenClaw"]
  A --> D["关键词：Agent"]
  A --> E["关键词：Skills"]
  A --> F["关键词：ClawHub"]

前文介绍了 OpenClaw 的整体架构与频道机制。接下来要进入更核心的一层：Agent 到底是如何被塑形、如何被约束、又如何被扩展的。

很多人第一次接触 OpenClaw 时，会把它理解成“一个能聊天、能调工具的 Bot”。这个理解不算错，但还不够。更准确地说，OpenClaw 里的 Agent 是一个嵌入在消息网关中的运行时：它有自己的工作区、有会话、有模型路由、有命令层，也有一套可插拔的 Skills 与 Memory 机制。你看到的回复，只是这个运行时在某个上下文中的外显结果。

理解这套系统很重要，因为它决定了三个实际问题：

Agent 为什么会这样说话：是系统引导文件塑造的；
Agent 为什么会这样做事：是工具策略、会话状态、命令和模型共同决定的；
Agent 为什么有时聪明、有时笨拙：往往不是“模型突然失灵”，而是上下文、技能、会话和权限层出了问题。

这一篇就围绕这些问题展开。

先抓住主线：Agent 系统由哪几层组成

可以把 OpenClaw 的 Agent 系统理解成五层：

工作区（Workspace）：Agent 的“家目录”，承载引导文件、记忆、工作区技能等；
运行时（Runtime）：负责加载上下文、维持会话、调用模型、驱动工具；
模型层（Model Routing）：决定用哪个模型、何时回退、会话里如何切换；
会话与命令层（Sessions / Slash Commands）：决定上下文如何延续、如何压缩、用户如何即时控制行为；
扩展层（Skills / Memory / Session Tools）：让 Agent 获得额外能力、跨会话能力和长期记忆能力。

后面的细节很多，但都可以落回这五层来理解。

Agent 工作区：它不是配置目录，而是 Agent 的“生活空间”

最容易混淆的一点是：~/.openclaw/ 并不等于工作区。

OpenClaw 把配置、凭证、会话记录和Agent 的工作区分开了。默认情况下，工作区是 ~/.openclaw/workspace，它是 Agent 的默认 cwd，也是文件工具、上下文读取和本地技能的主要落点。官方文档把它明确描述为 Agent 的“家”，并强调它应当被视为私有记忆，而不是普通项目目录。(OpenClaw)

这件事的工程含义是：工作区更像“认知环境”，而不只是一个文件夹。你往里面放什么，Agent 在后续会话里就更可能围绕什么来理解自己、理解你、理解任务。

默认位置与基本结构

默认工作区路径是：

~/.openclaw/workspace

如果启用了 profile，并且 OPENCLAW_PROFILE 不是 default，默认路径会变成 ~/.openclaw/workspace-<profile>。工作区路径也可以在配置中覆盖。(OpenClaw)

一个典型的工作区会包含这些文件：

路径	作用
`AGENTS.md`	操作指令、行为规则、优先级
`SOUL.md`	语气、人格、边界
`TOOLS.md`	本地工具和使用约定说明
`USER.md`	用户档案、称呼偏好
`IDENTITY.md`	Agent 的名字、风格、表情等
`BOOTSTRAP.md`	首次运行的一次性引导文件
`MEMORY.md`	可选的长期记忆
`memory/YYYY-MM-DD.md`	每日记忆日志
`skills/`	工作区本地 Skills
`canvas/`	可选的 Canvas UI 文件

这里最重要的，不是记住文件名，而是理解它们的角色分工：

AGENTS.md 更偏规则与操作原则
SOUL.md 更偏表达风格与人格边界
TOOLS.md 更偏工具使用约定
USER.md / MEMORY.md 更偏关系与记忆
skills/ 则属于能力扩展

这种分层是有价值的。因为在长期维护中，最怕的是把“行为规则”“人格口吻”“工具约束”“用户记忆”全部揉进一个大 prompt 文件。那样短期看似方便，长期会越来越难维护：你根本不知道 Agent 的某种行为到底来自哪条规则。OpenClaw 用多个引导文件把这些职责拆开，本质上是在降低 prompt 配置的耦合度。(OpenClaw)

注入文件：它们不是“配置项”，而是 Agent 的起点

OpenClaw 会在新会话的第一轮把这些引导文件内容直接注入到 Agent 上下文中。空文件会被跳过；过大的文件会被裁剪和截断；如果文件缺失，系统会注入一个“文件缺失”标记，而不是直接报错。openclaw setup 会在缺失时生成安全的默认模板。(OpenClaw)

这个机制有几个很重要的边界：

1）这些文件只是在“起步时”塑造 Agent，不等于永久真理

很多人会误以为：只要把规则写进 AGENTS.md，Agent 就会永远遵守。现实没这么理想。

引导文件只是上下文的一部分，它会影响模型，但不会像传统程序里的硬编码规则那样具备强约束力。真正影响行为的，通常是几层东西共同作用：

引导文件内容；
当前会话里已经发生的对话；
当前工具是否可用；
会话命令是否改变了模型、思考级别、权限；
当前渠道的发送策略与访问控制。

所以写 AGENTS.md 的正确思路，不是“把所有可能情况都列出来”，而是抓住最核心、最稳定的行为原则。太细、太长、太频繁修改的规则，通常不适合放在这里。

2）`TOOLS.md` 不控制工具存在与否

这是一个非常容易误解的点。TOOLS.md 的作用是告诉 Agent “工具应该怎么用”，而不是决定**“工具有没有”**。核心工具是否启用，受系统配置和工具策略控制，不由 TOOLS.md 决定。(OpenClaw)

这意味着，如果你发现 Agent 没有调用某个工具，不要先去改 TOOLS.md，而应先排查：

工具本身是否启用；
当前会话是否有权限；
当前模型是否支持或擅长工具调用；
Prompt 是否明确鼓励在该任务上使用工具。

3）工作区是默认 cwd，不是硬性沙箱

官方文档专门强调：工作区只是默认工作目录，不等于隔离边界。未启用沙箱时，工具虽然会优先相对工作区解析路径，但绝对路径仍可能访问主机其他位置。真正的隔离，需要启用 agents.defaults.sandbox 等沙箱机制。(OpenClaw)

这背后的工程含义很直接：不要把“工作区”误当成安全边界。如果你在写面向生产或团队使用的部署文档，这一点必须说清。否则很容易出现一种危险错觉：以为 Agent 只能碰工作区里的文件，实际却不是。

Pi 集成方式：不是“外接 Agent”，而是嵌入式运行时

原本最容易写错的一点，就是 OpenClaw 与 Pi 的关系。

OpenClaw 并不是把 Pi 当成一个外部子进程，通过 RPC 扔消息过去再拿结果回来；官方文档明确写的是：OpenClaw 使用 pi SDK，把 AgentSession 直接嵌入到自己的消息网关架构里，通过 createAgentSession() 实例化，而不是走“子进程 + RPC”模式。(OpenClaw)

这看起来像实现细节，但实际上影响很大。

为什么“嵌入式”比“外接式”更重要

如果是外接式 Agent，常见特征通常是：

生命周期控制更粗；
会话状态更难与宿主系统深度耦合；
工具注入和权限策略往往要靠协议层拼接；
渠道差异、消息分块、命令处理更容易割裂。

而嵌入式运行时的好处在于，OpenClaw 可以直接掌握：

会话生命周期；
事件流与流式返回；
各频道上下文定制；
自定义工具注入；
会话持久化与压缩；
模型路由与故障转移。

也正因为如此，OpenClaw 不是“Pi 的壳”，而是复用了 Pi 生态的一部分能力，但把会话管理、设备发现、工具连接、网关行为收归自己掌控。文档也明确指出：它不读取 ~/.pi/agent 或 <workspace>/.pi 设置。(OpenClaw)

从工程上看，OpenClaw 的 Agent 系统，不是“把一个现成 Agent 塞进聊天软件”那么简单，而是消息系统、会话系统、工具系统和模型系统的重新整合。

模型配置：真正该关注的是“路由策略”，不是只填一个模型名

很多入门文章会把模型配置写成这样：

{
  "agent": {
    "model": "gpt-4.1"
  }
}

这种写法在历史版本或简化示例中可能出现过，但从官方当前文档看，更完整、也更推荐的思路是围绕 agents.defaults.model、agents.defaults.models 和 agents.defaults.imageModel 来配置。主模型可以写成单值，也可以显式拆成 primary 与 fallbacks。(OpenClaw)

更关键的是，模型配置在 OpenClaw 里不是“填一个最强模型完事”，而是一个路由问题。

一个更接近实际的模型配置思路

{
  "agent": {
    "model": {
      "primary": "openai/gpt-5.2",
      "fallbacks": [
        "anthropic/claude-sonnet-4-5"
      ]
    }
  }
}

或者配合允许列表与别名：

{
  "agent": {
    "model": {
      "primary": "anthropic/claude-sonnet-4-5",
      "fallbacks": ["openai/gpt-5.2"]
    },
    "models": {
      "anthropic/claude-sonnet-4-5": { "alias": "Sonnet" },
      "openai/gpt-5.2": { "alias": "GPT" }
    }
  }
}

上面只是示意，核心不在具体模型名，而在三个原则：

主模型负责默认质量
回退模型负责可用性
允许列表负责可控性

模型选择不是线性的，而是两阶段失败处理

官方文档指出，OpenClaw 的故障转移大致分两层：

当前提供商内部先做凭证/配置文件轮换
当前提供商整体失败后，再进入下一个 fallback 模型

这意味着，model failover 不是简单的“主模型失败就切备用模型”，中间还夹着一层 provider/profile 的故障处理。(OpenClaw)

这件事的工程价值在于：它把“模型不可用”拆成了两个不同问题——

是这个模型本身不行？
还是这个提供商下的当前凭证、配额、冷却状态有问题？

如果你只在日志里看到“为什么它总换模型”，却不知道前面还有凭证轮换这一层，就很难准确定位问题。

模型强，不代表系统整体更好

这是实践里最常见的误区之一。

很多人默认认为：把主模型换成当前最强模型，Agent 整体就会变好。实际上未必。因为对带工具的 Agent 来说，真正影响结果的往往是：

工具调用是否稳定；
上下文是否干净；
提示是否明确；
会话是否过度膨胀；
技能是否恰当；
权限和执行环境是否合适。

模型越强，确实越能兜住复杂推理和含糊需求；但如果系统层配置混乱，强模型只会更高成本地犯同样的错。

会话管理：Agent 的“记忆感”主要来自这里，而不只来自 Memory

很多用户感受到“这个 Agent 像记得我”，第一反应会想到长期记忆插件。但在 OpenClaw 里，最先决定连续体验的，其实是会话系统。

OpenClaw 的会话是持久化的，历史以 JSONL 形式存储。主私聊通常对应 main 这个会话桶；群聊、频道会话、定时任务、hooks、节点会话则有不同键模型。会话工具 sessions_list、sessions_history、sessions_send 以及 sessions_spawn 也围绕这套键模型工作。(OpenClaw)

这意味着：Agent 的连续性，本质上是“上下文沿着哪个 session key 延续”。

Main session 与 group session 的区别

可以用一个更直观的方式理解：

概念	作用
Main session	主私聊上下文，最接近“长期对话”
Group session	群组/频道上下文，和主私聊隔离
Cron / Hook / Node session	自动化任务或特定系统上下文
Session tools	允许 Agent 读取或向其他会话发消息

这种分桶的价值在于避免“上下文串味”。

比如你在私聊里让 Agent 帮你写周报，同时它又在群里扮演“只在 @ 时响应的机器人”。如果没有会话隔离，它很容易把私聊里的语境、偏好、任务残留带进群聊，既混乱又危险。OpenClaw 把这些上下文拆开，至少在默认设计上，尽量降低了这种交叉污染。

队列模式和“被打断”的体验

除了会话隔离，另一个很重要却常被忽略的点是队列模式。

当 Agent 正在生成回复时，新消息进来该怎么处理？是立即插入？排队？合并？跟进？不同策略会显著改变体感。

OpenClaw 文档提到，在不同 queue mode 下，消息可能在工具调用边界被注入当前运行，也可能在当前轮完成后作为 follow-up 启动下一轮。(OpenClaw)

这背后的真实含义是：

更实时的模式：更像和人打断式对话，但当前任务更容易被中断；
更保守的模式：更像异步工作流，但互动体感会变迟钝。

工程上没有绝对正确的模式，只有更适合当前场景的取舍。私聊、群聊、自动化任务，往往需要不同的默认策略。

`/compact` 不是“清缓存”，而是上下文治理

/compact 经常被误解成“把聊天清空一点”。其实不是。

官方文档对 compaction 的定义很明确：它会把较早的对话压缩成一个紧凑摘要条目，并把这条摘要持久化写入会话历史；之后的请求使用的是“压缩摘要 + 压缩点之后的近期消息”。这和单纯在内存里裁掉历史不同。(OpenClaw)

所以 /compact 更像是一次上下文治理操作，而不是视觉层的“整理聊天记录”。

为什么长会话会越来越“怪”

这是 LLM 系统里非常真实的失败模式：

旧任务残留越来越多；
大量工具输出堆积；
局部约束被后续聊天稀释；
历史里存在多个版本的目标、指令和口径；
模型为了兼容所有上下文，开始产生“看似合理、实际模糊”的回答。

这时强行继续聊，效果通常只会越来越差。/compact 的意义，就是把长会话里的“噪声历史”压成一个更短、但仍可延续的摘要状态。它适合用在：

对话明显臃肿；
话题已经几次转向；
工具输出非常多；
需要保留上下文，但不想彻底 /new。

`/new`、`/reset`、`/compact` 的区别

一个实用的理解方式是：

命令	适合什么场景
`/compact`	还想保留上下文，但要瘦身
`/new`	想开一个干净的新会话
`/reset`	也会启动新会话，语义上更接近重置当前状态

官方文档明确提到：如果你需要真正全新开始，应使用 /new 或 /reset；如果只是上下文膨胀，则优先考虑 /compact。(OpenClaw)

聊天命令：它们不是“聊天内容”，而是 Gateway 的控制面

斜杠命令的一个关键事实是：大多数命令由 Gateway 处理，而不是交给模型自由理解。尤其是 /think、/verbose、/reasoning、/elevated、/exec、/model、/queue 这类“指令型命令”，它们会在模型看到消息前被剥离。(OpenClaw)

这点非常重要，因为它解释了为什么这些命令比“对模型说一句请更认真思考”可靠得多：它们不是软提示，而是运行时控制。

命令与指令，不是一回事

OpenClaw 文档把两类东西区分得很清楚：

命令：独立的 /... 消息；
指令：可以嵌在普通消息里的控制项，例如 /think、/model 等。若作为独立消息发送，会持久化会话设置；若嵌在普通消息中，只对当前条消息生效。(OpenClaw)

这意味着下面两种写法，行为并不相同：

/think high

和：

帮我规划一下发布流程 /think high

前者通常会把当前会话的思考级别切到 high；后者更像这条消息上的一次内联提示，不一定持久化。

这个细节很值得写进实践文章，因为很多人会在“为什么上条还高思考，这条又不是了”这种问题上迷惑很久。

常见命令

在日常使用里，比较常见的一组命令大致包括：

命令	作用
`/help` / `/commands`	查看可用命令
`/status`	查看当前状态
`/whoami` / `/id`	查看发送者身份
`/new` / `/reset`	开新会话或重置上下文
`/compact`	压缩上下文
`/think <level>`	设置思考级别
`/model ...`	切换或查看当前模型
`/queue ...`	调整队列模式
`/verbose ...`	控制详细输出
`/usage ...`	查看用量显示方式
`/skill <name> [input]`	按名称运行 Skill

需要注意的是，命令是否生效，还受授权发送者、白名单、访问组和渠道能力影响。未授权发送者发出的某些指令会被当成纯文本，甚至被静默忽略。(OpenClaw)

这一点在群聊里尤其关键：你以为大家都能用 /think high 控制机器人，实际上往往只有被授权的发送者可以。

思考级别：它调的不是“聪明程度”，而是推理预算与行为倾向

/think 常见级别包括：

off
minimal
low
medium
high
xhigh

它确实会影响复杂任务表现，但更准确的理解应该是：它在调整运行时愿意给这次任务分配多少推理预算、以及多大程度鼓励更深的中间推理。(OpenClaw)

什么时候不该盲目拉高

很多人一遇到复杂任务就想直接 xhigh。这并不总是划算。

因为在真实工程里，问题经常不是“推理不够深”，而是：

输入信息不够；
会话太脏；
工具没启用；
权限不够；
任务目标本身模糊。

这类问题即便切到 xhigh，也只是更贵地绕圈子。

一个更稳妥的经验是：

轻问答、改写、摘要：off / minimal
一般多步任务：low / medium
复杂规划、排错、架构讨论：high
确实涉及高复杂度推理，且信息充分：xhigh

思考级别不是越高越好，而是要和任务复杂度、成本敏感度、上下文质量匹配。

Elevated 与 `/exec`：它们处理的是“执行边界”，不是“更厉害模式”

/elevated 经常被简化成“高权限开关”，这不算错，但有些过于粗糙。

当前文档里，/elevated 支持的并不只是 on/off，还包括 ask 与 full 这类更细粒度状态；相关执行策略还可以通过 /exec 指定 host、security、ask 等参数。(OpenClaw)

这说明 OpenClaw 在设计上，不是把“执行权限”做成一个二元布尔开关，而是把它当成一套风险分级与审批策略。

为什么这比单纯“能不能执行 bash”更重要

Agent 真正危险的地方，从来不只是“它会不会执行命令”，而是：

在什么环境执行；
默认允许到什么程度；
是否需要审批；
出错时会不会扩大影响面；
是否会跨会话保留这种执行状态。

所以更实用的理解方式是：

/elevated 决定当前会话的执行许可级别
/exec 决定执行策略与审批规则
沙箱决定执行环境边界
TOOLS.md 决定Agent 如何理解你的工具使用习惯

四者缺一不可。

对于普通用户或共享环境，保持保守默认通常更安全；对于高级用户或受控自动化流程，才逐步把执行权限放开。否则最常见的失败模式不是“执行不了”，而是“执行得太顺手，以至于忘了它本该更谨慎”。

Skills：它不是插件市场的营销词，而是“可复用能力单元”

讲 Skills 时，最容易落入一种空泛说法：“Skill 就是给 Agent 增加能力。” 这句话没错，但不够有用。

更准确一点，Skill 是一种可被发现、可被描述、可被复用的能力封装。它通常以一个包含 SKILL.md 的目录存在，可以附带其他文本或代码资源；Agent 根据技能描述、命令入口或运行时策略来调用它。ClawHub 则负责分发、搜索、安装、更新和发布这些 Skills。(OpenClaw)

运行时加载来源，和分发来源，要分开说

原文里把 Skills 说成“四种来源：内置、托管、工作区、ClawHub”。更精确的说法应该是：

运行时加载来源有三个：

Bundled / 内置 Skills：随安装包提供；
Managed / Local Skills：安装在 ~/.openclaw/skills；
Workspace Skills：位于 <workspace>/skills。

而 ClawHub 更像 Skills 的公共注册中心和分发入口，不是运行时的第四种加载位置。你可以从 ClawHub 搜索并安装 Skill，但安装完成后，它最终仍会落到某个本地可加载位置。官方文档也明确写的是“从三个位置加载 Skills”，并另外把 ClawHub 作为公共 Skills registry 介绍。(OpenClaw)

这个区分很重要，因为它对应两种完全不同的问题：

“这个 Skill 从哪里被发现和安装？” —— ClawHub
“这个 Skill 在机器上从哪里被加载？” —— bundled / managed / workspace

如果把这两层混成一层，后面就很容易讲不清更新、覆盖和排错逻辑。

Workspace Skills：最适合做“你自己的能力层”

本地工作区 Skills 的典型结构是：

~/.openclaw/workspace/skills/
  └── my-skill/
      └── SKILL.md

这类技能的最大价值，不只是“能自定义”，而是它天然贴近你的工作流上下文。

举个很常见的例子：

某些团队有自己特定的 release checklist；
某些人总是按固定格式整理会议纪要；
某些项目需要 Agent 在回答前先读某个本地约定文档；
某些场景需要把多步操作封成稳定套路。

这些事情未必值得做成“通用插件”，但非常值得做成“工作区技能”。因为它们：

不希望被升级覆盖；
与你本地环境强相关；
常常包含团队或个人约定；
需要随着实践逐渐打磨，而不是一次写死。

名称冲突时，工作区优先

OpenClaw 当前文档说明，Skills 名称冲突时，工作区技能优先于托管/内置技能。(OpenClaw)

这既是便利，也是风险。

便利在于：你可以用本地版本覆盖一个通用 Skill，快速做定制化修正。

风险在于：覆盖是一种“静默改变行为”的机制。如果团队里有人以为自己调用的是社区 Skill，实际上跑的是你工作区里同名但逻辑不同的版本，就可能出现“为什么同一个命令在你机器上和我机器上结果不一样”。

所以只要进入团队协作阶段，本地 Skill 命名最好保持清晰，不要随便与常见公共技能撞名。

ClawHub：它解决的是发现、安装与发布，而不只是“下载技能”

ClawHub 是 OpenClaw 的公共 Skills 注册中心，提供网页和 CLI 路径来浏览、搜索、安装、更新和发布 Skills。官方文档强调，Skills 本质上就是包含 SKILL.md 和辅助文件的文件夹，所有人都可以查看、共享和复用。(OpenClaw)

很多人看到 registry，第一反应是“哦，一个插件商店”。这个类比有一点像，但不完全对。

ClawHub 真正解决的问题

它真正解决的其实是三个工程问题：

发现问题：我不知道别人已经把什么能力做出来了；
安装问题：我不想手工拷贝文件、处理依赖和更新；
声明问题：一个 Skill 到底依赖什么、会访问什么、需要什么环境变量，应该可见。

尤其是第三点，往往最被低估。

ClawHub 的 skill format 文档里，不只是讲 SKILL.md 结构，还强调了依赖、环境变量、安装规格等元数据声明；其安全分析会检查 Skill 声明的内容与实际代码使用是否一致，例如引用了某个环境变量却没有在元数据里声明，会被视为不匹配。(GitHub)

这说明 ClawHub 的目标不只是“方便分享”，还包括让 Skill 的可审计性更强。

为什么这对 Agent 系统很关键

一旦 Agent 能执行工具、访问外部系统、读写本地文件，Skill 就不再只是“提示词模板”，而是带有执行后果的能力包。

这时用户真正需要知道的不是“它看起来能做什么”，而是：

它会不会调用外部命令？
它依赖哪些二进制工具？
它需要哪些环境变量？
它的说明和真实行为是否一致？

这意味着，Skills 的工程化核心不是“多厉害”，而是“边界是否清楚”。ClawHub 在往这个方向推进，而不是只做一个漂亮的搜索页。

`SKILL.md`：描述技能，不等于替代设计

很多文章介绍 SKILL.md 时，只会说里面有名字、描述、触发条件、示例。这些都对，但还不够。

从当前 ClawHub skill format 来看，Skill 往往至少包含两层信息：

面向 Agent 的描述信息：它是什么、何时用、怎么触发、可以做什么；
面向系统与用户的元数据：依赖、环境变量、安装规格、主页等。(GitHub)

所以 SKILL.md 不是简单的“写个介绍文案”，它更像是Skill 的接口说明书。

写 Skill 最常见的三个误区

误区一：把 Skill 写成“万能入口”

如果一个 Skill 试图处理太多互不相关的任务，Agent 其实更难判断何时调用它。结果往往是：

不该用时乱用；
该用时反而想不起来；
说明文档越写越长；
触发条件越来越模糊。

好的 Skill，通常都比想象中更窄。它应该围绕一个相对清晰的能力边界，例如“把一段会议记录整理为行动项”，“从某个 API 抓取状态”，“把当前目录代码做安全检查”等。

误区二：只写“能做什么”，不写“什么时候别用”

实践里，失败模式经常不是能力不够，而是被错误触发。因此一个成熟的 Skill 说明，除了写“适合什么场景”，最好还要隐含或显式说明：

哪些输入不适合；
哪些前置条件必须满足；
哪些副作用需要注意；
哪些情况下应回退到普通对话或别的工具。

误区三：把 Skill 当“提示词外挂”，忽略依赖声明

随着 Skill 越来越接近真实工具链，依赖声明、环境变量声明、安装规格声明就不再是“锦上添花”，而是可维护性的基础。否则你会得到一个“在作者电脑上好用、换台机器就坏掉”的技能生态。

技能命令与模型选择：Skill 不总是绕过模型

还有一个容易误解的点：当 Skill 以斜杠命令暴露时，不代表它一定是“纯运行时命令”，也不一定完全绕过模型。官方文档提到，user-invocable Skills 可以作为斜杠命令公开；而 /skill <name> [input] 也可以按名称运行 Skill；默认情况下，Skill 命令会作为普通请求转发给模型。(OpenClaw)

这说明 Skill 的调用路径并不总是“像 shell 命令那样直接执行”。很多时候，模型仍然参与其中——负责理解意图、组织调用或包裹结果。

这会带来两个现实后果：

Skill 的稳定性仍受模型理解能力影响 Skill 说明写得越模糊，模型越容易误调或漏调。
强模型与好 Skill 是乘法关系，不是替代关系 模型强，但 Skill 边界糟糕，仍然会乱；Skill 设计好，但模型太弱，也可能不会正确选择它。

Memory：长期记忆不是“模型自己记住了”，而是写入磁盘的 Markdown

OpenClaw 的记忆机制有一个非常值得强调的设计：记忆文件是 Markdown，且这些文件才是事实来源。官方文档明确写道，模型只“记住”已经写入磁盘的内容；默认由活跃的 memory 插件（默认 memory-core）提供搜索工具。(OpenClaw)

这点和很多“AI 会记住你”的产品叙事不同。OpenClaw 的思路更接近工程系统：

记忆不是神秘状态；
记忆是外部化、可检查、可备份、可编辑的文本；
记忆插件负责索引与检索；
文件内容才是真正长期有效的知识载体。

默认的两层记忆

文档描述的默认布局通常有两层：

memory/YYYY-MM-DD.md：每日追加日志，会话开始时读取今天和昨天；
MEMORY.md：可选的精选长期记忆，仅在主私有会话中加载，不进入群组上下文。(OpenClaw)

这个设计很合理，因为它把“最近发生的事情”和“长期稳定偏好/事实”分开了。

如果全都写在一个长期文件里，随着时间推移会越来越臃肿；如果全都只记在每日文件里，长期偏好又会被淹没。两层结构正好解决这个矛盾。

Memory 插件的正确理解

原文说“Memory 是特殊插件槽位，同一时间只能激活一个”，这个方向基本没问题。官方文档里也确实使用 plugins.slots.memory 这个配置槽位，并支持设为 "none" 禁用；默认实现是 memory-core。(OpenClaw)

但真正需要补充的是：Memory 插件负责的是“搜索与索引机制”，不是替代记忆文件本身。

换句话说：

记忆内容：在 Markdown 文件里；
记忆能力：由插件提供索引、搜索、检索入口；
是否形成长期效果：取决于是否真的写回、如何组织、什么时候读取。

这比“开了一个记忆插件所以 Agent 就更懂我了”要真实得多。

Agent 间通信：它不是“多智能体很酷”，而是受控的跨上下文协作

OpenClaw 提供的会话工具包括：

sessions_list
sessions_history
sessions_send
sessions_spawn(OpenClaw)

这组工具的意义，并不只是“可以多 Agent 协作”，而是让 Agent 能够在不同 session 之间建立受控联系。

这类能力适合什么场景

它适合的，不是那种玄乎的“AI 自治协作”叙事，而是更具体的工程场景：

主会话把某项调查任务派给子会话；
定时任务把结果发回主会话；
某个上下文只负责执行和采集，另一个上下文只负责汇总；
群聊中的结果被转交给私聊继续处理。

真正的边界在哪里

多会话能力带来的风险，不在于“太高级”，而在于上下文可见性和信息污染。

如果没有清晰边界，一个负责执行的会话可能把噪声带入主会话；一个共享上下文中的输出可能被不小心写进本应私有的记忆；一个自动化子会话可能在错误的时机把中间结果推送回来。

所以会话工具真正重要的，不是“能不能跨会话发消息”，而是你是否清楚：

谁能看到谁；
哪类上下文应该隔离；
哪些信息允许回流到主会话；
哪些会话只是执行容器，不应承载长期认知。

会话激活与群组行为：真正的问题是“什么时候该响应”

在群组里，Agent 的体验好坏，往往不由模型决定，而由激活策略决定。

OpenClaw 的常见激活方式包括：

私聊默认激活；
群组仅在 @mention 时响应；
群组仅在回复 Bot 时响应；
若干条件组合。(OpenClaw)

这件事的本质是：Agent 不该只追求“能响应”，而应追求“在正确的时候响应”。

为什么这比“响应更灵敏”更重要

群聊里的失败模式通常不是“机器人太笨”，而是“机器人太爱说话”：

别人随手一句话也被当成请求；
命令和普通消息混在一起；
非授权用户触发高风险动作；
长线程里插入无关回复，打断人类交流。

因此一个成熟的群聊配置，通常会优先控制：

谁能发命令；
机器人何时被激活；
命令是否绕过提及门控；
结果往哪里发送；
是否允许内联命令。

这些都属于“系统行为设计”，不是模型质量问题。

实践建议：如何把 Agent 与 Skills 系统配得更稳

如果把前面的内容都压缩成几个实战结论，大概是下面这些。

1）先把工作区当成“认知资产”，再谈技能生态

很多人一上来就想装一堆 Skills。其实更应该先把工作区的基础引导文件理顺：

AGENTS.md 写核心规则；
SOUL.md 写表达边界；
TOOLS.md 写本地约定；
USER.md / MEMORY.md 管理长期关系信息。

如果这层没打好，Skills 越多，行为只会越不稳定。

2）优先设计能力边界，而不是追求“大而全”的 Skill

好的 Skill 不是功能列表长，而是边界清楚、触发明确、依赖透明。能做什么重要，但什么时候别做同样重要。

3）把 `/compact` 当作常规维护动作，而不是最后补救

一旦会话明显膨胀，就主动压缩。不要等到 Agent 已经开始答非所问、上下文发黏时才想起来治理。

4）把模型配置看成路由策略

主模型、fallback、允许列表、凭证轮换，应该一起看。只有这样，你在排查“为什么这次换模型了”“为什么这次没响应”时，才不会停留在表面。

5）在共享环境里对执行权限保持克制

/elevated、/exec、沙箱、工具策略，这些本质上都在处理一个问题：给 Agent 多大行动空间，才既有用又可控。默认保守，按场景逐步放开，通常是更稳的路线。

小结

Agent 与 Skills 系统，是 OpenClaw 真正的“系统层核心”。

工作区决定 Agent 从什么样的自我描述与记忆环境出发；嵌入式运行时决定它如何与消息网关、工具和会话深度耦合；模型路由决定它用什么脑子思考；命令系统决定用户如何在运行时接管控制；Skills 与 Memory 则决定它能做什么、能记住什么、能如何把能力沉淀下来。(OpenClaw)

如果只把 OpenClaw 理解成“一个接了大模型的聊天机器人”，你会很难解释很多真实现象：为什么同样的问题在不同会话里表现不同，为什么某些命令比自然语言更可靠，为什么一个 Skill 好不好用往往不是“功能多不多”，而是“边界是否清楚”。

从系统视角看，Agent 并不是一个单点能力，而是一组运行时机制的组合体。你调的不是一句 prompt，而是在调一整套认知环境、执行环境和扩展环境。

下一篇，我们就继续往下走：当 Agent 不只是“会想”，而是开始“会动手”时，工具与自动化层到底怎么工作。