Agent 一跑长任务就开始饿死高优先级请求：从 Deadline Propagation 到 Priority Inheritance 的工程实战

明明只是多了些长任务为什么紧急请求反而开始排不上队很多团队把 Agent 从“单轮问答”升级到“多分钟长任务”后最先坏掉的常常不是成功率而是队列公平性。⚠️ 日志回放看起来一切都在推进真正上线后却会出现另一种反常普通总结任务把 worker 长时间占满带SLA 5 min的紧急工单反而排在后面人工兜底请求也迟迟抢不到执行槽。这类问题之所以难查是因为链路并没有报错。 planner 还在产出步骤tool 也能返回结果监控上甚至能看到总体吞吐提升但高优先级请求真正依赖的是“最晚什么时候必须被处理”不是“系统平均每秒做了多少事”。 一旦 deadline 只停留在入口层后面的tool_queue、callback_worker和resume_scheduler就会把所有任务当成同一种负载。图 1deadline 只停在入口层时长任务会持续挤压紧急流量 真正被拖死的不是 worker 数量而是 deadline 丢失、锁等待和优先级反转真正把系统拖死的通常有三层。 第一层是 deadline 没有沿子任务下传长任务拆出来的搜索、审批和回调都拿着默认超时继续排队第二层是共享锁等待低优先级任务先拿到租户配额或会话写锁高优先级请求只能在外面空转第三层是优先级反转紧急任务依赖的慢工具线程反而被批量长任务占住。一组客服 Agent 灰度里若所有任务共用同一执行池P95 dispatch lag为1.9 s但高优先级工单超时率达到8.4%。✅ 仅把入口请求打上优先级标签后整体超时率降到5.7%可一旦依赖锁冲突关键请求仍会被低优先级长任务卡住直到系统补上 deadline 透传和 priority inheritance超时率才压到1.2%。方案高优先级超时率lock_wait_p95dispatch_lag_p95典型问题统一执行池8.4%740 ms1.9 s长任务持续占坑仅入口打标签5.7%620 ms1.6 s锁冲突仍会反转优先级deadline 透传 priority inheritance1.2%180 ms0.8 s更稳适合生产图 2deadline 丢失、锁等待和优先级反转会一起放大饥饿效应️ 更稳的工程做法是让 deadline 穿透到每个子调用再用 priority inheritance 解锁关键路径更稳的做法不是再开一个“紧急队列”就结束而是让 deadline 变成执行层的一等字段。️ planner 下发每个 step 时除了task_id和trace_id还要把deadline_at、priority_class、budget_ms一起写进 ledger工具线程、回调消费者和恢复器都要按剩余预算重排而不是只看最初的请求标签。 这样系统才能判断一个子调用是该加速、降级还是直接放弃。真正关键的一步是在共享资源上启用 priority inheritance。 当高优先级请求被低优先级持锁者挡住时持锁任务应临时继承更高优先级尽快释放配额、会话锁或回写槽位否则所谓“高优先级”只停留在队列入口到了执行层还是照样饿死。 同时要持续观察deadline_miss_ratio、inheritance_boost_ms和lock_wait_p95否则问题只会在投诉出现后才暴露。defdispatch(job,holderNone):remaining_msjob.deadline_at-now_ms()ifremaining_ms0:returndegrade_or_drop(job)ifholderandholder.priorityjob.priority:holder.priorityjob.priority holder.boost_untilmin(job.deadline_at,now_ms()3000)job.budget_msremaining_ms ledger.write(task_idjob.task_id,step_idjob.step_id,deadline_atjob.deadline_at,priority_classjob.priority,budget_msjob.budget_ms,)returnready_queue.push(job,key(job.priority,remaining_ms,job.created_at))图 3让 deadline 透传再让持锁者临时提级关键路径才会真正让路 接下来 3 到 6 个月Agent 调度的分水岭会从“能跑长任务”转向“能守住紧急流量”接下来3到6个月Agent 编排的分水岭不会是谁能接更多工具而是谁能把长任务与紧急流量放进同一套调度合同。 只要系统还把任务分级理解成“入口字段”而不是贯穿 planner、executor、callback 和 recovery 的运行时约束长链路越多紧急请求越容易在尾部堆积。笔者认为成熟的 Agent 平台会越来越像带 deadline 和租约的事件调度器而不是只会串步骤的工作流壳。 真正能上线放量的不是平均吞吐更高的系统而是高优先级请求来时知道该让谁让路、让多久、失败后如何降级的系统。 你们线上更常见的是长任务占满执行槽还是锁等待把紧急请求拖穿SLA欢迎交流。图 4上线后更该盯住 deadline miss、锁等待和提级收益而不是只看平均吞吐