上一篇我们讲了 Tool Use——让 LLM 能「调工具」。这一篇升一级让 LLM 自主完成多步任务——也就是Agent。2025-2026 业界普遍把这两年称为「Agent 元年」。原因有几个Claude 4 / GPT-5 / o3 推理能力突破→ 多步规划可靠Tool Use 标准化MCP→ 工具生态成熟Cursor / Devin / Manus 等爆款→ 验证商业价值Computer Use / Browser Use→ 突破纯文字交互但Agent 应用的工程化复杂度极高。这就是 Agent 框架存在的意义——把让 LLM 完成任务这件事工程化。下面这些问题你一定遇到过LangChain 写起来很麻烦但又很流行——到底要不要用LangGraph、AutoGen、CrewAI、Smolagents 都是什么怎么选多 Agent 协作真的比单 Agent 强吗Agent 跑着跑着就跑飞了怎么治想做一个生产级 Agent 服务从哪里开始读完本文你将能区分 5 大主流 Agent 框架的差异理解 Agent 的 4 大设计模式根据业务选对框架跑通一个端到端 Agent 应用避免 Agent 工程化的常见陷阱我们开始。一、Agent 是什么从概念到工程1.1 Agent 的精确定义Anthropic 给的定义很好用Agent LLM Tools LoopAgent 一个 LLM 一组工具 一个循环自主决定下一步做什么 目标停止条件和 Tool Use 的区别Tool Use单次调用工具用户控制流程AgentLLM 控制流程自主多步1.2 Agent 的关键特征特征含义自主性不需要每步都人工介入目标导向给一个目标自己想办法工具使用调用各种工具完成任务状态管理跨多步记住上下文错误恢复失败了能自己重试 / 换策略1.3 2026 年 Agent 应用版图应用类型Cursor / WindsurfAI Code 助手Devin全自主软件工程师Claude Code终端 AI CodingManus通用任务 AgentOpenAI Operator浏览器自动化AI 客服 Agent客户支持Multi-Agent 研究助手学术研究GitHub Copilot Workspace项目级开发这些应用全部需要 Agent 框架支撑。二、五大 Agent 框架介绍2.1 LangChain / LangGraph生态最广LangChain是 2022.10 出现的 LLM 应用框架生态最丰富。但传统 LangChain 写代码繁琐2024 推出了LangGraph作为 Agent 专用框架。LangChain 特点覆盖广RAG、Agent、向量库、LLM 接入全包集成多几百个工具 / 模型 / 向量库文档全但内容多到容易迷失抽象重很多 wrapper 层LangGraph 特点基于状态图每个节点是一个步骤边定义流转可循环天然支持 Agent loop可中断人在循环Human-in-the-loop持久化状态可存可恢复from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator classAgentState(TypedDict): messages: Annotated[list, operator.add] defcall_model(state): response llm.invoke(state[messages]) return {messages: [response]} defshould_continue(state): last state[messages][-1] if last.tool_calls: returntools return END # 构建图 workflow StateGraph(AgentState) workflow.add_node(agent, call_model) workflow.add_node(tools, tool_node) workflow.set_entry_point(agent) workflow.add_conditional_edges(agent, should_continue) workflow.add_edge(tools, agent) # 工具完了回到 agent app workflow.compile() result app.invoke({messages: [HumanMessage(...)]})适合需要复杂控制流条件分支、循环、人工介入已经用 LangChain 生态团队想要高度可控不适合简单单线程 Agent杀鸡用牛刀追求极简代码2.2 LlamaIndexRAG Agent 友好LlamaIndex 起家于 RAG第 26 篇用过后来加入了 Agent 能力。特点RAG 集成天然好Workflow 引擎事件驱动的 Agent 设计Agentic RAGAgent RAG 一体化from llama_index.core.workflow import Workflow, step, Event classResearchAgent(Workflow): step asyncdefplan(self, ctx, event: StartEvent) - SearchEvent: # 拆解任务 plan await llm.acomplete(fPlan: {event.query}) return SearchEvent(planplan) step asyncdefsearch(self, ctx, event: SearchEvent) - AnalyzeEvent: results await retriever.aretrieve(event.plan) return AnalyzeEvent(resultsresults) step asyncdefanalyze(self, ctx, event: AnalyzeEvent) - StopEvent: answer await llm.acomplete(f基于{event.results} 回答) return StopEvent(resultanswer) agent ResearchAgent() result await agent.run(query...)适合RAG 为主的应用 Agent 能力事件驱动的工作流不适合不需要 RAG 的纯 Agent 应用2.3 AutoGen / Microsoft AG2多 Agent 之王AutoGen 是微软 2023 推出的多 Agent 协作框架。2024 末分叉出社区版AG22025 微软推出AutoGen v0.4。特点多 Agent 对话多个 LLM 互相聊天解决问题角色化定义不同 Agent 的角色和工具可配置工作流从两人对话到群聊from autogen_agentchat.agents import AssistantAgent from autogen_agentchat.teams import RoundRobinGroupChat # 定义两个 Agent coder AssistantAgent( nameCoder, model_clientclient, system_message你是一个 Python 程序员, ) reviewer AssistantAgent( nameReviewer, model_clientclient, system_message你是一个 Code reviewer, ) # 创建团队 team RoundRobinGroupChat([coder, reviewer], max_turns10) result await team.run(task写一个二分查找算法并 review)适合任务可以被分解为不同角色需要 Agent 之间互相批评 / 协作科研类多步推理不适合简单单线任务对成本敏感多 Agent 调用 API 次数翻倍2.4 CrewAI声明式多 AgentCrewAI 是 2024 年的明星——比 AutoGen 更直观、声明式。特点简洁优雅YAML / 装饰器风格角色 / 任务 / 流程清晰Agent Task Crew Process新手友好上手最快from crewai import Agent, Task, Crew, Process # 定义 Agent researcher Agent( roleResearch Analyst, goal深入研究指定话题, backstory你是该领域 10 年经验的专家, tools[search_tool, browser_tool], llmllm, ) writer Agent( roleTech Writer, goal把研究结果写成清晰的文章, backstory你是技术博客作者, llmllm, ) # 定义任务 research_task Task( description研究 {topic}, agentresearcher, expected_output一份详细研究报告, ) write_task Task( description基于研究写一篇文章, agentwriter, expected_output2000 字博客文章, context[research_task], # 依赖关系 ) # 组成 Crew crew Crew( agents[researcher, writer], tasks[research_task, write_task], processProcess.sequential, ) result crew.kickoff(inputs{topic: 大模型推理优化})适合业务流程明确先 A 后 B 再 C角色分工清晰团队希望可读性高不适合高度动态的任务流需要复杂状态管理2.5 SmolagentsHuggingFace 极简HuggingFace 在 2025 推出的极简 Agent 框架主打用代码而非 JSON 调工具。特点代码即工具调用让 LLM 直接生成 Python 代码极简 1000 行核心代码HF 生态原生集成 Transformers / Hubfrom smolagents import CodeAgent, HfApiModel agent CodeAgent( tools[search_web, calculate], modelHfApiModel(Qwen/Qwen3-32B-Instruct), ) result agent.run(查一下上海和北京的常住人口告诉我哪个多)Code Agent 的特殊优势LLM 直接写 Python 代码shanghai search_web(上海常住人口) beijing search_web(北京常住人口) print(f上海 {shanghai}, 北京 {beijing}) print(f差异{shanghai - beijing})比传统 Function Calling 更灵活——能做循环、条件、计算。适合数据处理 / 分析类任务想用代码替代 JSON 工具调用HuggingFace 生态用户不适合安全敏感执行 LLM 生成代码有风险简单确定流程2.6 一表速看框架强项学习曲线适合LangGraph控制流陡复杂工作流 ⭐LlamaIndexRAG Agent中Agentic RAGAutoGen多 Agent中协作场景CrewAI易用平业务流程 ⭐Smolagents极简平数据分析三、Agent 的 4 大设计模式无论用什么框架Agent 的设计模式就那几种。3.1 ReActReasoning Acting第 27 篇讲过。最基础的模式Thought → Action → Observation → Thought → ...适合单线任务、迭代式探索。3.2 Plan-and-Execute先规划再执行Step 1规划Planner LLM → 把任务拆成子任务列表 Step 2执行Executor → 逐个执行子任务 → 中间可重新规划def plan_and_execute(task): plan planner.invoke(f拆解任务{task}) # plan [search X, analyze Y, write Z] results {} for step in plan: result executor.invoke(step, contextresults) results[step] result # 中途重规划如果发现需要 if needs_replan(result): new_plan planner.invoke(...) return final_aggregate(results)适合复杂多步任务、长程规划。3.3 Reflection自反思Agent 自我批评 改进1. Agent 生成初版结果 2. Critic同一个 LLM 不同角色批评 3. Agent 基于批评改进 4. 直到满足质量标准适合高质量输出场景写作、代码。3.4 Multi-Agent Collaboration多个 Agent 分工协作┌────────────┐ │ Manager │ ── 分配任务 └─────┬──────┘ ├──→ Researcher查资料 ├──→ Coder写代码 ├──→ Tester测试 └──→ Writer写报告经典案例MetaGPT 的软件公司模拟。适合复杂任务可分解、各 Agent 有明确角色。警告多 Agent 不一定比单 Agent 好。Anthropic 2024 一份研究发现很多场景下单 Agent 好的 prompt 比多 Agent 更稳定且便宜。3.5 设计模式选择场景推荐简单工具调用ReAct长程规划Plan-and-Execute高质量写作 / 代码Reflection角色明确的流程Multi-Agent经验从简单到复杂渐进——先 ReAct发现不够再上 Plan-and-Execute。四、Agent 选型决策4.1 按业务场景业务推荐框架Code Agent写代码 / 修 bugLangGraph / 自研客服 AgentCrewAI / LangGraph研究助手AutoGen / LangGraph数据分析师Smolagents文档 RAG AgentLlamaIndex浏览器自动化自研 Browser-use 库业务流程自动化CrewAI4.2 按团队规模团队推荐1-3 人CrewAI / Smolagents快速验证4-15 人LangGraph / LlamaIndex生产级大厂自研 借鉴 LangGraph 思想4.3 按业务阶段原型期CrewAI / Smolagents ↓ MVPCrewAI / LangGraph ↓ 生产LangGraph控制粒度细 ↓ 规模化自研 工程化4.4 「不用框架」的选项很多大厂的 Agent 应用其实不用框架——直接写循环 Tool Useasync defcustom_agent(task): messages [{role: user, content: task}] for _ inrange(max_iter): response await llm.acomplete(messagesmessages, toolstools) messages.append(response.message) ifnot response.tool_calls: return response.content # 执行工具 for tc in response.tool_calls: result await execute_tool(tc) messages.append({role: tool, content: result}) return Max iterations reached什么时候自研而非用框架业务流程极特殊性能极其敏感团队不想吃框架更新的亏已经在用了迁移代价大五、生产实战完整 Agent 系统下面用 LangGraph 实现一个真实业务案例。5.1 案例技术支持 Agent业务需求用户提工单 → Agent 自动诊断 → 给出解决方案 / 升级到人工。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated, List import operator classTicketState(TypedDict): ticket: dict diagnosis: str relevant_kb: List[str] suggested_solution: str needs_human: bool messages: Annotated[list, operator.add] # 节点 1分类 asyncdefclassify_ticket(state): response await llm.acomplete( f对工单分类{state[ticket]}\n类别[bug, how-to, billing, other] ) state[category] parse_category(response) return state # 节点 2RAG 查文档 asyncdefsearch_kb(state): docs await rag.search(state[ticket][title], top_k5) state[relevant_kb] docs return state # 节点 3诊断 asyncdefdiagnose(state): response await llm.acomplete( f基于工单{state[ticket]} 和文档{state[relevant_kb]} 诊断问题原因 ) state[diagnosis] response return state # 节点 4生成方案 asyncdefgenerate_solution(state): response await llm.acomplete( f基于诊断{state[diagnosis]} 给出解决方案 ) state[suggested_solution] response # 自我评估能否独立解决 state[needs_human] needs_human_check(response) return state # 节点 5升级人工 asyncdefescalate(state): await notify_engineer(state[ticket], state[diagnosis]) return state # 构建图 workflow StateGraph(TicketState) workflow.add_node(classify, classify_ticket) workflow.add_node(search, search_kb) workflow.add_node(diagnose, diagnose) workflow.add_node(solve, generate_solution) workflow.add_node(escalate, escalate) workflow.set_entry_point(classify) workflow.add_edge(classify, search) workflow.add_edge(search, diagnose) workflow.add_edge(diagnose, solve) workflow.add_conditional_edges( solve, lambda s: escalateif s[needs_human] else END ) workflow.add_edge(escalate, END) app workflow.compile(checkpointermemory_saver)关键设计点状态机清晰每个节点单一职责条件分支根据信心度路由到人工持久化checkpointer 保存状态可观测LangSmith 追踪每步5.2 工程化实践5.2.1 Human-in-the-loopworkflow StateGraph(...) workflow.add_node(propose_action, ...) workflow.add_node(human_review, lambda s: s) # 等人审批 workflow.add_edge(propose_action, human_review) # 编译时插入中断点 app workflow.compile( interrupt_before[human_review], checkpointermemory_saver, )允许中断 → 等人审批 → 继续。关键场景发邮件、改数据库、付钱。5.2.2 状态持久化from langgraph.checkpoint.postgres import PostgresSaver checkpointer PostgresSaver(connpsycopg_conn) app workflow.compile(checkpointercheckpointer) # 中断的会话能恢复 config {configurable: {thread_id: user-123}} result app.invoke(input, configconfig)5.2.3 可观测性import langsmith # 自动追踪每一步 langsmith.trace async def agent_run(...): ... # LangSmith UI 可看到完整 trace5.2.4 错误处理async defsafe_node(state): try: returnawait actual_logic(state) except RetryableError: # 让 Agent 重试 state[retry_count] 1 if state[retry_count] 3: state[needs_human] True return state except FatalError as e: # 立即升级 state[error] str(e) state[needs_human] True return state5.3 性能与成本优化优化 1路由小模型 → 大模型async def smart_route(state): # 用小模型判断复杂度 complexity await small_llm.classify(state[task]) if complexity simple: return await fast_model_handle(state) # 7B 模型 else: return await big_model_handle(state) # 70B混合后成本降 60-80%。优化 2缓存中间结果redis_cache(ttl3600) async def expensive_step(input): return await llm_heavy_compute(input)优化 3并行节点# LangGraph 支持节点并行 workflow.add_node(search_kb, search_kb) workflow.add_node(search_web, search_web) workflow.add_node(merge, merge_results) workflow.add_edge(START, search_kb) workflow.add_edge(START, search_web) workflow.add_edge(search_kb, merge) workflow.add_edge(search_web, merge)六、避坑6.1 坑 1循环卡死症状Agent 反复调用同一工具。对策设max_iter检测重复相同工具相同参数 3 次 → 强制终止prompt 中加不要重复同样的调用6.2 坑 2上下文爆炸症状多步后 context 越来越长 → OOM。对策中间结果摘要滑动窗口只保留最近 N 步用 KV store 存中间状态按需召回6.3 坑 3幻觉工具症状模型调用不存在的工具。对策严格 schema 校验失败时返回 tool not found, available: [...]6.4 坑 4成本失控症状单次 Agent 任务花掉 $5。对策设置 token / 调用次数预算用小模型做路由缓存常见操作6.5 坑 5不可观测症状Agent 出问题不知道哪一步坏。对策必上 LangSmith / Langfuse / Phoenix记录每步 input / output / token / 时间6.6 坑 6过度依赖多 Agent症状明明单 Agent 能解决搞 5 个 Agent 协作。对策从单 Agent 开始验证瓶颈再加 AgentAnthropic 的建议单 Agent 好 prompt 优先七、结语Agent 框架是「LLM 工程化」的当下答案读完本文你应该明白LangGraph 适合复杂控制流生产首选CrewAI 适合简洁业务流程原型快AutoGen 适合多 Agent 协作Smolagents 适合数据分析类4 大设计模式ReAct / Plan-Execute / Reflection / Multi-Agent不一定要用框架——直接写循环也是合理选择可观测 错误处理 成本控制是生产 Agent 的三大要点参考文献Agent 框架对比LangChain / LlamaIndex / AutoGen / CrewAI