你是不是也踩过这种坑本地测试跑得飞快上线之后用户说「你这 AI 咋这么慢」或者月初信心满满上了新功能月底对账单看到数字翻了三倍却找不到是哪儿吃掉了那么多 Token这些坑不是你代码写得差是你优化的维度没到位。01 先建一张「性能地图」搞清楚时间花在哪里在动刀之前先得知道哪里是瓶颈。一个典型的 LangGraph Agent 调用链路耗时分布大概长这样用户请求 │ ▼ [节点调度] ~5ms │ ▼ [工具描述注入] ~50-300msToken 计算 │ ▼ [LLM 推理] ~500ms-3s ← 最大头 │ ▼ [工具执行] ~200ms-2s ← 第二大头外部 API │ ▼ [结果回写 State] ~5ms │ ▼ 响应返回你会发现LLM 推理 工具执行占了全部耗时的 90% 以上。其余的节点调度、State 读写基本可以忽略。所以优化的本质是减少 LLM 被调用的次数、降低每次调用的输入 Token、让工具执行不再串行等待。来看三个维度怎么搞。02 延迟优化让用户感觉「快了一截」延迟可以从两个角度切降低真实延迟和优化感知延迟。前者是让调用本身变快后者是让用户感觉变快——两个都重要。2.1 流式输出 Redis 缓存 模型路由三连击最直接的「感知延迟」优化是流式输出不改任何推理逻辑只把响应从「等全部生成完再发」改成「边生成边发」。配合 Redis 缓存相同问题命中缓存直接返回5ms vs 1500ms再加模型路由简单任务用 mini 模型便宜 15 倍快 3 倍三者叠加效果显著// 版本langchain0.3.x · langchain/openai0.3.x · langgraph0.2.ximportChatOpenAIfromlangchain/openaiimportHumanMessagefromlangchain/core/messagesimportRedisCachefromlangchain/community/caches/ioredisimportfromlangchain/core/language_models/baseimportRedisfromioredis// ① Redis 全局缓存相同 prompt 命中后 5ms 直接返回constnewRedisCachenewRedishostlocalhostport6379ttl3600setGlobalLLMCache// ② 模型路由按任务复杂度选模型80% 的简单请求用 minitypeComplexitysimplemediumcomplexfunctionrouteModeltask: stringChatOpenAIconstincludes推理includes设计length500constlength50includes分析includes代码constmodelMapRecordComplexitystringsimplegpt-4o-mini// 便宜 15 倍速度快 2-3 倍mediumgpt-4ocomplexo1-previewconstlevelComplexitycomplexsimplemediumreturnnewChatOpenAImodelstreamingtrue// ③ 流式接口用户 200ms 内看到第一个字不再等 3 秒转圈get/streamasyncsetHeaderContent-Typetext/event-streamconstrouteModelqueryqasstringconstawaitstreamnewHumanMessagequeryqasstringforawaitconstofwritedata: ${JSON.stringify({ token: chunk.content })}\n\nend// 注意坑Cache Key 是 prompt model temperature 的哈希// 如果 prompt 里有时间戳/随机 ID缓存命中率会接近 0// 解法把动态内容从 prompt 剥离Prompt 模板本身保持稳定 hljs # 版本langchain0.3.x · langchain-openai0.2.x · langgraph0.2.xfromimportfromimportfromimportfromglobalsimportfromimportfromimportfromimportimport# ① Redis 全局缓存localhost63793600# ② 模型路由defroute_modeltask: str推理inor设计inorlen500len50and分析notinand代码notinsimplegpt-4o-minimediumgpt-4ocomplexo1-previewcomplexifelsesimpleifelsemediumreturnTrue# ③ 流式接口app.get(/stream)asyncdefstream_endpointq: strasyncdefgenerateasyncforinyieldfdata: {json.dumps({token: chunk.content}, ensure_asciiFalse)}\n\nreturntext/event-stream实测一个典型的客服 Agent80% 请求是简单问答用这套组合后平均延迟从 1.8s 降到 0.6s缓存命中率 37%。03 Token 消耗优化把账单从月均 压到800一个典型 Agent 的单次调用 Token 分布部分平均 Token 数优化空间系统 Prompt500–2000高历史对话1000–5000高工具描述1000–3000高RAG 检索结果500–2000中用户输入100–500⚪低模型输出300–2000中前三项是重灾区而且完全在你控制之内。3.1 精简 System Prompt 上下文裁剪 动态工具注入三个 Token 杀手一起拆importBaseMessageAIMessagefromlangchain/core/messagesimportStructuredToolfromlangchain/core/toolsimportChatOpenAIfromlangchain/openai// ─── ① System Prompt 精简 ────────────────────────────────────────// ❌ 冗余版800 tokens20 条注意事项逐条列出// ✅ 精简版40 tokens核心约束一句话const专业客服。准确、友好、诚实、守法。不确定时直接说不知道。// ─── ② 上下文裁剪中间消息用摘要替代而非直接删除 ──────────────asyncfunctiontrimMessages messages: BaseMessage[], keepFirst 2, keepLast 6PromiseBaseMessageiflengthreturnconstslice0constsliceconstsliceiflength0return// 用 gpt-4o-mini 做摘要便宜 15 倍100 tokens 替代 3000 tokensconstnewChatOpenAImodelgpt-4o-minimaxTokens100constmapm ${m._getType()}: ${m.content}join\nconstawaitinvoke用 2-3 句话总结\n${raw}returnnewAIMessage[对话摘要] ${summary.content}// ─── ③ 动态工具注入只给 LLM 看它需要的 3 个工具 ────────────────asyncfunctionselectRelevantTools query: string, allTools: StructuredTool[]PromiseStructuredToolconstnewChatOpenAImodelgpt-4o-minimaxTokens60constmapt namejoin, constawaitinvoke问题${query}\n工具${names}\n输出最相关3个工具名逗号分隔constcontentasstringsplit,maps trimreturnfiltert includesname hljs fromimportfromimportfromimportfromimportList# ─── ① System Prompt 精简 ────────────────────────────────────────专业客服。准确、友好、诚实、守法。不确定时直接说不知道。# ─── ② 上下文裁剪中间消息用摘要替代 ──────────────────────────asyncdeftrim_messages messages: List[BaseMessage], keep_first: int 2, keep_last: int 6Listiflenreturnifnotreturn# 用 gpt-4o-mini 做摘要100 tokens 替代 3000 tokensgpt-4o-mini100\nf{m.type}: {m.content}forinawaitf用 2-3 句话总结\n{raw}returnf[对话摘要] {summary.content}# ─── ③ 动态工具注入只给 LLM 看它需要的 3 个工具 ────────────────asyncdefselect_relevant_tools query: str, all_tools: List[BaseTool]Listgpt-4o-mini60, forinawaitf问题{query}\n工具{names}\n输出最相关3个工具名逗号分隔forin,returnforinifin三项叠加Token 消耗从 ~8000/次降到 ~1800/次节省约 77%。04 并发优化让工具调用不再「排队等待」这是最容易被忽视但收益最高的优化。很多 Agent 的工具调用是串行的先调 API A等返回再调 API B再等返回。但这些调用往往互相独立完全可以并发。4.1 LangGraph 并行节点 批处理指数退避LangGraph 的图结构天然支持并发节点——两个节点如果没有数据依赖加入同一个分支就能并行执行。同时配合批处理时的指数退避防止 Rate LimitimportStateGraphAnnotationfromlangchain/langgraphimportChatOpenAIfromlangchain/openai// ─── ① LangGraph 并行节点 ─────────────────────────────────────────constAgentStateAnnotationRootqueryAnnotationstringweatherResultAnnotationstringnewsResultAnnotationstringstockResultAnnotationstringfinalAnswerAnnotationstringconstnewStateGraphAgentStateaddNodefetchWeatherasyncweatherResultawaitinvokequeryaddNodefetchNewsasyncnewsResultawaitinvokequeryaddNodefetchStockasyncstockResultawaitinvokequeryaddNodemergeasyncconstnewChatOpenAImodelgpt-4oconstawaitinvoke整合信息天气${state.weatherResult}新闻${state.newsResult}股票${state.stockResult}问题${state.query}returnfinalAnswercontentaddEdge__start__fetchWeatheraddEdge__start__fetchNewsaddEdge__start__fetchStockaddEdgefetchWeathermergeaddEdgefetchNewsmergeaddEdgefetchStockmergeaddEdgemerge__end__// 串行 2100ms → 并行 800ms节省 62%// ─── ② 批处理 指数退避防止 Rate Limit 雪崩 ──────────────────asyncfunctionitemsprocessor(item: T) Promisestring5200Promisestringconstresultsstringconstsleepms: numbernewPromiser setTimeoutasyncfunctionwithRetryfn: () Promisestring, maxRetries 3Promisestringforlet0tryreturnawaitfncatcheanyifstatus4291awaitsleepMathpow21000continuethrowthrownewErrorMax retries exceededforlet0lengthconstslicepushawaitPromiseallmapitem withRetry() processoriflengthawaitsleepreturn// 50 篇文档串行 30s → 批量并发batchSize56s快 5 倍 hljs fromimportfromimportfromimportCallableListimport# ─── ① LangGraph 并行节点 ─────────────────────────────────────────classAgentStateTypedDictstrstrstrstrstrasyncdeffetch_weatherstate: AgentStatedictreturnweather_resultawaitqueryasyncdeffetch_newsstate: AgentStatedictreturnnews_resultawaitqueryasyncdeffetch_stockstate: AgentStatedictreturnstock_resultawaitqueryasyncdefmergestate: AgentStatedictgpt-4oawaitf整合信息天气{state[weather_result]}f新闻{state[news_result]}股票{state[stock_result]}问题{state[query]}returnfinal_answerfetchWeatherfetchNewsfetchStockmerge# 三节点同时从 START 出发自动并行fetchWeatherfetchNewsfetchStockfetchWeathermergefetchNewsmergefetchStockmergemerge# 串行 2100ms → 并行 800ms节省 62%# ─── ② 批处理 指数退避防止 Rate Limit 雪崩 ──────────────────Tasyncdefbatch_process items: List[T], processor: Callable[[T], asyncio.coroutine], batch_size: int 5, delay_ms: int 200Liststrasyncdefwith_retryitem: T, max_retries: int 3strforinrangetryreturnawaitexceptasifhasattrstatus_codeand429and1await2continueraiseraiseMax retries exceededforinrange0lenawaitforiniflenawait1000return# 50 篇文档串行 30s → 批量并发batch_size56s快 5 倍05 三个维度的量化收益对比下面是一个真实生产项目月活 5 万的 AI 客服 Agent实施上述优化前后的数据优化项优化前优化后提升幅度平均响应时间3.2s0.8s含流式首字-75%月 Token 消耗180M tokens52M tokens-71%月 API 费用$2,700$780-71%并发吞吐量12 req/s38 req/s217%缓存命中率0%37%—单独贡献最大的三项流式输出→ 感知延迟 -75%用户体验提升最明显上下文裁剪 System Prompt 精简→ Token -55%成本下降最大并行节点执行→ 吞吐量 200%容量提升最多06 常见坑优化了但没效果或优化出了新问题坑 1缓存 Key 设计不对命中率为 0把时间戳、用户 ID、session_id 混进了 prompt导致每次 prompt 都不一样缓存形同虚设。解法把动态内容从 prompt 中剥离Prompt 模板本身保持稳定。坑 2上下文裁剪太激进LLM「失忆」裁剪到只剩最近 2 轮结果 Agent 忘了用户一开始说的需求答非所问。解法用摘要替代而不是直接删除——中间的消息做成「1 条摘要」而不是「0 条记录」。坑 3并发太猛触发 Rate Limit 雪崩batchSize 设太大同时发 50 个请求直接被 429 限流全部失败重试反而更慢。解法根据账号 RPM 配额调整 batchSize加上指数退避见上方代码。坑 4流式输出后 LangSmith Trace 显示不完整流式 token 分批返回某些 trace 工具默认只记录完整响应会漏掉中间 token。解法在onLLMNewToken回调里额外记录保证 trace 完整。坑 5模型路由分错了复杂任务给了简单模型路由逻辑用「消息长度 50 simple」结果短但复杂的问题如「解释量子纠缠」被分给 mini 模型质量大幅下降。解法加一层 LLM 分类器做意图判断比纯规则准得多。07 业界成熟产品怎么做从 Claude Code、Hermes 源码里看真实选择上面的方案是「教科书答案」但真正的生产代码是怎么实现的我翻了 Claude CodeAnthropic 开源和 Hermes Agent腾讯内部 Agent 框架的源码提炼出三个最有参考价值的真实决策。7.1 Claude Codememoize缓存 Promise.all并发 压缩边界自动 GC延迟优化System Context 用memoize缓存整个会话只算一次// 来源claude-code/src/context.tsimportfromlodash-es/memoize.js// getGitStatus 和 getSystemContext 都用 memoize 包裹// 同一个会话里无论 query() 被调用多少次git status 只 exec 一次exportconstmemoizeasyncPromisestringnull// 内部并行拉 branch / defaultBranch / status / log / userNameconstawaitPromiseallgetBranchgetDefaultBranchexecFileNoThrowgitExestatus--shortexecFileNoThrowgitExelog--oneline-n5execFileNoThrowgitExeconfiguser.name// 超过 2000 字符自动截断附提示「需要更多信息请用 BashTool 跑 git status」constlengthMAX_STATUS_CHARSsubstring0MAX_STATUS_CHARS\n... (truncated)returnjoin\n\n// 关键注入变更时主动清缓存不等 TTL 过期exportfunctionsetSystemPromptInjectionvalue: string | nullvoidcacheclear// ← 精准失效不是全量清空cacheclear hljs # Python 等价实现用 functools.lru_cache / asyncio 版本importimportfromimportOptional# 注意asyncio 版本需要自己实现可清空的 memoizelru_cache 不支持 asyncOptionalstrNoneasyncdefget_git_statusOptionalstrglobalifisnotNonereturnasyncwithifisnotNone# double-checkreturn# 并行拉取所有 git 信息awaitgitstatus--shortgitlog--oneline-n52000\n... (truncated)iflenelsefBranch: {branch}\nStatus:\n{truncated}\nLog:\n{log}returndefinvalidate_git_status_cacheglobalNone# 注入变更时精准失效Token 优化compact_boundary 后立刻 GC 历史消息Claude Code 的QueryEngine.ts里有一段设计很精妙——每次compact_boundary消息到达会立刻把mutableMessages里压缩边界之前的消息全部 splice 掉// 来源claude-code/src/QueryEngine.ts节选ifsubtypecompact_boundary// 压缩边界到达 → 前面的消息已经被摘要可以释放内存constthismutableMessageslength1if0thismutableMessagessplice0// ← 立刻 GC// 同步清空本次 query 的 messages 副本constlength1if0splice0 hljs # Python 等价压缩边界后立刻截断历史classQueryEnginedef__init__selfselflistdefhandle_compact_boundaryself, boundary_idx: int压缩边界到达 → 丢弃边界前的消息立刻释放内存。if0# 只保留 boundary 本身 之后的消息selfself# 注意UI 层REPL保留完整历史用于滚动显示# 只有 headless/SDK 路径才激进 GC——这是个关键设计选择设计洞察Claude Code 的 compact 不是「裁剪 丢弃」而是「摘要 精准 GC」。摘要由 LLM 生成并插入compact_boundary消息GC 在边界到达时立刻触发内存不会无限增长。7.2 Hermes Agent自动上下文压缩 线程安全的 API 调用 decorrelated jitter 退避Hermes 是腾讯内部的长对话 Agent 框架在上下文管理和重试机制上有几个值得借鉴的真实实现。Token 优化独立的ContextCompressor类自动检测并压缩Hermes 把上下文压缩抽成了专门的context_compressor.py核心思路是当 token 使用量接近上下文窗口时自动调用辅助 LLM 生成摘要替换中间对话段。# 来源hermes-agent/agent/context_compressor.py节选已简化classContextCompressor自动上下文压缩检测窗口压力 → 选段 → 摘要替换defshould_compressself, messages: list, model: str, usage: dictbool判断是否需要压缩token 使用率超过阈值时触发input_tokens00.75# 75% 时触发returnasyncdefcompressself, messages: list, aux_clientlist选取中间段落 → 用辅助 LLM 生成摘要 → 替换原消息# 保留头部系统 prompt 前几条和尾部最近 N 条selfselfselfselfifnotreturn# 用便宜的辅助模型压缩不用主模型省钱awaitroleusercontentf总结以下对话历史保留关键决策、代码片段、用户意图\n\nf{m[role]}: {m[content]}forin500roleassistantcontentf[对话摘要] {summary_resp}return hljs // TypeScript 等价classContextCompressorconstructor private keepFirst 2, private keepLast 8, private threshold 0.75, shouldCompresstotalTokensnumbercontextWindownumberbooleanreturnthisthresholdasynccompressmessagesMessageauxLLMChatOpenAIPromiseMessageconstslice0thiskeepFirstconstslicethiskeepLastconstslicethiskeepFirstthiskeepLastiflengthreturnconstawaitinvoke总结以下对话历史保留关键决策、代码片段、用户意图\nmapm ${m._getType()}: ${m.content}join\nreturnnewAIMessage[对话摘要] ${summary.content}并发优化interruptible_api_call— API 调用跑在独立线程主循环保持响应Hermes 的chat_completion_helpers.py里API 调用不在主协程里直接await而是用线程池跑主循环可以在等待期间检测中断信号# 来源hermes-agent/agent/chat_completion_helpers.py节选definterruptible_api_callagent, api_kwargs: dict把 API 调用放到独立线程主循环可以随时打断不用等完整 HTTP 往返。responseNoneerrorNoneclientNone# 线程本地 client中断只关这一个def_calltry# 每个请求线程独立创建 client互不干扰clientchat_completion_requestresponseclientexceptaserrorfinally# 请求完成后立刻关闭 client释放连接池ifclientclientrequest_completeTrue# 主循环以 100ms 间隔轮询保留打断能力while0.1if# 用户按 CtrlC → 关 client → 线程退出ifclientclientbreakreturnresponseerror延迟优化decorrelated jitter 退避比指数退避更快恢复Hermes 的retry_utils.py用的不是普通指数退避而是decorrelated jitter——每次退避时间在[base, prev * 3]之间随机打破多客户端的同步重试风暴# 来源hermes-agent/agent/retry_utils.py节选defjittered_backoffattempt: int, base: float 1.0, cap: float 30.0floatDecorrelated jitter比指数退避更快从 429 风暴中恢复。 AWS 白皮书推荐的算法sleep random(base, prev_sleep * 3) 优于固定指数退避多客户端不会在同一时刻集体重试。 2max10returnmin3# 使用示例asyncdefcall_with_retryfn, max_retries5forinrangetryreturnawaitexceptif1raiseawait hljs // TypeScript 等价functionjitteredBackoffattempt: number, base 1.0, cap 30.0numberconstMathpow2Mathmax10returnMathminMathrandom3asyncfunctionfn() Promise5Promiseforlet0tryreturnawaitfncatcheanyifstatus4291throwawaitnewPromiser setTimeoutjitteredBackoff1000thrownewErrorunreachable7.3 横评业界产品选择对比产品延迟策略Token 策略并发/重试策略Claude Codememoize缓存 System Context注入变更时精准失效compact_boundary到达立刻 GC不等 TTL多 git 命令Promise.all并行compact 后消息自动截断Hermes AgentAPI 调用独立线程主循环 100ms 轮询保留打断能力ContextCompressor75% 阈值自动触发用辅助 LLM 摘要decorrelated jitter 退避防多客户端同步重试风暴Cursor增量同步文件变更只 diff不全量上传代码库动态注入相关代码片段无关文件不进上下文LSP 查询本地并发LLM 调用独立线程不阻塞编辑器CodeBuddy流式输出编辑器内 token 边生成边显示工具调用结果摘要后再喂给 LLM避免大段终端输出撑爆上下文工具执行与 LLM 推理异步解耦下一轮工具可以提前发起规律总结缓存所有产品都在 System Prompt 或上下文注入层做缓存而不是在 LLM 调用层GC摘要后立刻释放原始消息不留「僵尸消息」占内存退避生产级产品普遍用 jitter而不是固定指数退避解耦API 调用和主业务逻辑解耦线程/协程保持主循环响应性总结这篇我们从三个维度系统拆解了 Agent 的性能优化延迟维度流式输出把感知延迟从 3s 压到 200msRedis 缓存让相同问题「零延迟」模型路由让简单任务用便宜快的模型Token 维度System Prompt 精简到最小化上下文裁剪加摘要替代动态工具注入只给 LLM 看它需要的工具并发维度LangGraph 并行节点天然支持批处理打包请求指数退避防止 Rate Limit 雪崩量化效果综合以上优化典型 Agent 延迟降幅 70%Token 费用降幅 60%吞吐量提升 200%学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
