---
read_when:
    - 设置无需逐项任务提示即可运行的自主智能体工作流
    - 定义智能体可以独立执行的操作，以及哪些操作需要人工审批
    - 通过明确的边界和升级规则构建多程序智能体架构
summary: 为自主智能体程序定义永久运行权限
title: 长期指令
x-i18n:
    generated_at: "2026-07-26T06:37:41Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 9e7ad622efe734facc9dc3716f5ee7f57ed3923499db78730bda234a5c62ad80
    source_path: automation/standing-orders.md
    workflow: 16
---

长期指令授予你的智能体对指定程序的**永久操作权限**。你无需为每项任务提示智能体，而是定义具有明确范围、触发条件和升级规则的程序，智能体便会在这些边界内自主执行：“每周报告由你负责。每周五编制并发送报告，仅在发现异常时升级处理。”

## 为什么使用长期指令

**没有长期指令：**你需要针对每项任务提示智能体，例行工作容易被遗忘或延误，而你会成为瓶颈。

**使用长期指令：**智能体在定义的边界内自主执行，例行工作按计划完成，你只需介入异常情况和审批。

## 工作原理

长期指令在你的 [Agent 工作区](/zh-CN/concepts/agent-workspace)文件中定义。建议直接将其包含在 `AGENTS.md` 中（每个会话都会自动注入），确保智能体始终在上下文中获得这些指令。对于较大的配置，也可以将其放在 `standing-orders.md` 等专用文件中，并从 `AGENTS.md` 引用该文件。

每个程序需指定：

1. **范围** - 授权智能体执行的操作
2. **触发条件** - 何时执行（时间安排、事件或条件）
3. **审批关卡** - 执行前哪些操作需要人工签字批准
4. **升级规则** - 何时停止并寻求帮助

智能体每次会话都会通过工作区引导文件加载这些指令（有关自动注入文件的完整列表，请参阅 [Agent 工作区](/zh-CN/concepts/agent-workspace)），并依据这些指令执行，同时结合[定时任务](/zh-CN/automation/cron-jobs)实施基于时间的强制执行。

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

## 长期指令的结构

```markdown
## 程序：每周状态报告

**权限：**汇总数据、生成报告并发送给利益相关者
**触发条件：**每周五下午 4 点（通过定时任务强制执行）
**审批关卡：**标准报告无需审批。标记异常情况以供人工审查。
**升级条件：**数据源不可用或指标看起来异常（偏离正常值 >2σ）

### 执行步骤

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

### 禁止事项

- 不得将报告发送给外部人员
- 不得修改源数据
- 不得因指标表现不佳而跳过发送——必须如实报告
```

## 长期指令与定时任务

长期指令定义智能体获准执行**什么**操作。[定时任务](/zh-CN/automation/cron-jobs)定义操作在**何时**发生。二者协同工作：

```text
长期指令：“每日收件箱分类由你负责”
    ↓
定时任务（每天上午 8 点）：“按照长期指令执行收件箱分类”
    ↓
智能体：读取长期指令 → 执行步骤 → 报告结果
```

定时任务提示应引用长期指令，而不是重复其内容：

```bash
openclaw cron 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
## 程序：内容与社交媒体

**权限：**起草内容、安排帖子发布时间、编制互动报告
**审批关卡：**前 30 天所有帖子均需所有者审查，之后转为长期批准
**触发条件：**每周周期（周一审查 → 周中起草 → 周五简报）

### 每周周期

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

### 内容规则

- 语气必须符合品牌风格（参阅 SOUL.md 或品牌语气指南）
- 在面向公众的内容中绝不表明自己是 AI
- 有可用指标时应将其包含在内
- 重点关注为受众提供价值，而非自我宣传
```

### 示例 2：财务操作（事件触发）

```markdown
## 程序：财务处理

**权限：**处理交易数据、生成报告、发送摘要
**审批关卡：**分析无需审批。建议需要所有者批准。
**触发条件：**检测到新数据文件，或进入计划的每月周期

### 新数据到达时

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

### 升级规则

- 单个项目 > $500：立即发出警报
- 类别超出预算 20%：在报告中标记
- 无法识别的交易：请所有者进行分类
- 重试 2 次后仍处理失败：报告失败，不得猜测
```

### 示例 3：监控和警报（持续执行）

```markdown
## 程序：系统监控

**权限：**检查系统健康状况、重启服务、发送警报
**审批关卡：**自动重启服务。如果重启失败两次，则升级处理。
**触发条件：**每个 Heartbeat 周期

### 检查项

- 服务健康端点正常响应
- 磁盘空间高于阈值
- 待处理任务未过期（>24 小时）
- 发送渠道运行正常

### 响应矩阵

| 条件             | 操作                       | 是否升级？                 |
| ---------------- | -------------------------- | -------------------------- |
| 服务中断         | 自动重启                   | 仅在重启失败 2 次时        |
| 磁盘空间 < 10%   | 向所有者发出警报           | 是                         |
| 任务过期 > 24h   | 提醒所有者                 | 否                         |
| 渠道离线         | 记录并在下个周期重试       | 离线时间 > 2 小时时        |
```

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

长期指令与严格的执行纪律结合使用时效果最佳。长期指令中的每项任务都应遵循以下循环：

1. **执行** - 完成实际工作（不要只确认收到指令）
2. **验证** - 确认结果正确（文件存在、消息已发送、数据已解析）
3. **报告** - 告知所有者完成了哪些工作以及验证了哪些结果

```markdown
### 执行规则

- 每项任务都遵循“执行—验证—报告”流程，无一例外。
- “我会去做”不等于执行。先完成，再报告。
- 未经验证就声称“已完成”不可接受。必须提供证明。
- 如果执行失败：调整方法后重试一次。
- 如果仍然失败：报告失败及诊断结果。绝不静默失败。
- 绝不无限重试——最多尝试 3 次，然后升级处理。
```

此模式可以防止智能体最常见的失败情况：确认任务，却没有完成任务。

## 多程序架构

对于管理多个关注领域的智能体，应将长期指令组织为边界清晰的独立程序：

```markdown
## 程序 1：[领域 A]（每周）

...

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

...

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

...

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

- [通用升级条件]
- [适用于所有程序的审批关卡]
```

每个程序都应具有：

- 自己的**触发频率**（每周、每月、事件驱动、持续执行）
- 自己的**审批关卡**（某些程序比其他程序需要更多监督）
- 清晰的**边界**（智能体应知道一个程序在哪里结束，另一个程序从哪里开始）

## 最佳实践

### 应当

- 从有限权限开始，并随着信任的建立逐步扩大权限
- 为高风险操作定义明确的审批关卡
- 包含“禁止事项”部分——边界与权限同等重要
- 与定时任务结合，实现可靠的定时执行
- 每周审查智能体日志，验证是否遵循长期指令
- 随着需求变化更新长期指令——它们是持续演进的文档

### 避免

- 第一天就授予广泛权限（“做你认为最合适的任何事情”）
- 省略升级规则——每个程序都需要“何时停止并询问”的条款
- 假设智能体会记住口头指令——将所有内容写入文件
- 在单个程序中混合不同关注领域——为不同领域设置独立程序
- 忘记使用定时任务强制执行——没有触发条件的长期指令只会成为建议

## 相关内容

- [自动化](/zh-CN/automation)：快速了解所有自动化机制。
- [定时任务](/zh-CN/automation/cron-jobs)：为长期指令强制执行时间安排。
- [Hooks](/zh-CN/automation/hooks)：用于智能体生命周期事件的事件驱动脚本。
- [Webhooks](/zh-CN/automation/cron-jobs#webhooks)：入站 HTTP 事件触发器。
- [Agent 工作区](/zh-CN/concepts/agent-workspace)：长期指令的存放位置，包括自动注入的引导文件完整列表（`AGENTS.md`、`SOUL.md` 等）。