架构设计

引言：为什么Agent系统需要微服务化？ 2026年，随着Agent系统在生产环境中的大规模部署，单体架构的局限性日益凸显。一个典型的Agent系统包含意图理解、工具调用、记忆检索、上下文管理和响应生成等多个子系统，当这些功能耦合在一个进程中时，扩展性、可用性和迭代速度都会受到严重制约。 本文将从实际工程角度，系统阐述Agent系统从单体到微服务的完整演进路径。 单体Agent架构的痛点 在早期阶段，大多数Agent系统采用单体架构——所有功能模块运行在同一个进程中： ┌─────────────────────────────────────┐ │ Monolithic Agent │ │ ┌───────┐ ┌───────┐ ┌───────────┐ │ │ │ LLM │ │ Tools │ │ Memory │ │ │ │ Call │ │ Exec │ │ Store │ │ │ └───────┘ └───────┘ └───────────┘ │ │ ┌───────┐ ┌───────┐ ┌───────────┐ │ │ │ Router│ │ Prompt│ │ Response │ │ │ │ │ │ Builder│ │ Formatter │ │ │ └───────┘ └───────┘ └───────────┘ │ └─────────────────────────────────────┘ 核心痛点包括： ...

从Naive RAG到Agentic RAG的演进 RAG技术的发展经历了三个阶段： Naive RAG (2023) → Advanced RAG (2024) → Agentic RAG (2025-2026) 朴素检索 增强检索 智能体检索 单次查询 多次优化 自主决策 固定管道 模块化 动态规划 传统RAG是一个"固定管道"：查询→检索→拼接→生成，一锤子买卖。Agentic RAG将LLM作为"大脑"，让它自主决定是否需要检索、检索什么、检索几次、何时停止。这就像从"查字典"升级为"咨询一个会查资料的研究员"。 Agentic RAG的核心架构 ┌─────────────────────────────────────────────────────┐ │ Agentic RAG Architecture │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────────────────────┐ │ │ │ User │───▶│ Agent Controller │ │ │ │ Query │ │ (LLM + Planning + Memory) │ │ │ └──────────┘ └──────────┬───────────────────┘ │ │ │ │ │ ┌─────────┼─────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌───────┐ ┌─────────┐ │ │ │ Router │ │ Query │ │ Evaluator│ │ │ │ (路由) │ │Rewrite│ │ (评估器) │ │ │ └────┬────┘ └───┬───┘ └────┬────┘ │ │ │ │ │ │ │ ┌─────────┼──────────┼──────────┘ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ │ │ │ Vector │ │ Web │ │ SQL │ │ Graph │ │ │ │ Store │ │ Search │ │ DB │ │ Store │ │ │ └──────────┘ └────────┘ └──────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 四大核心组件 组件 职责 关键能力 Agent Controller 任务规划与决策 分解问题、决定工具调用顺序 Router 工具路由 选择合适的数据源（向量库/搜索引擎/数据库） Query Rewriter 查询改写 将用户问题改写为更有效的检索查询 Evaluator 结果评估 判断检索结果是否充分，决定是否需要追加检索 核心模式解析 模式1：迭代检索（Iterative Retrieval） from langgraph.graph import StateGraph, END from typing import TypedDict, List, Annotated import operator class AgentState(TypedDict): question: str retrieved_docs: Annotated[List[str], operator.add] answer: str iteration: int sufficient: bool def retrieve_node(state: AgentState) -> dict: """基于当前问题+已有信息生成查询并检索""" query = query_rewriter(state["question"], state["retrieved_docs"]) docs = vector_store.similarity_search(query, k=5) return {"retrieved_docs": docs, "iteration": state["iteration"] + 1} def evaluate_node(state: AgentState) -> dict: """评估检索结果是否足以回答问题""" if state["iteration"] >= 3: return {"sufficient": True} prompt = f"""基于以下检索到的文档，能否完整回答用户问题？ 问题: {state['question']} 文档: {state['retrieved_docs']} 如果信息充分回答"SUFFICIENT"，否则回答"INSUFFICIENT"并说明缺什么。""" response = llm.invoke(prompt) sufficient = "SUFFICIENT" in response return {"sufficient": sufficient} def answer_node(state: AgentState) -> dict: """基于所有检索文档生成最终回答""" prompt = f"问题: {state['question']}\n\n参考资料:\n{state['retrieved_docs']}" return {"answer": llm.invoke(prompt)} # 构建工作流 workflow = StateGraph(AgentState) workflow.add_node("retrieve", retrieve_node) workflow.add_node("evaluate", evaluate_node) workflow.add_node("answer", answer_node) workflow.set_entry_point("retrieve") workflow.add_edge("retrieve", "evaluate") workflow.add_conditional_edges( "evaluate", lambda state: "answer" if state["sufficient"] else "retrieve" ) workflow.add_edge("answer", END) agent = workflow.compile() 模式2：多路检索（Multi-Route Retrieval） def route_query(state: AgentState) -> str: """根据问题类型选择检索路径""" routing_prompt = f""" 分析以下问题，选择最合适的数据源： 问题: {state['question']} 选项: - "vector": 适合从内部文档库检索事实性信息 - "web": 适合需要最新信息的时效性问题 - "sql": 适合结构化数据查询 - "graph": 适合关系推理和多方关联 返回JSON: {{"route": "...", "reason": "..."}} """ decision = llm.invoke(routing_prompt) return json.loads(decision)["route"] 模式3：自我纠正检索（Self-Corrective RAG） def grade_documents(state: AgentState) -> dict: """对检索文档打分，过滤低质量结果""" graded_docs = [] for doc in state["retrieved_docs"]: score_prompt = f"""评估文档与问题的相关性(0-10): 问题: {state['question']} 文档: {doc.page_content[:500]} 只返回数字。""" score = int(llm.invoke(score_prompt).strip()) if score >= 6: graded_docs.append(doc) # 如果所有文档都不相关，触发查询改写 if not graded_docs: new_query = llm.invoke(f"改写这个查询以获得更好的检索结果: {state['question']}") return {"retrieved_docs": [], "question": new_query} return {"retrieved_docs": graded_docs} 工程实现：基于LangGraph的完整Agentic RAG from langgraph.graph import StateGraph, END from langgraph.prebuilt import ToolNode from langchain_core.tools import tool from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage # 定义工具 @tool def vector_search(query: str) -> str: """从内部知识库检索相关文档""" docs = vector_store.similarity_search(query, k=5) return "\n\n".join([d.page_content for d in docs]) @tool def web_search(query: str) -> str: """从网络搜索最新信息""" results = search_api.search(query, num_results=5) return "\n\n".join([r["content"] for r in results]) @tool def sql_query(question: str) -> str: """查询业务数据库""" sql = text2sql(question) return db.execute(sql) # Agent决策循环 tools = [vector_search, web_search, sql_query] llm = ChatOpenAI(model="gpt-4o", temperature=0) llm_with_tools = llm.bind_tools(tools) def agent_decision(state): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def should_continue(state): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END # 构建Graph graph = StateGraph(dict) graph.add_node("agent", agent_decision) graph.add_node("tools", ToolNode(tools)) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") # 工具执行后回到agent做下一轮决策 app = graph.compile() # 执行 result = app.invoke({ "messages": [HumanMessage(content="对比2026年Q1三大云厂商的AI服务收入")] }) 性能基准对比 我们在三个数据集上对比了不同RAG架构的表现： ...

为什么需要多模态RAG？ 传统RAG只能处理文字，但现实世界的信息是多维的。技术文档里穿插架构图、产品手册里有演示截图、研究报告里有数据图表——这些信息，纯文本RAG完全丢失了。 用户问"系统的整体架构是什么样的？"，纯文本RAG只会返回一段文字描述，而无法返回架构图。这就是多模态RAG要解决的问题。 多模态RAG架构全景 ┌─────────────────────────────────────────────────────────┐ │ 多模态RAG系统架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 用户查询 │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Query 分析 │ 判断用户需要图片、文字、还是图文 │ │ └──────┬──────┘ │ │ │ │ │ ┌────┴────┐ │ │ ▼ ▼ │ │ [纯文本查询] [需要图片查询] │ │ │ │ │ │ ▼ ▼ │ │ 文本检索 多模态检索 │ │ (向量库) (CLIP/图片向量) │ │ │ │ │ │ └────┬────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ 结果融合 │ 图文结果融合排序 │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ 多模态LLM生成回答（可理解和描述图片） │ │ │ └─────────────────────────────────────────────────────────┘ 四种架构方案详解 方案1：独立双路检索（Easiest） 文本向量库 图片向量库 │ │ └──► 合并 ◄──┘ │ ▼ 多模态LLM生成 最简单也是最常见的方案：文本和图片分别Embedding，分别检索，然后合并结果交给多模态LLM生成回答。 ...

Agent编排：从简单到复杂的演进之路 2026年，Agent编排模式已经从早期的"提示词+循环"发展为成熟的架构模式体系。本文将系统梳理从最简单到最复杂的编排模式，帮助你在实际项目中做出正确的架构选择。 模式全景 复杂度 ──────────────────────────────────────────→ 串行 ─→ 并行 ─→ 路由 ─→ 循环 ─→ 递归 ─→ 图式 ─→ 自治 │ │ │ │ │ │ │ │ │ │ │ │ │ └─ Agent自主决策 │ │ │ │ │ └─ DAG + 条件边 + 子图 │ │ │ │ └─ 分治递归 │ │ │ └─ ReAct循环 / 反思循环 │ │ └─ if-else路由 / 内容分发 │ └─ 扇出-扇入 / Map-Reduce └─ Pipeline直线流程 模式1：串行编排（Pipeline） 最基础的编排模式，Agent按固定顺序执行。 ...

Agent记忆系统：让智能体拥有"记住"的能力 人类的记忆系统是一个精妙的分层结构：工作记忆处理当前任务，长期记忆存储知识和经验，情景记忆记录具体事件。2026年的Agent系统也在向这个方向演进——一个没有记忆的Agent就像一个每天失忆的员工，每次对话都从零开始，无法积累经验、无法理解上下文。 记忆系统三层架构 ┌───────────────────────────────────────────────┐ │ 记忆系统架构 │ ├───────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 1: 短期记忆 (Working Memory) │ │ │ │ - 当前对话上下文 │ │ │ │ - 当前任务状态 │ │ │ │ - 最近的工具调用结果 │ │ │ │ 容量: ~32K tokens | TTL: 会话结束 │ │ │ └─────────────────────────────────────────┘ │ │ ↓ 溢出压缩 │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 2: 情景记忆 (Episodic Memory) │ │ │ │ - 具体事件记录（时间、地点、人物） │ │ │ │ - 对话历史摘要 │ │ │ │ - 任务执行日志 │ │ │ │ 容量: 无限 | TTL: 90天衰减 │ │ │ └─────────────────────────────────────────┘ │ │ ↓ 知识提取 │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 3: 长期记忆 (Long-term Memory) │ │ │ │ - 用户偏好和习惯 │ │ │ │ - 学到的知识和规则 │ │ │ │ - 经验教训 │ │ │ │ - 语义关联 │ │ │ │ 容量: 无限 | TTL: 永久 │ │ │ └─────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────┘ Layer 1: 短期记忆（Working Memory） 短期记忆是Agent在当前会话中保持的上下文信息，主要通过LLM的上下文窗口实现。 ...

Agent可观测性：你无法优化你看不见的东西 传统软件的可观测性已经相当成熟——我们有Prometheus做指标、ELK做日志、Jaeger做追踪。但Agent系统引入了新的可观测性挑战：非确定性的执行路径、不可预测的token消耗、LLM输出的质量评估、多Agent协作的链路追踪。2026年，Agent可观测性已经形成了一套独立的最佳实践。 Agent可观测性的三大支柱 ┌───────────────────────────────────────────────────┐ │ Agent 可观测性三大支柱 │ ├─────────────┬─────────────┬───────────────────────┤ │ │ │ │ │ 追踪 │ 日志 │ 指标 │ │ (Traces) │ (Logs) │ (Metrics) │ │ │ │ │ │ Agent执行 │ 结构化事件 │ 性能计数器 │ │ 链路追踪 │ 决策记录 │ 资源消耗 │ │ 跨Agent关联 │ 上下文快照 │ 质量评估 │ │ │ │ │ └─────────────┴─────────────┴───────────────────────┘ 1. 分布式追踪 Agent Trace模型 Agent系统的追踪比传统微服务更复杂，因为一个"请求"可能涉及多轮LLM调用、多次工具调用、跨多个Agent。 from dataclasses import dataclass, field from datetime import datetime from typing import Any, Optional import uuid @dataclass class AgentSpan: """Agent追踪的基本单元""" span_id: str = field(default_factory=lambda: str(uuid.uuid4())) parent_id: Optional[str] = None trace_id: str = "" # 基本信息 name: str = "" # span名称 span_type: str = "" # llm_call / tool_call / agent_step / sub_agent agent_name: str = "" # 哪个Agent start_time: datetime = field(default_factory=datetime.now) end_time: Optional[datetime] = None # Agent特有信息 input_data: Any = None output_data: Any = None model: str = "" # 使用的LLM模型 prompt_tokens: int = 0 completion_tokens: int = 0 cost: float = 0.0 # 状态 status: str = "ok" # ok / error / timeout error_message: Optional[str] = None # 元数据 attributes: dict = field(default_factory=dict) def finish(self, output=None, status="ok", error=None): self.end_time = datetime.now() self.output_data = output self.status = status self.error_message = error @property def duration_ms(self) -> float: if self.end_time: return (self.end_time - self.start_time).total_seconds() * 1000 return 0 追踪实现 class AgentTracer: """Agent追踪器""" def __init__(self, service_name="agent-service"): self.service_name = service_name self.spans: list[AgentSpan] = [] self.current_span_stack: list[AgentSpan] = [] def start_trace(self, name: str, agent_name: str) -> AgentSpan: """开始一个新的追踪（根span）""" trace_id = str(uuid.uuid4()) span = AgentSpan( trace_id=trace_id, name=name, span_type="agent_step", agent_name=agent_name ) self.spans.append(span) self.current_span_stack.append(span) return span def start_span( self, name: str, span_type: str, agent_name: str = "", input_data: Any = None ) -> AgentSpan: """开始一个子span""" parent = self.current_span_stack[-1] if self.current_span_stack else None span = AgentSpan( trace_id=parent.trace_id if parent else str(uuid.uuid4()), parent_id=parent.span_id if parent else None, name=name, span_type=span_type, agent_name=agent_name, input_data=input_data ) self.spans.append(span) self.current_span_stack.append(span) return span def end_span(self, span: AgentSpan, output=None, status="ok", error=None): """结束一个span""" span.finish(output, status, error) if self.current_span_stack and self.current_span_stack[-1].span_id == span.span_id: self.current_span_stack.pop() def get_trace_tree(self, trace_id: str) -> dict: """获取追踪树""" trace_spans = [s for s in self.spans if s.trace_id == trace_id] return self._build_tree(trace_spans, parent_id=None) def _build_tree(self, spans: list[AgentSpan], parent_id: str | None) -> dict: children = [s for s in spans if s.parent_id == parent_id] return [ { "span_id": s.span_id, "name": s.name, "type": s.span_type, "agent": s.agent_name, "duration_ms": s.duration_ms, "tokens": s.prompt_tokens + s.completion_tokens, "cost": s.cost, "status": s.status, "children": self._build_tree(spans, s.span_id) } for s in children ] 使用示例 tracer = AgentTracer() # 开始追踪 root = tracer.start_trace("用户咨询", "router_agent") # Agent执行LLM调用 llm_span = tracer.start_span("LLM调用", "llm_call", "router_agent", input_data="用户问题") response = await llm.complete("...") tracer.end_span(llm_span, output=response.text, status="ok") llm_span.prompt_tokens = response.usage.prompt_tokens llm_span.completion_tokens = response.usage.completion_tokens llm_span.cost = calculate_cost(response.usage, "gpt-4o") # Agent调用工具 tool_span = tracer.start_span("搜索知识库", "tool_call", "router_agent") results = await knowledge_base.search("query") tracer.end_span(tool_span, output=results) # 路由到子Agent sub_agent_span = tracer.start_span("专家Agent处理", "sub_agent", "expert_agent") # ... 子Agent内部会有自己的span ... tracer.end_span(sub_agent_span, output="最终回答") # 结束追踪 tracer.end_span(root, output="最终回答") # 查看追踪树 trace_tree = tracer.get_trace_tree(root.trace_id) 追踪可视化 追踪树可以渲染为瀑布图： ...

多Agent系统：从单体到协同的架构挑战 2026年，随着Agent能力的提升，单个Agent已经难以处理复杂的企业任务。多Agent系统（Multi-Agent System, MAS）成为解决复杂问题的主流架构。但多Agent也带来了新的架构挑战：Agent之间如何通信？如何协调行动？当多个Agent得出矛盾结论时如何解决？ 核心挑战 ┌─────────────────────────────────────────────────┐ │ 多Agent系统的三大核心挑战 │ ├─────────────────────────────────────────────────┤ │ │ │ 1. 通信 (Communication) │ │ Agent A 如何告诉 Agent B 它需要什么？ │ │ - 消息格式 │ │ - 通信协议 │ │ - 异步 vs 同步 │ │ │ │ 2. 协调 (Coordination) │ │ 多个Agent如何协同完成一个任务？ │ │ - 任务分配 │ │ - 资源竞争 │ │ - 死锁避免 │ │ │ │ 3. 冲突解决 (Conflict Resolution) │ │ 当Agent意见不一致时怎么办？ │ │ - 投票机制 │ │ - 仲裁机制 │ │ - 置信度加权 │ │ │ └─────────────────────────────────────────────────┘ 1. 通信协议设计 消息格式标准化 在多Agent系统中，统一的消息格式是互操作的基础： ...

引言 混合专家（Mixture of Experts, MoE）架构通过将模型参数划分为多个"专家"子网络，每次推理只激活其中一部分，实现了参数规模与计算量的解耦。这一设计使得MoE模型在保持稠密模型性能的同时，大幅降低了推理成本。2026年，MoE已成为主流大模型（Mixtral、DeepSeek-V3、Qwen3-MoE）的核心架构。本文将深入解析MoE的路由机制与负载均衡策略。 MoE基础架构 标准MoE Layer MoE层由 $N$ 个专家网络和1个门控网络（Router/Gating Network）组成： class MoELayer(nn.Module): def __init__(self, d_model, n_experts, n_active, expert_dim): super().__init__() self.n_experts = n_experts self.n_active = n_active # Top-K激活专家数 self.gate = nn.Linear(d_model, n_experts, bias=False) self.experts = nn.ModuleList([ ExpertBlock(d_model, expert_dim) for _ in range(n_experts) ]) def forward(self, x): """ x: [batch_size, seq_len, d_model] """ B, T, D = x.shape # 门控分数 gate_logits = self.gate(x) # [B, T, n_experts] gate_probs = F.softmax(gate_logits, dim=-1) # Top-K选择 topk_probs, topk_indices = gate_probs.topk(self.n_active, dim=-1) # 重新归一化 topk_probs = topk_probs / topk_probs.sum(dim=-1, keepdim=True) # 专家计算（分散式） output = torch.zeros_like(x) for i in range(self.n_active): expert_idx = topk_indices[..., i] # [B, T] expert_weight = topk_probs[..., i].unsqueeze(-1) # [B, T, 1] # 对每个专家ID，批量计算 for eid in range(self.n_experts): mask = (expert_idx == eid) if mask.any(): expert_input = x[mask] expert_output = self.experts[eid](expert_input) output[mask] += expert_weight[mask] * expert_output return output 主流MoE模型对比 模型 总参数 激活参数 专家数 Top-K 特点 Mixtral 8x7B 47B 13B 8 2 首批开源MoE DeepSeek-V2 236B 21B 160 6 细粒度专家 DeepSeek-V3 671B 37B 256 8 共享专家+细粒度 Qwen3-235B 235B 35B 128 8 GQA+MoE Mixtral 8x22B 141B 39B 8 2 大规模MoE 路由机制详解 Top-K路由 标准Top-K路由： ...

MoE（Mixture of Experts）已成为2026年大模型架构的事实标准。从DeepSeek-V3到GPT-5，MoE让模型在保持推理效率的同时实现万亿级参数规模。本文将深入MoE的技术内核。 1. MoE架构基础 1.1 从稠密到稀疏 标准Transformer的FFN层对所有输入执行相同计算。MoE将FFN替换为多个"专家"网络，每个token仅激活少数专家： $$\text{FFN}{MoE}(x) = \sum{i \in \mathcal{I}(x)} g_i(x) \cdot E_i(x)$$ 其中 $\mathcal{I}(x)$ 为路由到token $x$ 的专家索引集合，$g_i(x)$ 为门控权重，$E_i$ 为第 $i$ 个专家。 1.2 参数与计算量的解耦 MoE的关键优势：参数总量与计算量解耦。 模型 总参数 激活参数 FLOPs/token 等效稠密模型 Mixtral 8x7B 47B 13B ~13B ~13B DeepSeek-V3 671B 37B ~37B ~37B GPT-5 (估) 3T 300B ~300B ~300B MoE用3T参数获得了300B稠密模型的效果，但推理仅需300B的计算量。 2. 路由机制详解 2.1 Top-K路由 最基础也最常用的路由策略： class TopKRouter(nn.Module): def __init__(self, d_model, num_experts, top_k=2): super().__init__() self.gate = nn.Linear(d_model, num_experts, bias=False) self.top_k = top_k self.num_experts = num_experts def forward(self, x): # x: [batch * seq_len, d_model] logits = self.gate(x) # [batch * seq_len, num_experts] # Top-K选择 topk_logits, topk_indices = torch.topk(logits, self.top_k, dim=-1) # Softmax归一化（仅对选中的专家） weights = F.softmax(topk_logits, dim=-1) return weights, topk_indices 2.2 Expert Choice路由 反转路由方向：不是token选专家，而是专家选token。 ...

2026年是AI Agent元年。如果说2023-2024年大家在探索"Agent能做什么"，2025年大家在尝试"怎么构建Agent"，那么2026年的核心问题已经变成"用哪个框架构建Agent"。LangChain（含LangGraph）、Microsoft AutoGen、CrewAI三足鼎立，各有千秋。本文将通过架构分析、功能对比和真实项目测试，给出最全面的选型指南。 一、三大框架概览 LangChain + LangGraph 1.0 LangChain在2025年底完成了架构重组，将核心库精简为langchain-core，同时LangGraph从实验项目升级为正式的Agent编排框架。 定位：全功能AI应用开发框架 核心组件： LangChain：链式调用、工具集成、文档处理 LangGraph：基于状态图的Agent编排，支持循环、分支、并行 LangSmith：调试、监控、评估平台 LangServe：API部署 2026年关键更新： LangGraph 1.0正式发布，引入"持久化状态"和"人在环路"原生支持 预构建Agent模板：ReAct、Plan-and-Execute、Reflexion等 原生支持Claude 5的Computer Use能力 Microsoft AutoGen 0.4 AutoGen在2026年发布了0.4版本（经过重大重写），从"对话式多Agent"进化为"事件驱动的异步Agent框架"。 定位：多Agent对话与协作框架 核心组件： Agent Runtime：异步消息传递的Agent运行时 GroupChat：多Agent群聊协作 Code Executor：安全的代码执行沙箱 AgentChat：高级API，简化多Agent对话 2026年关键更新： 完全异步架构，支持高并发 跨语言支持：Python + .NET 与Microsoft Azure AI深度集成 新增"Agent Workflow"可视化编排界面 CrewAI 0.5 CrewAI在2026年获得了$2000万A轮融资，成为增长最快的Agent框架。它专注于"角色扮演式多Agent协作"——定义不同的Agent角色，分配任务，让他们像团队一样工作。 定位：简洁直观的多Agent协作框架 核心组件： Crew：Agent团队定义 Agent：角色定义（角色、目标、背景故事） Task：任务定义（描述、期望输出、分配的Agent） Process：任务执行模式（顺序/层级/共识） Tools：工具集成 2026年关键更新： 新增"共识决策"模式——Agent通过投票/讨论达成共识 支持Agent记忆持久化 内置多种行业模板（研究、营销、开发等） CrewAI Cloud：托管部署平台 二、架构设计对比 核心架构差异 LangGraph：状态机模型 LangGraph将Agent工作流建模为状态图（StateGraph）： 每个节点是一个处理步骤（LLM调用、工具调用、条件判断） 边定义了状态转移规则 支持循环（用于ReAct等迭代推理模式） 状态在节点间传递，可持久化 优势：精确控制流程，支持复杂工作流，可调试性强 劣势：学习曲线陡，简单任务显得过度工程化 ...