吴师兄大模型
实战项目 · 面试解析

在多智能体(Multi-Agent)系统中,常见的调度策略有哪些?请说明其实现机制及在任务分配、资源协调方面的考量。

Agent 智能体进阶
← 返回列表
核心概念

Multi-Agent(多智能体系统)将一个大任务拆分给多个专职 Agent 协作完成。核心动机:单 Agent 处理复杂任务时会出现 Context 爆炸、注意力分散、容易死循环等问题。Multi-Agent 的本质是专业分工 + SOP 流程——每个 Agent 只做自己专长的事,由 Orchestrator(协调者)统一调度,就像人类公司的部门协作。

面试答题思路
4步拆解
1
先说单 Agent 的三个困境
Context 爆炸、注意力分散、容易死循环。Multi-Agent 的动机就是解决这三个问题。
2
介绍两种经典拓扑
顺序流(流水线,流程固定)和 Supervisor 模式(层级调度,任务复杂)。用具体场景举例:写研报用顺序流,开发软件用 Supervisor。
3
用 LangGraph 代码说明实现
StateGraph 构建节点和边,条件边实现动态路由,这是目前工业界最主流的实现方式。
4
说工程化挑战
消息路由、状态一致性、max_iterations 限制、Agent 间通信方式。体现你做过生产级 Multi-Agent 系统。
详细解析

为什么单 Agent 不够用?

问题 1: Context 爆炸

任务越复杂,上下文越长,LLM 对早期内容的注意力越弱

-> 出现「忘了最初需求」的情况

问题 2: 注意力分散

既要扮演产品经理,又要扮演程序员,角色混乱

-> 代码质量和需求分析质量都打折扣

问题 3: 死循环风险

代码报错后,单 Agent 可能不断重试相同错误

-> 缺乏跳出机制

两种经典协作拓扑

顺序流(Sequential Flow)——流水线模式

适用于:流程固定的任务(写研报、处理保险理赔)

用户需求

-> Agent A(产品经理):需求分析 -> 需求文档

-> Agent B(程序员):代码实现 -> 代码文件

-> Agent C(测试员):测试验证 -> 测试报告

-> 最终输出

Supervisor 模式(层级调度)——项目经理制

python
class SupervisorAgent:

def __init__(self):

self.workers = {

"researcher": ResearchAgent(), # 搜索信息

"analyst": AnalystAgent(), # 数据分析

"writer": WriterAgent(), # 报告撰写

}

def orchestrate(self, task: str) -> str:

plan = self.llm.plan(task) # 拆分任务

results = {}

for step in plan:

worker = self.workers[step.agent]

result = worker.execute(step.instruction)

# 检查质量,必要时触发返工

if not self.is_satisfactory(result):

result = worker.retry(step.instruction, result)

results[step.name] = result

return self.merge_results(results)

LangGraph 实现 Multi-Agent

python
from langgraph.graph import StateGraph

graph = StateGraph(AgentState)

graph.add_node("router", RouterNode())

graph.add_node("planner", PlannerNode())

graph.add_node("executor", ExecutorNode())

graph.add_node("reflector", ReflectorNode())

graph.add_node("critic", CriticNode())

# 条件边:根据意图动态路由 def route_by_intent(state):

if state["intent"] == "general":

return "critic" # 普通问答直接回答

return "planner" # 复杂任务需要规划

# 反思后决定是否继续 def should_continue(state):

if state["should_continue"]:

return "executor" # 继续执行

return "critic" # 生成最终答案

graph.add_conditional_edges("router", route_by_intent)

graph.add_edge("planner", "executor")

graph.add_conditional_edges("reflector", should_continue)

app = graph.compile()

Multi-Agent vs Single-Agent 对比

维度Single AgentMulti-Agent
适用任务中等复杂度,工具 < 5 个高度复杂,需多专业协作
上下文管理简单,单一上下文复杂,需要消息路由和隔离
调试难度高(难定位哪个 Agent 出错)
性能顺序执行可并行,效率高
重点提示
Multi-Agent 的核心价值:每个 Agent 只看自己相关的上下文,减少干扰;可以单独优化某个角色的 Prompt;像搭积木一样组装流程。本质是将「一个大 Prompt」拆成「多个专职小 Prompt」。
Multi-Agent 最大工程挑战:消息路由和状态一致性。多个 Agent 并发执行时,需要设计同步机制防止竞争条件。必须设置全局 max_iterations 防止 Agent 间互相调用陷入死循环。
知识卡片
4个知识点
Supervisor 模式 vs 顺序流

顺序流适合流程固定、每步输出作为下一步输入的任务;Supervisor 模式适合任务可能需要返工或非线性流转的复杂场景,由 Orchestrator 动态调度。

Agent 间通信方式

共享 State 对象(LangGraph 方式,简单高效);消息队列(Kafka/Redis,解耦但延迟高);直接函数调用(高效但耦合)。LangGraph 的 Graph State 是目前最推荐的方式。

AutoGen vs LangGraph

AutoGen(微软):对话即开发,Agent 通过互相聊天协作,适合代码生成和快速原型;LangGraph:图状态机,精确控制每一步,适合生产环境和复杂企业级应用。

冲突检测与协调

当多个 Agent 策略冲突时:① 引入 Arbitrator 节点仲裁;② 使用优先级队列(关键 Agent 优先);③ 投票机制(多 Agent 对同一问题的结果取多数);④ 回滚到最近一致状态。

面试官视角

面试官问你们为什么用 Multi-Agent 而不是单 Agent,不要说因为 Multi-Agent 更先进。正确答案:我们在单 Agent 方案中遇到了两个问题:① 处理金融分析时,同时做数据查询、分析、报告生成,上下文过长导致前期需求被遗忘;② 一个 Agent 身兼多职导致角色混乱,SQL 质量和分析质量都下降。所以改成三个专职 Agent(数据 Agent + 分析 Agent + 报告 Agent)+ Supervisor 协调,各 Agent 只看自己相关的上下文,整体准确率提升了约 15%,同时 Prompt 优化更容易——只需调整某个专职 Agent 的提示词,不影响其他模块。