做Agent开发这两年被问到最多的一句话是“现在主流的Agent开发框架到底选哪个”这个问题看着简单真答起来绕不开一堆细节。市面上的框架早就卷成一片红海有LangChain这种大而全的老牌生态有从LangChain拆出来专攻图编排的LangGraph有死磕数据索引的LlamaIndex有搞多智能体对话的AutoGen有主打角色化协作的CrewAI还有微软的Semantic Kernel、Java圈的Spring AI、Google下场做的ADK。这篇内容主要解决一件事面对这么多Agent开发框架怎么根据业务场景做技术选型以及把一个Agent真正跑到生产环境时记忆、工具、并发、部署、安全这些绕不开的坑怎么填。适合正在做大模型应用、准备落地Agent项目或者需要给团队做技术预研与选型的工程师。1. 主流Agent开发框架全景盘点1.1 应用层生态LangChain与LangGraphLangChain基本是圈内默认的入门选择因为它的抽象足够“亲民”Chain、LLM、Prompt Template、Tool、Memory这些概念对新手特别友好社区里教程、demo、插件数量也是所有框架里最多的。早期我们用LangChain做POC概念验证确实很快配置好大模型API、挂两三个工具函数、串一条链几分钟就能跑出个能对话的demo。但LangChain早期有个被吐槽最多的点抽象太多、太绕一旦业务逻辑复杂起来调试成本直线上升。链式结构本质上是“线性执行”很难表达“模型多次决策、调用不同工具、失败后重试”这种非确定性的流程。所以LangChain团队后来单独拆出了LangGraph用图结构来编排Agent的逻辑节点就是“某个处理阶段”比如模型推理、工具执行边就是“状态流转的规则”状态则在整个图生命周期里被持续管理和传递。LangGraph的设计思路更适合生产级Agent它允许你显式定义分支、循环、条件跳转也自带checkpoint机制可以把每一步状态持久化掉电恢复或者人工介入都更容易。社区基本形成了一个共识POC用LangChain快速验证生产级Agent用LangGraph做复杂编排。如果你看到网上有项目直接用LangChain实现Agent大概率只适合学习不建议照搬上线。1.2 数据智能体方向LlamaIndexLlamaIndex最初解决的核心痛点是“大模型怎么更好用你自己的数据”所以它的索引结构、检索管线、混合RAG能力一直是强项。后来它发展出面向Agent的Workflow框架核心思路跟LangGraph类似都是把复杂流程编排成一张图但LlamaIndex侧的默认配置和内置组件明显更偏向“数据访问”和“知识检索”。如果你的Agent核心场景是密集的知识库问答、结构化数据抽取、文档分析、基于私有数据的决策支持LlamaIndex是一个很稳的选择。它有完整的Retriever、Query Engine、Data Connector体系对PDF、数据库、数仓、API等数据源的支持比较全面。我的体感是如果Agent的主要工作流是“读数据→理解→回答/操作”LlamaIndex的学习曲线比LangGraph更平缓而且检索效果的可控性更高。1.3 多智能体协作系AutoGen、CrewAI与MetaGPT单Agent应付复杂任务时很容易出现“一个人又当规划师又当执行者”的瓶颈所以多智能体方向也出了不少框架。微软的AutoGen核心是“多Agent对话”把不同的Agent设计成可以互相发消息的角色比如Planner、Executor、Critic通过群聊模式共同完成一个任务。这个模式的好处是思考过程更透明每个Agent各司其职适合大型复杂任务拆解和分工协作。缺点是通信开销大、token消耗高而且多Agent对话的稳定性需要花心思调。CrewAI走的是“角色扮演团队”路线用Crew团队、Agent成员、Task任务、Process流程这套概念来模拟一个虚拟团队。它比AutoGen更轻量定义好角色和任务后自动化程度很高适合结构相对固定、任务边界清晰的多Agent协作场景。MetaGPT则更偏向软件开发场景它以Software Company为抽象内置了产品经理、架构师、项目经理、工程师等多角色核心思路是“标准化中间产物”驱动上下游协作。这类框架的局限也明显它们对任务类型有预设一旦脱离其预设流程定制成本会上升。1.4 企业技术栈系Semantic Kernel与Spring AI微软的Semantic Kernel主打“企业级大模型应用”特别适配.NET生态但Java/Python版本也都有维护。它的核心概念是Planner、Skill、Memory设计上更强调“把大模型能力当作常规软件组件来集成”跟微软云和生态结合得比较紧密。我用过一段时间的感受是Semantic Kernel的工程规范性很好适合有成熟软件工程规范、需要把AI能力嵌进现有系统的团队因为它对依赖注入、日志、配置管理、可观测性的支持很原生。Spring AI则是Java开发者不可忽视的选择。它不是为了Agent而生的框架而是一套面向Spring生态的AI应用集成层提供了ChatClient、EmbeddingModel、VectorStore等抽象以及对主流大模型API和向量数据库的适配。基于Spring AI搭Agent你能复用Spring Boot的成熟体系配置管理、AOP、事务、分布式链路追踪、容器化部署生态。Java团队做Agent与其强上Python框架再搞一套跨语言的服务不如在Spring AI上做一套更符合团队技术栈的实现。1.5 新兴趋势框架Google ADK与国产框架Google在今年初开源了Agent Development KitADK定位是轻量级Agent开发框架强调可扩展性和企业级特性。ADK支持多Agent编排、内置安全护栏、基于Python的快速开发跟Vertex AI的集成比较顺滑。从设计风格看ADK比LangGraph更简洁抽象层级没那么多有“原生Agent开发”的取舍感。对已经重度使用Google云生态的团队值得提前关注和体验。国内团队在Agent框架上的动作也很多但很多商业化产品不太适合当作代码级框架直接引入更多是平台化能力。企业如果要评估国内Agent开发平台重点看三件事是否支持私有化部署、能否对接已有模型网关、底层是否暴露可编程的编排接口。很多平台表单化配置看起来很漂亮真落到“我要写一个特殊的工具函数并且对结果做复杂校验”时就力不从心了。我做技术选型有个习惯先把每个框架跑一个最小demo只测“模型能不能自主决策调一个函数”这一项就能筛掉一半框架——有些框架在文档里宣传得很好实际跑的时候光环境配置就能卡你一天。2. 框架选型逻辑先想清楚要解决什么问题2.1 拆解Agent的能力等级与工程要求选型真正要回答的问题不是“哪个框架最好”而是“我的Agent到底需要什么能力”。这里借用吴恩达在Agent课程里的经典四要素规划Planning、工具Tools、记忆Memory、反思Reflection。但落到工程上我会多补三个维度并发处理能力、可观测性、安全与权限控制。可以先做一个能力分级评估等级能力特征典型场景L1单轮工具调用模型根据用户请求执行一个函数天气查询、单据翻译、简单信息抽取L2多步任务规划自主决定调用多个工具数据分析、报告生成、客服工单处理L3具备外部记忆能记住历史偏好并动态调整方案个性化助手、企业知识顾问、学习陪练L4多Agent协作拆解大型任务并行推进软件研发助手、全流程运营机器人大多数框架都能支持L1和L2但只有部分框架在L3和L4的工程化上做得够好。比如LangGraph和LlamaIndex对状态管理、持久化、节点复用有成熟的实现而简单Chain框架在L3阶段就很容易“状态绕晕”。在选型之前先标定自己当前要做哪个等级能避免很多“框架换了一套又一套”的折腾。2.2 不同场景对应的框架建议基于我过去项目的经验分享一套选型组合仅供参考。数据密集型的知识问答Agent优先LlamaIndex它的检索链路是开箱即用的。复杂流程控制、需要多轮工具调用的任务型Agent优先LangGraph因为状态机模型对这种场景是天然适配的。多Agent协作且有清晰角色分工的场景CrewAI更容易上手如果你需要更自由的Agent对话协商机制再考虑AutoGen。Java技术栈为主的公司不用纠结直接调研Spring AI同时看LangChain4j做补充后者对Java生态的适配也很完善。微软体系里Semantic Kernel是自然的选择。如果你做的是边缘计算或嵌入式设备上的Agent可以考虑ROS 2 Micro-Ros Agent这类方案优先保证运行时资源占用小、确定性高。很多人在选型时只关注“模型支持哪些”却忽略了“运维体系能不能融合”。框架最好选择和现有监控、日志、链路追踪体系能对接的否则后期补可观测性的成本远高于迁移框架的成本。2.3 别忽视非功能需求并发、可观测与安全选型时最容易翻车的其实是非功能需求。Agent项目上线之后并发能力直接取决于框架对异步支持和状态隔离的处理方式。一个很现实的问题是框架是不是默认为“单用户单Session”设计的如果是就意味着框架本身不承诺多会话并发安全需要你自己把控。可观测性也一样。Agent的执行链路是非线性的一个请求可能经历“模型思考→选工具→改参数→循环重试”如果没有完整的trace机制出了问题靠打印日志逐个猜测排查效率会极低。LangGraph天然有状态流转的记录能挂接LangSmith或OpenTelemetry追踪Semantic Kernel对.NET的日志和Metrics体系支持得好Spring AI则可以直接依赖Spring Boot的Actuator做健康检查和指标采集。安全这块更重要尤其在工具可以写库、调用外部API的情况下。安全设计需要考虑验证用户输入是否包含恶意指令、控制工具的执行权限与访问范围、记录审计日志、对模型输出做二次校验。很多小众框架连基础的Session隔离都做得不严谨选型时一定要翻一翻框架和引擎底层对安全隔离的文档说明。3. 核心抽象拆解记忆、工具与编排3.1 记忆Agent的“心理状态”记忆是Agent和普通接口最大的区别之一。没有记忆的Agent每次对话都是“陌生人”有了记忆才能让用户觉得“这个助手懂我”。但记忆的实现没那么简单至少要分三层短期记忆当前对话的上下文窗口通常直接用大模型的context里保存但这部分有token上限限制对话长了就会被截断。工作记忆Agent在任务执行过程中的临时状态比如“我已经查了订单A现在要判断是否退款”这层记忆更适合放在结构化存储里比如Redis或者关系型数据库。长期记忆跨会话的用户偏好、事实性信息、历史行为一般要落到向量数据库或图谱里按需检索取回。谈到这里就要提一个重要概念Agent存储中的Working Memory。很多框架都号称支持“记忆”但实现方案差异很大。LangGraph提供的State全部可以序列化保存天然承担了工作记忆的角色LlamaIndex的Memory模块注重检索式记忆管理AutoGen的设计则是对话历史即记忆简单粗暴但token消耗高。工程上现在比较认可的做法叫“混合记忆”短期上下文给模型保持连贯性结构化状态存Redis保证可恢复长期事实存向量库做近似检索关键事实用规则或小模型抽取后存关系型数据库方便复核。这样既控制成本又兼顾准确度。3.2 工具调用越简单越不容易出错工具调用是Agent执行能力的体现。用框架开发Agent时最容易踩的坑是“工具函数写得太复杂”。框架层对工具的抽象一般是函数名、参数schema、描述、返回值。大模型在决策时依赖这个schema去生成调用参数写得太复杂会让模型无所适从。经验法则一个工具只做一件具体的事。比如“查询订单状态”和“修改订单备注”应该拆成两个工具而不是合并成“订单操作”。因为模型在意图识别阶段需要明确的边界参数越少、描述越清楚调用的准确率就越高。工具调用还有一个隐藏知识点——失败处理。真实场景里工具本身可能报错比如下游接口超时、数据格式变化、权限不足。好的框架会让你在工具函数里自定义异常捕获并返回一段结构化错误信息给模型让模型决定是换一种方案还是向用户解释。这比“工具抛异常后整个任务中断”要优雅得多。3.3 编排图、对话和流程控制的取舍Agent流程编排方式可以分成几类理解它们能帮你更精准地选择框架。链条式编排是最初形态适用于固定步骤接收问题→查数据→生成回答。这种编排在简单场景下很高效但完全不能应对循环。图式编排是当前的主流方向LangGraph、LlamaIndex Workflow、Google ADK都是这类思路每个节点有明确输入输出条件边控制流转天然支持循环和分支。对话式编排则是AutoGen这类多Agent框架的方式Agent之间的“对话”本身就是流程控制逻辑优点是灵活缺点是流程不可预测、难调试。我个人的建议是核心业务流程尽量用图式编排尤其是在生产环境。把“模型决策”作为节点把“规则判断”作为边二者结合是最可控的。比如“用户意图分类”节点→条件判断→进入“订单查询工具”节点→结果反馈→循环或终止。这种结构的好处是每个节点都能打日志、设置超时、单独重试出了故障可以定位到具体环节。4. 实操案例从0到1搭一个生产级Agent4.1 一个真实需求企业知识库数据分析Agent为了演示框架的实际用法我拿一个比较典型的场景举例给企业内部做一个“数据洞察Agent”员工可以用自然语言查询业务数据Agent需要理解问题→调用SQL查询工具→获取数据库结果→组织成报表回答。这个场景综合了工具调用、结构化输出、上下文管理非常适合用来说明完整链路。技术选型上用LangGraph加一个关系型数据库连接工具再挂一个向量库做历史问答记录的长期记忆。结构非常清晰整个Agent的核心代码量可以控制在几百行以内。4.2 用LangGraph实现核心链路先定义一个Agent的状态结构。在LangGraph里状态是整个图的“全局变量”每个节点都可以读写状态这是它支持复杂任务编排的基础力量。from typing import TypedDict, Annotated, List from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): question: str sql: str query_result: str answer: str retry_count: int三个核心节点模型生成SQL、执行SQL工具、生成最终回答。from langchain_openai import ChatOpenAI from langchain_core.messages import SystemMessage, HumanMessage llm ChatOpenAI(modelgpt-4o-mini, temperature0) def generate_sql(state: AgentState): prompt f 你是一个数据分析师。请根据用户的业务问题生成SQL查询。 业务问题{state[question]} 请注意只输出SQL语句不要输出任何解释。 sql llm.invoke([HumanMessage(contentprompt)]).content.strip() return {sql: sql} def execute_sql(state: AgentState): import sqlite3 conn sqlite3.connect(business.db) cur conn.cursor() try: cur.execute(state[sql]) result cur.fetchall() return {query_result: str(result), retry_count: state[retry_count]} except Exception as e: return {query_result: fSQL执行错误: {e}, retry_count: state[retry_count] 1} finally: conn.close() def generate_answer(state: AgentState): answer llm.invoke([ SystemMessage(content你是业务分析师请基于查询结果给用户解释分析结论。), HumanMessage(contentf业务问题{state[question]}\n查询结果{state[query_result]}) ]) return {answer: answer.content}构建图并且为SQL错误节点增加条件判断。这一步是LangGraph跟传统Chain的明显区别加一条条件边如果SQL执行失败且重试次数小于2重新回到生成SQL的节点如果失败超过2次直接结束并提示用户。条件边用函数控制比硬编码循环更灵活。def should_retry(state: AgentState): if SQL执行错误 in state[query_result] and state[retry_count] 2: return retry return direct_answer graph StateGraph(AgentState) graph.add_node(generate_sql, generate_sql) graph.add_node(execute_sql, execute_sql) graph.add_node(generate_answer, generate_answer) graph.add_edge(START, generate_sql) graph.add_edge(generate_sql, execute_sql) graph.add_conditional_edges( execute_sql, should_retry, {retry: generate_sql, direct_answer: generate_answer} ) graph.add_edge(generate_answer, END) agent_app graph.compile()运行时执行非常简单输入用户问题之后整个图的调度由LangGraph自动完成。这个示例传达了Agent框架的核心优雅之处——业务逻辑被拆解成可调试的节点模型决策和规则判断可以天然共存。4.3 实现记忆与工具注册的工程细节上面的示例只展示了核心链路生产级还要补充记忆和工具注册。记忆方面把对话历史存入Redis每个Session维护一个key保存最近N轮对话。每次调用模型前把历史作为上下文注入还可以把历史中出现的业务关键词抽取出来存入向量库检索相关结果补充长期记忆。注意一个细节不是所有历史都有必要塞进上下文可以设定策略只保留最近两轮完整对话更早关键信息通过检索补全这样才能把token开销控制住。工具注册方面LangGraph配合LangChain的tool装饰器可以在函数上定义工具的参数schema和描述框架会把这些信息传给模型用于决策。from langchain_core.tools import tool tool def query_order_status(order_id: str) - str: 查询订单状态返回订单当前节点描述。 # 内部调用订单系统API return f订单{order_id}当前状态已发货工具描述里一定要写清楚“这个工具是干什么的、什么时候使用、需要哪些参数”。模型就是靠这段描述做匹配的描述不准确哪怕函数写得再好也没有意义。工具函数内部要做好超时控制和错误兜底超时统一设3秒错误信息用安全格式返回。4.4 Java技术栈的Spring AI补充方案如果团队主语言是Java其实也可以照搬这套思路。Spring AI提供了ChatClient接口对接大模型用Tool注解暴露可调用的工具方法用ChatMemory组件管理对话历史。Spring AI的Agent能力虽然没有LangGraph那么“显式”但配合Spring StateMachine或其他工作流引擎可以做类似的分支控制。更彻底的方案是引入LangChain4j它内置了AiServices和MessageWindowChatMemory对Java开发者来说自己实现一套基于Spring的Agent编排并不需要太多额外学习成本。关键点在于模型接入、工具定义、回调事件这三个抽象做扎实上层Agent逻辑完全可以用Java的流程控制语言保住工程性。5. 并发、部署与可观测性Agent上生产的必修课5.1 Agent如何抗住高并发这是“AI Agent怎么扛并发”这个高频问题背后的核心。首先要认清一个现实Agent类应用的本质是慢IO密集一个Agent完整的推理链路通常包含多次模型调用和工具调用单请求耗时会明显高于传统后端接口。因此在系统架构上必须做“异步化”改造将长耗时的Agent任务与用户请求连接解耦用任务队列接收请求并由Worker异步处理处理完成后再通过WebSocket等方式通知用户。这跟传统同步接口是截然不同的设计方式。并发问题上第二个关键是“无状态化”。Agent实例本身不保存用户的状态所有会话状态都要放到外部存储Redis或数据库里。这样Agent服务可以随意水平扩容每个请求落到任意一个实例都能继续。LangGraph的checkpoint机制在这方面很有价值它可以自己保存状态Agent在任意节点中断后都能从保存点恢复。最后是限流与降级。模型API侧的限流尤其要提前规划方案上要做两层限流第一层在网关层限制用户提交频率防止接口被打爆第二层在模型调用层做令牌桶限流防止超出模型服务的配额。此外还要做模型超时控制。市面上成熟的模型调用工具或框架本身内置了这些策略没有内置的话一定要自己封装统一入口。压测数据可以参考我跑过的一个项目单个Agent服务实例如果完整链路需要调用模型3到5次吞吐量大概是每分钟处理60到80个任务。想翻一倍最直接的手段不是优化代码而是加队列、加Worker实例、加Redis做状态共享这样整体扩展性才会体现出来。但值得注意的地方是上下文窗口本身有上限高并发场景下必须配合上下文压缩策略来控制每请求的token消耗避免大量请求同时把模型服务打满。5.2 部署形态流式响应还是任务式响应部署形态要根据使用场景分。实时对话类的Agent尽量走流式响应模型生成的每个token都通过流式输出给用户首token延迟会明显缩短用户会觉得“它真的在思考”。框架层LangChain、LlamaIndex都有流式调用的支持前端配合SSE模式即可。批处理类的Agent则用任务队列加轮询通知的模式比如数据分析Agent用户提交问题后先返回“任务分析中”处理完再推送结果这种模式抗压能力强很多。部署平台的资源配比上Python类框架LangGraph、LlamaIndex需要特别注意Gunicorn或Uvicorn的Worker数设置。Agent应用是IO密集型Worker数可以比标准Web应用多一些同时Agent应用内存占用比普通应用高因为要加载模型相关SDK和对话状态容器内存配置要留有至少2倍余量。5.3 链路追踪不观测等于没上线Agent应用的可观测性是三个维度。第一是Log要带SessionId和TaskId方便串联一次完整交互第二是Metric要覆盖请求量、模型调用量、延迟、工具调用成功率、token消耗第三是Trace要对整个图中的每个节点打点能看清楚一个请求走到了哪个节点、为什么走到了这个分支。LangGraph接OpenTelemetry的方案比较成熟可以在节点入口和出口加span记录节点名、耗时、输入输出摘要。Spring AI天然支持Micrometer指标。LlamaIndex也有内置的Callback Handler做观测。没有可观测体系就上生产的话遇到“模型在循环调用某个工具”这类问题只能靠逐条看日志猜测效率非常低。6. 常见问题与排查技巧实录6.1 典型故障速查表现象可能原因排查方向Agent一直循环调用同一个工具缺少终止条件或模型判断错误增加最大迭代数限制检查工具描述意图边界是否清晰工具参数反复解析失败模型生成JSON不规范schema过于复杂简化参数名提供示例值开启JSON Mode或结构化输出上下文一长回答质量明显下降对话历史累积过多超出模型窗口启用截断策略或摘要记忆加检索式记忆并发一高就大量超时同步阻塞调用模型无队列无限流改造异步任务队列两层限流扩容Worker模型返回内容含幻觉数据缺少事实校验环节增加对数据库结果或API结果的校验后才输出沙盒或执行环境报更新失败容器镜像缓存陈旧环境依赖变更重新构建镜像清理缓存锁定依赖版本第三行的“Sandbox更新失败”有一点值得展开很多Agent自带的代码执行环境比如AI编程工具的沙盒是一个容器化运行时报更新失败时老代码的依赖可能与沙盒内置工具版本不一致或本地仍在使用旧镜像缓存。解决方案是清理本地容器缓存重新拉取最新环境镜像并且把Agent服务升级镜像的操作写进CI流程而不是每次手动触发。6.2 安全风险与工程防护Agent安全是上线前必须做的一项工作。Agent本质上是开放接口你给了它调用工具的能力就要防止这份能力被滥用。最典型的攻击方式是提示注入用户通过输入构造恶意指令诱导Agent执行未授权的操作。比如“忽略之前的系统提示”或者“帮我把以下内容用SQL插入到订单表”。工程上常用的几道防线输入侧对用户输入进行意图识别和敏感词过滤检测异常指令模式。工具侧工具函数内部校验权限确认当前用户是否有操作对应资源的权限参数白名单校验对SQL查询建议用参数化查询或只读连接。会话隔离严格建立“用户级别租户级别”的隔离边界防止跨会话越权。输出侧Agent输出在某些场景要经过出口规则校验比如不允许直接输出系统Prompt内容、不允许对外透出敏感字段。框架本身很多也提供了安全能力。Google ADK内置了安全护栏模板LangGraph可以在节点边加校验Semantic Kernel有插件权限的特性。不要寄希望于模型自身“守规矩”把安全边界建在代码层才可靠。6.3 排查思路别用“猜”来定位问题Agent应用的故障排查链路比传统应用复杂因为不确定性太多。我总结的排查顺序是第一步先看输入输出日志确认模型在这一轮到底生成的是什么内容是工具调用失败还是模型压根就没有正确理解问题。第二步看状态流转如果在LangGraph里就是查看每个节点的输入输出快照找出从哪个节点开始“跑偏”。第三步看Token消耗有时候问题不是功能错误而是成本失控——一个任务烧掉几十万token这种情况下需要优化记忆和压缩策略而非修逻辑。推荐在开发环境开启框架的Verbose模式比如LangGraph的debugTrue能看到每一步的完整状态变化。生产环境的日志照前面说的链路追踪方式详细打点问题排查的效率可以提高一个量级。7. 写在最后踩过坑之后的几条真实体会我之前带过的一个项目刚上线两周就遇到一次“工具调用风暴”——用户连续追问了十几个问题Agent在上下文里累积了过长的历史模型开始频繁地把“查询订单”和“修改订单”的工具混淆连续调错三次。当时的处理方案是给Agent加了一个“上下文截断节点”同时把工具描述重写得更具区分度这个问题的根子才真正解决。小程序上线前千万别省掉全链路压力测试。我见过太多团队在做POC的时候一切都好一上生产并发就超时推到框架头上说“这个框架不行”。说实话九成的问题不是框架的锅而是架构设计时没考虑队列、异步、状态外置这些基本功。如果你正在选型我的建议是先写一个最小可用的Agent跑通模型调用、工具调用、状态流转这三件套再决定框架。不要因为某个框架热度高就盲目引入。工具永远是次要的真正决定Agent上限的还是你对任务拆解、状态建模、错误恢复和系统边界这四个问题的理解深度。
