> ## Documentation Index
> Fetch the complete documentation index at: https://openclaw.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 常设指令

常设指令赋予你的代理针对已定义程序的**永久操作权限**。你无需为每项任务都单独提示代理，而是通过定义具有清晰范围、触发条件和升级规则的程序，让代理在这些边界内自主执行：“周报由你负责。每周五汇总并发送，只有在发现异常时才上报。”

## 为什么需要常设指令

**没有常设指令：** 你需要为每项任务都去提示代理，日常工作会被遗忘或延迟，而你会成为瓶颈。

**有常设指令：** 代理会在定义好的边界内自主执行，日常工作按计划进行，而你只在例外情况和审批时介入。

## 它们如何工作

常设指令定义在你的 [代理工作区](/concepts/agent-workspace) 文件中。推荐直接将它们写入 `AGENTS.md`（它会在每次会话中自动注入），这样代理始终能在上下文中获取它们。对于更大的配置，你也可以把它们放到诸如 `standing-orders.md` 之类的专用文件中，并在 `AGENTS.md` 中引用它。

对于严格的、临时的 CI 或脚本入口点，请使用 [`openclaw agent exec`](/cli/agent#agent-exec)。它会跳过工作区引导文件，因此每次一次性运行都是自包含的，而不是受常设指令约束。

每个程序指定：

1. **范围** - 代理被授权做什么
2. **触发条件** - 何时执行（按计划、事件或条件）
3. **审批门槛** - 在采取行动前需要哪些人工签字确认
4. **升级规则** - 何时停止并寻求帮助

代理会在每次会话中通过工作区引导文件加载这些指令（有关自动注入文件的完整列表，请参阅[代理工作区](/concepts/agent-workspace)），并结合[自动化](/automation/cron-jobs)执行基于时间的强制实施。

<Tip>
  将常设指令放在 `AGENTS.md` 中，以确保每次会话都会加载它们。工作区引导会自动注入 `AGENTS.md`、`SOUL.md`、`IDENTITY.md`、`USER.md`、`BOOTSTRAP.md` 和 `MEMORY.md`——但不会注入子目录中的任意文件。
</Tip>

## 常设指令的结构

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## 程序：每周状态报告

**权限：** 汇总数据、生成报告、向利益相关者交付
**触发条件：** 每周五下午 4 点（通过自动化任务强制执行）
**审批门槛：** 标准报告无需审批。发现异常时标记以供人工审核。
**升级条件：** 如果数据源不可用或指标看起来异常（偏离正常值超过 2σ）

### 执行步骤

1. 从已配置的数据源拉取指标
2. 与上一周及目标进行比较
3. 在 Reports/weekly/YYYY-MM-DD.md 中生成报告
4. 通过已配置渠道发送摘要
5. 将完成情况记录到 Agent/Logs/

### 不要做的事

- 不要将报告发送给外部方
- 不要修改源数据
- 即使指标看起来很差，也不要跳过交付——要如实报告
```

## 常设指令与自动化

常设指令定义代理**获授权执行的操作**。[自动化](/automation/cron-jobs)定义**执行时间**。二者协同工作：

```text theme={"theme":{"light":"min-light","dark":"min-dark"}}
常设指令：“你负责每日收件箱分诊”
    ↓
自动化（每天上午 8 点）：“根据常设指令执行收件箱分诊”
    ↓
代理：读取常设指令 → 执行步骤 → 报告结果
```

自动化任务提示应引用常设指令，而不是重复其中的内容（`openclaw automations`；`openclaw cron` 仍是别名）：

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
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 "根据常设指令执行每日收件箱分诊。检查邮件中的新警报。解析、分类并持久化每一项。向负责人报告摘要。升级未知项。"
```

## 示例

### 示例 1：内容和社交媒体（每周周期）

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## 计划：内容与社交媒体

**权限范围：** 起草内容、安排发布、汇总互动报告
**审批门槛：** 前 30 天所有帖子都需要负责人审阅，之后为常设批准
**触发条件：** 每周周期（周一审查 → 周中起草 → 周五简报）

### 每周周期

- **周一：** 审查平台指标和受众互动
- **周二至周四：** 起草社交媒体帖子，创建博客内容
- **周五：** 汇总每周营销简报 → 交付给所有者

### 内容规则

- 语气必须与品牌一致（见 SOUL.md 或品牌语气指南）
- 在面向公众的内容中绝不自称为 AI
- 在可用时包含指标
- 聚焦对受众的价值，而不是自我宣传
```

### 示例 2：财务运营（事件触发）

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## 计划：财务处理

**权限范围：** 处理交易数据、生成报告、发送摘要
**审批门槛：** 分析无需审批。建议需要负责人批准。
**触发条件：** 检测到新的数据文件 OR 按月定期执行

### 新数据到达时

1. 在指定输入目录中检测新文件
2. 解析并分类所有交易
3. 与预算目标进行比较
4. 标记：异常项目、超阈值、全新的经常性费用
5. 在指定输出目录中生成报告
6. 通过已配置渠道向负责人发送摘要

### 升级规则

- 单笔 > $500：立即提醒
- 某类别超预算 20%：在报告中标记
- 无法识别的交易：向负责人询问分类
- 重试 2 次后仍处理失败：报告失败，不要猜测
```

### 示例 3：监控与告警（持续运行）

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## 计划：系统监控

**权限范围：** 检查系统健康状况、重启服务、发送告警
**审批门槛：** 自动重启服务。如重启两次都失败，则升级处理。
**触发条件：** 每个心跳周期

### 检查项

- 服务健康端点响应正常
- 磁盘空间高于阈值
- 待处理任务不是陈旧的（>24 小时）
- 交付渠道可用

### 响应矩阵

| 条件             | 操作                     | 是否升级？                  |
| ---------------- | ------------------------ | --------------------------- |
| 服务宕机         | 自动重启                 | 仅当重启失败 2 次时          |
| 磁盘空间 < 10%   | 提醒负责人               | 是                          |
| 陈旧任务 > 24 小时 | 提醒负责人             | 否                          |
| 渠道离线         | 记录并在下一个周期重试   | 若离线 > 2 小时则升级        |
```

## 执行-验证-报告模式

当与严格的执行纪律结合时，常设指令效果最佳。常设指令中的每个任务都应遵循这个循环：

1. **执行** - 做实际工作（不要只是确认指令）
2. **验证** - 确认结果正确（文件存在、消息已送达、数据已解析）
3. **报告** - 告诉所有者做了什么以及验证了什么

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
### 执行规则

- 每个任务都遵循“执行-验证-报告”。没有例外。
- “我会处理”不算执行。先做，再报告。
- 没有验证就说“完成”是不可接受的。要证明它。
- 如果执行失败：使用调整后的方法重试一次。
- 如果仍然失败：报告失败并附带诊断。绝不要静默失败。
- 永远不要无限重试——最多 3 次，然后升级处理。
```

这种模式可以防止代理最常见的失败方式：只确认任务，却没有真正完成。

## 多程序架构

对于管理多个关注点的代理，应将常设指令组织为边界清晰的独立程序：

```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}
## 程序 1：[领域 A]（每周）

...

## 程序 2：[领域 B]（每月 + 按需）

...

## 程序 3：[领域 C]（按需）

...

## 升级规则（所有程序）

- [通用升级标准]
- [适用于所有程序的审批门槛]
```

每个程序都应该有：

* 自己的**触发频率**（每周、每月、事件驱动、持续运行）
* 自己的**审批门槛**（有些程序比其他程序需要更多监督）
* 清晰的**边界**（代理应知道一个程序在哪里结束、另一个从哪里开始）

## 最佳实践

### 应当这样做

* 从有限的权限开始，随着信任建立逐步扩大权限
* 为高风险操作定义明确的审批关卡
* 包含“不要做什么”部分——边界与权限同样重要
* 与自动化结合，以可靠地执行基于时间的任务
* 每周检查代理日志，确认常规指令是否得到遵循
* 随着需求变化更新常规指令——它们是不断演变的文档

### 应避免这样做

* 在第一天就授予广泛权限（“做你认为最好的事”）
* 跳过升级规则——每个程序都需要包含“何时停止并询问”的条款
* 假设代理会记住口头指令——将所有内容写入文件
* 在单个程序中混合多个关注点——不同领域使用不同的程序
* 忘记通过自动化来强制执行——没有触发器的常规指令最终只会变成建议

## 相关内容

* [自动化](/automation)：一览所有自动化机制。
* [自动化任务](/automation/cron-jobs)：用于执行常规指令的计划安排。
* [钩子](/automation/hooks)：由事件驱动的代理生命周期脚本。
* [Webhooks](/automation/cron-jobs#webhooks)：入站 HTTP 事件触发器。
* [代理工作区](/concepts/agent-workspace)：常规指令所在的位置，其中包括自动注入的引导文件完整列表（`AGENTS.md`、`SOUL.md` 等）。