任务调度

将Task分派给有预算、能力与配额的执行资源。

调度器决定工作何时运行、由谁运行，以及等待和恢复如何发生。它不负责证明模型结论正确。短小、只读且便宜重做的任务可使用任务表与队列；需要等待人工数天、跨部署恢复或协调昂贵副作用时，才比较持久执行引擎和框架托管服务。选择依据是任务合同，而非架构图的规模。

队列往往至少一次投递，同一个Run可能被多个worker看到。领任务要原子更新租约和版本，重复消息按事件或业务操作身份去重。worker崩溃后的重新分配要读取已提交状态，不能从头重做全部外部动作。人工等待应释放计算资源，保留可恢复状态，而不是让进程一直占着连接。

交互问答、后台研究和批量知识接入应有优先级与配额。调度按租户公平，热点用户不能无限占用模型并发。deadline、模型配额、sandbox容量和工具依赖共同决定可接入的工作量。只增加worker数量可能把瓶颈转成429风暴，降低所有任务的完成率。

组合框架时，一项操作只保留一个重试与恢复权威。外层工作流可以管理等待和业务重试，内层Agent负责局部探索，但要明确已提交模型结果和工具回执如何记录。测试至少覆盖重复投递、worker宕机、长时间审批、取消后仍有队列消息与配额突降，并报告排队时间和任务完成时间，而不只报告每秒领取数。

排队中的Task也需要过期和取消语义。一个报价分析在两小时后开始执行时，原价格窗口可能已经失效；待批准动作等了数日，原资源版本也可能改变。调度成功领取任务前，应重新检查任务是否仍有价值、deadline是否有效和授权是否成立，而不是机械处理所有积压消息。

实践重点：交互与批任务分队列；人工等待不占计算；只保留一个恢复权威。

验证抓手：测排队公平性、worker退出与重复投递。

常见误区：两套调度器互相重试，或批量ingest拖垮在线请求。

Temporal：执行状态与外部副作用；OpenAI：托管Agents架构。