龙虾之后：常驻型智能体

你晚上关掉聊天框，第二天早上却收到一份已整理的故障摘要：系统在凌晨被监控事件叫醒，读取日志，完成分析，再把结果发到群里。它看起来像“整夜都在工作”，实际并不是模型连续思考了八小时，而是后台程序一直运行，在约定时间或事件到来时才启动一次智能体任务。

先给答案

常驻型智能体是本文用来描述一类通用运行模式的词：后台服务长期在线，按消息、时间或事件触发智能体执行，再保存状态并送出结果。OpenClaw 是具备这些特征的具体开源产品；“龙虾”只是围绕该产品出现的称呼，不是一个经官方标准定义的统一产品类别。

“常驻”到底是谁没有退出？

长期运行的首先是调度和连接程序，不是大语言模型持续生成文字。也就是说，后台服务保持消息通道、任务计划和会话状态；没有新消息、定时点或事件时，模型可以完全不被调用。触发发生后，服务才组装上下文，调用模型和工具，得到结果后结束这一轮。

OpenClaw 官方资料把产品定义为自托管 Gateway：你在自己的机器或服务器上运行一个 Gateway 进程，它连接聊天渠道与 AI 编程智能体，并管理会话、记忆、工具和多智能体路由。Gateway 也就是网关，是负责接收消息、选择会话并转交任务的长期进程。它是 OpenClaw 的产品架构，不等于所有常驻模式都必须照着实现。

举例说，你从聊天软件发来“检查昨晚备份”，Gateway 收到消息后找到对应会话，智能体调用脚本读取备份记录，再把“12 项成功、1 项失败”发回原渠道。另一个团队完全可以不用 OpenClaw，自己用消息队列、定时器和模型 API 组成类似流程。两者共享的是“后台触发—执行—交付”模式，不是同一种产品。

这一区分很重要。把 OpenClaw 的某个配置写法说成“所有龙虾都这样”，会把产品事实误写成行业规律；反过来，用“常驻智能体”这个泛称也不能证明某个产品支持特定渠道、任务类型或安全措施。讨论能力时，要分别说清产品文档确认了什么，以及从中抽象出的通用模式是什么。

它靠什么被叫醒，又怎样把结果送回来？

常见触发有三类。第一类是消息触发：用户在聊天渠道发来一句话，后台连接收到后立即启动。第二类是时间触发：每天固定时间生成日报，或间隔一段时间做一次检查。第三类是事件触发：代码仓库出现新问题、监控发出告警、表单收到提交，外部系统通过 webhook 通知后台。Webhook 也就是说，一个系统在事件发生时向另一个系统发送 HTTP 请求。

OpenClaw 当前把后台机制分为 Automations、Background Tasks、Hooks、Standing Orders 和 Task Flow。一次性或重复工作由 Automations 调度并持久化作业；Background Tasks 只是异步工作账本，不负责调度。Heartbeat 是系统管理的 monitor automation，按计划发起主会话轮次，不创建后台任务记录。

触发后要选择会话。一次性日报可用隔离会话，避免进入日常聊天；连续追踪问题的 webhook 可复用指定会话。OpenClaw 的 Automations 会话目标包括 isolated、current、named 和 main，这是产品实现选项，不是行业通用分类。复用越多，越容易带入无关或敏感历史。

结果交付同样需要明确地址。任务在哪个渠道、发给哪个账号、失败时通知谁，都不应靠模型猜。一个每周报表任务如果只写“发给老板”，换了群聊或负责人后就可能送错。后台系统要保存目标、身份和失败记录，智能体只负责生成和处理任务内容。

为什么“随时在线”会放大风险？

聊天框里的错误通常停在屏幕上；常驻系统的错误可能按计划重复。若日报任务把错误收件人保存下来，它会每周发送一次；若监控提示里混入恶意文字，下一次唤醒时模型可能把外部内容误当指令。持续运行把单次风险变成时间上的累积风险。

权限也是长期存在的。Gateway 为了读取邮箱、仓库或服务器，往往保存访问凭据。机器被入侵、插件来源不明、日志意外记录密钥，都会扩大影响。自托管只说明程序跑在你的设备上，并不自动等于更安全；你仍要负责更新、账号权限、网络入口、备份和审计。

事件内容尤其要当作不可信输入。OpenClaw 官方配置文档提醒，webhook 载荷应视为不可信内容，并要求为入口设置认证和受限的会话键范围。通用做法也是如此：外部工单里的一句话不能自动取得管理员权限，邮件正文不能覆盖系统规则，来自公网的请求必须验证来源。

还要为每个后台任务设置配额和停止条件。一次监控可以最多读取 20 条日志、调用 5 次工具、运行 10 分钟；连续失败 3 次后暂停并通知人。否则一个错误触发器可能重复唤醒，模型又反复调用外部服务，直到有人注意到账单或系统负载。

最后是可见性。你应该能回答：现在有哪些定时任务？谁创建的？上次何时运行？读了什么数据？调用了哪些工具？结果发到哪里？如何立即停掉？如果产品只能展示“智能体在线”，却不能列出任务和运行记录，就不适合承接重要后台工作。

因此，常驻模式的价值不是让 AI 假装一直醒着，而是把合适的工作放进可靠的触发和交付系统。真正决定可用性的，是调度、身份、权限、隔离、失败恢复与日志；模型只是每次被叫醒后参与判断的一部分。

自己试一下

2026 年 8 月 27 日，我在当前 AI 对话环境中做了一个后台任务设计实验。你可以把下面的提示词发给任意 AI 聊天框：

设计一个“每天检查备份结果，失败才通知运维群”的常驻型智能体任务。请列出触发器、数据来源、所需最小权限、隔离或持久会话选择、最多工具调用次数、失败重试上限、通知目标、日志字段和紧急停用方法。不得假设模型 24 小时持续思考。

观察它是否分开常驻进程与单次模型调用，是否采用只读权限，并给出暂停、接管和会话选择。本次只运行了包含全部检查项的一版提示，输出覆盖调用上限、失败暂停、重复告警、日志和停用入口；没有对照组，不能据此归纳通常会漏掉什么。它验证的是通用任务设计提示，不是 OpenClaw 实机能力。

常见误解

第一，OpenClaw 不是所有常驻型智能体的统称，“龙虾”也不是已证实的统一技术类别；本文只把它作为一个产品案例。第二，常驻不等于模型连续运行，真正持续的是 Gateway、调度器或消息连接。第三，自托管不等于数据一定不离开机器：模型服务、外部工具和消息渠道仍可能传输数据，必须逐条看部署与连接方式。

三句话总结

1. 常驻模式让后台服务按消息、时间或事件唤醒智能体，而不是让模型不停思考。
2. OpenClaw 是采用 Gateway、会话与自动化机制的具体产品，不能代表所有同类实现。
3. 长期凭据、重复触发和外部不可信内容会放大风险，必须有最小权限、上限、日志和停用入口。

如果你要做决定

评估任何“24 小时 AI 助理”时，请对方画出触发、会话、工具、凭据和结果交付的完整路径，并现场展示任务列表、一次失败记录与紧急停用。若回答只剩“它会自己处理”，说明关键运行责任还没有被说清。