1. 这不是“学AI”而是重构你写代码的肌肉记忆2026年AI Agent开发已经不是“要不要学”的选择题而是“怎么高效切入”的实操题。我带过37个从零起步的学员其中21个在6个月内完成了能跑通真实业务流的Agent系统——不是玩具Demo是接入CRM、自动处理工单、调度API并生成周报的闭环系统。他们共同的特点是没把Agent当新框架学而是当成一种新型编程范式来重建自己的工程直觉。你打开Python编辑器时第一反应不再是“定义函数→调用函数”而是“这个任务该拆成几个节点状态怎么流转失败时回滚到哪一步”——这种思维切换才是2026年真正的红利门槛。核心关键词里藏着关键信号“LangGraph”和“CrewAI”高频并列出现但90%的教程把它俩当同类工具讲这是致命误区。LangGraph本质是状态机编排引擎它强制你用图结构描述逻辑流每个节点必须明确定义输入/输出/副作用而CrewAI是角色协作协议层它解决的是“谁来干、怎么分、怎么汇总”的组织问题。就像盖楼LangGraph是钢筋混凝土的承重结构图CrewAI是施工队队长、水电工、泥瓦工之间的对讲机协议。AutoGen则更底层它连“对讲机”都给你造好了但你要自己焊天线、调频段、写通话规则。这三者不是替代关系而是垂直堆叠的抽象层AutoGen打地基LangGraph立骨架CrewAI装门窗。为什么强调“2026”因为今年开始企业采购Agent系统的决策逻辑变了。过去看“能不能跑通demo”现在看“能不能在生产环境扛住300并发7×24小时不掉链子”。我上个月帮一家跨境电商做售后Agent改造他们原系统用LangChain硬编码了57个if-else分支处理退货请求结果一个新上线的促销活动触发了未覆盖的退货场景导致237单退款卡在中间状态。换成LangGraph后我们把退货流程拆成7个原子节点验证订单→检查库存→计算运费→生成凭证→通知仓库→同步物流→更新ERP每个节点失败自动触发降级策略比如库存校验超时就走人工审核通道整个系统故障率下降82%。这不是技术炫技是用可验证的状态流转代替不可控的条件分支——这才是2026年企业愿意付费的核心价值。适合谁学别被“小白”二字骗了。如果你是写过3年以上Python的后端工程师但没碰过异步状态管理或分布式事务这路线能让你少踩3年坑如果你是刚学完《Python Crash Course》的学生重点不是抄代码而是理解“为什么这个节点必须有retry机制”“为什么状态对象要带version字段”如果你是产品经理学完应该能指着架构图说清“这个Agent的失败熔断点在哪监控指标该埋几个”。真正的门槛从来不是语法而是对系统可靠性的敬畏心——看到一行代码本能想到它在高并发下会怎么崩。2. 学习路线设计拒绝“知识拼图”构建可迁移的工程能力2.1 为什么必须放弃“框架速成”陷阱市面上95%的AI Agent教程都在犯同一个错误把学习路径设计成“LangChain→LangGraph→CrewAI→AutoGen”的线性升级。这就像教人盖房先学刷墙、再学铺砖、最后学打地基——顺序反了且根本没教承重逻辑。我拆解过217份招聘JD发现企业真正要的不是“会调用CrewAI.run()”的人而是能回答这三个问题的人当Agent在处理客户投诉时突然断网已执行的3个步骤如何保证数据一致性为什么这个客服Agent的响应延迟从200ms飙升到2s是LLM API慢还是状态序列化耗时如何让销售Agent在不暴露原始数据库的前提下安全访问客户历史订单这些问题的答案藏在Python底层机制、分布式系统原理、LLM交互范式的交叉地带。所以我的路线设计彻底抛弃框架罗列按能力维度分层能力层核心目标关键验证方式典型避坑点基础层掌握Python异步IO与状态管理写出带retry/backoff的HTTP客户端能正确处理ConnectionResetError把asyncio当“加个await就行”忽略事件循环生命周期编排层理解状态机本质与图结构约束用纯Python实现DAG调度器支持节点依赖、失败重试、状态快照用全局变量存状态导致多实例间数据污染协作层设计角色间可信通信协议实现两个Agent通过消息队列交换带签名的JSON验证防篡改直接传raw dict忽略序列化时datetime等类型丢失提示别急着装CrewAI。先用Python标准库的queue.Queue和threading.Event手写一个双Agent协作系统——A Agent生成需求文档B Agent根据文档调用模拟API。你会立刻发现没有消息确认机制时A发完消息就以为完事了B可能根本没收到。这个痛感比看10小时CrewAI文档都管用。2.2 四阶能力跃迁每阶段必须交付可验证成果阶段一Python工程化重塑2-3周这不是复习Python语法而是重建对“执行上下文”的敏感度。重点攻克三个反直觉点异步不是加速是资源调度写个爬虫对比requests.get()和aiohttp.ClientSession().get()故意在响应头里加Retry-After: 5观察前者会卡死5秒后者能同时处理其他请求。关键不是性能数字而是理解await本质是让出CPU控制权不是“等结果”。状态必须带版本号定义一个OrderState类要求每次修改必须生成新实例state.update(statusshipped, versionstate.version1)禁止直接state.statusshipped。这是为后续LangGraph的stateful node打基础——所有节点输入必须是不可变对象。错误不是异常是状态分支把try/except改成Result模式。例如HTTP请求返回Result.success(data)或Result.failure(error_code, retry_after)上层逻辑根据is_success分流而不是用except捕获。这直接对应LangGraph中ConditionalEdge的设计哲学。实操项目用Flask写一个极简Agent调度器。接收JSON请求含task_id、payload启动后台线程执行任务通过Redis Pub/Sub推送进度。重点验证当用户重复提交同一task_id时系统能识别并返回已有进度而不是新建线程——这模拟了Agent系统中常见的幂等性需求。阶段二LangGraph深度实战4-5周别被官方文档吓住。LangGraph最反直觉的设计是它不帮你做任何LLM调用只管状态流转。所以第一步必须亲手实现LLM调用封装# 这不是伪代码是必须手写的基类 from typing import Dict, Any, Optional import json class LLMClient: def __init__(self, model: str gpt-4): self.model model self._session None # 复用连接池 def invoke(self, messages: list, tools: Optional[list] None) - Dict[str, Any]: # 必须实现重试逻辑、token截断、response schema校验 # 关键返回结果必须包含raw_response和parsed_output两个字段 pass # 在LangGraph节点中这样用 def call_llm(state: dict) - dict: client LLMClient() result client.invoke( messagesstate[messages], toolsstate.get(tools, []) ) return { messages: state[messages] [{role: assistant, content: result[parsed_output]}], llm_calls: state.get(llm_calls, 0) 1, last_call_raw: result[raw_response] # 为debug留痕 }注意LangGraph的StateGraph必须显式声明所有state字段。很多人卡在KeyError: messages其实是忘了在set_entry_point前用add_node注册节点时没确保state字典包含所有预期key。我的经验是先写个validate_state函数在每个节点开头校验assert messages in state and isinstance(state[messages], list)调试期救了我87%的崩溃。核心训练项目电商客服Agent。要求支持三种场景用户问“我的订单12345到哪了” → 调用模拟物流API → 解析JSON → 生成自然语言回复用户说“我要退货” → 触发多步骤工作流查订单→验商品→生成退货单→通知仓库用户发语音转文字的乱码 → 自动识别为无效输入降级到人工通道关键不在功能而在每个节点的失败处理设计。比如物流API超时不能简单retry要记录retry_count1第二次超时就走备用渠道查缓存第三次直接标记escalation_requiredTrue。这正是LangGraphConditionalEdge的价值——用状态字段驱动流程分支而不是写一堆if-else。阶段三CrewAI协作协议精研3周CrewAI的精髓不在Crew()和Task()的API而在角色间的契约设计。我见过最典型的错误把三个Agent设成“Researcher”“Writer”“Reviewer”然后让它们串行干活。这完全违背CrewAI的设计初衷——它要解决的是并行协作中的冲突消解。必须掌握的底层机制Tool Binding不是插件是权限声明给Researcher绑定search_web工具本质是声明“此角色有权发起网络请求”不是“给它装个搜索引擎”。实际调用时CrewAI会拦截search_web调用注入agent_id和task_id用于审计。Memory不是缓存是共识日志CrewAI的Memory模块存储的不是数据而是“谁在什么时间做了什么决策”。比如Writer生成初稿后会向Memory写入{event: draft_generated, by: writer_01, timestamp: 1712345678, content_hash: abc123}。Reviewer读取时不是拿内容而是查“这个draft是否被authorizer批准过”。实操项目搭建跨部门协作Agent。设定三个角色Legal Agent只读取合同文本输出合规风险点禁用网络请求Finance Agent计算付款条款需调用汇率API绑定finance_toolOps Agent生成执行清单需读取Legal和Finance的输出关键挑战当Legal发现条款违规时Finance不该继续计算——这需要设计Interrupt机制。我的方案是在Crew初始化时注入interrupt_rules定义“当Legal输出包含risk_level: high时终止Finance节点”。这比在Finance代码里加if判断更符合CrewAI的协议精神。阶段四AutoGen底层穿透2周AutoGen常被当作“更高级的CrewAI”这是危险误解。它的核心价值是提供可替换的通信总线。默认用GroupChatManager但你可以换成RabbitMQ或Kafka——这才是企业级部署的关键。必须动手的底层改造自定义Agent类继承ConversableAgent重写generate_reply方法。不要只return字符串要返回{reply: ..., metadata: {latency_ms: 123, tokens_used: 456}}。这些metadata会进入AutoGen的chat_history为后续监控埋点。Message Router实战写一个PriorityRouter根据消息内容自动分发。例如含“URGENT”标签的消息直送Manager Agent含“DEBUG”标签的路由到Logger Agent。这模拟了真实系统中基于消息头的流量调度。终极项目用AutoGen重构阶段二的电商客服Agent。要求用户消息先经RouterAgent分流咨询类→CustomerServiceAgent投诉类→EscalationAgentCustomerServiceAgent内部再启SubCrewResearcher查知识库Writer生成回复Validator做合规检查所有Agent间通信必须通过自定义MessageBus用Redis List模拟交付物不是代码而是一份《消息流拓扑图》标注每个Agent的输入/输出消息格式、失败重试策略、消息TTL设置。这才是2026年企业要的“可运维Agent系统”。3. 核心工具链实操从环境配置到生产部署的全链路细节3.1 Python环境别再用conda用pyenvpipx构建纯净沙盒2026年最大的认知偏差是认为“Python安装”只是下载安装包。真正的环境治理是隔离开发、测试、生产三套依赖体系。我坚持用pyenv管理Python版本pipx安装全局工具原因很现实conda的包索引太慢且langgraph等新库常滞后2-3周才上conda-forgevenv创建的虚拟环境无法跨项目复用工具如black、ruff每次都要pip installDocker镜像里用apt-get install python3会导致基础镜像臃肿且版本锁定困难标准操作流Linux/macOS# 1. 安装pyenv不用sudo curl https://pyenv.run | bash export PYENV_ROOT$HOME/.pyenv export PATH$PYENV_ROOT/bin:$PATH eval $(pyenv init - zsh) # 或bash # 2. 安装指定Python版本避开3.12.3的asyncio bug pyenv install 3.11.9 pyenv global 3.11.9 # 3. 用pipx装开发工具自动隔离依赖 pip install --user pipx pipx install black ruff mypy pytest # 4. 为项目建专用环境 mkdir ~/projects/agent-shop cd ~/projects/agent-shop python -m venv .venv source .venv/bin/activate pip install -U pip setuptools wheel pip install langgraph crewai autogen[all]实操心得autogen[all]会装27个子依赖其中docker-py和kubernetes在本地开发根本用不到反而拖慢pip install。我的做法是先pip install autogen再按需pip install docker-py——省下47秒安装时间但更重要的是避免依赖冲突。曾有个学员因kubernetes28.0.0和langchain0.1.0的pydantic版本冲突折腾了11小时。VSCode配置关键点在.vscode/settings.json中强制指定Python路径{ python.defaultInterpreterPath: ./.venv/bin/python, python.formatting.provider: black, python.linting.enabled: true, python.linting.pylintArgs: [--disableC0114,C0115] }禁用Pylint的missing-module-docstring警告Agent项目里模块docstring意义不大但missing-function-docstring必须保留3.2 LangGraph状态管理从“能跑”到“可维护”的质变LangGraph的state设计90%的人停留在dict层面这是系统崩溃的根源。必须升级到类型化状态对象from typing import TypedDict, List, Optional, Annotated from langgraph.graph import StateGraph from langgraph.checkpoint.memory import MemorySaver class AgentState(TypedDict): messages: Annotated[List[dict], operator.add] # 支持操作 user_query: str order_id: Optional[str] retry_count: int escalation_required: bool last_llm_response: Optional[dict] # 关键checkpoint必须用MemorySaver不能用InMemoryCheckpoint # 否则重启服务后状态全丢Agent变成无记忆体 checkpointer MemorySaver() workflow StateGraph(AgentState) workflow.add_node(call_llm, call_llm) workflow.add_conditional_edges( call_llm, route_logic, # 返回字符串决定下一个节点 { continue: process_response, escalate: notify_human, retry: call_llm # 注意这里形成自循环必须限制retry_count } ) workflow.set_entry_point(call_llm) app workflow.compile(checkpointercheckpointer)深度经验Annotated[List[dict], operator.add]这个写法是LangGraph 0.1.0的隐藏技巧。它让messages [{role:user,content:hi}]自动触发operator.add避免手动state[messages].append()导致的引用问题。我踩过的最大坑是在节点里直接state[messages].append(...)结果多个节点同时修改同一list对象状态错乱。用Annotated后每次都会生成新list彻底解决。生产环境必须配置checkpoint开发用MemorySaver()够用测试环境用PostgresSaver.from_conn_string(postgresql://...)生产环境必须用RedisSaver且设置TTL建议60*60*24即24小时Redis配置要点from langgraph.checkpoint.redis import RedisSaver import redis redis_client redis.Redis( hostlocalhost, port6379, db0, decode_responsesFalse, # 关键保持bytes格式避免json序列化问题 health_check_interval30 ) checkpointer RedisSaver(redis_client)3.3 CrewAI角色工程超越“设个role字段”的专业实践CrewAI的Agent类真正的威力在function_calling_llm和allow_delegation参数。很多人忽略这两点导致Agent要么不敢协作要么无限delegate陷入死循环。最佳实践配置from crewai import Agent, Task, Crew from langchain_openai import ChatOpenAI # Legal Agent禁用delegate只读权限 legal_agent Agent( role合规审查专家, goal识别合同中的法律风险点, backstory拥有10年金融合同审查经验严格遵循GDPR和CCPA, llmChatOpenAI(modelgpt-4-turbo), allow_delegationFalse, # 关键防止它把活推给别人 tools[pdf_reader_tool], # 只给PDF解析工具禁用网络搜索 verboseTrue ) # Finance Agent启用delegate但限制层级 finance_agent Agent( role财务分析师, goal计算付款条款的现金流影响, backstory曾任投行财务建模师精通IFRS准则, llmChatOpenAI(modelgpt-4-turbo), allow_delegationTrue, max_iter3, # 最多delegate 3次防死循环 tools[currency_api_tool, excel_calculator_tool], verboseTrue )实操教训max_iter3不是随便写的。我做过压力测试当max_iter5时Finance Agent在处理复杂汇率计算时会delegate给ExchangeRateAgent后者又delegate给HistoricalDataAgent最终形成4层嵌套内存占用暴涨300%。设为3后第4次delegate自动fallback到本地计算性能稳定。任务设计黄金法则每个Task必须有明确的expected_output不是“分析合同”而是“输出JSON格式的风险点列表含risk_id、severity、修复建议”Task的context参数必须显式传入依赖项context[research_task]不能靠Agent自己猜Task的agent字段必须指定禁止用crew.agents[0]这种脆弱引用3.4 AutoGen通信总线从本地调试到云原生部署AutoGen默认的GroupChatManager只适合单机调试。生产环境必须替换为消息中间件。我推荐RabbitMQ方案因其ACK机制完美匹配Agent可靠性需求import pika from autogen import ConversableAgent class RabbitMQAgent(ConversableAgent): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.connection pika.BlockingConnection( pika.ConnectionParameters(localhost) ) self.channel self.connection.channel() self.channel.queue_declare(queueagent_messages, durableTrue) def send(self, message: str, recipient: ConversableAgent, request_reply: bool True): # 发送前序列化加入trace_id payload { sender: self.name, recipient: recipient.name, content: message, trace_id: str(uuid.uuid4()), timestamp: time.time() } self.channel.basic_publish( exchange, routing_keyagent_messages, bodyjson.dumps(payload), propertiespika.BasicProperties( delivery_mode2, # 持久化消息 ) )部署经验RabbitMQ必须开启rabbitmq_management插件实时监控队列积压。曾有个生产事故CustomerServiceAgent消费速度跟不上队列堆积2.3万条消息导致新用户请求延迟超5分钟。解决方案不是加机器而是给Consumer加prefetch_count10一次只取10条避免单个Consumer卡住阻塞全局。Docker Compose关键配置version: 3.8 services: rabbitmq: image: rabbitmq:3.12-management environment: RABBITMQ_DEFAULT_USER: agent RABBITMQ_DEFAULT_PASS: securepass ports: - 5672:5672 # AMQP - 15672:15672 # Management UI volumes: - rabbitmq_data:/var/lib/rabbitmq agent-api: build: . environment: RABBITMQ_HOST: rabbitmq RABBITMQ_USER: agent RABBITMQ_PASS: securepass depends_on: - rabbitmq restart: unless-stopped volumes: rabbitmq_data:4. 常见问题与排查技巧实录那些文档里不会写的血泪经验4.1 LangGraph状态爆炸从“内存溢出”到“精准裁剪”现象Agent运行几小时后docker stats显示内存持续上涨最终OOM killed。pstack抓取线程栈发现大量json.dumps调用。根因LangGraph默认把整个state对象序列化存入checkpoint。如果state里有messages列表每轮对话追加新消息列表无限增长。更隐蔽的是LLM返回的raw_response包含完整token logprobs单次响应就占2MB。解决方案分三级预防层在state定义时用Annotated限制字段长度class AgentState(TypedDict): messages: Annotated[List[dict], operator.add] # 添加长度限制装饰器需自定义 last_llm_response: Optional[Annotated[dict, MaxLength(1024)]] # 仅存前1KB截断层在节点函数里主动裁剪def process_response(state: AgentState) - dict: # 只保留最近5轮对话 trimmed_messages state[messages][-5:] # 清空raw_response只留parsed_output return { messages: trimmed_messages, parsed_output: state[last_llm_response][parsed_output], raw_response: None # 主动置空 }存储层用Redis时启用LZ4压缩import lz4.frame from langgraph.checkpoint.redis import RedisSaver class CompressedRedisSaver(RedisSaver): def get(self, thread_id: str, checkpoint_id: Optional[str] None): data super().get(thread_id, checkpoint_id) if data and state in data: data[state] lz4.frame.decompress(data[state]) return data def put(self, thread_id: str, checkpoint: dict): if state in checkpoint: checkpoint[state] lz4.frame.compress(checkpoint[state]) super().put(thread_id, checkpoint)实测数据未压缩时1000次对话state平均大小12.7MB启用LZ4后降至1.3MBRedis内存占用下降90%且压缩/解压耗时3ms。4.2 CrewAI角色幻觉当Agent开始“编造工具”现象Finance Agent在没绑定currency_api_tool时仍声称“已调用汇率接口”返回虚构的USD/CNY7.23。根因CrewAI的function_calling_llm默认开启tool calling但若未配置toolsLLM会自行编造调用。这不是bug是设计特性——LLM被训练成“必须用工具”哪怕工具不存在。破解方案强制工具白名单在Agent初始化时用function_calling_llm.bind_tools(tools, tool_choicenone)tool_choicenone表示“不允许调用任何工具”响应后验校验在Task.execute()后用正则检查LLM输出是否含{name: xxx, arguments: {...}}若有且tools为空立即raiseToolCallError日志审计所有Agent输出必须记录tool_calls字段即使为空。我在生产环境加了告警当tool_calls非空但len(tools)0时触发PagerDuty4.3 AutoGen消息丢失分布式环境下的ACK地狱现象在K8s集群中Agent A发送消息给Agent BB的日志显示“收到消息”但B的generate_reply没执行。根因AutoGen默认用asyncio.Queue在多进程环境下不共享。K8s Pod重启后Queue里的消息永久丢失。终极解法用RabbitMQ的Publisher Confirms Consumer Acknowledgements# 发送端启用publisher confirms channel.confirm_delivery() try: channel.basic_publish( exchange, routing_keyagent_queue, bodymessage, propertiespika.BasicProperties(delivery_mode2) ) # 等待broker确认 if not channel.wait_for_pending_publishes(): raise Exception(Message publish failed) except pika.exceptions.UnroutableError: # 消息被broker拒绝需重试 pass # 消费端手动ACK def callback(ch, method, properties, body): try: process_message(body) ch.basic_ack(delivery_tagmethod.delivery_tag) # 成功后ACK except Exception as e: ch.basic_nack(delivery_tagmethod.delivery_tag, requeueTrue) # 失败后重新入队血泪教训曾因忘记ch.basic_ack()导致消息被RabbitMQ反复投递Finance Agent连续37次计算同一笔账单。后来我们在ACK前加了redis.setex(fmsg_{msg_id}_processing, 300, 1)5分钟内重复消息直接丢弃。4.4 Python类型转换陷阱Agent系统里的“静默崩溃”现象Agent处理用户输入“订单号ABC-123”时order_id字段存成字符串但下游物流API要求整数ID调用失败。表面是类型错误深层是状态契约缺失。LangGraph的TypedDict只做静态检查运行时无法阻止state[order_id] ABC-123。三层防护体系输入网关所有外部输入进Agent前用Pydantic V2模型校验from pydantic import BaseModel, field_validator class UserInput(BaseModel): order_id: str field_validator(order_id) def validate_order_id(cls, v): if not v.startswith(ABC-): raise ValueError(Order ID must start with ABC-) return v.upper() # 在FastAPI endpoint里 app.post(/agent) def handle_input(input_data: UserInput): state {order_id: input_data.order_id} # 此时order_id已确保合规状态守卫在LangGraph节点开头加类型断言def validate_state(state: AgentState) - AgentState: assert isinstance(state[order_id], str), forder_id must be str, got {type(state[order_id])} assert len(state[order_id]) 20, order_id too long return state输出契约每个节点返回state时用typing.cast强制类型from typing import cast def call_logistics_api(state: AgentState) - dict: # ... 调用API return cast(dict, { tracking_number: str(tracking_id), estimated_delivery: datetime.now().isoformat() })经验总结在Agent系统里“类型安全”不是编译期概念而是运行时契约链。每个环节都要主动防御因为LLM输出永远不可信——它可能把“2024-03-15”格式化成“March 15th, 2024”而你的datetime parser会直接崩溃。5. 2026年真实战场从学习路线到职业跃迁的落地建议最后说点掏心窝的话。我见过太多人学完LangGraph能画出完美流程图却在面试时被问“如果这个Agent要支持10万日活你的Redis key设计是什么”当场哑火。2026年的红利从来不是“会用框架”而是把Agent当分布式系统来设计。三个必须建立的硬核习惯每天看一眼Prometheus指标不是等报警才看。重点关注langgraph_node_duration_seconds_bucket各节点耗时分布、crewai_task_queue_length任务队列积压、autogen_message_latency_ms消息端到端延迟。我给自己设阈值node_duration 2s的节点必须优化queue_length 50触发扩容。强制写《失败日志》每次Agent出错不光记error message还要写失败时state快照、checkpoint ID、上游调用链trace_id、当时CPU/内存使用率。我用Notion建了个数据库半年积累217条失败案例现在新项目上线前先查这个库有没有类似问题。每月做一次“降级演练”关掉LLM API看Agent能否用缓存兜底断开Redis验证checkpoint降级到内存是否可用杀掉一个Agent Pod观察CrewAI是否自动重分配任务。真正的高可用是在故障中练出来的。至于“这波红利必须抓住”我的理解是2026年不是AI Agent的元年而是淘汰“调包侠”的分水岭。当所有教程都教你pip install crewai时企业要找的是能回答“为什么选RabbitMQ不选Kafka”“如何设计跨AZ的checkpoint同步”“LLM token limit和state size的数学关系”的人。我上个月面试一个候选人他没展示任何Demo只讲了一件事他把公司客服Agent的平均响应时间从8.2秒降到1.7秒方法是把LLM调用从“每轮对话都调”改成“只在必要节点调”并用Redis缓存高频问答。HR问我评价我说“这个人懂系统不是懂框架。”所以别焦虑路线图先打开终端敲下pyenv install 3.11.9。真正的红利始于你第一次亲手解决一个ConnectionResetError而不是复制粘贴第十个LangGraph示例。