夜雨聆风
这是《Agent 进化论》的第 2 篇。
上一篇《Agent 会变聪明，还是只是记住了你？》建立了一把判断尺：上下文适应、长期记忆、Skill 优化、系统自修改、组织结构演化和模型训练，是六种不同深度的变化。
我们也留下了一个前提问题：如果 Agent 每次都只活在一个聊天窗口里，任务结束就失去环境、工具和状态，它甚至很难积累用于改进的真实轨迹。
“龙虾”热潮首先解决的，正是这个前提。
中文社区里的“龙虾”不是一个始终精确的项目名。
很多人用它指代 OpenClaw：一个运行在用户设备上、通过统一 Gateway 连接模型、工具、消息渠道和可选伴生应用的个人 Agent Runtime。
也有人说“有道龙虾”，指的是网易有道开源的 LobsterAI。按照其官方 README，LobsterAI 是桌面 Agent 产品，Cowork 承担产品和会话层，底层使用 OpenClaw 作为 Runtime 与 Gateway。
因此，本系列使用如下口径：
- • OpenClaw 是 Runtime / Gateway；
- • LobsterAI 是基于 OpenClaw 的桌面产品化案例。
它们不是两个完全同层的 Agent 内核，也不适合做简单功能对打。
聊天机器人与 Agent Runtime，差的不只是一个工具按钮
普通聊天应用的生命周期很短：收到消息，调用模型，返回文本。
Agent Runtime 则要持续管理一组相互关联的状态：
- • 用户从哪个入口发来任务；
- • 当前任务属于哪个 session；
- • Agent 能访问哪些模型、工具和文件；
- • 哪些动作需要审批或隔离；
- • 工具执行产生了什么事件和 Artifact；
- • 用户断开后任务是否继续；
- • 稍后怎样重新连接并恢复上下文。
OpenClaw 的官方定位很直接：它是运行在用户设备上的个人 AI 助手，通过一个 Gateway 把模型、工具、消息渠道和伴生应用连接起来。
这里的关键词不是“助手”，而是 Gateway。
Gateway 是本地控制面，负责 sessions、tools、events 和 channel connections。Control UI、CLI 和 TUI 都连接到它；WhatsApp、Telegram、Slack、Discord、Signal、iMessage 等 Channels 也通过它把任务送入系统。
模型不再等于产品。模型只是 Runtime 中可以替换的一部分。
Gateway：让一次调用变成一段持续工作
把 Gateway 理解为 Agent 的“进程与交通管理中心”更准确。
用户可能早上从 Telegram 发来“整理昨晚的行业新闻”，中午在电脑 Control UI 查看进度，下午再让 Agent 把结果写进文档。对模型而言，这是多轮请求；对用户而言，这是同一件工作。
Runtime 必须负责把这些请求映射到正确的 session，保留事件流、工具状态和工作空间，并在不同入口之间保持连续性。
这也是为什么 Agent 产品逐渐从“一个精心设计的 Prompt”变成真正的软件系统。只靠大模型 API 无法处理进程恢复、任务队列、权限、设备节点、消息渠道和本地数据生命周期。
模型决定一次推理能走多远，Runtime 决定这份能力能否进入真实工作。
Channels：Agent 开始出现在工作发生的地方
过去，用户必须打开一个 AI 应用，主动把任务搬进去。
Channels 反过来把 Agent 放进用户已经使用的通讯环境：Telegram、Slack、Discord、Google Chat、Signal、iMessage 等。伴生应用和设备节点还可以增加语音、Canvas、相机、屏幕和本地动作。
这带来两个变化。
第一，Agent 从“偶尔咨询的网页”变成“随时可触达的服务”。任务可以在通勤时发出，在办公室继续，在后台完成后再推送结果。
第二，输入边界迅速扩大。消息不再只来自坐在电脑前的唯一用户，还可能来自群组、机器人转发、外部文件和网页内容。
OpenClaw 官方安全说明明确提醒：入站消息应被视为不可信输入；可以发送私信的渠道默认对未知发送者执行配对流程。这不是一个附属细节，而是 Runtime 进入真实世界后的基本安全条件。
Tools、Skills 与 Plugins：从“会说”到“能做”
Agent 要完成真实任务，必须操作系统之外的对象：文件、终端、浏览器、邮件、数据库和各种业务 API。
OpenClaw 使用 Tools、Skills 和 Plugins 扩展能力：
- • Tool 提供可以实际执行的操作；
- • Skill 提供针对任务的说明、流程与可复用能力；
- • Plugin 扩展系统级集成；
- • Workspace 为 Agent 提供与任务有关的文件和持久状态。
这比给模型塞入一份“你是高级助理”的系统提示更接近工程能力。因为工作方法可以被发现、加载、共享和更新，工具也有明确的调用接口。
但也正是在这里，风险从“回答错误”升级为“动作错误”。
官方 README 说明，主 session 的工具默认在宿主机上运行，除非另外配置 sandboxing。也就是说，Agent 执行模型生成的命令时，可能拥有与当前用户接近的操作系统权限。
这要求产品必须区分：
- • 只读查询与写入修改；
- • 当前项目目录与更广泛文件系统；
- • 可信 Skill 与第三方 Skill；
- • 本地受控输入与外部不可信内容；
- • 自动执行与必须人工批准的高风险动作。
“能做更多”从来不是免费的。
有道 LobsterAI：Runtime 如何变成桌面产品
OpenClaw 提供 Runtime 和 Gateway，但普通用户还需要一个可以理解的产品层。
根据 LobsterAI 官方 README，它把系统分为 Cowork 产品/session 层与底层 OpenClaw Runtime。桌面应用负责本地持久化、权限、UI 状态、Artifacts、Agents、Memory 和 IM 绑定，OpenClaw 负责 Agent 执行。
这个分层很有代表性。
Cowork 负责把长任务呈现给用户
桌面产品需要显示流式进度、工具输出和会话历史，也要在敏感文件操作、终端命令或网络访问前请求批准。
这解决的是“用户如何理解并控制 Agent 正在做什么”。仅有后台 Runtime，用户很难区分系统是在认真执行、陷入循环，还是准备做一项危险修改。
本地数据负责连续性
LobsterAI 将会话和应用数据保存在本地 SQLite 中；OpenClaw workspace memory 则使用诸如 MEMORY.md、USER.md、SOUL.md 和每日笔记等文件保存持久偏好与项目上下文。
这让状态不必完全依赖云端对话记录，也使用户更容易检查和迁移数据。
多 Agent 和 IM 绑定负责产品组织
用户可以创建拥有独立身份、模型、Skills、工作目录和 IM 绑定的 Agent。一个主 Agent 处理通用任务，其他 Agent 承担固定角色。
这已经接近数字岗位的产品形态：不同入口、权限和工作空间对应不同职责，而不是把所有事情交给一个无限权限的万能 Agent。
为什么“常驻”是演进的前提
一个系统想从经验中改进，首先要有经验可收集。
短对话只能留下输入和答案；常驻 Runtime 可以留下更丰富的轨迹：
- • 用户真正给了什么目标；
- • Agent 调用了哪些工具；
- • 哪一步失败、为何重试；
- • 哪些动作被用户拒绝；
- • 任务最终是否完成；
- • 成本、耗时和人工接管点在哪里。
这些轨迹是以后优化 Skill、Prompt、工具和调度策略的原材料。
Runtime 还提供了让新能力生效的载体。没有统一的 Skill、Plugin 与 Workspace 机制，即使 Agent 总结出经验，也只能散落在聊天记录里，无法稳定进入下一次执行。
所以 OpenClaw 代表的是“演进之前的基础设施”：持续身份、真实环境、可执行能力和状态沉淀。
但为什么常驻仍不等于自我演进
一台服务器运行得再久，也不会因此自动改进软件架构。
同样，Agent 能够：
- • 保存会话；
- • 记住用户；
- • 定时执行；
- • 远程接收指令；
- • 调用很多工具；
仍然只证明它拥有连续运行与执行能力。
要进入上一篇定义的 L2 或 L3，它还需要把轨迹转成明确改动，并用独立标准证明改动有效。
例如，Agent 每周都漏掉某类报表异常。真正的改进不是在 Memory 里写“注意异常”，而是修改报表 Skill、构建包含正常与异常样本的评测集、验证召回率和误报率，再把通过门禁的新版本发布出去。
OpenClaw 可以承载这一过程，却不会因为 Runtime 存在就自动完成这一过程。
Runtime 让 Agent 拥有生活史；演进机制决定它能否从生活史中获得更好的工作方法。
它解决了什么
OpenClaw 解决的是 Agent 的运行与连接问题：统一 sessions、tools、events 和 channels，让模型能够进入用户设备、消息渠道和真实工作空间。
LobsterAI 展示了 Runtime 之上还需要哪些产品能力：桌面会话、权限审批、本地持久化、Artifacts、多 Agent 管理和 IM 绑定。
二者共同说明，Agent 产品的核心已从单次模型调用转向完整的软件生命周期。
它没有解决什么
常驻 Runtime 没有自动解决：
- • 记忆是否真实、是否过期；
- • Skill 是否比旧版本更好；
- • 多 Agent 是否真的提高成功率；
- • 外部输入是否污染长期状态；
- • Agent 修改自身能力时由谁评测和批准。
工具默认接触宿主权限也意味着，Runtime 越深入真实工作，sandbox、approval、日志与最小权限越不能靠后补。
可复用的架构启示
如果你在建设自己的 Agent，先把模型与 Runtime 分开设计。
模型层负责推理，Runtime 至少负责：
- 1. session 与任务生命周期；
- 2. 工具、Skill 和 Plugin 注册；
- 3. 工作空间与 Artifact；
- 4. 渠道接入和身份映射；
- 5. 权限、sandbox 与审批；
- 6. 事件、轨迹和可观测性；
- 7. 中断、恢复与版本迁移。
只有把这些能力放进稳定控制面，后续的记忆与演进才有可靠落点。
下一篇：Hermes 如何把失败变成新版 Skill
到这里，我们已经有了一个能长期运行、接触真实工具并积累轨迹的 Agent。
下一篇《Hermes 的进化实验：Agent 如何用失败记录重写自己的 Skill》，我们会进入演进闭环最关键的一步：怎样从执行记录中发现问题，生成候选 Skill，并用评测和约束门选择更好的版本。
也就是说，我们将从“Agent 活得更久”，进入“Agent 是否真的学到了可复用的方法”。
参考资料
- • OpenClaw 官方仓库[1]
- • OpenClaw 官方文档[2]
- • OpenClaw Security[3]
- • OpenClaw Sandboxing[4]
- • 网易有道 LobsterAI 官方仓库[5]
引用链接
[1] OpenClaw 官方仓库: https://github.com/openclaw/openclaw
[2] OpenClaw 官方文档: https://docs.openclaw.ai/
[3] OpenClaw Security: https://docs.openclaw.ai/gateway/security
[4] OpenClaw Sandboxing: https://docs.openclaw.ai/gateway/sandboxing
[5] 网易有道 LobsterAI 官方仓库: https://github.com/netease-youdao/LobsterAI