任务优先级排序
根据价值、紧急程度、依赖关系和成本对智能体的候选任务进行排序，而不是按照先进先出（FIFO）的方式进行处理。通过评分函数和优先级队列决定下一步运行什么，从而将有限的算力、预算和时间投入到最重要的工作中。随着状态的变化重新评分，并限制队列大小以防止其无限制增长。
问题
分解目标的智能体通常会同时产生许多候选任务：要运行的搜索、要读取的文件、要调用的工具、要追求的子目标。按到达顺序处理这些任务会将琐碎的清理步骤与具有截止日期的阻塞性任务同等对待。重要的工作在廉价的噪音之后等待，依赖关系被破坏，并且在情况发生变化后，预算被浪费在不再重要的任务上。
适用场景
当智能体或编排器积压了独立或松耦合的任务，且由于算力、速率限制、成本或实际时间限制而无法立即运行所有任务时，请使用此模式。它适用于由一个组件选择下一步执行内容的规划器和主管智能体架构。它假设你可以为每个任务附加信号（影响、截止日期、依赖关系、成本），并且随着新观测结果的到来，优先级可能会发生变化。
解决方案
为每个任务附加显式信号：对目标的预期影响、紧急程度或截止日期、依赖关系（必须先完成什么）以及在 token、资金或延迟方面的预估成本。通过透明、可审计的函数将这些信号组合成一个分数，而不是依靠不透明的模型判断。将评分后的任务输入优先级队列，以便下一步运行价值最高且已就绪的任务。务必首先遵守依赖关系：无论分数如何，前置条件未满足的任务都不是“就绪”状态，这可以保持正确的顺序并防止无谓的重试。
使优先级排序动态化。在每一步之后，重新对受影响的任务进行评分，因为新结果会改变影响、截止日期会临近，且某些任务会变得过时并可以丢弃。通过老化机制（aging，逐渐提高等待时间较长任务的优先级）或为较低层级保留容量来防止饥饿。通过显式上限和准入策略限制积压工作：当队列满时，拒绝、合并或驱逐最弱的任务，而不是让其无限制增长。保持评分权重可配置，并记录选择每个任务的原因，以确保行为保持可解释性。
组件
优势
- 有限的算力、预算和时间会被投入到高价值、时间紧迫的工作中，而不是最先到达的任务。
- 遵守前置条件可以避免因在输入存在之前运行任务而导致的无谓重试和返工。
- 重新评分使智能体能够随着情况的演变放弃目前已无关紧要的任务，并提升新紧急任务的优先级。
- 成本感知评分和受限队列使 token 和延迟预算保持在可控范围内，而不是无限制的。
风险
- 错误的权重或糟糕的成本估算可能会系统性地导致重要工作饥饿，或盲目追求低价值任务；该公式需要审查和校准。
- 如果没有老化机制或保留容量，低优先级任务可能永远不会运行，导致必要的清理或后台工作永久处于未完成状态。
- 过于频繁的重新评分会导致智能体不断切换焦点，付出上下文切换的成本且永远无法完成任何工作。
- 如果任务分解添加任务的速度快于完成速度，未设上限的积压工作将导致内存、成本和规划延迟膨胀。
不适用场景
- 当只有少数几个相似的任务时，FIFO 或简单的并行处理会更简单，评分的开销并不划算。
- 如果任务必须按照领域规定的固定顺序运行，那么静态工作流或 DAG 会比动态优先级队列更清晰。
- 当你可以立即在预算和限制范围内运行所有内容时，就没有什么需要排定优先级的，排序只会增加不必要的复杂性。
技术
示例
- 收集证据的智能体会优先处理最有可能解决未决问题的搜索，并在断言得到确认后跳过冗余查询。
- 运维智能体根据爆炸半径和截止日期对修复步骤进行排序，在处理低影响告警之前先处理面向客户的停机故障。
- 流水线智能体会优先调度高价值或临近截止日期的文档，并推迟廉价的批量项目，同时老化机制可防止批量队列永久停滞。
生产实践证据
- 上下文
- 在 57 天内（161 个会话 / 2,776 个轮次）观察到的单操作员、本地优先的 OpenClaw 部署，数据从智能体自身的轨迹追踪中聚合而来。
- 场景
- 自主智能体按计划被唤醒（心跳 + cron），通过整点错峰和心跳冷却提供背压，以防止任务堆积。
- 技术
- CronService 调度器、心跳运行器、5 分钟整点错峰、心跳冷却推迟逻辑，以及心跳结果上的低/中/高优先级字段。
- 负载
- 57 天内包含 2,801 个心跳轮次 + 57 个 cron 轮次 + 106 个用户轮次（心跳约占触发源的 94%）。
- 结果
- 调度器每天维持大约 50 次自主唤醒，错峰和冷却机制防止了任务堆积；未出现由调度驱动的失效模式。单操作员本地优先部署。
KPI
- 单位成本完成的加权任务价值
- 捕获精力是否投入到高影响力的工作上；表现良好意味着与 FIFO 基线相比，每个 token 或美元交付了更多与目标相关的价值。
- 时间紧迫型任务的截止日期 / SLA 遵守率
- 表明紧急信号正在发挥作用；表现良好意味着紧急任务在大多数情况下都能在截止日期前完成。
- 饥饿指标（低优先级任务的最大和尾部等待时间）
- 揭示老化机制是否有效；表现良好意味着最坏情况下的等待时间是有界的，且没有任务无限期卡住。
- 队列深度与上限对比以及准入/驱逐率
- 确认积压工作保持有界；表现良好意味着深度保持在上限以下，且驱逐仅针对真正低价值的任务。
已观测到的失效模式
- 高优先级任务等待一个永远不会被调度的低优先级前置条件；解析器必须将紧急程度传播给阻塞任务。
- 仅计算一次且从未刷新的优先级会基于过时的影响或截止日期信息做出决策，因此必须在相关状态发生变化时触发重新评分。
- 低估任务成本会导致其垄断预算；估算需要来自实际测量消耗的反馈。
- 激进的准入策略会丢弃后来被证明是必需的任务，从而迫使进行昂贵的重新发现；驱逐应优先选择真正冗余的项目。
经验教训
- 与关于下一步做什么的不透明模型判断相比，可审计、可配置的公式更容易调试和微调。
- 将前置条件的完成视为独立的就绪检查，这样高评分绝不会让任务抢在其输入之前执行。
- 从一开始就添加老化机制或保留容量；永远不运行的低优先级后台工作会成为隐蔽的正确性缺陷。
- 设立具有明确准入策略的硬性上限，是防止失控的任务分解导致成本和延迟飙升的最简单防御手段。
常见问题
- 这与目标分解有什么不同？
- 分解产生任务；优先级排序决定这些任务的执行顺序。它们是互补的：分解负责填充待办列表，优先级排序负责合理地消耗它。
- LLM 本身应该对优先级进行评分吗？
- 它可以提出诸如预估影响之类的信号，但应将这些信号与透明、可审计的函数结合起来。相比于单次不透明的排序调用，基于命名信号的确定性公式更容易校准、记录和信任。
- 如何防止低优先级任务永远无法运行？
- 使用老化（aging）机制逐渐提高等待时间较长任务的优先级，或者为较低层级保留一部分容量，并监控尾部等待时间以确保没有任务被饿死。