OpenClaw 常驻指令怎么写：把「每次都要提醒」换成一份带边界的长期授权

用 Agent 用久了，多数人都会撞上同一堵墙：事情它都能干，但每一件都得你开口。周报要你提醒，收件箱整理要你提醒，账单文件到了还是要你提醒。到最后你没省下时间，只是把「自己动手」换成了「自己派活」，瓶颈从执行挪到了调度，而调度那一头站着的还是你。

OpenClaw 文档把这个状态叫做「没有常驻指令」的默认状态，描述得挺直白：你为每一个任务提示一次，例行工作被遗忘或拖延，而你成了瓶颈。它给出的解法是 standing orders——常驻指令，官方原话是授予 Agent 永久操作授权（permanent operating authority）。不是一次性任务，是一段长期有效的、写明边界的授权书：「周报归你。每周五编好、发出去，只有看着不对劲的时候才来找我。」

这篇把官方 standing orders 文档拆开讲：一份常驻指令由哪几块构成、写进哪个文件才会被真正加载、怎么和定时任务分工、以及官方特别强调的那套执行纪律。文末顺手说清一件容易踩空的事——自动化目录下那篇 poll 文档已经搬家了。

常驻指令必须写清的四件事

文档规定，每一个「程序」（program）要指明四项内容。少一项，这份指令就不完整：

要素	英文	说明
授权范围	Scope	Agent 被允许做什么
触发条件	Triggers	什么时候执行（按计划、按事件、或按条件）
审批关口	Approval gates	哪些动作在执行前需要人签字
升级规则	Escalation rules	什么情况下停下来求助

这四项里，中文读者最容易略过的是第三和第四项。前两项是「让它干活」，后两项是「让它知道什么时候别自己拿主意」。文档在最佳实践里把这点说得很重：每一个程序都需要一条「什么时候停下来问」的条款，跳过升级规则被明确列进了要避免的做法。

写在哪个文件里才会被加载

这是常驻指令最实际的一个问题：文件放错地方，写得再好也等于没写。

官方推荐的做法是直接写进 AGENTS.md。原因是这个文件会被工作区引导流程自动注入每一次会话，因此 Agent 永远带着这份指令在上下文里。如果配置比较大，也可以单独建一个 standing-orders.md，然后从 AGENTS.md 里引用它。

文档在提示框里点名了自动注入的完整文件清单：AGENTS.md、SOUL.md、IDENTITY.md、USER.md、BOOTSTRAP.md、MEMORY.md。同时给了一句明确的否定——子目录里的任意文件不会被注入。所以「我在某个文件夹下写了一份规矩」这种做法，除非有人显式引用它，否则不会自动生效。

还有一条容易忽略的例外：如果你要的是严格、一次性的 CI 或脚本入口，文档建议用 openclaw agent exec。它会跳过工作区的引导文件，也就是说每一次单次运行都是自包含的，不受常驻指令管辖。这个区别在做流水线时挺关键——你可能恰恰不希望 CI 里的那次调用被一份长期授权影响。

一份常驻指令长什么样

文档给了一份骨架示例，结构一目了然：

## Program: Weekly Status Report

**Authority:** Compile data, generate report, deliver to stakeholders
**Trigger:** Every Friday at 4 PM (enforced via automation job)
**Approval gate:** None for standard reports. Flag anomalies for human review.
**Escalation:** If data source is unavailable or metrics look unusual (>2σ from norm)

### Execution steps

1. Pull metrics from configured sources
2. Compare to prior week and targets
3. Generate report in Reports/weekly/YYYY-MM-DD.md
4. Deliver summary via configured channel
5. Log completion to Agent/Logs/

### What NOT to do

- Do not send reports to external parties
- Do not modify source data
- Do not skip delivery if metrics look bad - report accurately

值得单独拎出来的是最后那个「What NOT to do」小节。文档把它列进了推荐做法：包含「不该做什么」的章节，边界和权限一样重要。上面三条禁令的性质各不相同——第一条防数据外流，第二条防副作用，第三条防的是 Agent 为了让报告好看而选择性沉默。第三类约束在实践中最容易被漏掉，因为它约束的不是能力，是动机。

常驻指令管「能做什么」，定时任务管「什么时候」

文档把两者的分工写得很清楚：standing orders 定义 what，automations 定义 when。链路是这样的：

Standing Order: "You own the daily inbox triage"
    ↓
Automation (8 AM daily): "Execute inbox triage per standing orders"
    ↓
Agent: Reads standing orders → executes steps → reports results

关键的一条工程建议是：定时任务的 prompt 应该引用常驻指令，而不是把内容复制一遍。复制会立刻产生两份真相，改一份忘一份就开始漂移。对应的命令是（openclaw automations，其中 openclaw cron 仍作为别名保留）：

openclaw automations add \
  --name daily-inbox-triage \
  --cron "0 8 * * 1-5" \
  --tz America/New_York \
  --timeout-seconds 300 \
  --announce \
  --channel imessage \
  --to "+1XXXXXXXXXX" \
  --message "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."

注意 --message 里那句话的写法：它只说「按常驻指令执行每日收件箱整理」，加上几句结果要求，具体步骤一个字没有。步骤在 AGENTS.md 里。这样改流程时你只动一个地方。

反过来说，文档在「要避免」的清单里也放了一条对称的警告：忘了用自动化去强制执行，常驻指令就退化成建议。光写授权不配触发器，这份文件就只是一份没人念的规章。定时任务本身跑不起来怎么排查，可以另看定时任务不触发怎么查；周期性任务该用 cron 还是 heartbeat，见cron 与 heartbeat 怎么选。

官方给的三个程序示例，三种触发方式

文档给了三个完整例子，恰好覆盖三类触发节奏，可以当模板照抄结构。

例一：内容与社媒（周循环）。 授权是起草内容、排期发布、汇总互动数据。审批关口写得很有意思——头 30 天所有帖子都要主人过目，之后转为长期批准。触发是一个每周循环：周一看平台数据和受众互动，周二到周四写社媒帖和博客，周五汇总营销简报交付。内容规则里有一条硬约束：在对外内容中绝不表明自己是 AI。

例二：财务处理（事件触发）。 授权是处理交易数据、生成报告、发送摘要；分析类操作不需要审批，但建议类需要主人批准。触发条件是「检测到新数据文件」或「按月周期」二选一。它的升级规则写得非常具体，可以直接当阈值模板用：单笔超过 500 美元立即告警；某类目超预算 20% 在报告中标记；无法识别的交易向主人请示归类；重试 2 次仍失败就报告失败，不许猜。

例三：系统监控（连续）。 授权包括检查系统健康、重启服务、发送告警；重启是自动执行的，但连续两次重启失败就要上报。它给了一张响应矩阵，是这三个例子里最值得抄的形式：

条件	动作	是否升级
服务不可用	自动重启	仅当重启失败两次
磁盘空间低于 10%	告警主人	是
任务停滞超过 24 小时	提醒主人	否
渠道离线	记录并在下一周期重试	离线超过 2 小时则升级

把「动作」和「是否升级」拆成两列，这个做法比一段散文式的描述好用太多。Agent 拿到的是一张查表，而不是一段需要理解的意图。

Execute-Verify-Report：这套纪律解决的是「假装做完」

文档专门用一节讲执行纪律，并且点明了它要防的失败模式——确认了任务却没有完成它。这大概是 Agent 最常见也最难察觉的一种失效。

它要求每个任务都走三步循环：执行（真的动手，不是应下来）、验证（确认结果正确，比如文件存在、消息送达、数据解析成功）、报告（告诉主人做了什么、验证了什么）。对应写进指令文件的原文规则是：

### Execution rules

- Every task follows Execute-Verify-Report. No exceptions.
- "I'll do that" is not execution. Do it, then report.
- "Done" without verification is not acceptable. Prove it.
- If execution fails: retry once with adjusted approach.
- If still fails: report failure with diagnosis. Never silently fail.
- Never retry indefinitely - 3 attempts max, then escalate.

这几条里有两处值得留意。一是失败后只允许换个方式重试一次，再失败就带诊断上报，最多 3 次尝试就必须升级——重试上限写死，避免 Agent 在一个坑里空转。二是「绝不静默失败」，失败也必须变成一条明确的报告。这两条合起来，把不确定性从「不知道有没有做」压缩成「知道它失败了、失败在哪」。

多程序怎么分线

Agent 同时管几摊事的时候，文档建议按程序拆开，各自独立成块，最后再加一节适用于所有程序的公共升级规则：

## Program 1: [Domain A] (Weekly)
## Program 2: [Domain B] (Monthly + On-Demand)
## Program 3: [Domain C] (As-Needed)

## Escalation Rules (All Programs)

每个程序要有自己的触发节奏（每周、每月、事件驱动、连续）、自己的审批关口（有的程序需要更多监督），以及清晰的边界——Agent 应该知道一个程序在哪结束、另一个从哪开始。与之对应的反面做法被写进了避免清单：别把不同关注点混在一个程序里，不同领域就分开写。

在「该做」那一栏，还有两条是关于节奏而非结构的：从窄授权开始，随着信任建立再扩大；每周复查一次 Agent 日志，验证常驻指令确实被遵守了。文档明确称常驻指令是「活文档」，需求变了就得改。授权边界怎么和沙箱、工具策略配合，可以延伸看沙箱、工具策略与提权的边界。

顺手澄清：poll 文档搬走了

如果你按老链接去 /automation/poll 找轮询相关的说明，会看到一个重定向页。官方在那页写明：本页已迁移，轮询文档——包括 openclaw message poll 的参数以及各渠道的限制——现在归在 Message tool（/cli/message）页面下。

这个位置变动本身透露了一个分类判断：poll 是消息工具的一种用法，而不是自动化机制。所以在自动化章节里找不到它是正常的。至于具体有哪些参数、每个渠道各自的上限是多少，那篇重定向页没写，本文也不做推断，需要以 Message tool 页面的正文为准。除此之外，那个重定向页只留了三条相关链接，分别指向 webhooks、计划任务和后台任务。

什么时候别急着上常驻指令，以及哪些问题它没解决

先说不适用的场景。授权范围还没想清楚的时候不要写。 文档把「第一天就给出宽泛授权」列为要避免的做法，原文举的反例是那句听着很省事的「你觉得怎么好就怎么做」。窄授权慢慢放宽是可逆的，反过来则很难收。

一次性的、严格受控的调用也不该走这条路。 前面提到 openclaw agent exec 会跳过工作区引导文件，就是为这类场景准备的：你要的是可复现的单次运行，不是被一份长期文件影响的行为。

再说这份文档没有覆盖的部分，避免读者产生错误预期：

• 审批关口的具体落地机制文档没有展开。 它规定了要写 approval gate，但「等待批准时 Agent 处于什么状态、人怎么批、超时怎么办」在这篇里没有说明，需要另找对应文档。
• 示例里的阈值都是示例。 500 美元、20%、30 天转长期批准、2σ 偏离，这些是官方样例中的数值，不是产品的默认行为，也不是推荐给你的业务参数。照抄数字之前要换成你自己的口径。
• 没有任何性能或规模数字。 一份指令文件写多长合适、程序数量的上限、注入这些文件对上下文的占用，文档均未说明，别按感觉估。
• 常驻指令不保证被执行。 它是写进上下文的指令，最终执行仍取决于模型行为，所以文档才会同时要求「每周复查日志验证是否被遵守」和「用自动化去强制触发」。把它当成契约，不是当成开关。

真要落地，最省事的顺序是：先挑一件你现在每周都要提醒一次的例行事，按四要素写一个程序，把「不该做什么」和升级规则写足，放进 AGENTS.md，再配一条只写「按常驻指令执行」的定时任务。跑上两周，翻日志对一遍，再决定要不要把授权放宽。事件驱动那一侧要挂脚本的话，hooks 生命周期与用法那篇可以接着看。

延伸阅读

• 从头读起：OpenClaw 架构总览：网关、Agent、渠道、节点、插件五层各管什么，出问题该往哪查
• 本专题共 40 篇，完整分组目录见专题页
• OpenClaw 的 Agent 循环怎么转：从 agent RPC 到落盘的一整条链路
• OpenClaw 会话模型讲清楚：消息落到哪个 session、主会话汇进来什么、状态怎么不串

---

本文依据 OpenClaw 官方仓库（github.com/openclaw/openclaw）docs/ 下的官方文档整理，核对日 2026-08-17。 我们没有安装或运行过 OpenClaw，因此不涉及界面外观、操作手感与实测耗时的任何描述； 文中的默认值、命令与配置项均为文档口径，不构成对实际运行结果的保证。 该项目迭代很快，请以仓库最新内容为准。接入即时通讯平台前，请自行确认所在平台的规则与合规要求。