AI工程化落地：LangChain、LangGraph等六大框架选型实战指南

1. 这不是“选框架”，而是给AI项目装上真实可用的骨架

你有没有遇到过这样的情况：模型调通了，prompt写得像诗一样工整，本地跑demo时效果惊艳，可一到实际业务场景里就卡壳——数据进不来、流程串不起来、多步骤任务总在第三步崩掉、团队协作时连调试日志都对不上号？我带过7个从0到1落地的AI应用项目，其中5个在第二阶段就陷入“能演示、不能上线”的泥潭。后来复盘发现，问题根本不在模型本身，而在于我们把AI当成了单点技术，却忽略了它本质上是一套需要精密协同的工程系统。LangChain、LangGraph、AutoGen、CrewAI、Agno、n8n这些名字，不是时髦标签，而是解决具体工程断点的“机械关节”。比如，LangChain解决的是“怎么把大模型和数据库、API、文档这些现实世界的数据源接上”；LangGraph解决的是“当一个AI任务要分12步走，且第7步结果决定是跳到第8步还是退回第3步重算时，怎么不写成一团意大利面条代码”；而n8n则干脆绕开代码，让运营同事自己拖拽配置“用户提交表单→自动打标→触发飞书通知→同步CRM”这种链路。它们各自覆盖AI工程中不可替代的一环：LangChain是“连接器”，LangGraph是“流程引擎”，AutoGen是“多智能体调度台”，CrewAI是“角色化协作沙盒”，Agno是“轻量级状态管理器”，n8n是“低代码自动化中枢”。这篇文章不讲抽象概念，只讲我在银行风控模型部署、电商客服知识库升级、制造业设备故障预警三个真实项目里，怎么根据具体瓶颈选框架、怎么避坑、怎么让非技术同事也能参与维护。如果你正卡在“模型很好，但用不起来”的阶段，这篇就是为你写的实操手册。

2. 框架选型不是技术炫技，而是精准匹配业务断点

2.1 LangChain：当你的AI必须“读懂”企业内部文档和数据库时

LangChain的核心价值，从来不是“让大模型调用API”，而是解决“大模型如何理解并操作企业私有数据”这个根本矛盾。我接手的第一个项目是某城商行的信贷审批辅助系统。业务方的需求很朴素：“让客户经理上传一份PDF版的抵押物评估报告，AI能自动提取关键字段（产权人、评估价、抵押率），再查核心系统里的贷款余额，最后生成一段合规提示。”听起来简单，但实际落地时，我们卡在三个地方：PDF解析后文本错乱、大模型对银行专有名词（如“LTV”“押品重估触发线”）理解偏差、每次调用都要手动拼接数据库查询语句。LangChain的Document Loaders + Text Splitters + Vector Stores组合，直接切中要害。我们用PyPDFLoader加载PDF，用RecursiveCharacterTextSplitter按段落切分（不是按字符硬切，避免把“抵押率=65%”切成两行），再用Chroma向量库建立本地索引。关键细节在于：我们没用默认的OpenAIEmbeddings，而是用银行自研的金融领域微调版BERT模型做嵌入——实测下来，对“押品”“授信”“五级分类”等术语的语义召回准确率从62%提升到89%。> 提示：LangChain的RetrievalQA链不是万能钥匙。我们在测试中发现，当用户问“该客户最近三笔贷款的抵押率是否都低于70%？”时，纯向量检索会漏掉时间维度信息。解决方案是加一层SQLDatabaseChain，让LLM先生成SQL查询，再执行——这要求你提前把数据库schema用SQLDatabase.from_uri()注册进去，并用llm_chain_kwargs={"prompt": custom_prompt}定制提示词模板，明确告诉模型“你只能生成SELECT语句，禁止UPDATE/DELETE”。

2.2 LangGraph：当AI任务变成“带条件分支的流水线”时

LangGraph的诞生，直指LangChain最大的软肋：无法优雅处理复杂状态流转。我们为某新能源车企做的电池健康度预测系统，需求是典型的“决策树”结构：输入车辆实时BMS数据 → 若SOC<20%，触发深度放电预警 → 若温度>45℃且电压波动>5%，启动热失控推演 → 否则进入常规衰减模型计算。用LangChain的SequentialChain硬写，代码会迅速膨胀成嵌套if-else地狱，且无法回溯中间状态。LangGraph用State Graph重构了整个逻辑：我们定义了一个BatteryState类，包含soc,temp,voltage_std,alert_level等字段；每个节点（check_soc,check_thermal,run_degradation）都是纯函数，只读取state并返回更新后的state；边（edges）用ConditionalEdge定义，例如lambda state: "thermal_alert" if state.temp > 45 and state.voltage_std > 5 else "degradation"。最实用的经验是：永远把“人工审核”作为一个独立节点接入图中。在热失控推演节点后，我们加了human_review节点，当模型置信度<0.85时自动暂停，把推演过程、原始数据、风险依据打包成飞书卡片推送给工程师。这样既保证了安全底线，又让系统具备了可解释性——运维同事第一次看到这个流程图时说：“原来AI不是黑箱，是张能看懂的电路图。”> 注意：LangGraph的checkpointer（检查点）不是可选项。我们在生产环境强制启用MemorySaver，每步执行后自动保存state快照。某次线上事故中，正是靠回溯第7步的state，发现是BMS数据采集模块时间戳异常导致温度误判，而非模型问题。

2.3 AutoGen：当任务需要“多个专家坐在一起开会”时

AutoGen的本质，是把“单个大模型干所有活”的范式，切换成“组建一支AI特遣队”。我们为某跨境电商做的智能选品系统，需要同时完成：市场趋势分析（需爬取Shopee/Lazada实时销量）、竞品定价策略解读（需比对10+竞品页面）、供应链库存预警（对接ERP接口）、生成本地化营销文案（适配东南亚多语言）。如果用单个Agent硬扛，响应延迟高、错误传播严重（比如爬虫出错会导致后续所有环节瘫痪）。AutoGen的GroupChatManager让我们定义了四个角色：MarketAnalyst（专注数据清洗与趋势识别）、PricingStrategist（只处理价格对比逻辑）、SupplyChainBot（专精ERP接口调用）、ContentCreator（负责文案生成）。关键设计在于消息路由规则：我们没用默认的“轮流发言”，而是设置speaker_selection_method="auto"，让Manager根据当前message.content中的关键词自动分发——当消息含“库存”“缺货”，直接路由给SupplyChainBot；含“马来语”“泰语”，路由给ContentCreator。实测下来，任务平均完成时间从单Agent的42秒降至17秒，且错误隔离性极强：某天Lazada反爬升级导致MarketAnalyst失败，其他三个Agent照常工作，系统仅降级为“无趋势分析的选品”。> 实操心得：AutoGen的ConversableAgent必须严格定义system_message。我们给PricingStrategist的system_message是：“你只做三件事：1. 接收竞品价格列表；2. 计算我方产品价格竞争力得分（公式：100-|我方价-均价|/均价*100）；3. 输出JSON格式{‘competitiveness_score’: 87.3, ‘recommendation’: ‘建议降价3%’}。禁止生成任何解释性文字。”——这避免了模型“自由发挥”导致下游解析失败。

2.4 CrewAI：当你要让AI“扮演特定角色并承担KPI”时

CrewAI和AutoGen看似相似，但内核完全不同：AutoGen关注“能力分工”，CrewAI聚焦“角色驱动”。我们为某在线教育平台做的课程质量巡检系统，核心诉求是“让AI像资深教研组长一样工作”。这里的关键不是技术能力，而是角色行为约束。我们创建了三个Crew：CurriculumInspector（检查课程知识结构完整性）、PedagogyReviewer（评估教学法合理性，如是否符合“先行组织者”原则）、EngagementAnalyzer（分析学生互动数据，识别枯燥章节）。每个Agent的goal和backstory被写得像岗位说明书：PedagogyReviewer的backstory是“15年K12教学经验，熟悉布鲁姆分类学，曾获省级教学创新奖”，其goal是“确保每节课至少包含2个高阶思维训练环节”。最妙的是Process.SEQUENTIAL模式：CrewAI强制按顺序执行，且前一个Agent的输出会作为下一个Agent的context。当CurriculumInspector指出“第3章缺少案例导入”，PedagogyReviewer会基于此上下文，专门检查“案例导入”环节的教学设计质量。这模拟了真实教研组的协作逻辑——不是各干各的，而是带着前序结论深入。> 警惕：CrewAI的verbose=True不是调试开关，而是生产环境必需项。我们上线后开启verbose，发现EngagementAnalyzer频繁调用错误的API端点。日志显示它把“学生答题正确率”指标误认为“视频完播率”，根源是prompt中expected_output描述模糊。修正为“输出JSON，键名必须为‘video_completion_rate’‘quiz_accuracy_rate’‘discussion_participation_rate’”后问题消失。

2.5 Agno：当你的AI应用需要“轻量级状态记忆”时

Agno常被误认为是LangGraph的简化版，但它解决的是更底层的问题：如何让AI记住“我们聊到哪了”，且不依赖外部数据库。我们为某医疗SaaS做的患者随访助手，要求AI能连续5轮对话追踪患者服药情况：“第1轮问是否按时吃药→第2轮若回答‘否’，追问原因→第3轮根据原因推荐解决方案→第4轮确认方案接受度→第5轮约定下次随访时间”。用LangChain的ConversationBufferMemory，状态存在内存里，服务重启就丢失；用LangGraph又过于重型。Agno的State对象完美匹配：我们定义FollowUpState包含current_step: int,medication_adherence: str,reason_for_noncompliance: str,proposed_solution: str。每个对话节点通过@agno.step装饰器更新state，且Agno自动将state序列化为JSON存入Redis（配置redis_url="redis://localhost:6379/1"）。最实用的技巧是state版本控制：我们在state里加version: str = "v2.1"字段，当业务规则变更（如新增第6轮“药物副作用询问”），只需升级version并写迁移函数，旧对话自动按新逻辑续跑。> 注意：Agno的@agno.step函数必须是纯函数（无副作用）。我们曾因在step里直接调用邮件发送API导致状态不一致，后改为step只更新state，另起一个异步worker监听state变更事件来发邮件。

2.6 n8n：当你的AI需要“无缝融入现有IT系统”时

n8n不是AI框架，而是AI的“工业接口”。我们为某物流企业做的运单异常预警系统，核心AI能力（OCR识别运单、NLP判断异常类型）已由算法团队封装为HTTP API。但业务痛点是：这个API需要接入12个不同来源（快递面单扫描、司机APP拍照、网点监控截图），且预警结果要分发到飞书、钉钉、短信、内部工单系统。如果每个渠道都写SDK，开发量巨大。n8n用可视化工作流解决了这个问题：一个Webhook节点接收所有来源图片 →HTTP Request节点调用OCR API →IF节点根据response.anomaly_type分流 →Switch节点按类型路由到不同通知节点。关键优势在于错误熔断与重试：我们给HTTP Request节点配置maxTries: 3,retryDelay: 1000，当OCR服务短暂不可用时，n8n自动重试，且失败消息进入Error Trigger节点，触发告警。更绝的是低代码扩展：运营同事用n8n内置的Code节点，几行JavaScript就能实现“若异常类型为‘地址模糊’，且寄件城市为‘深圳’，则优先派单给A组处理”。> 提示：n8n的Credentials管理是安全基石。我们为所有API密钥创建独立Credential，且在Settings → General → Instance Type中设为main，禁止前端暴露密钥。生产环境强制开启EXECUTIONS_DATA_PRUNE，自动清理30天前执行日志。

3. 实操全景：从零搭建一个跨系统AI客服知识库

3.1 项目背景与架构蓝图

这个项目来自一家拥有200+线下门店的连锁家电品牌。原有客服系统是传统FAQ库，搜索匹配率不足40%，且无法处理“帮我查下上周在杭州西湖店买的那台冰箱的保修期还剩多久”这类跨系统查询。我们的目标是：用户自然语言提问 → AI自动关联订单系统、产品库、维修记录 → 生成带数据溯源的答案 → 同步更新知识库。最终架构采用分层解耦设计：

• 接入层：n8n统一接收微信/APP/网页多渠道提问，做基础清洗（去广告语、补全缩写如“iQOO”→“iQOO手机”）；
• 认知层：LangChain + LangGraph构建知识图谱问答引擎，处理语义理解与多跳推理；
• 执行层：AutoGen协调三个专业Agent（OrderFetcher查订单、ProductSpecReader查参数、WarrantyCalculator算剩余保修）；
• 反馈层：CrewAI的KnowledgeCuratorAgent每日扫描未解决提问，自动生成知识库更新建议。
  整个系统不碰客户原始数据，所有敏感字段（手机号、身份证）在n8n入口节点即脱敏，符合GDPR要求。

3.2 核心模块实现详解

3.2.1 n8n接入层：多源提问的“交通警察”

我们创建了n8n工作流customer_query_ingest，起点是Webhook节点（URL为https://api.yourdomain.com/webhook/customer）。关键配置：

• HTTP Request节点调用公司统一身份认证API，验证X-Auth-Token有效性；
• Function节点执行脱敏逻辑：

// JavaScript代码块 const text = $input.item.json.text; const maskedText = text.replace(/1[3-9]\d{9}/g, '1XXXXXXXXXX') // 手机号 .replace(/\d{17}[\dXx]/g, 'XXXXXXXXXXXXXXXXX'); // 身份证 return { json: { ...$input.item.json, text: maskedText } };

• Switch节点按channel字段分流：微信消息走WeCom节点发到企业微信客服群，APP消息走HTTP Request调用内部IM SDK。

实操心得：n8n的Error Trigger必须连接到Telegram节点（配置公司运维Telegram Bot），我们吃过亏——某次订单系统维护，OrderFetcher持续报错，若没这个告警，客服会以为AI失灵而手动处理，导致工单积压。

3.2.2 LangChain+LangGraph认知层：让AI真正“理解”家电术语

知识库构建是成败关键。我们没用通用语料，而是基于3000份真实客服录音转录稿、127份产品说明书PDF、5年维修工单摘要，构建专属向量库。步骤：

1. 文档预处理：用UnstructuredFileLoader解析PDF，HTMLLoader抓取产品官网，CSVLoader导入维修记录；
2. 智能分块：不用RecursiveCharacterTextSplitter，改用SemanticChunker（基于sentence-transformers/all-MiniLM-L6-v2），确保“变频压缩机”“一级能效”等术语不被切碎；
3. 混合检索：MultiVectorRetriever结合关键词检索（BM25Retriever）与向量检索（Chroma），对“冰箱不制冷”类模糊查询，BM25召回产品型号，向量检索召回维修方案。
   LangGraph图谱定义：

• state：{"query": "string", "product_id": "string", "order_id": "string", "retrieved_docs": "list"}；
• retrieve_docs节点：调用MultiVectorRetriever.get_relevant_documents(query)；
• generate_answer节点：用LLMChain，prompt模板强调“答案必须标注数据来源，如【产品说明书P12】、【维修记录#20230815】”。

注意：我们禁用了LangChain的stuff文档注入方式，改用map_reduce——对长文档先分段总结，再汇总，避免上下文溢出导致关键参数丢失。

3.2.3 AutoGen执行层：三个Agent的“精准手术”

OrderFetcherAgent的system_message严格限定：
“你只调用get_order_by_id(order_id: str) -> dict函数。输入必须是纯数字ID（如'20230815123456'），禁止添加任何前缀。输出JSON必须含warranty_end_date字段，格式为YYYY-MM-DD。”
ProductSpecReader则绑定get_product_spec(product_id: str) -> dict，专注返回compressor_type,energy_efficiency等字段。
WarrantyCalculator不接触外部API，纯逻辑计算：

def calculate_remaining_warranty(warranty_end: str, current_date: str = None) -> int: from datetime import datetime, timedelta end = datetime.strptime(warranty_end, "%Y-%m-%d") now = datetime.strptime(current_date, "%Y-%m-%d") if current_date else datetime.now() return max(0, (end - now).days)

三个Agent通过GroupChatManager协作，human_input_mode="NEVER"确保全自动。

实操心得：AutoGen的function_map必须做类型校验。我们曾因get_order_by_id返回字符串"2023-08-15"而非datetime对象，导致WarrantyCalculator计算出负数天数。解决方案是在function_map中包装一层：

def safe_get_order(order_id): data = get_order_by_id(order_id) data["warranty_end_date"] = datetime.strptime(data["warranty_end_date"], "%Y-%m-%d").strftime("%Y-%m-%d") return data

3.2.4 CrewAI反馈层：让知识库“自我进化”

KnowledgeCuratorCrew包含两个Agent：

• QueryAnalyzer：Goal是“识别7天内重复出现≥3次且无满意答案的提问”，Backstory是“10年客服培训师，精通消费者心理”；
• ContentWriter：Goal是“根据QueryAnalyzer输出，撰写1条新FAQ，含标准问法、答案、适用场景说明”，Backstory是“百科全书编辑，擅长将技术语言转化为用户语言”。
  流程：QueryAnalyzer扫描n8n失败日志，输出{"repeated_queries": ["冰箱冷藏室结冰怎么办", "空调制热慢是什么原因"]}→ContentWriter生成FAQ条目，经HumanInputNode由客服主管审核 → 审核通过后，HTTP Request节点调用知识库API更新。

提示：CrewAI的verbose日志必须接入ELK。我们用Logstash收集content_writer的输出，当发现其频繁生成“请联系售后”的模板答案时，立即调整QueryAnalyzer的重复阈值，避免知识库被无效内容污染。

3.3 部署与监控：让AI系统像水电一样可靠

3.3.1 容器化部署实战

所有组件用Docker Compose编排：

• n8n服务：image: n8nio/n8n:latest，挂载/home/n8n/.n8n卷持久化凭证；
• langgraph-api服务：基于FastAPI，Dockerfile中COPY requirements.txt . && pip install --no-cache-dir -r requirements.txt，关键包锁定langgraph==0.1.42,langchain==0.1.20；
• autogen-workers服务：celery -A worker.celery worker --loglevel=info，并发数设为--concurrency=4（避免GPU显存耗尽）；
• redis与chroma：独立服务，chroma配置CHROMA_DB_IMPL=duckdb+parquet,PERSIST_DIRECTORY=/data/chroma。
  网络策略：n8n与langgraph-api同属ai-net网络，但禁止n8n直连chroma，强制通过langgraph-api中转——这是安全红线。

3.3.2 全链路监控体系

我们用Prometheus+Grafana搭建监控：

• n8n层：监控execution_success_rate（目标≥99.5%）、avg_execution_time（目标≤3s）；
• LangGraph层：埋点记录retrieval_latency（向量检索耗时）、llm_generation_time（大模型生成耗时）；
• AutoGen层：统计agent_call_count（各Agent调用频次），当OrderFetcher调用量突增300%，触发OrderSystemHealthCheck告警；
• 业务层：customer_satisfaction_score（用户点击“答案有帮助”按钮的比例），低于85%自动触发CrewAI知识库优化流程。

关键经验：监控指标必须与业务KPI对齐。我们曾发现llm_generation_time平均2.1秒，但customer_satisfaction_score只有72%。深挖日志发现，高延迟集中在“维修方案”类提问，原因是向量库中维修记录文本过长。解决方案：对维修记录摘要做truncate(length=500)预处理，满意度升至89%。

4. 血泪教训：那些框架文档里绝不会写的坑

4.1 LangChain的“向量陷阱”：相似度分数不是绝对真理

我们曾用Chroma做法律文书相似度匹配，设定阈值score > 0.8视为匹配成功。上线后发现大量误判：两份完全无关的合同，因都含“甲方”“乙方”“违约责任”等高频词，相似度高达0.85。根源在于：向量相似度衡量的是语义空间距离，不是业务相关性。解决方案是双阈值过滤：

1. 向量相似度score > 0.75（粗筛）；
2. 关键字段匹配率field_match_ratio > 0.6（精筛），例如合同必须同时匹配“签约主体”“标的金额”“管辖法院”三个字段。
   我们用spaCy的PhraseMatcher实现字段匹配，对“标的金额”字段，不仅匹配数值，还匹配单位（“万元”“USD”）和表述（“人民币壹佰万元整”）。> 提示：永远用业务数据测试相似度阈值。我们取100份真实合同，人工标注“相关/不相关”，画出ROC曲线，最终选定score=0.72为最优阈值，F1-score达0.91。

4.2 LangGraph的“状态雪崩”：别让state变成垃圾场

在电池健康度项目中，我们最初把所有传感器原始数据（每秒100条）都塞进BatteryState。结果运行3天后，Redis内存暴涨至12GB，checkpointer保存一次state耗时47秒。根因是：LangGraph的checkpointer默认序列化整个state对象。解决方案是state瘦身三原则：

• 只存必要字段：BatteryState只保留soc,temp,voltage_std,last_alert_time，原始时序数据存入InfluxDB，state中仅存influxdb_query_id；
• 用引用代替复制：retrieved_docs字段不存全文，只存[{"doc_id": "pdf_123", "page": 5}]，查询时按需加载；
• 定期归档：写cleanup_state函数，每小时删除state.timestamp < now - 1h的旧快照。

注意：LangGraph的StateGraph构造函数必须传configurable={"thread_id": "..."}，否则多用户并发时state会混乱。我们用用户手机号MD5后8位作thread_id，确保隔离性。

4.3 AutoGen的“幻觉传染”：一个Agent的错误会毒化全链路

PricingStrategistAgent曾因竞品数据源临时失效，返回空JSON。下游ContentCreator没做空值校验，直接把None塞进prompt，生成“建议降价None%”。更糟的是，GroupChatManager的max_round=10导致它反复重试，直到超时。解决方案是三层防御：

1. 输入校验：每个Agent的function_map函数开头加assert isinstance(input, dict) and "price" in input；
2. 输出契约：用Pydantic定义PricingResponse模型，强制competitiveness_score: float，recommendation: str；
3. 熔断机制：在GroupChatManager中加timeout=30，且handle_parsing_errors=True，当解析失败时返回预设兜底答案。

实操心得：AutoGen的register_function必须配合description。我们给get_order_by_id的description写明“返回订单详情字典，含warranty_end_date（str, YYYY-MM-DD格式）”，这能让LLM在生成函数调用时更准确。

4.4 CrewAI的“角色越界”：当Agent开始“多管闲事”

ContentWriterAgent曾擅自修改QueryAnalyzer的输出，把“空调制热慢”改成“空调制热效果不佳”，理由是“后者更专业”。这破坏了流程一致性。根源是system_message不够强硬。我们重写其goal为：“你只做一件事：将QueryAnalyzer提供的原始提问，按以下格式重写：【标准问法】原始提问；【答案】根据知识库生成的答案；【适用场景】一句话说明该答案适用的用户情境。禁止修改原始提问的任何字词。” 并在Crew初始化时加process=Process.SEQUENTIAL, verbose=2，确保每步输出可审计。

提示：CrewAI的Task对象必须设output_file。我们为每个Task指定output_file=f"/tmp/crew_output/{task_id}.md"，方便运维直接查看中间产物，无需登录容器。

4.5 n8n的“执行幽灵”：看不见的失败比报错更可怕

某次促销活动期间，n8n工作流promo_alert突然停止发送短信。日志显示一切正常，但SMS节点输出为空。排查3小时后发现：运营商API返回HTTP 200，但响应体是{"code": 5001, "msg": "余额不足"}。n8n默认只检查HTTP状态码，忽略业务错误码。解决方案是：

• 在HTTP Request节点后加IF节点，expression: {{$json["code"] == 0}}；
• false分支接Set节点，values: {"error": "SMS balance low"}，再接Telegram告警；
• true分支才走短信发送。

关键经验：n8n的Error Trigger必须配置onFailedNodeTypes: ["httpRequest"]，且continueOnFail: true，确保单点失败不影响全局。

5. 框架组合的黄金法则：没有银弹，只有适配

5.1 选择决策树：从业务问题出发，而非技术热度

我画了一张决策表，贴在团队站会白板上，新人入职第一周必须背熟：

这张表不是教条，而是我们踩坑后凝练的共识。比如，当客户提出“让销售助理AI自动跟进100个线索”，表面看是多Agent协作，但深挖需求发现：线索跟进步骤固定（发邮件→等回复→若未回复则电话→记录结果），无复杂条件分支。这时LangGraph的StateGraph比AutoGen更合适——代码更少，状态更可控，运维更简单。

5.2 成本意识：框架不是免费午餐

框架选型必须算三笔账：

• 开发成本：LangChain上手快，但复杂流程需大量自定义Chain；LangGraph学习曲线陡峭，但一旦建好图谱，维护成本极低。我们测算过：一个含5个条件分支的流程，LangChain需写320行代码，LangGraph仅需180行，且后者调试时间节省60%。
• 运维成本：n8n需单独维护Redis+PostgreSQL，而LangChain可嵌入现有Flask/FastAPI服务。我们为小团队项目选LangChain，为跨部门大型项目选n8n+LangGraph组合。
• 隐性成本：AutoGen的GroupChatManager默认启用llm进行消息路由，这意味着每次Agent切换都要调用大模型。我们项目中将其替换为rule_based路由，每年省下$12,000 API费用。

5.3 我的终极建议：从LangChain+LangGraph起步，渐进式演进

如果你正在启动一个新AI项目，我的建议是：

1. 第一阶段（1-2周）：用LangChain快速连接数据源，验证核心能力（如PDF解析准确率、数据库查询成功率）。此时拒绝任何复杂流程，目标是“能跑通”。
2. 第二阶段（2-3周）：当发现流程分支增多，立刻引入LangGraph，将LangChain的Chain重构为Graph节点。不要重写，用StateGraph.add_node("langchain_step", langchain_chain.invoke)封装。
3. 第三阶段（按需）：当出现明确的多角色需求（如“需要一个专门查库存的Agent，一个专门写文案的Agent”），再引入AutoGen或CrewAI。切忌一开始就堆砌框架。
   我们有个血泪教训：某项目初期强行上AutoGen，结果80%的代码在处理Agent间消息序列化，真正业务逻辑不到20%。后来砍掉AutoGen，用LangGraph+自定义函数，交付时间提前11天。

最后分享个小技巧：所有框架的配置文件，我坚持用TOML格式（而非JSON/YAML），因为TOML支持注释。在langgraph_config.toml里，我会写：

# 生产环境务必开启，避免状态丢失 checkpointer = "redis" redis_url = "redis://prod-redis:6379/2" # 开发环境用内存，避免污染生产Redis [dev] checkpointer = "memory"

这样，git diff能清晰看到环境差异，新人一眼明白配置意图。技术选型的智慧，不在于用最炫的工具，而在于让每个选择都经得起业务压力的检验。