带时限的任务窃取是动态调控行为，需满足时效阈值（如运行超600ms）和水位阈值（如Kafka Lag升高），绑定stage_id触发窃取与降级，配合落盘日志实现断点续传与弱一致恢复。
在多步骤工作流向导中实现带时限的窃取判定，核心是把“任务窃取”从纯负载均衡机制，升级为一种可感知时间压力与资源水位的动态调控行为。它不是等线程空闲了才去偷，而是在中间件流量接近饱和前，就主动触发跨队列的任务再分配，并配合超时约束与降级策略，保障关键路径不阻塞。
设定带时限的窃取触发条件
窃取动作不能无条件发起，需绑定两个硬性阈值：
- 时效阈值：例如某阶段预期耗时≤800ms，若本地队列头部任务已运行超600ms且未完成，即标记为“可能卡顿”，触发窃取探测
- 水位阈值：监听中间件（如Kafka）的消费延迟（Lag）或Broker端响应P99 > 2s，或本地缓冲区积压消息数 ≥ 队列容量的70%，此时即使线程未空闲，也允许主动发起窃取
用阶段ID绑定窃取上下文与降级开关
QClaw等支持阶段化编排的系统中，每个子任务已有唯一stage_id。可在窃取判定时附加该ID，使目标线程能识别“这不是普通任务，而是来自stage_3的紧急分流请求”。同时，在阶段配置中嵌入降级标识：
- 设置
fallback_on_throttle: true，当窃取后仍无法在时限内完成，自动跳过非核心子步骤（如跳过格式美化、启用精简摘要模板） - 对stage_4这类高依赖外部API的环节，预置
timeout_ms: 1200与fallback_to_cache: true，确保超时即读缓存返回弱一致结果
模拟饱和时的窃取-降级联动流程
以QClaw + Kafka组合为例，可这样闭环验证：
- 在Webhook监听服务中注入人工延迟：当收到
stage_id=3 & status=running时，向Kafka对应topic写入1000条测试消息并暂停3秒，模拟Broker打满 - 观察worker线程行为：本地deque积压达阈值 → 启动窃取扫描 → 发现peer线程deque尾部有stage_3任务 → 带
deadline=2026-05-25T12:08:30Z参数拉取 - 若被窃取任务在deadline前未完成，执行预设降级逻辑（如返回HTTP 202 + “processing with reduced fidelity”），而非让整个流程挂起
状态持久化支撑断点+降级双恢复
所有窃取动作和降级决策必须落盘，否则重试时无法延续上下文。建议复用QClaw的阶段落盘机制：
- 每次窃取发生时，生成
steal_log_stage3_202605251205.json，记录源/目标worker ID、窃取时间、deadline、是否触发fallback - 降级输出（如精简版报告）仍按原stage_id保存，路径中加入
_degraded后缀，便于后续审计或人工补全 - 下一次同task_id重入时，系统比对log与文件存在性，自动选择“重跑stage_3”还是“加载_degraded结果继续stage_4”
