OpenClaw 的 Agent 是常驻进程吗？

很多人第一次接触 OpenClaw，会把 Agent 想象成一个一直运行的独立程序：

Gateway
  ├── Agent A  ← 一直运行
  ├── Agent B  ← 一直运行
  └── Agent C  ← 一直运行

其实理解 Agent 时，更合适的方式是：

Gateway 是长期运行的服务，而 Agent 更偏向“按任务/会话被调度执行的逻辑实体”。

一、Agent 是怎么工作的？

当一条消息到来后，可以把 Agent 的执行过程理解成三个阶段：

用户发送消息
     ↓
① 加载
     ↓
② 执行
     ↓
③ 保存状态
     ↓
等待下一次调用

1. 加载：先搞清楚“我是谁”

Agent 开始处理任务时，需要获得自己的工作区配置和上下文。

例如可能包括：

AGENTS.md
SOUL.md
相关 Skills
Session / Context
其他 Workspace 配置

这些内容共同决定：

我是谁、应该怎么回答、能使用什么能力、之前聊了什么。

---

2. 执行：进入 Agent Loop

准备完成后，Agent 开始真正干活：

用户输入
   ↓
读取上下文
   ↓
调用 LLM
   ↓
判断是否需要 Tool
   ↓
执行 Tool
   ↓
读取结果
   ↓
再次调用 LLM
   ↓
生成答案

复杂任务可能循环多次：

Think → Tool → Result → Think → Tool → Result → Answer

这就是前面讲过的 Agent Loop。

---

3. 保存：把需要的状态留下

一次处理完成后，需要保留的会话状态可以持久化，而本次执行所占用的临时资源则可以释放。

所以不要把 Agent 理解成：

一个 Agent
=
一个永远挂在后台的进程

更容易理解成：

Agent
=
配置 + 上下文 + 模型 + Skills + Tools
        ↓
需要处理任务时被调度执行

---

二、为什么要这样设计？

最大的好处之一就是资源利用率。

假设配置了 20 个 Agent，并不意味着一定要长期运行 20 个重量级独立进程。

更合理的模式是：

Gateway
   │
   ├── 消息来了 → 调度 Agent A
   │
   ├── 消息来了 → 调度 Agent B
   │
   └── 没有任务 → 不做无意义计算

第二个好处是配置与执行逻辑分离。

Agent 的人格、规则、Skills、Workspace 等可以通过配置管理，而 Gateway 继续承担消息入口和调度职责。

---

三、Session 和 Agent 不要混淆

这里尤其容易搞错。

Agent 是“谁来干活”，Session 是“这次对话进行到哪里了”。

例如：

             CodeReview Agent
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
      Session A  Session B  Session C
        张三        李四        王五

三个人都可以使用同一个 Agent，但各自拥有不同的会话上下文，因此不会因为使用同一个 Agent 就必然共享一份聊天记录。

---

四、一句话记住

OpenClaw 的整体关系可以这样理解：

Gateway
= 长期运行的入口和调度中心

Agent
= 被调度执行任务的智能体逻辑

Session
= 某次/某条会话的状态

LLM
= Agent 的推理核心

Tools
= Agent 的手脚

Skills
= Agent 的能力扩展

所以，与其简单说：

“Agent 是一个 per-session、执行完就彻底销毁的进程。”

更稳妥的说法是：

Agent 不应简单等同于一个长期常驻的独立进程；Gateway 持续提供服务，Agent 根据消息和会话上下文被调度执行，并在执行过程中调用 LLM、Skills 和 Tools。

这样理解之后，Gateway、Agent、Session 三者的关系就基本清楚了。