自动化与任务
长期指令
长期指令授予你的智能体对指定程序的永久操作权限。你无需为每项任务提示智能体，而是定义具有明确范围、触发条件和升级规则的程序，智能体便会在这些边界内自主执行：“每周报告由你负责。每周五编制并发送报告，仅在发现异常时升级处理。”
为什么使用长期指令
**没有长期指令：**你需要针对每项任务提示智能体，例行工作容易被遗忘或延误，而你会成为瓶颈。
**使用长期指令：**智能体在定义的边界内自主执行，例行工作按计划完成，你只需介入异常情况和审批。
工作原理
长期指令在你的 Agent 工作区文件中定义。建议直接将其包含在 AGENTS.md 中（每个会话都会自动注入），确保智能体始终在上下文中获得这些指令。对于较大的配置，也可以将其放在 standing-orders.md 等专用文件中，并从 AGENTS.md 引用该文件。
每个程序需指定：
- 范围 - 授权智能体执行的操作
- 触发条件 - 何时执行（时间安排、事件或条件）
- 审批关卡 - 执行前哪些操作需要人工签字批准
- 升级规则 - 何时停止并寻求帮助
智能体每次会话都会通过工作区引导文件加载这些指令（有关自动注入文件的完整列表，请参阅 Agent 工作区），并依据这些指令执行，同时结合定时任务实施基于时间的强制执行。
长期指令的结构
## 程序：每周状态报告 **权限：**汇总数据、生成报告并发送给利益相关者**触发条件：**每周五下午 4 点（通过定时任务强制执行）**审批关卡：**标准报告无需审批。标记异常情况以供人工审查。**升级条件：**数据源不可用或指标看起来异常（偏离正常值 >2σ） ### 执行步骤 1. 从已配置的来源提取指标2. 与前一周的数据和目标进行比较3. 在 Reports/weekly/YYYY-MM-DD.md 中生成报告4. 通过已配置的渠道发送摘要5. 将完成记录写入 Agent/Logs/ ### 禁止事项 - 不得将报告发送给外部人员- 不得修改源数据- 不得因指标表现不佳而跳过发送——必须如实报告长期指令与定时任务
长期指令定义智能体获准执行什么操作。定时任务定义操作在何时发生。二者协同工作：
长期指令：“每日收件箱分类由你负责” ↓定时任务（每天上午 8 点）：“按照长期指令执行收件箱分类” ↓智能体：读取长期指令 → 执行步骤 → 报告结果定时任务提示应引用长期指令，而不是重复其内容：
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：内容和社交媒体（每周周期）
## 程序：内容与社交媒体 **权限：**起草内容、安排帖子发布时间、编制互动报告**审批关卡：**前 30 天所有帖子均需所有者审查，之后转为长期批准**触发条件：**每周周期（周一审查 → 周中起草 → 周五简报） ### 每周周期 - **周一：**审查平台指标和受众互动情况- **周二至周四：**起草社交媒体帖子，创作博客内容- **周五：**编制每周营销简报 → 发送给所有者 ### 内容规则 - 语气必须符合品牌风格（参阅 SOUL.md 或品牌语气指南）- 在面向公众的内容中绝不表明自己是 AI- 有可用指标时应将其包含在内- 重点关注为受众提供价值，而非自我宣传示例 2：财务操作（事件触发）
## 程序：财务处理 **权限：**处理交易数据、生成报告、发送摘要**审批关卡：**分析无需审批。建议需要所有者批准。**触发条件：**检测到新数据文件，或进入计划的每月周期 ### 新数据到达时 1. 检测指定输入目录中的新文件2. 解析并分类所有交易3. 与预算目标进行比较4. 标记：异常项目、超出阈值的项目、新增周期性费用5. 在指定输出目录中生成报告6. 通过已配置的渠道向所有者发送摘要 ### 升级规则 - 单个项目 > $500：立即发出警报- 类别超出预算 20%：在报告中标记- 无法识别的交易：请所有者进行分类- 重试 2 次后仍处理失败：报告失败，不得猜测示例 3：监控和警报（持续执行）
## 程序：系统监控 **权限：**检查系统健康状况、重启服务、发送警报**审批关卡：**自动重启服务。如果重启失败两次，则升级处理。**触发条件：**每个 Heartbeat 周期 ### 检查项 - 服务健康端点正常响应- 磁盘空间高于阈值- 待处理任务未过期（>24 小时）- 发送渠道运行正常 ### 响应矩阵 | 条件 | 操作 | 是否升级？ || ---------------- | -------------------------- | -------------------------- || 服务中断 | 自动重启 | 仅在重启失败 2 次时 || 磁盘空间 < 10% | 向所有者发出警报 | 是 || 任务过期 > 24h | 提醒所有者 | 否 || 渠道离线 | 记录并在下个周期重试 | 离线时间 > 2 小时时 |执行—验证—报告模式
长期指令与严格的执行纪律结合使用时效果最佳。长期指令中的每项任务都应遵循以下循环：
- 执行 - 完成实际工作（不要只确认收到指令）
- 验证 - 确认结果正确（文件存在、消息已发送、数据已解析）
- 报告 - 告知所有者完成了哪些工作以及验证了哪些结果
### 执行规则 - 每项任务都遵循“执行—验证—报告”流程，无一例外。- “我会去做”不等于执行。先完成，再报告。- 未经验证就声称“已完成”不可接受。必须提供证明。- 如果执行失败：调整方法后重试一次。- 如果仍然失败：报告失败及诊断结果。绝不静默失败。- 绝不无限重试——最多尝试 3 次，然后升级处理。此模式可以防止智能体最常见的失败情况：确认任务，却没有完成任务。
多程序架构
对于管理多个关注领域的智能体，应将长期指令组织为边界清晰的独立程序：
## 程序 1：[领域 A]（每周） ... ## 程序 2：[领域 B]（每月 + 按需） ... ## 程序 3：[领域 C]（需要时） ... ## 升级规则（所有程序） - [通用升级条件]- [适用于所有程序的审批关卡]每个程序都应具有：
- 自己的触发频率（每周、每月、事件驱动、持续执行）
- 自己的审批关卡（某些程序比其他程序需要更多监督）
- 清晰的边界（智能体应知道一个程序在哪里结束，另一个程序从哪里开始）
最佳实践
应当
- 从有限权限开始，并随着信任的建立逐步扩大权限
- 为高风险操作定义明确的审批关卡
- 包含“禁止事项”部分——边界与权限同等重要
- 与定时任务结合，实现可靠的定时执行
- 每周审查智能体日志，验证是否遵循长期指令
- 随着需求变化更新长期指令——它们是持续演进的文档
避免
- 第一天就授予广泛权限（“做你认为最合适的任何事情”）
- 省略升级规则——每个程序都需要“何时停止并询问”的条款
- 假设智能体会记住口头指令——将所有内容写入文件
- 在单个程序中混合不同关注领域——为不同领域设置独立程序
- 忘记使用定时任务强制执行——没有触发条件的长期指令只会成为建议
相关内容
Was this useful?
