---
title: "执行状态"
description: "活动执行记录会经历的每种状态，一次等待中的运行能存活多久，以及失败时会针对出错节点记录什么。"
canonical: https://docs.afp.monster/zh-cn/reference/execution-states
updated: 2026-08-19
pageType: reference
---

一条执行记录是某个活动的图针对一个人的一次遍历，它始终处于五种状态之一：运行中、等待回复、等待延迟、已完成，或已失败。一条运行中的执行记录会逐个节点遍历图，直到某个节点让它停留或结束。已完成和已失败是终态——执行记录永远不会重新开始，不过之后的事件可以启动一条新的。

画布的执行面板不会直接打印这五个名称。它显示一条执行记录是否活跃、它所在的节点、它经过的路径，以及有错误时的错误消息；下面的名称描述了这些字段共同的含义。

## 概览

| 状态 | 执行记录在做什么 | 转移到什么状态，以及触发条件 |
|---|---|---|
| 运行中 | 遍历图，执行它到达的每个节点 | 等待、已完成或已失败——取决于下一个节点产生的结果 |
| 等待回复 | 停留在一个开启了 `wait_for_reply` 的 `condition` 上 | 收到回复后转为运行中；沉默 7 天后转为已失败 |
| 等待延迟 | 停留在一个已调度恢复时间的 `delay` 节点上 | 等待结束后转为运行中；若回复取消了等待则转为已完成；若恢复从未执行则转为已失败 |
| 已完成 | 已结束。不会再运行任何节点 | 终态 |
| 已失败 | 已停止，并记录了针对它的错误 | 终态 |

## 状态图

```d2 title="Execution states and the transitions between running, waiting for a reply, waiting out a delay, completed and failed"
direction: down
begin: Start {shape: circle}
running: "运行中"
awaitingReply: "等待回复"
awaitingDelay: "等待延迟"
completed: "已完成"
failed: "已失败"
finish: End {shape: circle}
begin -> running: 匹配事件到达
running -> awaitingReply: 条件设置为等待回复
awaitingReply -> running: 那个人回复或点击了按钮
running -> awaitingDelay: 到达延迟节点
awaitingDelay -> running: 等待结束
awaitingDelay -> completed: 回复取消了一个设置为仅在无回复时运行的等待
running -> completed: "stop 节点，或一个没有连接的输出"
running -> failed: 节点被重新访问，或停滞后被清理
awaitingReply -> failed: "7 天内无回复"
awaitingDelay -> failed: 调度的步骤从未运行
completed -> finish
failed -> finish
```

## 运行中

- **是否活跃：** 是
- **记录内容：** 当前所在的节点，以及已经经过的每个节点
- **结束条件：** 一个 `stop` 节点、一个下游没有连接的输出，或一个被重新访问的节点

一条运行中的执行记录会一次性经过整个图：先是触发器，然后依次经过每个连接的节点。操作节点发送私信、发布评论，或更改联系人的标签，然后将控制权交给下一个节点。没有任何内容是被调度的——一条执行记录只会在 `delay` 节点或等待回复的 `condition` 上暂停。

一个引发错误的操作会阻止执行记录继续前进，但不会结束它。执行记录会保持活跃状态，并将错误记录在该节点上，这就是为什么面板可能显示一条哪儿都不去的活跃执行记录；之后的清理会将其关闭为已失败。

重新访问一个节点会结束该执行记录，并记录一个指出该节点的循环错误。图中的每个节点在每条执行记录中最多运行一次。

## 等待回复

- **是否活跃：** 是
- **记录内容：** 针对它停留的 `condition` 节点记录一条"等待回复"条目
- **存活时长：** 无回复状态下 7 天

开启了 `wait_for_reply` 的 `condition` 会将执行记录停留，而不是立即评估。那个人的下一条私信、同一串上的评论回复，或按钮点击会唤醒它，而该回复的文本就是条件所匹配的内容：Match 会让执行记录走第一个输出，No Match 走第二个。

一条等待 7 天仍无回复的执行记录会被关闭为已失败，并附带一条说明该人从未回复的消息。这同样适用于测试执行——一条停留在等待条件上的测试执行不会有真实的回复到来，会以同样的方式过期。

## 等待延迟

- **是否活跃：** 是
- **记录内容：** 一条以秒为单位命名等待时长的"已调度延迟"条目
- **存活时长：** 整个调度的等待时长；恢复时间超过一小时未执行则会被判定为失败

一个 `delay` 节点会调度一次恢复，并停止前进。配置的 `delay_seconds` 会被限制在 1 秒到 31,536,000 秒（365 天）之间；超出该范围的值会被裁剪而不报错。

`only_if_no_reply` 开启的延迟，会在等待结束时检查是否有回复。如果那个人在等待期间的任何时候回复过，执行记录会完成，而不是继续沿分支走下去。

一个从未到来的恢复，会在其到期时间超过一小时后被每小时一次的清理捕获，该执行记录会被关闭为已失败。

## 已完成

- **是否活跃：** 否
- **记录内容：** 完成时间，以及该执行记录经过的完整节点路径
- **错误消息：** 无

当执行记录到达一个 `stop` 节点、当它所走的输出没有连接任何内容，或当一个回复取消了设置为仅在无回复时才继续的延迟时，执行记录会完成。在 `stop` 节点结束的执行记录，其最后记录的步骤会携带一条"流程已停止"条目，用以区分有意的结束和一个本就没有连接任何内容的分支。

已完成并不代表活动做到了你想要的效果：一条没有匹配任何关键词、并从未连接的 No Match 输出离开的执行记录，仍然是一条已完成的执行记录。

## 已失败

- **是否活跃：** 否
- **记录内容：** 一条错误消息，以及执行记录停止时所在的节点
- **重试：** 延迟之后的调度恢复，最多三次；其他内容不重试

执行记录有四种失败方式：一个节点被重新访问、一个操作节点引发错误且停滞的执行记录被清理、一个等待条件超过 7 天没有回复，或一次调度的恢复从未运行。

一条停滞的执行记录——处于活跃状态，且其最后访问的节点上有错误——如果仍有未完成的调度步骤，会在一小时内被关闭；如果没有，则会在闲置 7 天后被关闭。在此之前，面板会将其显示为活跃，所以一条活跃执行记录上的错误消息，实际上就是它已经结束的信号。

## 一次失败会记录什么

| 记录内容 | 你在哪里看到它 |
|---|---|
| 来自失败调用的错误文本——被拒绝的私信、已不存在的评论、被撤销的主页令牌 | 在执行记录上，以及在路径中引发它的节点上 |
| 执行记录停止时所在的节点 | 画布叠加层中的当前节点标记 |
| 到达该节点为止所走的路径 | 该执行记录所固定的图版本上的已访问节点高亮 |
| 清理关闭该执行记录的原因 | 在执行记录上：7 天内无回复，或一个未运行的调度步骤 |

重试的范围很窄。`delay` 之后的调度恢复最多尝试三次，间隔从五秒开始逐渐扩大，第三次尝试后执行记录会被标记为失败。在执行记录遍历图时失败的操作不会被重试，也没有任何执行记录会从头重新运行。

执行记录失败的人不会被排除在活动之外。每人一条执行记录的规则只计算仍在运行中的执行记录，所以他们的下一个匹配事件会启动一条全新的执行记录。

## 说明

- 每条执行记录都固定在它开始时所在的图版本上。在执行记录进行中保存活动，会让该执行记录保留在它自己的版本上，面板会依据它使用的版本回放它。
- 测试执行会运行整个图，但不会调用 Facebook 或 Instagram，也不会更改标签。`delay` 节点会结束测试执行，而不是调度它，并将该延迟记录为已跳过。
- 面板列出该活动最近的 20 条执行记录，最新的在前，测试执行标记为测试，且不会自动更新——刷新它才能查看一条执行记录进行到了哪里。

## 相关

- [触发事件](/zh-cn/reference/trigger-events) — 哪些事件会启动执行记录，哪些会被忽略。
- [测试和调试活动](/zh-cn/guides/test-and-debug-campaigns) — 当活动没有做到你预期的效果时，如何阅读执行面板。
- [节点类型](/zh-cn/reference/node-types) — `wait_for_reply`、`delay_seconds` 和 `only_if_no_reply` 背后的配置。