企业官网建设流程全解析

为什么一个 Agent 不够用？

前面八篇文章里，我们构建的都是单 Agent：一个 LLM，一组工具，一条对话历史。这套架构能解决大多数问题。

但有些任务天然是"多专家"的：

• 写一篇技术文章，需要研究员收集资料、写手起草、编辑润色——三个角色，三种思维方式
• 处理用户工单，需要意图识别、知识库查询、回复生成——三个阶段，独立可测
• 代码评审，需要静态分析、安全扫描、可读性审查——三个维度，互不干扰

用单 Agent 处理这些任务并非不可以，但你会发现 System Prompt 越写越长，输出质量越来越不稳定——因为你在强迫一个角色扮演所有人。

多 Agent 的核心价值：职责分离，每个 Agent 只做一件事，做好它。

两种主流架构模式

多 Agent 系统有多种拓扑结构，其中两种最常见：

Supervisor 模式（动态路由）： classify → supervisor → researcher ↘ writer ↘ reviewer ↘ FINISH 特点：有一个"指挥中心"，决定下一步调哪个 Agent Pipeline 模式（固定顺序）： outline_agent → draft_agent → polish_agent → END 特点：执行路径硬编码，每个 Agent 只知道自己的上下文和下一个节点

两种模式不是竞争关系，而是适用场景不同。

Demo 1：Supervisor 模式

设计思路

Supervisor 模式的挑战在于路由可靠性。如果让 LLM 每一步都决定"下一个调谁"，它会出现：

• 重复调用同一个 Worker
• 忘记记录已调用过的 Worker
• 不知道何时该终止

更好的设计是两阶段混合：

Phase 1: LLM 做一次任务分类（simple_fact vs full_article） Phase 2: Python 根据分类 + 已调用列表做确定性路由

LLM 负责"看清楚这是什么任务"，Python 负责"按规则执行"。

LangGraph 实现

classSupervisorState(TypedDict):messages:Annotated[list,add_messages]task:strtask_type:str# "simple_fact" or "full_article"called:list[str]next:strdefclassify_node(state:SupervisorState)->SupervisorState:"""LLM 做一次分类，结果写入 state，后续路由全程可用"""decision=_ask("Classify this task:\n"" simple_fact — a factual question with a direct short answer\n"" full_article — needs research, writing, and editorial review\n""Output one word only: simple_fact / full_article",f"Task:{state['task']}",).strip().lower()task_type="full_article"if"full_article"</