最近总有朋友跑来问同一个问题AI Agent这么火大家都在往上冲我要不要也搭一个我的回答往往是一句反问——你先把基础设施想清楚了吗不是泼冷水。作为一个从单体应用时代一路摸爬滚打过来的后端开发者这几年我见过太多团队被新概念冲昏头AI Agent的Demo三周跑通生产环境一上线就被流量拍死或者被外部模型的超时拖到全线崩溃。AI Agent不是普通Web服务加一个提示词接口它对基础设施的要求是另一种维度。我在这篇文章里把这些年踩过的坑、验证过的架构方案、以及最终沉淀下来的一套“扛得住”的实践一起拆开说说。1. AI Agent为什么让老架构措手不及1.1 先理解AI Agent到底是什么“物种”很多人把AI Agent理解成“更聪明的ChatGPT包装层”这是最大的误区。传统Web服务是一个“请求-响应”模型客户端发请求服务端处理返回结果连接结束。AI Agent是“目标驱动”模型用户给一个目标Agent自己规划步骤、调用工具、读取结果、再推理、再执行直到目标完成。这就带来一个本质差异传统接口是秒级返回Agent是分钟级甚至小时级的持续运行。这个差异直接冲击了基础设施的三个底层假设。第一连接模型变了。一个用户请求进来背后可能是一连串的LLM调用、外部API调用、中间结果校验整个链路需要长时间占据资源和连接而不是处理完就释放。第二并发模型变了。传统服务靠“线程池加阻塞IO”或“进程池加队列”就能压住量但Agent的每个会话都是多步状态机需要随时保存和恢复执行现场线程池和队列根本表达不了这种状态。第三容错逻辑变了。传统接口超时最多重试一次Agent链路中间任何一步失败都可能导致整个目标执行失败又得从头再来。如果你还在用“Spring MVC Nginx MySQL”这一套应对AI Agent流量那本质上是用自行车拉货——不是不能动是拉不动。1.2 那几个被热词忽略的真正瓶颈热词里“ai agent 怎么扛并发”是最高频的搜索之一说明大家都意识到并发有问题但很多人把并发问题简化成了“增加服务器”。真正扛住AI Agent流量至少面对四个瓶颈。LLM调用的延迟放大效应。传统接口的瓶颈通常在数据库但Agent的主要耗时在LLM推理和外部工具调用。一次LLM调用按3秒算这已经算快了一个Agent任务平均10次LLM调用最保守就是30秒起步。如果并发100个任务意味着你要同时管理几百个挂起中的LLM请求。这不是“加两台机器”能解决的而是整个系统的设计模式都得变。状态管理的复杂性。Agent的每次推理决策都依赖之前的对话历史和工具返回结果这些状态放在内存里一重启就全丢放在MySQL里频繁读写会成为新瓶颈如果所有状态都塞进大模型上下文成本和时延同时爆炸。外部依赖的不稳定。目前大多数AI Agent都依赖外部LLM API和第三方工具API但外部API没有义务为你的SLA负责。它们会限流、会超时、会返回格式错误、会升级模型导致输出变样。基础设施如果把这些外部因素当成“可信依赖”生产事故就是早晚的事。成本的无上限增长。LLM是按token计费的Agent的每次循环都在烧钱。传统基础设施你只需要关注CPU和内存的水位Agent基础设施还要盯住“每一笔请求花了多少钱”。流量一倍增长成本可能是十倍增长因为多步推理让每单token消耗量剧增。所以这里的“基础设施”不是指服务器机房而是架构模式、运行引擎、状态存储、可观测性、成本控制和弹性策略的一整套组合。2. 想扛住Agent流量先认清四个核心瓶颈2.1 延迟放大从“单一请求”到“多跳调用”我给Agent系统做过一次最简单的链路拆解用户问“帮我查一下上周的销售数据然后分析下滑原因再写一封邮件给区域总监”这条链路大概是意图识别1次LLM调用→ 查询数据库外部动作→ 数据摘要1次LLM调用→ 原因分析1次LLM调用→ 生成邮件1次LLM调用最后再经过一轮自我检查1次LLM调用。也就是说用户看到的是一个请求后端实际发生了至少5次LLM调用加多次数据查询。传统接口的RT响应时间是“一次计算的时间”Agent接口的RT是“多跳计算的叠加”。基础设施必须为此改变的第一个设计就是异步化。用户点击之后不能让他干瞪眼等30秒正确的做法是立即返回一个任务ID后台异步运行状态通过轮询或者WebSocket/SSE推送给前端。我把这套叫做“任务化改造”它几乎是所有Agent生产化改造的第一步否则你的网关、负载均衡、容器编排全部会在长连接和慢请求上集体阵亡。另一个必须改变的设计是并行化。Agent内部有一些步骤天然可以并行比如“查销售数据”和“查库存数据”可以同时发起没有必要严格串行。把串行变成并行直接压缩了总时长也让资源利用更平滑。2.2 状态爆炸Agent状态的存储与恢复Agent运行时的状态由三部分组成对话上下文、任务执行状态当前执行到哪一步、每一步的结果、以及各类临时数据工具返回的原始结果、中间推理过程。第一代Agent实现基本都栽在这里把状态全部放在内存字典里进程一重启所有任务全部丢失服务一扩容新节点接管不了老任务。我见过最夸张的一次事故某团队把Agent状态存在本地内存上线第二天线上流量把服务压崩了两次每次重启所有用户的Agent任务都回到起点用户投诉直接打爆客服。正确的做法是把状态外置引入状态存储层。首选是Redis适合短期、高频、结构简单的状态如果Agent任务运行时间较长、状态历史复杂建议采用Redis加对象存储的组合近期活跃状态放Redis归档数据放S3或MinIO。核心原则只有一条任何节点都可以被随时替换状态不能绑定在进程里。这条原则做到了你的Agent系统才敢谈水平扩容。2.3 外部依赖失控模型API和工具API的稳定性治理Agent比普通微服务依赖更多外部系统而且这些系统个个都是不可控的。LLM API会限流第三方工具会宕机更麻烦的是它们的错误返回往往是静默的——模型没有崩溃但是输出格式完全不符合预期你的Agent还要判断“这结果到底能不能用”。基础设施需要为这些外部依赖建立三个机制。限流与退避。每个外部API都有配额超出配额被拒绝是常态。基础设施要做客户端限流把自己的调用频率控制在配额之下同时遇到429/503要自动退避重试退避策略采用指数退避加抖动防止所有请求在同一时刻重试形成“重试风暴”。超时与熔断。外部调用必须有明确的超时时间不能无限等待。我习惯将LLM调用超时设为30秒工具调用超时设为10秒超时后走降级路径。连续失败次数达到阈值时触发熔断直接返回“当前服务繁忙”的降级响应而不是继续怼着一个已经挂掉的外部系统死磕。结果校验。对LLM返回做结构化的格式校验比如用JSON Schema验证输出结构。有一次我排查一个Agent任务全链路成功率只有60%的问题最后定位到是模型偶尔把JSON输出截断了下游解析直接报错Agent被迫重跑整个流程。后面加了一层输出校验加自动修复截断时补全成功率直接拉到95%以上。2.4 成本黑洞Token消耗的监控与干预很多团队第一版Agent系统上线后先崩溃的不是技术是财务。因为Agent的多步循环让单次任务的token消耗比普通问答高出几十倍。一个普通聊天请求可能消耗几百个token一个Agent任务动辄几万token。基础设施必须有成本干预能力。我常用的手段有三类第一在Agent每步调用前做“上下文裁剪”只保留关键信息比如历史对话每隔几轮做一次摘要压缩工具返回只保留核心字段不要让无关内容流入上下文第二建立预算上限每个任务或每个用户在单位时间内的token消耗达到阈值后自动降低模型档位从大模型降到中等模型或者直接终止任务并提示用户第三全链路标记每个任务在链路日志中携带token用量和成本字段按用户、按业务、按时间维度做成本分析。成本问题本质上也是基础设施问题因为它直接决定你的系统能不能长期跑下去。一个每笔订单都亏损的Agent系统再稳定也是死的。3. 基础设施升级的实操方案3.1 架构分层把Agent系统拆成通信层、编排层、执行层很多团队做Agent是一股脑全塞在一个服务里HTTP接口、Agent逻辑、工具调用、状态管理、Prompt模板全部耦合在一起。这在Demo阶段没问题一旦流量起来任何一个小改动都可能引发全链路故障更别提水平扩展了。我推荐的架构是清晰的三层通信层、编排层、执行层。通信层负责接入所有客户端Web端、小程序、企业微信等做协议转换、鉴权、限流和任务ID分配。这一层不包含任何Agent业务逻辑只需要“接任务、发任务、查状态”。编排层是Agent大脑所在地负责规划、决策、任务分解和状态流转。这一层会持续调用LLM所以它是整个系统里最需要消耗CPU和内存的也是最容易成为瓶颈的地方。编排层必须是无状态的——所谓的“无状态”不是说不保存状态而是状态全部通过状态存储层读写进程本身不持有用户会话的任何数据。执行层负责调用具体工具包括数据库操作、内部API、第三方API。执行层的服务实例可以按工具类型拆分比如搜索工具、数据分析工具、邮件工具各自独立部署这样某个工具崩了不会拖垮全部Agent任务。分层的好处很明显每层可以独立伸缩。比如促销大促时搜索请求量大只需扩容执行层中的搜索工具实例不需要把整个Agent服务都翻倍。3.2 异步化改造从同步等待到事件驱动Agent系统的主流程应该是异步的。我现在落地的标准实现是HTTP接口收到请求后先做参数校验和基础鉴权然后生成一个任务ID写入任务队列立即返回202状态码给客户端。客户端后续轮询“GET /tasks/{taskId}”或通过SSE订阅状态更新。任务队列是整个异步架构的基石。小规模可以用Redis的List或Stream每个任务是队列里的一个消息。规模再大一些建议引入专业消息队列Kafka或RabbitMQ好处是消费进度可控、支持重试和死信。编排层从队列里拉取任务执行每一步每完成一步就把状态写入状态存储直到整个任务完成。这样做还有一个额外的好处——流量削峰。当瞬时流量超过系统处理能力任务会堆积在队列里而不是把服务压垮。用户感知到的只是“任务排队中等了几秒”而不是“服务请求超时失败”。我实测过同步改异步之后同样的服务实例数量扛住的并发任务量能提升3到5倍。3.3 关键参数与配置建议这里给出我在实际项目中沉淀的一组配置基线大家可以根据自己的压测结果调整。线程池参数以Tomcat/Undertow为例。Agent接口的线程池不能设置太大因为每个请求占用的时间较长线程池太大反而会频繁切换上下文。我把核心线程数设为CPU核数的2倍最大线程数设为CPU核数的4倍队列容量根据压测结果控制在100到500之间。注意这些参数本身就是一种隐式限流——线程池满了新的请求自然进不来。外部调用超时。我给所有外部调用都设了默认超时LLM调用30秒工具调用10秒数据库操作5秒。每超过一层你的系统能容纳的并发就越低因为线程都被卡在等待上。超时必须逐层收敛下游先超时上游才能更快释放资源。如果所有层都是60秒超时一个故障能把系统卡死半小时。限流阈值。按用户维度限流例如单用户每分钟最多发起5个Agent任务按IP维度限流单IP每分钟最多20个请求。限流算法的选择上通常用令牌桶允许短时间突发但也限制持续流量。这些参数要结合你的服务容量和外部模型配额来定不能拍脑袋。3.4 多模型接入与模型网关成熟的Agent基础设施不能只依赖单一模型供应商一是因为单点故障风险太高二是因为不同任务场景适合不同模型三是价格和性能需要互相博弈。我建议架构里引入一个“模型网关”层。它不承担业务逻辑只做模型路由、限流、重试、降级和计费。路由策略可以按任务类型配置规则复杂推理任务路由到高性能大模型简单分类任务路由到轻量级模型批量生成任务路由到便宜模型。当主模型供应商限流或报错时自动切换到备选模型供应商用户侧无感知。模型网关同时承担统一的请求格式转换这样上游业务层不需要关心当前用的是哪家模型模型方升级或替换时对业务侧是透明的。实现上可以基于FastAPI独立部署一个轻量服务通过配置中心下发路由规则方便随时调整。4. 用 FastAPI LangGraph 搭一个扛得住的Agent服务4.1 技术选型为什么是这个组合热词里有“FastAPI LangChain LangGraph”的组合这套选型我实际用了很长时间确实很适合中小团队快速落地一个可控的Agent服务。FastAPI作为通信层非常合适原生支持async/await配合UVicorn在高并发下表现亮眼OpenAPI文档开箱即用联调和交付效率都很高。LangGraph负责编排层它把Agent流程建模成一张有向图节点是工具调用或LLM调用边是执行顺序这让Agent的每一步都变得可观测、可控、可中断恢复。相比直接用LangChain的AgentExecutor一个黑盒循环LangGraph的图模式更贴近工程化需求——你能看到每一步发生了什么也能在任意节点插入干预逻辑。4.2 一个最小可落地的异步Agent服务骨架第一步初始化FastAPI应用并规划任务接口。示例代码from fastapi import FastAPI, BackgroundTasks from pydantic import BaseModel app FastAPI() class TaskRequest(BaseModel): user_id: str goal: str class TaskResponse(BaseModel): task_id: str status: str app.post(/tasks, response_modelTaskResponse) async def create_task(req: TaskRequest, background: BackgroundTasks): task_id generate_task_id(req.user_id) background.add_task(run_agent_task, task_id, req.user_id, req.goal) return TaskResponse(task_idtask_id, statuspending)关键点在于接口立即返回task_id实际的Agent任务在后台执行。这里用BackgroundTasks是一个简单起步方式但生产环境建议替换为真正的消息队列——BackgroundTasks只在当前进程内执行进程重启任务就丢了。第二步状态存储用Redis。每个任务维护一个状态哈希包含当前节点、执行历史、最终结果示例import redis import json redis_client redis.Redis(hostredis, port6379, decode_responsesTrue) def save_state(task_id, node, data): key fagent:{task_id} redis_client.hset(key, mapping{node: node, data: json.dumps(data)}) redis_client.expire(key, 3600) def load_state(task_id): state redis_client.hgetall(fagent:{task_id}) return state.get(node), json.loads(state.get(data, {}))这里的细节是给每个任务设置了过期时间避免状态在Redis里无限堆积成为内存隐患。第三步用LangGraph定义Agent图。一个简单的“规划-执行-反思”三节点图from langgraph.graph import StateGraph def plan_node(state): # 调用LLM将用户目标拆解为子任务 return {plan: llm_generate_plan(state[goal])} def execute_node(state): # 执行规划的子任务 results [] for task in state[plan][tasks]: results.append(execute_tool(task)) return {results: results} def reflect_node(state): # 用LLM检查执行结果判断是否需要重新规划 check llm_check_result(state[results]) return {need_replan: check[need_replan]} graph StateGraph() graph.add_node(plan, plan_node) graph.add_node(execute, execute_node) graph.add_node(reflect, reflect_node) graph.set_entry_point(plan) graph.add_edge(plan, execute) graph.add_edge(execute, reflect) graph.add_conditional_edge(reflect, lambda s: plan if s[need_replan] else end) app_graph graph.compile()这段图定义的核心价值在于把Agent流程从黑盒变成了明线每个节点都可以加日志、加监控、加熔断、加入人工审核。执行过程中如果发现reflect节点判断需要重新规划图会自动回到plan节点再来一轮这是LangGraph最大的实用优势。第四步接入模型网关。我这里用一个虚拟的函数封装实际项目中需要替换为对模型网关的HTTP调用async def llm_call(prompt: str, model_level: str medium): # 实际实现中在这里调用模型网关并处理超时、重试、降级 response await http_client.post( http://model-gateway/v1/completions, json{prompt: prompt, model_level: model_level}, timeout30 ) return response.json()4.3 部署与容器化参数部署形态上通信层和编排层分开成两个服务更稳妥。通信层无状态可以随意水平扩容前面挂负载均衡编排层虽然也是无状态设计但因为它对LLM调用的并发控制策略更敏感单独部署方便独立调整并发上限和限流参数。容器化的资源限制建议编排层服务建议CPU给2核以上内存4GB以上因为LangGraph的图编排过程涉及大量状态对象的创建和销毁通信层相对轻量CPU 1核、内存1GB即可起步。建议设置最大并发任务数环境变量如MAX_CONCURRENT_TASKS编排层通过信号量控制同时运行的Agent任务数量超过上限的新任务先排队等待。这一步很关键因为LLM API的并发配额通常远低于你服务的并发能力信号量是保护外部配额的最后一道闸门。5. 可观测性与压测提前发现你扛不扛得住5.1 日志、指标、追踪三位一体Agent系统的故障排查比传统服务难得多因为一个用户任务的失败可能发生在第五次LLM调用上中间十几步的日志分散在各个服务。没有一套完整的可观测性体系排查问题全靠运气。日志方面必须全链路携带TraceID。用户请求进来时生成TraceID贯穿通信层、编排层、执行层和所有外部调用在每一条日志中都打上TraceID。这一步是所有可观测性的基础没有TraceID你的日志再多也是一堆无法关联的碎片。指标方面核心监控指标包括任务提交数、任务完成数、任务成功率、平均完成时长、各节点耗时分布、LLM调用次数、Token消耗量、外部API错误率。我尤其看重“任务成功率按节点分布”这个指标它能直接告诉你Agent流程中哪个环节最容易失败——有时候是LLM输出格式问题有时候是某个工具API在特定时段不稳定。追踪方面用OpenTelemetry对接Jaeger或Tempo把一次Agent任务的完整调用链记录成一条Trace。展开Trace你能看到每一步耗时多少、调用了哪个工具、哪一步是瓶颈、哪一步报错。我做Agent性能优化时基本流程都是先看Trace里的“宽节点”也就是耗时特别长的步骤通常集中在大模型的超长输出或外部工具响应上。5.2 压测方法用仿真流量代替基础流量压测Agent系统比压测普通接口复杂因为请求不只是“发一个HTTP请求”而是模拟一个完整的Agent任务链路。如果用传统的方法把所有压力集中在“提交任务”这个接口上压测结果毫无意义——你会看到的只是通信层的吞吐而编排层和外部依赖根本没被真正打满。我的做法是准备一组仿真任务集包含不同复杂度的Agent任务简单问答类预计1轮LLM调用、标准任务类预计5轮LLM调用、复杂任务类预计10轮以上LLM调用加多工具调用。压测时按业务比例混合发送重点观察三个数据任务完成率。压测过程中任务完成率不能低于95%如果发现完成率下降先看编排层是否有任务堆积再看外部LLM调用是否触发了限流。任务完成时长的P95和P99。这两个指标直接反映用户体验如果P99超过用户可接受范围就需要优化并行度或者升级模型速度。外部依赖错误率。这个指标在压测中经常被忽略但Agent系统压崩的往往是外部API配额而不是自身服务。压测结果要达到什么标准才算“扛得住”我的经验是目标并发量下任务完成率不低于95%P95完成时长不超过目标时长的1.5倍且系统内不存在明显的任务队列无限增长。满足这三条基础设施才算基本合格。5.3 容量评估与扩容策略Agent系统有一个特殊现象在线用户数不等于任务并发数。因为每个用户提交一个任务后Agent后台要跑几十秒甚至几分钟所以同时“正在执行中”的任务数量才是真正决定资源需求的指标。我在容量规划时的估算公式是并发任务数 QPS(任务提交速率) × 平均任务完成时长。如果你的系统每秒接收10个任务平均每个任务耗时60秒那么同时执行中的任务就是600个。这个600才是你需要支撑的并发量而不是每秒10个请求。基于这个数据就能推算扩容需求。按单个编排层实例能支撑50个并发任务估算600个并发任务就需要至少12个编排层实例再留30%的冗余部署16个左右比较稳。注意这里的前提是状态已经外置到Redis否则实例数量一多每个任务被调度到不同节点就会直接状态错乱。6. 常见问题与排查技巧实录6.1 高频故障一任务一直pending但不报错这是Agent系统最常见的故障现象。任务提交成功状态永远停在pending没有任何错误日志。排查思路是先看任务队列的消费情况——队列的堆积数量是否在增长消费端是否在正常拉取。如果消费端没有拉取检查编排层服务的线程池是否被打满很多情况下线程池满了消费任务的处理逻辑被阻塞新的任务就全堆在队列里等待。还有一个隐蔽原因编排层服务在启动时注册了消费逻辑但因为连接池配置错误导致消费端一直重连不成功任务始终无人消费。这类问题排查时要从任务的生命周期链路逐段检查先看队列再看消费端日志再看编排层线程池不要一开始就盯着LLM调用排查。6.2 高频故障二外部LLM API限流导致的连锁雪崩流量高峰期外部LLM API开始返回限流错误。Agent的自动重试机制触发后所有任务一起重试外部API限流更加严重形成“限流-重试-更严重限流”的雪崩循环整个系统任务完成率掉到零。我的处理方案有两层第一层是客户端限流在编排层用信号量控制并发LLM调用数量让整体调用速率始终低于供应商配额第二层是区分重试策略限流错误429和系统错误500走不同的退避策略限流错误退避时间拉长到几秒甚至几十秒系统错误可以快速重试一两次。更稳妥的做法是引入一个本地熔断器连续收到几个429后直接进入熔断状态短时间内所有新任务先降级为“排队等待”不再发起外部调用。6.3 高频故障三Agent任务状态丢失状态丢失的根因基本只有一个状态存在了进程内存里。表现为服务重启或发布新版本后所有正在执行的任务全部消失。排查时先确认状态存储的位置——如果代码里用的是全局字典或者实例变量那恭喜你这个问题一定会复现。解决方式就是把状态迁移到Redis或数据库同时加上定期快照机制将关键执行节点上的状态同步到持久化存储。另外提醒一个细节即使状态已经外置也要为状态数据设计版本号或者时间戳。因为Agent图升级改版后旧任务的状态结构可能和新代码不兼容恢复状态时需要做兼容转换否则老任务恢复后直接跑挂。6.4 常见问题速查表症状可能原因排查命令或手段解决方案任务一直pending队列堆积、消费端阻塞检查队列长度、消费组状态扩容编排层、调大线程池队列上限任务完成率骤降外部API限流、工具API故障查看外部依赖错误率指标客户端限流、熔断降级、切换备用模型长时间无响应线程池耗尽查看线程池活跃线程数和队列长度调小等待队列、限流、异步化改造状态丢失状态绑定在进程内存检查状态存储中间件状态外置Redis、增加快照机制Token成本飙升上下文未裁剪、循环无上限查看任务级Token用量的Trace上下文压缩、预算上限、模型降级模型返回格式错乱输出截断、幻觉字段查看LLM返回日志JSON Schema校验、截断补全、重试机制6.5 一些值得长期坚持的运维习惯最后聊几点从实战里沉淀下来的习惯。发布策略上Agent系统的发布变更比传统服务风险更高因为图结构的调整直接影响正在执行的任务。每次发布前先检查是否存在运行中的任务做优雅停机让老任务先跑完再下线新任务都进新版本。资源隔离上如果业务方比较多建议按业务线拆分成独立的Agent服务池避免某个业务线的突发流量把公共池打爆。例行巡检上每周看一次任务成功率的趋势变化留意成功率的缓慢下降——这可能是模型升级导致的隐性行为变化也可能是外部工具接口的渐进性能劣化这类问题靠“出问题再排查”的模式几乎不可能及时发现。写在最后把一个AI Agent从Demo推到生产本质上是一场基础设施思维的升级。我早期也天真地以为Agent的核心是提示词工程和模型选型后来被线上事故狠狠教育过几次才明白真正决定Agent系统生死的是背后的架构异步化是否彻底、状态是否外置、外部依赖是否有治理策略、成本是否有干预手段。这四项基本功做扎实了无论上层模型怎么换、Agent框架怎么升级你的系统都能稳稳接住流量。我个人现在评估一个Agent项目能不能量产不再只看它的智能表现而是先问一句基础设施扛得住吗如果答案是犹豫的那就先把这篇文章里的几个关键点逐项过一遍再上线。反正我试过这套方法帮我躲过了不少本可以预见的线上灾难。