1. ax调度到底在调度什么一次线上故障带给我的复盘先交代一个背景。前段时间我们团队上一个智能体项目跑在线上的服务突然开始连环报错表现很典型用户发起一个任务Agent 按计划调用了三个工具结果第一个工具成功、第二个工具超时、第三个工具拿到了错误参数整个任务流直接中断。当时第一反应是模型变笨了或者工具接口不稳定排查了半天才发现问题根本不是出在模型或者某个单一工具上而是出在整个执行过程的调度层——谁先调谁、参数怎么传、失败了谁来兜底这些逻辑又散又乱每个 Agent 节点都在自己判断最终导致了雪崩式的失败。ax调度这个词在社区里聊得很多但如果把它拆开看它讲的其实就是Agent 执行过程里的任务编排与调度。中文里的ax经常被用作 Agent Execution 的缩写所以ax调度指的就是当一个智能体需要完成一个复杂目标时系统如何把大目标拆成小步骤如何决定每一步调用哪个工具、传入什么参数、在什么条件下继续或中止以及整个过程的执行状态如何被追踪和管理。现在很多项目把功夫花在提示词、模型微调、RAG 召回上却普遍低估了调度层的复杂度。我在实际开发和排障中的体会是Agent 应用真正从 Demo 走向生产分水岭恰恰就是调度这个看不见摸不着的环节。Demo 阶段任务简单、链路短、单用户调用顺序执行就够了但一旦任务变多、工具变多、并发变大调度层的设计缺陷会集中爆发。这篇文章不聊哲学层面Agent 是什么直接讲工程层面任务调度怎么做。我会从一个真实项目的角度说说调度器怎么选型、工具调用边界怎么设计、状态怎么管理、失败怎么恢复以及多 Agent 并发时最容易被忽视的那些坑。如果你正在搭一个生产级的 Agent 应用或者你的 Agent 已经出现偶尔好用、偶尔抽风的症状这篇文章应该能帮你少走不少弯路。2. 调度器选型的取舍为什么我没有一开始就用重框架很多教程一上来就推荐 LangGraph、AutoGen、CrewAI 这类框架搞得好像不用框架就没法做调度。但我的实际体验是对于大多数业务场景特别是任务链路相对固定、工具集合明确的场景自研一个极简调度器反而比上重框架更可控。2.1 先搞清楚调度器到底要管什么调度器要管的不是模型生成什么文本而是模型生成文本之后要执行什么动作。一个合格的 ax 调度层至少要做这些事解析大模型输出的结构化指令工具名、入参。校验入参是否合法、是否缺失。决定当前步骤是继续调用下一个工具还是把结果回传模型还是直接终止。维护整个执行链的状态快照确保每一步都能回溯。处理超时、重试、失败兜底和上下文窗口溢出。如果这些逻辑全部散落在业务代码里每个 Agent 节点各写各的就会出现我在开头说的那种故障第二步失败了第三步不知道第三步拿到了脏参数继续往下传状态没人记录排障全靠翻日志。2.2 主流调度方案的适用边界我梳理过几种常见做法的适用边界方便你对照自己的场景来选择。方案适合场景不适合场景直接在业务代码里写顺序/分支链路极短、步骤固定、需求变化少链路复杂、分支多、后续扩展频繁LangGraph 等图编排框架需要复杂状态机/图结构、团队已有相关经验不想被框架的状态序列化和回调机制绑死Temporal、Celery 等通用任务队列需要持久化、重试、分布式执行的大型系统任务粒度太轻、上下文需要时刻跟随 Agent自研极简调度器链路中等、业务规则独特、需要精细控制需要完整生态和可视化界面我这里不是说框架不好而是想强调一个观点调度层的复杂度应该匹配任务本身的复杂度。我们项目早期用过一个图编排框架后来发现 90% 的任务其实都是线性流程加少量分支框架带来的状态传播、回调注册反而让调试变得更难。后来我基于一个几十行的循环调度器配合固定的工具接口规范反而把问题看清楚了。2.3 自研调度器的核心结构我最终实现的调度器核心很朴素就是一个模型-工具-模型的循环结构类似这样class SimpleScheduler: def __init__(self, model, tool_registry, max_steps8): self.model model self.tool_registry tool_registry self.max_steps max_steps def run(self, user_task, memoriesNone): messages [{role: user, content: user_task}] for step in range(self.max_steps): reply self.model.chat(messagesmessages, toolsself.tool_registry.schemas) if reply.get(tool_calls): messages.append(reply) for call in reply[tool_calls]: tool_result self.execute_tool(call) messages.append({role: tool, tool_call_id: call[id], content: tool_result}) else: return reply[content] raise TimeoutError(fexceed max steps: {self.max_steps})这段代码的好处是可读、可控、可改。什么变量注入、工具白名单、步骤上限全部在自己手里。如果团队刚起步我建议你也先写一个这样的最小循环把链路跑通再根据真实瓶颈决定要不要引入框架。3. 工具定义与执行边界调度的质量取决于工具契约有多严调度器本身不产生业务价值它调度的工具才是。我在项目里踩过最深的坑是工具定义不规范导致调度器像一个拿着错地图的司机——模型想调用参数传不对执行报错任务失败。3.1 把工具当 API 来设计而不是当函数来设计很多 Agent 项目把工具函数写得非常随意参数命名自由、类型不明确、返回值数据结构不固定。模型没法从自然语言描述里准确猜出你的参数格式于是它每隔几轮就会产生一次幻觉调用。后来我把工具定义统一成 JSON Schema每个工具都有明确的类型签名、必填参数、可选参数、返回结构。一个典型定义长这样{ type: function, function: { name: query_order_status, description: 查询订单当前状态支持按订单号或客户手机号查询, parameters: { type: object, properties: { order_id: {type: string, description: 订单号例如 SO20250101}, phone: {type: string, description: 客户手机号与订单号二选一} }, oneOf: [ {required: [order_id]}, {required: [phone]} ] } } }这个定义看起来不起眼但它能解决 90% 的参数幻觉问题。尤其是二选一这种约束如果不写清楚模型经常会把两个参数一起传或者都不传。3.2 执行边界的硬编码校验模型传参之后调度器不能直接信任参数必须做二次校验。我维护了一个很简单的校验层逻辑就是先验证、再执行、后格式化def execute_tool(self, call): tool self.tool_registry.get(call[name]) if not tool: return {error: funknown tool: {call[name]}} try: validated_args tool.validate(call[arguments]) except ValidationError as e: return {error: finvalid arguments: {e}} result tool.run(validated_args) return self._truncate_result(result, max_length2000)这里有两个细节值得单独说。校验失败时不要把异常直接抛给模型而是把错误信息变成工具返回结果塞回对话。因为模型需要看到为什么失败、怎么改才能自我修正。你把异常抛给调度器调度器只能干瞪眼。返回结果必须截断。一次工具调用可能返回几千上万字的 JSON模型上下文窗口装不下。切片保留关键字段比全量塞进去更高效。我甚至建议把截断结果也写进工具契约每个工具返回给模型的内容必须有一个明确的summary字段只包含模型决策需要的信息。这比事后截断更优雅。3.3 组合工具与工具内部分工当工具数量超过十个以后模型在每一步进行工具选择的准确率会明显下降。这不是模型不行而是候选集太大、语义空间太宽模型很难精准命中。我的做法是把相关能力组合成更上层的工具。比如不再暴露query_warehouse_stock、query_supplier_eta、calc_available_days这三个工具而是暴露一个estimate_delivery_date工具内部自己串联三步。这样工具数量精简了模型的选择难度降低了调用链路的整体稳定性明显提升。组合工具还有一个额外的好处中间结果不占上下文窗口。内部步骤的细节在聚合工具内部消化掉只把最终结果返回模型这就等于给上下文做了一次自清洗。4. 状态管理与可观测性让每次调度都可回放、可审计Agent 项目最让人头疼的一点是执行过程高度动态。同一个任务每次跑出来的调用序列可能都不一样。如果你没有把执行状态落盘出了问题就只能靠日志猜测这对生产环境是致命的。4.1 快照与事件日志缺一不可我为每次任务维护了两份东西一个任务快照记录当前 agent 的完整状态包括消息历史、已调用的工具、结果摘要、当前步骤、剩余预算。一个事件日志记录每一次调度的细节包括模型输入、模型输出、工具调用、工具返回、耗时、token 数、异常信息。快照用于恢复事件日志用于排查。两者配合才能做到每次调度都可回放。事件日志的字段我建议这样设计{ trace_id: task_xxx_step_3, task_id: task_xxx, step_index: 3, model_request: {messages_count: 12, prompt_chars: 3421}, tool_call: {name: query_order_status, arguments: {order_id: SO20250101}}, tool_result: {status: success, summary: 已发货预计3天后到达}, latency_ms: 842, token_usage: {input: 2310, output: 156}, error: null }我建议这个结构尽量扁平化、字段固定方便后续聚合统计。别小看这些数据它同时是监控指标的来源、回归测试的基准、以及调度策略优化的依据。比如你统计后发现query_order_status这个工具平均耗时 800ms但偶尔会飙到 30 秒那你就知道该给这个工具做缓存或降级了。4.2 断点续跑别让一次偶发超时毁了整个任务模型调用和工具调用都可能因为网络问题偶发失败。调度器必须有断点续跑的能力。我在上文的快照基础上实现了这样一个恢复机制任务执行到某一步时将最新快照写入存储。如果进程崩溃或调用超时从存储中读取最近快照。将最后未完成的步骤重新提交而不是从头运行。这个机制在第 3 节那个模型-工具-模型循环里不难实现核心是给每一步打上step_index并且保证工具调用是幂等的——同一个工具、同一个参数、多次执行的结果一致或者至少不会产生副作用叠加。4.3 成本预算和步数上限是调度器的安全绳Agent 一旦进入循环可能出现模型反复调用同一工具却拿不到想要结果的死循环。别指望大模型自己能判断该停了在工程上必须设置硬约束最大步数我一般设 5 到 10 步超过直接终止并提示用户。单任务 token 预算累计 token 超过阈值就停止后续模型调用。单工具超时单个工具调用超过阈值就标记失败不再等待。这些约束和模型能力无关它们是系统的工程护栏。没有护栏的调度器跑在公网上就是一种风险敞口——既烧钱又容易把下游接口打爆。5. 规模化的现实摩擦并发、限流、重试与幂等单个任务跑通之后接踵而来的问题是多个任务同时跑怎么办这里有几个坑不是理论推出来的是我被实际故障教训过后才总结出来的。5.1 上游限流 vs 调度器超时两套机制必须分层工具调用有上游限流调度器本身也会设置超时。如果这两者没有协调好会出现很尴尬的局面上游接口限流返回 429调度器没有特殊处理把它当成普通错误重试。结果重试次数越多429 越严重最终把限流时间拉长。我的处理方式是调度器里对限流类错误和偶发网络错误区分对待。限流类错误按指数退避后重试最多重试 2 次偶发网络错误最多重试 3 次业务错误比如参数校验失败不重试直接回传模型修正。重试预算耗尽后把错误信息作为工具结果返回让模型决定下一步。5.2 并发的粒度按任务隔离而不是按全局池化多任务并发时不要把工具调用放在一个全局线程池里不加隔离。一个任务里的工具调用耗尽了线程池其他任务全部阻塞这是我在生产环境遇到的真实事故。现在每个任务一个独立的任务执行器任务内部的工具调用使用独立的信号量控制并发数这样单个任务再慢也影响不到其他任务。具体的并发参数我没有标准答案但有一条经验值得参考任务的并发上限应该按下游系统的承受能力来定而不是按调度器的能力来定。调度器自己能扛住每秒 1000 次调用但下游系统只能扛住每秒 20 次那你依然会被打挂。5.3 幂等同一任务的重复执行不应产生重复副作用断点续跑和重试机制都要求工具具备幂等性。对于查询类工具天然幂等但对于创建订单、发送消息、扣减库存这类有副作用的工具必须显式处理。我的方案是在工具层增加一个请求指纹字段。每个外部调用带一个由任务 ID 和步骤 ID 生成的唯一 key下游系统用这个 key 做去重。这个 key 要由调度器生成并透传不能由模型自由发挥否则模型每次生成的参数不一样去重就失效了。6. 从单 Agent 到多 Agent调度粒度变粗之后问题反而更隐蔽最后聊聊多 Agent 场景。现在很多项目把一个大 Agent 拆成多个小 Agent每个 Agent 负责一个子领域再通过一个主调度器来编排。这种架构确实提升了单任务的专注度但也带来一个新的问题调度粒度变粗了问题的定位反而更困难了。6.1 主调度器协调子任务时要维护子任务的执行图多 Agent 编排的本质是把一个大的模型-工具循环拆成多个嵌套的循环。主调度器负责决定下一个执行哪个子 Agent而子 Agent 内部再做自己的工具编排。这就带来一个状态同步问题主调度器要知道每个子 Agent 的进度否则它无法决定下一步。我的做法是让每个子 Agent 执行完之后返回一个结构化的结果包裹里面包含status、summary、artifacts、remaining_budget这几个字段。主调度器只看包裹不深入子 Agent 内部细节。这样做有两个好处一是主调度器的上下文不会被子 Agent 的内部中间过程塞满二是每个子 Agent 的执行可以被高效缓存——如果任务重复直接复用结果。6.2 跨 Agent 的上下文传递不是传递全部历史多 Agent 协作时最容易犯的错误是把一个 Agent 的完整对话历史直接传给下一个 Agent。你的模型上下文窗口再大也不够这么造。正确做法是传递结构化摘要。每个子 Agent 结束时除了执行结果还要生成一段摘要说明它完成了什么、产出了什么关键结论、下一阶段需要什么信息。主调度器把这些摘要聚合后再分发给下一个子 Agent。我也曾尝试让 Agent 之间直接互相对话看起来灵活但实际工程上极难控制——两个 Agent 围绕同一个问题来回扯皮步数指数上升最后任务超时。还是主调度器 结构化传递更稳。6.3 多 Agent 的故障隔离比单 Agent 更需要设计单 Agent 出问题最多任务失败重跑一遍就行。多 Agent 出问题尤其是 A Agent 的异常状态通过共享上下文传递给了 B Agent那故障范围就会扩大。我给每个子 Agent 加了独立的配置边界工具权限、prompt 模板、可访问的存储空间、token 预算全部隔离。子 Agent A 不该访问的数据即使模型被误导调用也在权限层被拦截。多 Agent 系统的调度安全问题往往不是模型出问题而是权限边界没设好。7. 我个人在实际项目中的几个总结写到这里我不打算做什么系统性总结就分享几条我在实际项目里的切身感受可能会更有用一些。第一调度器的复杂度要从小往大长。我们项目最早就是一个 while 循环加几个 if后来逐步加了工具校验、状态快照、断点续跑、权限隔离。每一步都是被真实故障逼出来的而不是我一开始设计出来的。工程上永远先跑通再谈优化这在调度层特别重要。第二工具契约比调度器本身更值得打磨。我见过不少团队花大力气写调度器但工具定义潦草、参数说明含糊结果调度器再强也白搭。模型是调度器的大脑工具是手脚大脑本事再大手脚不听使唤也不行。把时间花在把每个工具写清楚、写严谨上回报率比调 prompt 高得多。第三可观测性要早做。我们项目早期对事件日志的重视不足出了问题全靠人肉翻日志加猜测效率极低。后来把事件日志结构统一之后不少问题直接看 trace 就能定位故障排查时间从小时级降到了分钟级。这一块投入很值得。第四现在社区讨论 ax 调度很多都在谈让模型自己规划、自己选工具但我还是那个观点模型的自由度应该被约束在调度器划定的边界内。规划可以自由执行必须可控。边界之外的自由最后都会转化为生产环境里难以排查的故障。如果你现在正被 Agent 应用的不稳定困扰先别急着换模型、调 prompt不妨把调度链路梳理一遍看看工具契约是否严谨、状态记录是否完整、重试机制是否分层。很多时候稳定性的瓶颈根本不在模型而在调度。