面试知识库
困难

多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/Skip
plaintext

四、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 的三板斧