运行记录

这页不只是告诉你去哪里看 run。

更重要的是：

• 运行记录到底在回答什么问题
• 为什么同一个任务在 Chat、Workflow、计划任务里看起来不一样，但最后仍要回到同一条运行事实
• 哪些状态只是表象，哪些才是你真正该看的东西
• 出问题时为什么要先找“第一个异常”，而不是盯着最后一条红字

先用一句话理解

运行记录回答的不是“任务有没有结束”。

它真正回答的是：

这次执行从哪里来，途中发生了什么，停在了哪一层，留下了什么结果，下一步该怎么办。

所以 run 不是简单的“成功 / 失败计数器”。

它更像一条事实链。

入口

你可以从这些地方进入运行记录：

• 完整工作台里的「推进处理 → 运行记录」
• 对话里的关联运行
• 项目页里的最近运行或结果入口
• 工作流、计划任务、审批相关的关联入口

实用建议是：

只要一件事“没按预期发生”，先找 run，不要先靠猜。

运行记录和其他板块是什么关系

一句话说：

不同入口负责“从哪里开始”，运行记录负责“这次到底发生了什么”。

运行记录最重要的价值，不是“看日志”

很多人把运行记录理解成日志页。

这不够。

更准确地说，运行记录有 5 个核心作用：

1. 给一次执行一个可追踪的事实入口
2. 把不同执行来源收口到统一状态语义
3. 区分执行过程、审批过程和交付过程
4. 让你能定位第一个异常点
5. 让你决定该重试、该补交付、该审批，还是该停住

用户不一定第一眼知道，但会直接影响理解的后台规则

这部分最关键。

1. Raydo 不应该有第二套 run truth

对用户来说，最实用的理解是：

无论底层执行器是谁，Raydo 都应该把最后可见的运行事实收回自己这边。

也就是说：

• 你可以从 Chat 发起
• 可以从 workflow 发起
• 可以从计划任务触发
• 甚至底层可以接不同 executor

但最后给用户看的运行状态，不应该每条链路各说各话。

如果一套系统让你必须同时看三套“谁说了算”的状态，那排查会很痛苦。

运行记录存在的一个核心价值，就是把这件事收口。

2. 运行来源可以不同，但事件语义要尽量统一

一次 run 可能来自：

• 聊天执行
• workflow 执行
• scheduled task 触发
• role / work pack 执行

来源不同很正常。

但对用户更重要的是：

• 它现在在运行
• 卡在等待
• 失败在工具、权限、审批还是交付
• 有没有产物
• 有没有外部影响

也就是说，用户不该被迫先理解底层 adapter 细节，才能看懂一次运行。

3. “完成”不等于“结果已经安全交付”

这是最常见的误解之一。

一个 run 完成，只说明：

这次执行生命周期到头了。

它不自动等于：

• 文件已经导出
• 结果已经发到外部渠道
• 项目交付物已经就绪
• 审批已经处理

所以你会看到这种情况：

• run 显示完成
• 但外部消息没发出去
• 或者产物已经生成，但没进最终交付位置

这不是矛盾。

而是说明“执行结束”和“交付完成”是两层事。

4. 最后一条错误，常常不是根因

很多任务失败时，用户第一反应是看最底下那条报错。

但最后一条错误，往往只是前面问题的结果。

例如：

• 真正问题是连接失效
• 后面才出现 delivery failed

或者：

• 真正问题是审批没过
• 后面才出现流程终止

所以 run 排查最重要的动作不是“找最红那句”。

而是：

找第一个异常事件，以及它前一个成功事件。

这通常比盯着末尾报错更接近真相。

5. 停止、取消、失败，用户体验可能很像，但处理方式不一样

表面上看，任务“没继续跑”都差不多。

但本质上可能完全不是一回事：

• 是你手动停了
• 是审批没过
• 是工具失败
• 是 delivery 失败
• 是系统为了避免重复外部影响而主动收口

这就是为什么“已停止”“失败”“已取消”“已完成但未交付”这些词，不能混着理解。

如果你混着看，后面就会误判该不该重试。

6. 运行记录应该消费的是 Raydo 归一后的事实，不是底层私有 payload

对用户来说，不需要知道内部字段长什么样。

但你需要知道一个原则：

运行记录应该尽量显示 Raydo 已经归一后的事件、结果、审批、产物和交付状态，而不是把底层 executor 的私有返回原样甩给你。

因为原样甩出来，通常会有两个问题：

• 看不懂
• 不同来源根本没法横向比较

一条 run 最少应该看哪几件事

如果你不想被信息淹没，最小检查顺序建议是：

常见状态怎么读

不同 run 类型的细节会有差异，但用户最常碰到的大类通常是这些。

运行中

表示任务还在处理中。

这时你更该判断的是：

• 它是真的在推进
• 还是其实卡在等待模型、外部服务、工具、审批

如果只是时间长，不一定有问题。

如果长时间没有新事件，才值得进一步怀疑。

等待

等待常见不是“系统坏了”，而是 run 正在等某个条件：

• 审批
• 权限
• 连接
• 外部资源
• 用户输入

这类状态最怕误重试。

因为问题不在“再跑一次”，而在“缺的条件还没补上”。

完成

完成只说明这次执行结束。

你还要继续确认：

• 有没有可用产物
• 有没有进入项目交付
• 有没有发到目标渠道
• 有没有留下需要人工后续的动作

失败

失败时先不要急着点 Retry。

先分清失败在：

• 输入
• 模型 / provider
• 工具
• 权限
• 审批
• delivery

不同层失败，处理方式完全不一样。

已停止 / 已取消

先确认是：

• 你手动停的
• 系统保护性停住的
• 还是某个上游条件不满足导致的终止

对外部有影响的任务，停止不一定是坏事。

有时候恰恰是系统在帮你避免重复写入。

事件流怎么读，才不会越看越乱

最实用的读法不是从上到下看完所有细节。

而是这样：

第一层，看阶段

先判断这条 run 大概在哪一层：

• 准备阶段
• 执行阶段
• 审批阶段
• 产物阶段
• 交付阶段
• 结束阶段

第二层，看第一个分叉点

再看第一次出现“和预期不一样”的地方。

例如：

• 本来应该继续执行，结果转成等待
• 本来应该生成产物，结果没有 artifact
• 本来应该交付，结果卡在 delivery

第三层，再看诊断细节

只有到这一步，才值得展开更细的错误文本、工具名、连接对象、receipt 或 trace。

这样看，心智负担会小很多。

哪些情况最容易误判

1. 显示完成，但用户说“其实没成功”

通常要查：

• 是不是执行完成但 delivery 失败
• 是不是产物生成了，但用户期待的是外部发送
• 是不是结果留在 Chat / 项目里，但用户没去对地方看

2. 显示失败，但外部系统里其实已经有结果

这类最危险。

要先核对外部事实，再决定是否重试。

尤其是：

• 发消息
• 提交表单
• 写入第三方系统

不要因为 run 红了，就立刻再点一次。

3. 一直运行中，但其实已经没有进展

要区分：

• 长任务正常处理
• 等待审批或连接恢复
• 真正卡死

连续重复提交通常不是好办法。

4. 同一个结果出现两次

先判断重复来自哪一层：

• 计划任务补跑
• workflow 重试
• 手动重复提交
• delivery 重发

不把重复来源分清，后面就很难止损。

运行记录和交付物是什么关系

run 不只记录“算没算完”。

它还和结果承接有关系。

常见要一起看的东西包括：

• artifact
• preview
• delivery refs
• 项目里的最终结果
• Inbox 里的后续动作

也就是说，一条 run 不一定只留下文本。

它也可能留下：

• 文件
• 预览
• 交付引用
• 审批材料
• 后续待处理动作

所以 run 页面不该只被当成报错页。

它也是交付追踪页。

运行记录和审批是什么关系

当一条 run 触碰高影响动作时，审批往往不是“额外附件”。

它可能就是 run 是否继续推进的关键节点。

你可以把它理解成：

• run 走到某一步
• 系统发现再往前就会造成外部后果
• 于是暂停在审批点
• 审批结果决定后续事件怎么继续展开

所以后面我们单独补审批页时，会把这两页串起来看。

什么情况下该重试，什么情况下不该重试

更适合重试的情况

• 临时 provider 抖动
• 临时网络问题
• 已确认没有外部副作用
• 你已经修好连接或权限

不该直接重试的情况

• 你还没查清第一次失败在哪
• 外部系统可能已经写入成功
• 审批还没处理
• delivery 目标本身没配好
• 输入本身就是错的

一句话：

先归因，再重试。

和计划任务页怎么配合看

如果一条 run 是计划任务触发的，排查顺序更推荐是：

1. 先到运行记录看这次实际发生了什么
2. 再回计划任务看它为什么会在这个时间触发
3. 最后才决定是改 schedule、改执行模式，还是改单次运行条件

不要反过来。

很多人一看计划任务没对，就先改 schedule。

结果真正的问题其实在 run 的执行或交付层。

和排障页怎么配合看

如果你已经确认这次 run 有问题，可以继续配合看：

• 任务执行问题

两页的分工可以这样理解：

• 运行记录页，教你怎么看一条 run
• 排障页，教你出了问题之后怎么收缩范围

常见问题

成功标志

一条运行记录真正“有用”，不是因为它显示了很多事件。

而是因为你能靠它回答这几个问题：

• 这次执行从哪里来
• 它停在了哪一层
• 第一个异常发生在哪里
• 有没有留下可用结果
• 下一步应该重试、补交付、处理审批，还是回源头改结构

做到这里，运行记录才算真正帮你减少了猜测。