1. 先说清楚：Agent里的"调度"到底调度什么
1.1 从普通程序到Agent的调度差异
很多刚开始接触AI Agent的开发者，第一反应是把它当成一个复杂点的API调用流程：用户说一句话，系统调一次大模型，把结果返回。真去实现一个带工具的Agent之后才发现，这套东西的复杂度根本不在"调用模型"，而在"怎么决定下一步调谁、什么时候调、调错了怎么补救"。
传统后端程序里，调度是确定性的：请求进来，经过A服务再到B服务，最后写库返回，链路是写死的。Agent不一样，模型的输出是不确定的，同样的用户问题，这次可能走工具A，下次可能直接回答，第三次可能连续调三个工具还不够。调度器面对的不是一条固定流水线，而是一棵随时可能长出奇怪分支的执行树。
我自己第一次搭建Agent系统时踩过一个很实在的坑：把所有工具调用逻辑都写在主流程里，模型返回一个JSON就立刻执行，执行完接着调模型。单独跑一个Demo没问题，但一旦并发上来、任务链变长，整个系统就像没有交通警察的路口——各种任务互相踩踏，上下文错乱，工具反复调用，最后用户等来一个不知所云的答案。
1.2 任务调度的核心链路全景
要理解Agent调度，最好先建立一张完整的链路图，哪怕只是用文字描述一遍，后面写代码时也清晰很多。一条完整的Agent调度链路通常长这样：
- 用户请求进入入口层，完成基本校验后绑定会话。
- 入口层做意图识别，判断这是简单问答还是需要多步执行的复杂任务。
- 如果是复杂任务，交给规划器拆解成子任务，并生成依赖关系。
- 执行引擎按顺序调度子任务，每个子任务可能需要调用工具、查询知识库或再次询问大模型。
- 每次子任务执行后，结果写回上下文，调度器根据新的上下文决定下一个动作。
- 整个过程中，状态机记录任务生命周期，日志系统记录每个节点的输入输出。
- 如果某个环节失败，重试或回退机制介入；如果超过时间阈值，人工介入通道打开。
这条链路里的每个环节都有自己的难点，但整条链路的骨架就是调度器。调度器决定一个Agent系统是"看起来能用"还是"真的能扛住生产环境"。
1.3 调度器必须回答的四个问题
我后来把调度器的工作概括成四个必须回答的问题：
第一，下一步做什么。模型返回的结果可能是回答用户，也可能是要求调用某个工具，调度器要能识别并决策。
第二，这一步怎么做。如果要调工具，参数从哪来，用哪个工具，超时设多少，这是执行细节。
第三，做完了怎么处理结果。工具返回值怎么解析，要不要喂回给模型，还是直接拼装给用户。
第四，失败怎么办。超时、报错、返回格式不对，重试还是换方案，还是直接告诉用户"我搞不定"。
这四个问题听起来不难，但每一条展开都有很多细节。后面几节，我会按请求从进入系统到最终返回的顺序，把每个环节的实现要点和踩坑经验都说一遍。
2. 入口层：请求进来之后第一步做什么
2.1 会话绑定让调度有"记忆"
入口层是调度链路的第一站，却往往被设计得最随意。很多初版Agent把入口层只当成转发层，收到请求直接扔给模型，结果就是任务执行到一半用户追加了一句"把刚才那个改一下"，系统完全不知道"刚才那个"是什么。
正确的做法是在入口层完成会话绑定。每个请求进来，先根据用户ID和会话ID找到对应的会话记录，包括历史消息、上下文摘要、当前执行状态。会话绑定这个动作直接决定了后面的调度能不能"记住"前面发生的事。
实现上建议用独立的会话存储，而不是把历史消息全塞在模型请求里。我自己常用的是Redis或分布式缓存，保存会话最近20轮到50轮的摘要，同时配合向量数据库存长期记忆。入口层拿到会话之后，把当前请求和历史上下文拼装好，再交给规划器。
这里有个容易被忽略的点：会话绑定必须在进入调度队列之前完成。如果并发高，同一个会话的多个请求同时进入，不做锁或序列化的话，上下文会互相覆盖。我见过一个真实案例，用户快速点了两次按钮，系统同时处理两个请求，后一步的执行结果覆盖了前一步，用户收到的答案里混着两轮对话的内容，非常诡异。
2.2 意图识别决定走哪条调度路径
会话绑定完成之后，下一步是意图识别。这一步不是为了炫技，而是为了分流——不是所有请求都需要走Agent的多步调度，大部分问题直接让模型回答就够了。如果每条请求都走完整的规划-执行链路，成本和响应时间都会翻几倍。
意图识别可以简单到一个分类器，也可以直接用模型判断。我的经验是，先用规则或轻量模型做粗分类，把明显的简单问答、闲聊、重复请求筛掉，剩下语义复杂的请求再走完整Agent链路。粗分类的好处是稳定和便宜，不会被模型偶尔抽风带偏。
具体来说，我会把意图分成三类。第一类是不需要工具的直接回答，包括闲聊、常识问答、产品功能介绍。第二类是单步工具调用，比如查天气、查订单状态，调一次API就能搞定。第三类是多步任务，比如"帮我对比三款产品的价格和口碑，再给我推荐一个"，必须规划、执行、汇总。三类请求走不同的调度路径，前两类可以走轻量级处理，第三类才进入完整调度器。
2.3 入口限流：先保住稀缺资源
入口层还有一项重要职责是限流和优先级控制。Agent系统的资源瓶颈往往在大模型API的并发上限和token配额，而不是机器本身。请求打到入口层之后，如果不管三七二十一全塞给调度器，一次大促或热点事件就能把API配额打光，后面的正常请求全部排队超时。
我常用的方案是双层限流。第一层是网关级的固定窗口或令牌桶限流，按用户维度做，防止单个用户刷爆系统。第二层是调度器内部的任务队列，按任务类型设置不同的优先级。比如简单问答的优先级可以低一些，因为用户能接受稍微慢一点；而需要多步执行的复杂任务，因为涉及模型多次调用和更长的响应时间，通常会给予更高的资源优先级。
调度队列的实现也值得设计一下。不要用简单的先进先出，建议引入超时机制：任务在队列里等的时间超过阈值，要么降级处理，要么提示用户"当前比较繁忙"。我自己在项目里会把任务的预估耗时写入队列元数据，调度器根据预估耗时和实际等待时间做动态优先级调整，效果比固定优先级好很多。
3. 任务拆解与规划：调度的"大脑"部分
3.1 为什么不能把工具调用都塞给一次模型调用
到了规划层，很多人会有一个疑问：既然大模型本身会生成工具调用，为什么还要单独搞一个规划器去拆解任务？直接告诉模型"你可以用这些工具"，让它自己一步步调用不就完了？
理论上可以，但实际生产中会发现三个问题。第一，模型在长链路工具调用中的稳定性不够，走到第三步容易忘记初始目标，或者前后矛盾。第二，可观测性太差，你没法直观看到任务拆成了几步、每步之间什么关系，出了问题只能看黑盒日志。第三，很难插入人工干预，如果某个子任务需要用户确认才能继续，只能在流程之外再搞一套状态管理。
所以我的建议是，把任务拆解从执行中独立出来。用一个规划器（Planner）先拆解任务，再把拆解结果交给执行引擎。规划器的输入是用户原始请求和工具列表，输出是一棵或多棵子任务图，每个子任务带上工具选择、输入参数模板和预期输出。
3.2 规划器的两种主流设计
规划器的实现方式，我做过两种，也对比过优劣。
第一种是ReAct模式的动态规划：模型和执行循环交替，每一步由模型决定下一步动作。这种方式实现简单，适合任务路径比较自由、没有固定流程的业务。缺点也很明显——模型每走一步都要充分理解前文，token消耗大，而且任务一旦复杂，循环次数不可控。
第二种是Plan-then-Execute静态规划：先用一次模型调用生成完整计划，然后按计划逐步执行，只有遇到计划外的结果才重新规划。这种方式更适合业务路径相对成熟的场景，比如订单处理、数据分析流程。优点是可控性高，每步的输入输出边界清晰，token消耗也更低。缺点是计划之外的场景处理弱，需要额外设计重规划机制。
我的实践结论是：生产系统尽量用Plan-then-Execute作为主链路，把ReAct模式降级为Plan执行失败的兜底策略。这样绝大多数任务走稳定路径，偶尔遇到计划覆盖不了的意外情况，再让模型临场应变。
3.3 子任务依赖关系的表达与执行顺序
规划器输出计划之后，调度器要解决的核心问题是怎么表达和执行子任务的依赖关系。最直接的方式是有向无环图。每个节点是一个子任务，边表达依赖关系，调度器从入度为0的节点开始执行，每完成一个节点就释放下游依赖。
DAG的表达方式我推荐用JSON，结构清晰，方便序列化和存储。字段一般包含task_id、type（工具类型）、depends_on（依赖的其他task_id列表）、input（参数模板）、timeout、retry策略等。有了这个结构，调度器写起来就很顺了，一个标准的拓扑排序就能搞定执行顺序。
但依赖关系设计上有两个容易踩的坑。第一个坑是"过度拆解"，把一个简单的两步任务拆成五个子任务，每个子任务都做一次模型调用或工具调用，响应时间翻倍，成本翻五倍。拆解的粒度应该控制在"一个子任务对应一次工具调用"或"一次必要的模型推理"，能合并就合并。第二个坑是"环形依赖"，规划器生成的计划偶尔会出现A依赖B、B依赖A的情况，执行引擎一跑就死循环。所以调度器做DAG校验时，必须检测环，一旦发现就强制走重规划流程，不能放过这个异常。
4. 执行引擎：工具调用与上下文管理的细节
4.1 工具注册：别把工具调用做成if-else
规划器拆解完之后，执行引擎开始真正干活。执行引擎第一个要解决的问题是工具调用怎么组织。
很多初版Agent把工具调用写成一系列if-else或switch-case：模型说要调天气，代码里就写一个weather函数，模型说要调日历，又写一个calendar函数。这种写法在工具数量少于五个的时候还凑合，一旦工具上两位数，代码变得又臭又长，而且新加一个工具就要改一次主流程，非常痛苦。
正确的方式是工具注册表机制。每个工具定义成统一结构的描述体，包含工具名、描述、参数Schema（JSON Schema格式）、执行入口、超时设置、重试策略。启动时把工具注册到表里，模型生成的工具调用通过工具名查表分发。我用Python实现的话大概是这个结构：
{ "name": "query_order_status", "description": "根据订单号查询订单当前状态及物流信息", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单编号"} }, "required": ["order_id"] }, "handler": "order_service.query_order_status", "timeout_ms": 5000, "retry": {"times": 2, "interval_ms": 500} }注册表机制最大的好处是解耦。工具的新增和下线都不需要改主流程，运营人员写一个描述文件就能投用。而且工具描述本身就是给模型看的Prompt，工具描述写得好不好，直接决定模型选工具的准确率。这一块值得花时间打磨，甚至要A/B测试。
4.2 上下文管理：不让记忆变成负担
执行引擎的第二个核心问题是上下文管理。一个多步任务执行下来，每步的工具返回结果可能都很长，如果全部塞给大模型，很快就把上下文窗口撑爆，而且注意力被无关信息稀释，回答质量会下降。
我的做法是把上下文分成三层管理。第一层是"执行摘要"，记录当前任务目标、已完成几步、每步的关键结论，始终保持在精简状态。第二层是"工具结果缓存"，保存最近几轮的完整工具返回值，按需引用。第三层是"历史会话"，用于用户追问和长时记忆，通过摘要或向量检索按需加载。
每次决定下一个子任务怎么执行时，调度器拼装的Prompt是"执行摘要+当前子任务的输入模板+必要的工具结果缓存"。这样既保证模型有足够的上下文做决策，又不会因为信息过载而做出错误判断。
上下文裁剪有一个实用技巧：给工具返回结果提前设置一个摘要器。工具返回很长的结构化数据时，先让一个轻量模型或规则脚本把它压成几十字的摘要，再去进Prompt。这个操作能显著降低token消耗，同时保留关键信息。我实测过，同样一个数据分析任务，加了摘要器后token消耗降了约四成，问题回答的准确率反而略有提升，因为模型不用在冗长数据里找重点了。
4.3 超时、重试与回退：别让卡死拖垮链路
工具调用不可控，这是做Agent执行引擎必须接受的事实。第三方API可能超时，数据库可能抖动，模型可能返回格式错误的JSON。调度器对这些异常的处理方式，直接决定了系统的稳定体验。
超时设置不能一刀切。查数据库和查订单这种轻量调用，我给3到5秒；调用外部知识库或搜索引擎的，给8到15秒；大模型本身的调用，给30到60秒。超时时间要用确定性设置，不要指望客户端能无限等待。
重试策略上我采用指数退避加抖动。第一次失败后等500毫秒重试，第二次等1秒，最多重试三到四次。每个重试都带上递增的等待时间，避免踩踏式的集中重连。特别要注意的是，重试只对幂等操作安全，比如查询类接口；如果工具本身会写数据，比如创建订单、发送通知，重试前必须确认接口是否支持幂等键，否则可能产生重复操作。
回退是比重试更高级的兜底。当某个工具连续重试仍然失败时，调度器有两种回退路径。一种是功能回退，比如搜索引擎挂了，改用知识库检索；另一种是路径回退，比如走完三步计划之后发现某步无法完成，回到前一个稳定节点重新规划。我的经验是，回退逻辑必须在规划阶段就设计好，而不是执行失败后再临时想对策。
5. 状态机与并发控制：任务跑到一半怎么办
5.1 Agent任务状态机的设计
Agent任务和普通异步任务最大的区别在于它的状态迁移不是流水线式的，中间有很多分叉。如果不用状态机管理，代码很快会变成一团乱麻。
我常用的状态集合是这样的：CREATED（已创建）、PLANNING（规划中）、READY_TO_EXECUTE（等待执行）、EXECUTING（执行中）、WAITING_CONFIRM（等待确认）、REPLANNING（重规划中）、COMPLETED（已完成）、FAILED（失败）、CANCELLED（已取消）、TIMEOUT（超时）。
每个状态对应允许的事件和迁移路径，调度器只处理合法迁移，非法的直接抛异常。比如一个任务正在EXECUTING，用户突然取消了，可以走到CANCELLED；但如果一个COMPLETED的任务收到重试事件，那就不合法，需要先REOPEN才能重新进入队列。
状态机实现只需要一个字典加一个更新函数，不复杂。复杂的是状态的持久化和恢复。任务跑一半，进程重启了，调度器必须有办法从存储恢复未完成任务，接着跑而不是从头来。我的方案是每个状态变更都写一份事件日志，重启时按事件日志重建状态机，这种方式虽然多写了一些代码，但排查问题和断点续跑都方便很多。
5.2 并发控制是事故高发区
Agent系统的并发控制和普通后端不太一样。普通后端通常以服务实例为粒度做并发控制，Agent还要细分到会话级和任务级，因为同一个会话的不同任务之间可能是有关联的。
先说会话级并发控制。同一个用户发起的新任务，不能和该会话的旧任务同时操作共享资源。比如用户在会话A里正在执行"修改订单地址"，另一个请求进来问"我的订单到哪了"，两个任务同时操作同一份订单数据，如果没有锁，后一个任务可能读到改了一半的数据。解决方案是给会话维度加分布式锁，或者按用户ID做一致性哈希，把同一会话的任务固定路由到同一实例。
任务级并发控制在执行引擎里也很重要。DAG中无依赖的节点理论上可以并行执行，比如"查天气"和"查机票"互不依赖，同时跑能缩短响应时间。但并行要设置最大上限，我一般控制在3到5个并发子任务，因为过多的并行会让模型API的并发压力陡增，而且后面的汇总阶段要把多个结果合并，结果越多，汇总的推理难度就越大，模型越容易遗漏。
5.3 中断、恢复与人工确认
实际业务里，Agent任务不可能永远独自跑完，经常会遇到需要中断等待的情况。最常见的两类中断：一类是需要人工确认，比如Agent要替用户下单，必须用户点头；另一类是前置条件不满足，比如要查实时库存，但库存服务暂时不可用，任务先挂起。
中断恢复的设计核心是"检查点"。调度器在执行每个子任务前后都记录检查点，包括当前执行到哪一步、这个节点的输入输出、下游有哪些节点等待。用户确认后或前置条件恢复后，调度器从最近的检查点继续执行，而不是整体重来。这个设计直接决定了中断恢复的效率和稳定性。
人工确认还有一个容易忽略的细节：确认动作本身要设置超时。用户可能一直不点确认按钮，如果任务永远挂在WAITING_CONFIRM状态，最后会积累一堆僵尸任务。我的做法是，人工确认超过15分钟自动取消任务，同时通知用户"该操作已取消，如需继续请重新发起"，把僵死任务清理出队列。
6. 可观测性：调度链路的日志与追踪
6.1 一次任务全链路需要记录什么
Agent系统的排障难度远超普通后端，因为一个任务的执行路径不是固定的，你没法提前知道它会走哪条分支。这时候，全链路日志就是唯一能依靠的线索。
我建议每个任务分配一个全局唯一的trace_id，从入口层开始生成，贯穿会话、规划、执行、工具调用、模型调用的全链路。日志格式统一用结构化JSON，至少包含时间戳、trace_id、task_id、节点类型、节点输入、节点输出、耗时、状态、错误信息。日志要落盘，同时同步到监控系统。
特别注意两个记录点：模型输入输出和工具输入输出。模型为什么选择了那个工具、为什么生成了那段回复，只有看了Prompt才能复盘；工具返回了什么数据、调度器怎么解析的，是排查"Agent答非所问"的关键。这些日志要保留足够长的时间，至少一周，方便事后复盘。
我见过太多Agent排障案例，最后都卡在"当时到底发生了什么"上。没有全链路日志，你只能对着一个错误答案猜是模型的错、工具的错还是调度的错，猜来猜去效率极低。
6.2 指标埋点与告警
有了日志，还要提炼指标做告警。日志是排查问题的素材，指标是发现问题的眼睛。Agent调度链路需要重点关注四类指标。
第一类是任务状态相关指标，包括任务创建数、完成数、失败数、超时数、取消数，以及各类状态之间的转化率。第二类是延迟指标，按阶段拆分：规划耗时、工具调用耗时、模型推理耗时、总耗时。第三类是成本指标，每类模型调用的token消耗，这里有两个细分维度：输入token、输出token，都要单独计量。第四类是质量指标，比如任务重规划率、工具重试率、用户放弃率，间接反映调度设计的合理性。
告警规则也要分等级设计。任务失败率超过5%是警告，超过15%是严重；平均规划耗时超过10秒是警告；单个任务的token消耗超过预设上限是提示作为成本预警。告警出来之后要有响应流程，不是打个电话通知人就行了，要能直接关联到一批trace_id，让值班的人有线索可以查。
6.3 一个真实事故的完整排查思路
拿我曾经遇到的一次线上事故举例，任务失败率在十分钟内从2%飙升到30%。故障的表现是用户反馈Agent经常答非所问，隔一会儿又正常。
我的排查思路是分层的。第一步查指标，发现任务失败集中在拆解后的执行阶段，而不是规划阶段，所以先怀疑工具层。第二步看工具调用的日志，发现失败的都是同一个搜索类工具，返回的HTTP状态码是503，说明是工具服务方在抖动。第三步查重试效果，发现重试策略虽然配置了，但重试间隔太短，工具服务还没恢复就把重试次数耗光了。第四步是修正方案：把该工具的超时放宽到8秒，重试间隔改成指数退避，同时增加一个功能回退，让搜索失败时改走知识库检索。
整个排查链路大概用了40分钟，其中有将近一半时间花在定位具体是哪个工具出问题上。如果当初没有按trace_id建立全链路日志，这种问题可能要查上半天。所以说可观测性不是说说的漂亮话，它是Agent生产系统里的刚需。
7. 调度的性能与成本优化
7.1 整个链路真正的瓶颈在哪
Agent调度系统的性能瓶颈，绝大多数情况不在服务器，而在模型API和大模型推理本身。一次多步Agent任务，可能要调三到五次模型，每次模型的响应时间动辄几秒，加在一起用户就要等十几秒甚至更久。调度器本身那点CPU消耗，跟模型推理一比可以忽略。
所以性能优化的核心思路是"减少不必要的模型调用"。目标不是让调度器跑得更快，而是让任务少调模型、调小Prompt、减少无效的推理轮次。
这里要算一笔账。一次普通的客户服务Agent任务，如果不做优化，大概要调模型四次：一次意图识别、一次规划、一次工具结果汇总、一次最终回答生成。如果用户中途追加一句追问，还要再加两次。按一次调用5秒计算，总耗时20到30秒，用户早就放弃了。做了优化之后，意图识别用规则或轻量模型，规划和汇总合并成一次推理，总调用降为两次，耗时控制在10秒内，体感完全不同。
7.2 缓存、合并与预调度
降模型调用的手段，我把它们总结为三层。
第一层是缓存。同一类任务的规划结果可以缓存。比如"查天气"这个功能，不同用户查同一城市同一时间，完全没有必要每次都规划一次，直接复用上次的规划模板，只替换参数。工具调用结果也要缓存，尤其是耗时高的外部API，设置一个合理的TTL能省下大量重复请求。
第二层是合并调用。模型的小步调用可以并成一大步。比如规划之后，如果多个子任务互相独立，可以尝试让模型一次性返回多个工具调用，而不是一个工具调完等返回再调下一个。实测在这种场景下的响应时间能缩短一半，只要保证上下文里提供了足够的工具描述和输入模板。
第三层是预调度。根据任务类型和历史数据，提前预置一批常见的规划模板。用户在界面上点"查天气""查附近餐厅"这类固定动作时，调度器甚至不用走规划器，直接从模板库取出子任务图，跳过模型推理直接进入执行阶段。这一步优化不仅快，还最稳定，因为模板是经过多次验证的。
7.3 分布式部署下的调度差异
如果Agent系统单机扛不住了，要扩展到分布式，调度器的设计也要跟着变。最核心的变化是，任务不再跑在单个进程里，而是要跨实例调度。
分布式的第一件事是把调度器做成分层的：全局调度器负责任务的接收、拆解和分发；工作节点执行具体的子任务和工具调用。全局调度器维护一个任务队列，把规划好的子任务发布到消息队列或任务队列里，工作节点空闲了就拉取执行，执行完写回任务状态。这里推荐的方案是Redis Stream或类似的消息队列，既有持久化能力，又支持消费者组模式。
分布式还有个绕不开的问题：会话状态和任务状态必须外部化。单机时代你可以把状态存在进程内内存，分布式绝对不能这么做。所有状态都要放到Redis或数据库中，每个状态的更新要走原子的条件更新，避免多个实例同时改一份状态导致的竞态问题。我遇到过最典型的问题是同一个任务被两个工作节点同时拉起执行，原因是任务状态从QUEUED到RUNNING的更新不是原子的，两个节点同时读到QUEUED状态就都去执行了。解决方式是加分布式锁或数据库乐观锁，把"抢占任务"做成原子操作。
最后是分布式下的人工干预能力。全局调度器收到人工确认或取消指令后，要能跨节点通知正在执行的工作节点暂停或终止。这个可以用一条广播消息实现，工作节点订阅事件，收到终止指令后立刻停止当前子任务并把状态回写。别小看这个设计，没有它的话，用户已经点了"取消"，后台还在傻乎乎地调API，成本一直涨。
8. 写在最后的几点体会
8.1 调度器不是越复杂越好
很多人一听说Agent任务调度，就觉得要上一堆框架，把ReAct、Plan-and-Execute、反思循环、多智能体协作全塞进去。我的亲身体会是：调度器的复杂度应该由业务场景决定，而不是由技术时髦程度决定。一个只处理"查询订单、查天气、闲聊"的系统，一个简单的Plan-then-Execute加工具注册表就够了，硬上复杂的反射机制和多Agent协作，只会让系统响应变慢、出错的概率变大、排查问题变得痛苦。
8.2 先跑通再优化，先小流量再全量
我做的每一次Agent系统改造，都遵循同样的节奏：先在离线环境跑通核心链路，再用一个内测用户组放小流量，观察日志和指标，最后才全量上线。Agent系统的行为不确定性决定了它不可能一次就调好，必须靠线上数据不断修正规划器拆解的粒度、工具超时设置和重试参数。拿五个真实任务跑通和拿五千个真实任务跑稳，中间隔着的就是这些细节的调优。
8.3 给新入坑的开发者一个起步建议
如果你是第一次搭Agent调度系统，我建议别直接用重型框架，先用你最熟悉的语言把最小闭环写出来：一个入口函数、一个工具注册表、一个简单的调度循环、几个日志。跑通之后你自然会发现哪里痛、哪里需要拆解、哪里需要加状态机，这时候再引入框架或重写都不迟。我始终觉得，调度这块的难点不在技术选型，而在于你有没有真正理解任务在你系统里是怎么流动的。理解清楚了，写出来的调度器不一定漂亮，但一定好用。
