中 困难
多Agent调度与失败传播#
一句话答案#
多 Agent 调度核心是任务队列+优先级+依赖图:Supervisor 分解任务后放入优先级队列,Worker 按依赖拓扑序执行;失败传播策略决定单 Worker 失败是重试、降级、跳过还是终止全局任务,防止 cascade failure 是平台级多 Agent 的关键挑战。
核心要点
一、任务调度架构
用户请求 → Supervisor(任务分解+编排)
│
├─ 任务队列(优先级+依赖)
│ ├─ Task A (priority:HIGH, deps:[]) → Worker Pool
│ ├─ Task B (priority:HIGH, deps:[A]) → 等 A 完成
│ ├─ Task C (priority:MEDIUM, deps:[A]) → 等 A 完成
│ └─ Task D (priority:LOW, deps:[B,C]) → 等 B+C 完成
│
└─ 调度器
├─ 依赖解析:拓扑排序确定执行顺序
├─ 并行度控制:无依赖任务可并行
├─ 资源分配:按优先级分配 Worker/Token
└─ 超时管理:每个任务独立超时plaintext二、调度策略
| 策略 | 原理 | 适用 |
|---|---|---|
| FIFO | 先进先出 | 简单场景,无优先级需求 |
| 优先级队列 | 高优先级任务先执行 | 有紧急任务和后台任务混合 |
| 依赖感知 | 拓扑排序+就绪队列 | 任务间有前后依赖 |
| 公平调度 | 按租户/用户轮询 | 多租户共享 Worker |
| 抢占式 | 高优中断低优 | 严格 SLA 要求 |
并行度控制:
max_concurrent_workers: 5 # 最多5个Worker同时执行
max_concurrent_llm_calls: 3 # 最多3个LLM并发调用(成本/限流)
per_task_timeout: 60s # 单任务超时
global_timeout: 300s # 全局超时plaintext三、失败传播策略
| 策略 | 行为 | 适用 |
|---|---|---|
| Retry (重试) | 失败后重试N次(指数退避) | 临时性故障(网络/限流/超时) |
| Fallback (降级) | 使用备选方案执行 | 有替代路径(换模型/换工具) |
| Skip (跳过) | 标记失败,跳过该子任务 | 非关键子任务(辅助信息收集) |
| Abort (终止) | 终止全局任务,触发补偿 | 关键子任务失败(核心数据不可用) |
| Escalate (升级) | 人工介入审批 | 高风险操作失败(写入/删除) |
Supervisor 决策逻辑:
Worker 返回失败
→ 检查失败类型
├─ 可重试错误(429/503/timeout)→ Retry(max 3次,指数退避)
├─ 不可重试错误(400/参数错误)→ 检查任务关键性
│ ├─ 关键任务 → Abort + 通知
│ └─ 非关键任务 → Skip + 记录
└─ 工具调用失败 → 检查是否有替代工具
├─ 有 → Fallback 到替代工具
└─ 无 → 按关键性决定 Abort/Skipplaintext四、Cascade Failure 防护
问题场景:
Worker A 超时 → Supervisor 等待 → Worker B 超时(A的结果是B的输入)
→ Worker C 超时 → ... → 全局超时 → 用户等很久才收到失败
防护措施:
1. 每层独立超时(而非只有全局超时)
2. 快速失败:依赖的前置任务失败→立即取消下游任务
3. 断路器:某 Worker 连续失败N次→暂停分配任务
4. 全局 Token 预算:总消耗接近上限→提前终止低优任务
5. 部分结果返回:已完成的子任务结果可用→返回部分答案plaintext五、仲裁与审批流
| 场景 | 仲裁规则 |
|---|---|
| 多 Worker 结果冲突 | Supervisor 综合评分取最佳 / 多数投票 / LLM 裁判 |
| Worker 结果置信度低 | 触发二次验证 / 换 Worker 重做 / 人工确认 |
| 高危操作(写入/删除) | 暂停执行→推送审批→人工确认后继续 |
| 预算即将耗尽 | 暂停低优任务→只执行关键路径 |
六、重放与审计
重放机制:
- 目的:排障时复现问题、评测时固定输入
- 记录:每次 Worker 调用的输入/输出/耗时/工具调用
- 重放模式:replay(重新执行)vs mock replay(用记录的输出)
- 幂等要求:重放的工具调用必须幂等或走 mock
审计日志:
{
"task_id": "global-001",
"subtask_id": "sub-003",
"worker_id": "worker-B",
"action": "tool_call",
"tool": "database_query",
"input": {"query": "SELECT ..."},
"output": {"rows": 42},
"status": "success",
"latency_ms": 156,
"token_usage": {"prompt": 500, "completion": 200},
"timestamp": "2026-05-26T10:30:00Z"
}json面试回答(2分钟版)
多 Agent 调度我设计了三层。第一层是任务队列:Supervisor 把用户请求分解成子任务放入优先级队列,调度器按拓扑排序解析依赖关系,无依赖的任务可以并行执行,有依赖的等前置完成后触发。第二层是失败传播策略:每个 Worker 失败时 Supervisor 根据失败类型和任务关键性决定是重试、降级、跳过还是终止。临时性错误如限流超时走重试,不可重试的关键任务走终止,非关键任务跳过继续。防止 cascade failure 的关键是每层独立超时加快速失败:前置任务失败立即取消所有下游任务,不是等到全局超时才反应。第三层是仲裁和审批:多 Worker 结果冲突时 Supervisor 综合评分选最佳,高危操作暂停等人工审批。所有调度记录都写审计日志支持重放排障。这套设计的核心类比是分布式任务调度系统加上 Agent 特有的不确定性处理。
追问与易错
追问方向:
- “和传统工作流引擎(Temporal/Airflow)区别?”→ Agent 任务图是动态的(LLM 运行时决定下一步),Supervisor 可能在运行中根据中间结果调整计划;传统引擎是静态 DAG,编排流程在启动前就确定
- “Worker 之间怎么传递上下文?”→ 三种方式:共享 context store(Redis/DB 存中间结果)、消息传递(MQ/事件总线)、Supervisor 中转(Supervisor 汇总 Worker 输出后分发给下游 Worker)
- “怎么监控多 Agent 系统健康?”→ 核心指标:Worker 任务成功率、平均/P99 延迟、cascade failure(级联失败)频率、人工介入率、Token 消耗趋势;Dashboard 按 Worker 类型分维度展示
- “并行度太高怎么限制成本?”→ 设全局 Token 预算(超预算暂停低优先级任务)+ 并发 LLM 调用数上限(信号量/令牌桶)+ 优先级抢占(高优任务可抢占低优任务的算力配额)
易错点:
- ❌ “所有任务都重试”——不可重试错误(参数错误/权限不足)重试无意义
- ❌ “只有全局超时”——必须每层独立超时,否则 cascade failure
- ❌ “Worker 之间直接通信”——应通过 Supervisor 中转,保证可控和可审计
- ✅ 核心思路:独立超时+快速失败+部分结果返回 = 防 cascade 的三板斧