多 Bot 并行跑任务时最后拿不到产出，通常只有两类原因：调度方根本没把任务派下去，或者调度方派出去了、执行方接了但没跑完。这两种情况在页面上都表现为“没有结果”，所以最容易被当成同一个故障反复重跑。先分清谁是调度、谁是执行，再决定改哪一侧的配置。判断依据不靠猜，靠任务记录里两套字段的时间顺序和状态流转。

把调度方理解为派活的，执行方理解为干活的：调度方留下派发记录（派发目标、任务描述、派发时间、派发状态），执行方留下执行记录（接收时间、开始时间、产出内容、结束状态）。出问题时先看派发记录是否存在，再看执行侧有没有开始时间，最后才看报错文本。派发记录缺失就改调度侧；派发存在但没有开始时间，查执行方接单环节；已开始却无产出，才排查执行过程。读不到任务记录时，先在配置里把日志级别调细。

从任务记录里区分调度方与执行方的输出字段

同一份任务记录里通常并排出现两类字段。适用场景是你能打开任务详情页或调度日志；操作动作是按角色把字段分成两栏看；验证方式是看哪一栏的字段先出现、状态停在哪个值；风险边界是字段名各平台不同，下表按语义命名，需要在你的配置里替换成实际字段。

字段缺失时的判断方式：

• 只有派发侧字段、没有执行侧字段：任务大概率没送达执行方，或执行方日志开关没打开、没有记录能力，建议先把执行侧日志级别调细再复现一次。
• 只有执行侧字段、没有派发侧字段：可能是手工触发或定时任务直接调用执行 Bot，此时调度层不在链路里，不要按调度故障排查。
• 两侧都有但状态对不上：以时间更早、状态更靠前的那一侧为准，另一侧多半是显示滞后或缓存未刷新。

用一段最小调度配置跑通两个 Bot 的派发

目的是验证调度确实把任务交给了执行者，而不是停在本地。下面是不绑定具体接口名的通用骨架，字段名按你的平台替换，放在调度配置的对应位置执行。

task:
  name: demo_parallel_task
  description: 同一份输入分别交给两个执行 Bot
  targets:
    - bot_id: worker_a
      role: executor
    - bot_id: worker_b
      role: executor
  result_sink:
    type: shared_store      # 可替换为 message_queue / log_file 等平台支持项
    location: runs/demo_parallel_task/
  timeout_seconds: 300
  log_level: debug

三个关键项缺一不可：任务描述用于在日志里认出这次运行；目标 Bot 标识决定派给谁；结果回传位置决定产出落到哪里。跑完后按顺序看三个地方确认派发成立：调度页面的任务列表是否出现两条子任务记录、调度日志里是否有带目标 Bot 标识的派发行、result_sink 指定位置是否出现预期目录或消息。只看到一条记录或一条都不出现，说明配置里的 targets 没被正确解析。

对比派发时间与开始执行时间

派发时间从调度方的任务记录或调度日志行时间戳读取，开始执行时间从执行方自己的记录或执行 Bot 的第一条日志读取。两个时间点拿到同一任务的同一实例再相减，用来判断是排队延迟还是执行卡住。

• 差值偏大（秒级以上到分钟级）：任务在队列里等，属于排队延迟。查调度方并发上限、执行方并发上限、目标 Bot 是否被前一个任务占用。
• 差值偏小但仍无产出：调度已经把任务交出去，执行方也已经开始，问题落在执行过程，跳到下一节排查。
• 执行侧连开始时间都没有：不要看差值，直接按下一节的顺序查。

单次抖动不足以判断，建议连续跑同类型任务 3 次以上，看是否每次都出现在同一侧；只有重复出现同一侧的缺失或延迟，才下结论并动手改配置。改之前先记录一次基线，改完只重跑一次对比。

子 Bot 没有产出时先查哪一侧

按固定顺序查，一次只动一侧，避免两边同时改导致无法归因。

1. 先看派发记录是否存在。存在则进入第 2 步；不存在则结论是任务没派出去，回去改调度侧：核对目标 Bot 标识拼写、并发是否已满、任务触发条件是否命中。
2. 再看执行侧是否有开始记录。有开始记录则进入第 3 步；只有接收记录、没有开始记录，结论是卡在接单或排队，查执行方并发上限、任务锁、前置依赖是否未完成。
3. 最后看是否有报错文本。有报错就按报错内容定位；无报错也无产出，多半是执行过程挂起或超时后没有写回，查超时设置和结果回传通道是否可达。

这个顺序的价值在于每步都能收敛到一个明确结论：第 1 步失败只改调度，第 2 步失败只改执行侧接单配置，第 3 步失败才进入具体业务逻辑。反过来先看业务代码，容易在调度根本没派活的情况下白白翻半天。

把角色分工写进任务模板

让下次启动任务时不用重新约定谁做什么，靠的是模板里的必填字段和命名约定。

• 任务标识（task_name）：同一次运行的所有日志都用这个前缀，便于按关键字捞出调度侧和执行侧记录。
• 角色（role）：dispatcher 或 executor，二者取一，不允许空值。
• 上游与下游（upstream / downstream）：分别写明派发方和目标执行方，便于从任一记录反查对端。
• 派发目标（targets）：调度模板必填，执行模板留空。
• 结果回传位置（result_sink）：调度方指定，执行方只写不读，避免互相覆盖。
• 超时（timeout_seconds）：两侧都写，且执行侧超时略小于调度侧，避免调度先超时误判。

命名约定建议统一前缀加角色后缀，例如 taskname-dispatcher 与 taskname-executor，日志检索和配置比对都会省事。

校验规则上，建议在任务启动前做一次必填检查：role 为空、targets 与 result_sink 同时缺失、上下游标识不一致，任一情况直接拒绝启动并返回缺失字段名，不要用默认值兜底跑起来。这样做的代价是启动时多一步校验，收益是出问题时能立刻定位到是哪一侧没按约定留痕。