做Agent开发这两年，被问到最多的一句话是：“现在主流的Agent开发框架到底选哪个？”这个问题看着简单，真答起来绕不开一堆细节。市面上的框架早就卷成一片红海：有LangChain这种大而全的老牌生态，有从LangChain拆出来专攻图编排的LangGraph，有死磕数据索引的LlamaIndex，有搞多智能体对话的AutoGen，有主打角色化协作的CrewAI，还有微软的Semantic Kernel、Java圈的Spring AI、Google下场做的ADK。这篇内容主要解决一件事：面对这么多Agent开发框架，怎么根据业务场景做技术选型，以及把一个Agent真正跑到生产环境时，记忆、工具、并发、部署、安全这些绕不开的坑怎么填。适合正在做大模型应用、准备落地Agent项目，或者需要给团队做技术预研与选型的工程师。

1. 主流Agent开发框架全景盘点

1.1 应用层生态：LangChain与LangGraph

LangChain基本是圈内默认的入门选择，因为它的抽象足够“亲民”：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 数据智能体方向：LlamaIndex

LlamaIndex最初解决的核心痛点是“大模型怎么更好用你自己的数据”，所以它的索引结构、检索管线、（混合）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 Kit（ADK），定位是轻量级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的工程化上做得够好。比如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搭一个生产级Agent

4.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(model="gpt-4o-mini", temperature=0) def generate_sql(state: AgentState): prompt = f""" 你是一个数据分析师。请根据用户的业务问题生成SQL查询。 业务问题：{state['question']} 请注意：只输出SQL语句，不要输出任何解释。 """ sql = llm.invoke([HumanMessage(content=prompt)]).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": f"SQL执行错误: {e}", "retry_count": state["retry_count"] + 1} finally: conn.close() def generate_answer(state: AgentState): answer = llm.invoke([ SystemMessage(content="你是业务分析师，请基于查询结果给用户解释分析结论。"), HumanMessage(content=f"业务问题：{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 典型故障速查表

第三行的“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的debug=True，能看到每一步的完整状态变化。生产环境的日志照前面说的链路追踪方式详细打点，问题排查的效率可以提高一个量级。

7. 写在最后：踩过坑之后的几条真实体会

我之前带过的一个项目，刚上线两周就遇到一次“工具调用风暴”——用户连续追问了十几个问题，Agent在上下文里累积了过长的历史，模型开始频繁地把“查询订单”和“修改订单”的工具混淆，连续调错三次。当时的处理方案是给Agent加了一个“上下文截断节点”，同时把工具描述重写得更具区分度，这个问题的根子才真正解决。

小程序上线前千万别省掉全链路压力测试。我见过太多团队在做POC的时候一切都好，一上生产并发就超时，推到框架头上说“这个框架不行”。说实话，九成的问题不是框架的锅，而是架构设计时没考虑队列、异步、状态外置这些基本功。

如果你正在选型，我的建议是：先写一个最小可用的Agent，跑通模型调用、工具调用、状态流转这三件套，再决定框架。不要因为某个框架热度高就盲目引入。工具永远是次要的，真正决定Agent上限的，还是你对任务拆解、状态建模、错误恢复和系统边界这四个问题的理解深度。