starter 细页：failure_inbox
适合成功交付、失败回 Inbox 的恢复型 starter。
failure_inbox 最适合那些“成功就继续交付，失败就别默默丢掉”的任务。
它的核心价值不是内容生产，而是恢复能力。
适合谁
- 定时任务、监控类任务
- 容易偶发失败、但失败后必须有人接手的流程
- 不想让失败静默消失的人
不适合谁
- 根本不需要失败回收的人
- 高风险提交前必须人工审批的人
- 成功和失败都很复杂、多层分支的人
最安全的改法
最安全的是改：
- 主工作节点
- 成功后的 delivery
- 失败后的 inbox 目标
保住“成功去交付，失败进 Inbox”这个主意图。
最容易改坏的地方
- 成功失败条件写乱
- 失败路径没有保留错误上下文
- 把 inbox 变成另一个复杂业务流
第一次试跑建议
先验证成功路径能正常交付。
再故意制造一次失败，确认 Inbox 能接到失败信息。
确认失败信息里带了足够的上下文，而不只是“失败了”。
字段映射示例
| 你填写的输入 / 运行中状态 | starter 里怎么用 | 最终去向 |
|---|---|---|
topic | 进入 collect-brief-source 节点，拉取本次任务内容 | 生成 summary 或错误上下文 |
node_collect.status == "success" | 触发 deliver-brief | 正常交付 |
node_collect.status == "failed" | 触发 send-failure-to-inbox | 失败进入 Inbox |
node_collect.error（运行中错误） | 自动写入 Inbox 节点输入 failure | 便于后续排查 |
推荐输入模板
{
"topic": "读取今天的行业快讯源，整理成内部简报；若失败则投递到排错 Inbox"
}这条 starter 不需要你提前手填错误信息。失败上下文会在运行时自动带进 Inbox，文档里更建议你把 topic 写成“别人一看就知道这次任务本来要做什么”。