第一次把 OpenClaw 从“跑个 Demo 试试”切到“让它自己在后台值班”是某个周四的晚上。周五早上起来任务队列死死卡在一个删除操作的确认弹窗上后面排着的活一件没动。那一刻我才意识到一个 Agent 能不能跑通一次任务和能不能长期稳定地跑下去完全是两个量级的问题。后面那个问题靠的不是模型多聪明而是整套可靠性架构。这半年里我在 OpenClaw 上跑过定时巡检、项目信息整理、飞书消息通知这几类长期任务从命令行前台运行一步步改成开机自启的系统服务中间踩的坑基本都能写成一本书。如果你也在做 Agent 开发尤其是想把 Agent 从演示变成真正连跑几周、甚至常驻后台的进程这篇应该对你有用。我会把 Executor 审批机制、进程守护、记忆与 Workspace 管理、外部依赖容错、版本与配置漂移这几个关键点逐个拆开讲清楚它们和“长期稳定”的关系。1. 先把故障面切开Agent 长期跑不动的真实死因长期跑 Agent 的人都有一个共同感受任务第一天很听话第三天开始抽风第七天干脆罢工。大部分人会归咎于模型能力不行或者 Prompt 没写清楚。但只要你认真盯过日志会发现真正杀掉任务的很少是“模型没想明白”而是四类工程问题。第一类是执行挂起。进程还活着CPU 也没跑满但任务就是不动了。最常见的场景是某个操作需要人工审批而审批弹窗在后台没人点所有依赖它的后续步骤全部排队等死。第二类是上下文污染。同一个会话跑太久模型开始“忘事”重复犯错token 消耗越来越离谱最后上下文窗口被塞满任务被强制截断。第三类是外部依赖故障。模型 API 超时、Webhook 推送失败、免费 token 额度耗尽任何一环抖动都可能让整个流程直接退出。第四类最尴尬属于环境和配置漂移——服务器重启后进程没了或者升级后旧配置不兼容命令都找不到更别说任务还能不能跑。我把这四类故障整理成一张排查表之后你遇到任何“Agent 突然不干活”的问题先按这个表定位会比对着日志瞎猜高效很多。故障面典型表现排查方向执行挂起进程活着任务卡在审批或等待输入几小时无进展审批队列、交互输入、Executor 状态上下文污染会话越长越笨重复犯错token 消耗异常增长会话长度、记忆摘要策略、上下文裁剪外部依赖故障API 超时、限流、Webhook 失败、额度耗尽导致整体退出网络调用日志、限流返回码、通知通道健康度环境与配置漂移重启后进程消失、命令找不到、升级后行为改变服务托管、PATH、配置目录备份、版本记录为什么要先把故障面切开因为可靠性不是一个独立功能它是执行沙箱设计、进程管理、状态管理和外部集成策略的总和。如果你不分类遇到问题只会修一个补一个分好类之后你会发现自己真正要搭建的是一套让 Agent 在每一种故障模式下都能恢复的机制。2. Executor 与 exec-approvals审批墙要是设计得好它就不挡路2.1 为什么安全边界决定了你敢不敢“放手让它跑”模型本身没有安全边界。给它一个终端权限它确实能完成复杂任务但也可能在一句 Prompt 的误导下执行rm -rf或者把内部文件推到公网。OpenClaw 的做法是用 Executor 作为动作执行层模型不直接驱动底层 shell而是把“想做什么”交给执行器执行器再根据预设的审批规则决定放行、询问还是拒绝。这个机制表面上是安全功能实际上直接决定长期运行的可用性。你让 Agent 在后台跑一周就必然会出现它想做某个高影响力操作的时刻。这时候如果审批墙设计得好它只拦截真正危险的动作任务不会被打断如果审批墙设计得烂十分钟弹一次确认框没人点就只能干等可靠性直接归零。打个比方让一个陌生实习生值夜班你不会把公司金库的总钥匙直接丢给他而是让他只能进允许进的门遇到拿不准的电话请示。但如果每次开一扇普通门都要打电话夜班就没法干了。正确做法是把“哪些门可以进”写成门禁规则而不是把每一次开门都变成人工请求。2.2 从 legacy exec-approvals 迁移说起我第一次升级 OpenClaw 版本时遇到过这样一条提示legacy exec approvals exist at /root/.openclaw/exec-approvals.json后面跟着让跑迁移命令的说明。第一次看到这个提示的人很容易慌以为配置文件坏了。其实原因不复杂。旧版本里OpenClaw 会把历史上你手动放行过的命令记录到这个 JSON 文件里新版本改变了审批规则的格式或存储结构启动时检测到旧文件提示你需要迁移。这时千万不要直接删文件里面存的是你过去一条条积累的授权记录删了之后 Agent 会突然开始频繁弹审批等于自己把审批墙调严了。我的处理步骤是先把这个文件原样备份一份再执行官方给出的迁移命令。如果迁移命令因为格式问题跑失败就打开 JSON 文件把旧字段按照新版本的策略结构手动整理一遍保存后重新启动。整个过程唯一的要点是别图省事直接删。2.3 审批策略怎么配才不会让 Agent 三天饿九顿审批规则的配置策略我建议按操作的影响范围分级而不是一刀切。默认配置里最常见的方案是只读操作直接放行写操作限制在 Workspace 内放行影响范围大的操作一律询问或拒绝。下面是一个简化版的规则示例不同版本的字段名会有出入但结构和思路是一致的{ version: 2, rules: [ { pattern: ls|find|cat|pwd|git status|git diff, action: allow }, { pattern: mkdir|touch|curl -o *, action: allow }, { pattern: rm -rf *, action: deny }, { pattern: git push*, action: ask, reason: 推送远端会影响他人需要人工确认 } ] }我的个人分法更细一些。ls/cat/find/pwd/git status这类只读命令全自动mkdir/touch以及只在工作区目录内下载文件的操作可以自动执行rm默认拒绝就算要清理临时文件也应该由 skill 内部调用一个限定路径的清理脚本而不是给 Agent 一把万能删除刀。git push、发送消息给真实用户这类会影响外部系统或他人的操作保持询问状态。这里要注意一个平衡。如果任务需要 24 小时无人值守最好在 Prompt 里告诉 Agent遇到需要审批的操作时先暂停并记录当前进度不要绕过去也不要尝试用别的方式强行完成。卡住不是最可怕的最可怕的是 Agent 为了绕过审批自己拼出一连串意想不到的命令。2.4 Skill 封装与 Agent 的分工热搜里经常有人问 skill 和 Agent 的区别。简单说Skill 更接近“能力包”或者“操作流程模板”Agent 则是会调用模型、会按目标组合技能的任务执行体。一个 Agent 可以挂十个 Skill每个 Skill 内部封装一组相对固定的操作步骤。这件事和审批墙的关系很大。如果 Agent 在运行时频繁临场拼装危险命令审批墙就会频繁拦截任务注定跑不长。反过来如果你把高频操作封装成 Skill并且在 Skill 内部只使用已经过安全审核的子命令运行时就不会频繁触发审批。我在搭建长期巡检任务时习惯先把“拉取信息源”“过滤条目”“生成日报草稿”分别封装成能力独立的 Skill然后再让 Agent 按流程调用。这样审批只需要集中在 Skill 边界上Agent 每个动作是否被授权会清晰很多。3. 进程守护与断点恢复让它“死了能自己爬回来”3.1 别用 SSH 窗口当后台很多人第一次让 OpenClaw 常驻用的都是最原始的办法开个终端窗口跑起来或者nohup丢到后台然后就不管了。这种做法在短任务上没问题但服务器一旦重启进程直接消失没有任何自动恢复机制。更麻烦的是如果你是在 SSH 会话里跑的只要网络断开进程就跟着会话一起没了。我把 OpenClaw 切到常驻模式后做的第一件事就是把它改成系统服务托管。只有让操作系统来管理进程生命周期才能实现开机自启和崩溃自动拉起。Linux 上用 systemdWindows 上用任务计划程序原理是一样的。3.2 systemd 服务托管配置以 systemd 为例一个用于承载 OpenClaw 长期运行的服务单元大致长这样[Unit] DescriptionOpenClaw Agent Long-running Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userops WorkingDirectory/home/ops/.openclaw/workspace EnvironmentFile/etc/openclaw.env ExecStart/usr/local/bin/openclaw serve Restartalways RestartSec5 TimeoutStopSec30 [Install] WantedBymulti-user.target注意几点。ExecStart里的子命令换成你自己平时启动 OpenClaw 的那条命令环境变量统一放/etc/openclaw.env不要在服务文件里堆一堆EnvironmentRestartalways保证进程崩溃后 5 秒自动拉起。配置好之后执行sudo systemctl daemon-reload sudo systemctl enable --now openclaw如果是 Windows 环境任务计划程序里的触发器选“计算机启动时”操作指向你的启动脚本即可。这一步做完至少服务器重启不再需要你手动去点进程。3.3 日志、心跳与外部看门狗系统服务解决了“进程没了自动拉起”但还有一个隐蔽场景进程还活着但 Agent 已经不干活了。可能是某个外部调用长期阻塞也可能是内部死循环。这时候需要心跳机制。我的做法是给 Agent 的任务加一个“最近活动时间”的概念每次成功完成一个任务节点就更新某个状态文件的时间戳。然后用一个外部定时任务检查这个时间戳如果超过阈值还没更新就重启服务。#!/usr/bin/env bash if ! systemctl is-active --quiet openclaw; then systemctl restart openclaw echo $(date): openclaw was down, restarted /var/log/openclaw-watchdog.log fi配合 crontab 每五分钟执行一次就可以覆盖掉绝大多数“假死”场景。日志方面如果 OpenClaw 的日志直接写到文件一定要配日志轮转不然磁盘被日志打满只是时间问题。一个简单的