1. 项目缘起当AI应用从玩具走向生产最近在折腾一个AI应用的后端服务核心功能是处理用户提交的文本调用大语言模型LLM来生成回复。最开始这活儿看起来挺简单不就是写个接口收到请求后把用户输入和预设的提示词Prompt拼一拼然后调用某个LLM的API再把结果返回去嘛。我随手写了个handler.ts里面直接硬编码了OpenAI的API Key和模型名称gpt-4测试了一下功能跑得挺欢。但很快现实就给了我当头一棒。当我把这个服务部署上线准备迎接第一批真实用户时问题接踵而至单点故障与成本所有流量都走同一个API Key和同一个模型比如gpt-4。一旦这个Key因为额度用尽、频率限制Rate Limit或者服务商临时故障失效整个服务立刻瘫痪。同时gpt-4虽然效果好但成本高昂并非所有请求都需要如此“奢华”的配置。上下文管理混乱用户希望进行多轮对话我需要维护一个不断增长的对话历史Context。简单地把所有历史消息都塞进下一次请求很快就会触及模型的上下文长度上限比如GPT-4的8K或32K导致最开始的对话内容被“遗忘”或者直接因超长而请求失败。资源利用不均有些用户的问题简单用便宜快速的模型如gpt-3.5-turbo就能很好回答有些则需要gpt-4的深度推理能力。如何根据请求的复杂度动态分配最合适的模型成为一个必须解决的问题。这些问题让我意识到之前那个handler.ts只是一个“玩具”。要构建一个健壮、可用、经济的生产级LLM应用后端必须设计一套更复杂的调度与守护机制。这就是run.ts诞生的背景——它不是一个简单的函数调用而是一个负责模型调度、账号轮询与上下文守护的核心引擎。今天这篇“上篇”我们就来深入拆解这个引擎的设计与实现。2. 核心架构设计从混沌到秩序面对上述问题一个清晰的架构是解决问题的第一步。我们不能在handler.ts里堆砌越来越多的if-else和全局变量。我的设计目标是构建一个可扩展、可观测、易维护的调度中心。最终我抽象出了三个核心模块它们共同构成了run.ts的骨架ModelDispatcher模型调度器它的职责是充当“智能路由”。根据预定义的策略如请求内容复杂度、用户级别、成本控制为每个传入的请求分配合适的LLM提供商如OpenAI、Anthropic、国内某云和具体的模型如gpt-4-turbo,claude-3-sonnet。AccountPool账号池对于同一个模型比如OpenAI的gpt-4我们可能有多个API Key多个账号来分散风险和提高并发上限。账号池负责管理这些Key实现自动轮询、故障转移和负载均衡。当一个Key触发频率限制返回429错误或余额不足时自动切换到下一个可用的Key。ContextKeeper上下文守护者这是对话系统的“记忆管家”。它负责维护和优化与每个用户或会话关联的对话历史。核心任务包括对过长的历史进行智能摘要Summarization、选择性遗忘Token修剪或者采用更高级的“滑动窗口”等策略确保每次请求投喂给模型的上下文都在其能力范围内且保留了最关键的信息。这三个模块并非孤立存在它们在run.ts的主流程中协同工作。一个典型的请求处理流程如下 用户请求进入 -ModelDispatcher根据策略选择模型 -AccountPool为该模型提供一个健康的API Key -ContextKeeper获取或处理该会话的历史上下文 - 组装最终的API请求参数 - 调用LLM API - 处理响应 -ContextKeeper更新对话历史 - 返回结果给用户。接下来我们深入到每个模块的内部看看它们是如何具体实现的。3. ModelDispatcher详解不只是简单的if-else模型调度器ModelDispatcher的核心任务是做出“用哪个模型”的决策。这个决策不能是随机的而应该基于一套可配置、可评估的策略。3.1 策略模式的应用我首先摒弃了硬编码的if-else链采用了策略模式Strategy Pattern。我将不同的调度策略抽象为独立的类它们都实现一个共同的接口例如IDispatchStrategy。interface IDispatchStrategy { selectModel(request: UserRequest, availableModels: ModelConfig[]): PromiseModelConfig; }这样我可以轻松地扩展新的策略。目前我实现了以下几种核心策略基于内容复杂度的策略ComplexityBasedStrategy这是最常用的策略。我会对用户输入的文本进行快速分析例如计算长度、检测是否包含需要复杂推理的关键词如“比较”、“分析”、“推导”、或者使用一个轻量级文本分类模型来打分。根据复杂度分数将其映射到不同的模型梯队。例如简单问答分数0.3用gpt-3.5-turbo中等复杂度0.3分数0.7用claude-3-haiku高复杂度分数0.7用gpt-4-turbo。实操心得这里的“复杂度分析”不必过于复杂和耗时否则会成为性能瓶颈。我最初尝试用BERT做分类延迟太高。后来改用基于规则关键词长度分段和极轻量的模型如text-davinci-003的少量提示词调用或本地运行的TinyBERT在精度和速度间取得了平衡。基于用户等级的策略UserTierStrategy与用户系统结合。付费用户或VIP用户默认使用更高性能的模型免费用户则使用成本更优的模型。这直接与服务商业化相关。成本控制策略CostAwareStrategy设置每日/每月的模型调用预算。该策略会实时查询各模型的累计消耗优先选择成本更低且符合要求的模型当某个模型成本接近预算时自动降级。故障转移策略FallbackStrategy这不是一个独立的主策略而是一个“装饰器”或“后备链”。当主策略选定的模型在AccountPool中所有账号都不可用连续失败时自动按预定义的降级路径选择备用模型。例如gpt-4-turbo-claude-3-sonnet-gpt-3.5-turbo。3.2 配置化与动态更新所有策略和模型梯队哪个分数对应哪个模型的映射关系我都将其配置化放在数据库或像Consul、Etcd这样的配置中心里。这样做的好处是我可以在不停机的情况下动态调整调度策略。比如我发现claude-3-haiku对某种类型的问题效果意外地好我就可以通过修改配置提高它在复杂度策略中的权重立即生效。模型配置ModelConfig的数据结构大致如下interface ModelConfig { provider: openai | anthropic | azure_openai | local; // 提供商 modelName: string; // 如 gpt-4-turbo-preview apiEndpoint?: string; // 对于自托管或Azure需要自定义端点 maxTokens: number; // 模型支持的最大上下文长度 costPer1KInputTokens: number; // 每千输入Token成本 costPer1KOutputTokens: number; // 每千输出Token成本 capabilities: { // 能力标签 reasoning: high | medium | low; speed: high | medium | low; contextLength: long | medium | short; }; isActive: boolean; // 是否启用 }ModelDispatcher在初始化时加载这些配置并根据当前生效的策略进行调度。注意策略的复杂度需要监控。过于复杂的策略可能引入决策延迟和不可预测的Bug。我的经验是从简单策略开始通过A/B测试和日志分析逐步迭代优化。同时一定要为调度决策打上详细的日志包括请求ID、选择的策略、候选模型列表、最终选择模型及理由这是后期排查问题和优化策略的黄金数据。4. AccountPool实战构建高可用的密钥管家账号池AccountPool要解决的是“用什么钥匙开门”的问题。目标是让多个API Key像一组热备的电池一样工作一个没电了自动切到下一个。4.1 数据结构与健康检查我为每个API KeyApiAccount维护了一个状态对象interface ApiAccount { id: string; apiKey: string; provider: string; model: string; // 这个Key绑定的模型一个Key可能只用于特定模型 priority: number; // 优先级用于负载均衡 quotaTotal?: number; // 总配额 quotaUsed?: number; // 已使用量 lastUsed: Date; // 最后使用时间 lastError?: { // 最后一次错误信息 code: number; // 如429 500 message: string; timestamp: Date; }; consecutiveFailures: number; // 连续失败次数 isActive: boolean; // 是否活跃手动或自动禁用 coolDownUntil?: Date; // 冷却截止时间触发频率限制后 }核心在于健康状态的维护。我定义了几个关键规则失败熔断当一个Key连续失败次数consecutiveFailures超过阈值如5次且错误码是4xx或5xx非临时的网络抖动则自动将其isActive设为false并发出告警。频率限制冷却当收到明确的429Too Many Requests错误时除了记录失败还会解析响应头如Retry-After或根据经验值如默认冷却5分钟设置coolDownUntil时间。在冷却期间该Key不会被选用。定期唤醒对于被熔断或冷却的Key会有一个后台任务定期比如每10分钟进行“探活”。方法是使用该Key发送一个非常简单的、低成本的API请求例如向OpenAI发一个只包含“ping”的ChatCompletion请求。如果成功则重置其失败计数和冷却状态重新激活。4.2 轮询算法不仅仅是Round Robin最简单的轮询是依次使用Round Robin。但这不够智能。我实现了一个加权的轮询算法综合考虑了优先级priority手动配置给更稳定、额度更高的Key更高优先级。使用频率倾向于使用最近使用次数较少的Key实现更均匀的负载。剩余额度如果能从API提供商处查询到额度部分提供商支持则优先使用剩余额度比例高的Key。回避刚失败过的Key即使一个Key刚从冷却中恢复也会暂时降低其权重观察一段时间。算法的大致逻辑是从所有isActive且不在冷却期的Key中根据上述因素计算一个动态权重然后按权重概率进行选择。这比简单的轮询能更好地应对不同Key的不同状态。4.3 与ModelDispatcher的对接AccountPool是ModelDispatcher的下游。调度器决定了用gpt-4模型后会向AccountPool请求“给我一个健康的、用于gpt-4的OpenAI API Key”。AccountPool则在其管理的、绑定到openai提供商和gpt-4模型的账号列表中运行上述加权算法选出一个返回。如果AccountPool发现某个模型的所有Key都不可用全部熔断或冷却它会立即向上游ModelDispatcher或run.ts主流程抛出一个明确的错误如AllAccountsUnavailableError。这触发了整体的故障转移流程ModelDispatcher可以据此执行降级策略FallbackStrategy换用其他模型。踩坑记录初期我把所有Key都放在一个池子里通过model字段区分。但在高并发下为每个请求筛选特定模型的Key带来了额外的性能开销。后来我改为按provider_model如openai_gpt-4为维度建立子池SubPool每个子池管理自己的一批Key选择算法在子池内运行性能提升显著。同时务必做好密钥的加密存储绝不能明文写在代码或配置文件中推荐使用Vault或云服务商的密钥管理服务。5. ContextKeeper设计与遗忘对抗的艺术上下文守护者是保证对话连贯性的核心也是最容易出性能问题和逻辑Bug的地方。它的核心挑战是如何在有限的模型上下文窗口Token数内保留对话中最有价值的信息。5.1 上下文存储与索引首先需要决定对话历史存在哪里。对于简单的、用户量不大的场景可以存在服务器的内存或Redis中以sessionId为Key。但对于生产环境考虑到持久化、扩展性和可靠性我选择了数据库如PostgreSQL或MongoDB。每条消息Message的结构如下interface Message { id: string; // 消息ID sessionId: string; // 会话ID role: user | assistant | system; content: string; // 消息内容 tokens: number; // 该条消息的Token数估算或实际值 createdAt: Date; // 可选用于高级修剪策略 importanceScore?: number; // 重要性分数 isSummary: boolean; // 是否为摘要消息 }每次用户发起新请求ContextKeeper需要做的是取出该sessionId下的所有历史消息经过处理组装成LLM API要求的格式如OpenAI的messages数组。5.2 上下文窗口优化策略直接取出所有历史消息计算总Token数如果超过模型上限如gpt-4-32k的32768就需要进行裁剪。我实现了以下几种策略可以单独或组合使用简单截断Truncation这是最粗暴但最有效的方法。直接从最旧的消息开始丢弃直到总Token数低于上限。但这会直接丢失早期的对话信息可能导致AI“失忆”。仅作为最后兜底方案。滑动窗口Sliding Window只保留最近N条消息或最近N个Token的消息。这符合大多数对话“近期内容更重要”的直觉。实现简单效果尚可。N的值需要根据模型上下文长度和平均对话长度来调优。关键信息提取/摘要Summarization这是更智能的方法。当历史消息过长时调用LLM本身通常用一个更便宜、快速的模型对超出窗口的部分或整个早期历史进行摘要生成一段浓缩的“背景摘要”。然后将这段摘要作为一条system或user消息放在上下文的最前面替代原来的详细历史。具体实现我会设置一个阈值比如当历史Token数超过最大限制的70%时触发摘要流程。摘要的目标是压缩到原有Token数的20%-30%。摘要提示词Prompt需要精心设计要求模型保留事实、用户意图和决策逻辑。示例Prompt“你是一个对话摘要助手。请将以下对话历史压缩成一段简洁的摘要保留用户的核心问题、已做出的关键决定和重要事实。摘要语言需简洁、客观。对话历史[...]”注意摘要本身也有成本和时间开销需要权衡。我通常会异步执行摘要操作不影响本次请求的响应速度。本次请求可能仍使用滑动窗口而摘要结果用于后续的对话。基于重要性的动态修剪Dynamic Pruning这是一种更前沿的思路。为每条历史消息计算一个“重要性分数”。分数可以基于规则例如包含用户明确指令的消息分数高AI的简单确认消息分数低或者用一个小型神经网络来预测。在需要修剪时优先丢弃分数低的消息。实现复杂度高但理论上效果最好。在我的run.ts第一版实现中我采用了滑动窗口为主摘要为辅的混合策略。我为每个会话维护两个版本的历史rawMessages原始消息和summarySoFar当前累计摘要。每次组装请求上下文时逻辑如下// 伪代码 function assembleContext(sessionId, newUserMessage) { const maxTokens 模型上限 * 0.9; // 留10%余量给本次交互和回复 let finalContext []; // 1. 加入系统提示词如果有 finalContext.push(systemPrompt); let usedTokens systemPrompt.tokens; // 2. 加入累计摘要如果存在 if (summarySoFar) { finalContext.push({role: system, content: 背景摘要${summarySoFar}}); usedTokens summarySoFar.tokens; } // 3. 从原始消息中从新到旧选取直到用完Token预算 const recentRawMessages getRecentMessages(sessionId, maxTokens - usedTokens); finalContext.push(...recentRawMessages); usedTokens recentRawMessages的总tokens; // 4. 加入新的用户消息 finalContext.push(newUserMessage); usedTokens newUserMessage.tokens; // 5. 检查是否需要触发新一轮摘要 if (usedTokens maxTokens * 0.7) { // 如果用了70%以上 triggerAsyncSummarization(sessionId); // 异步触发更新summarySoFar } return finalContext; }5.3 Token计数与性能准确的Token计数是这一切的基础。不同模型的Token化方式不同如GPT系列使用cl100k_baseClaude使用不同的分词器。我最初使用OpenAI官方tiktoken库的Node.js版本来计算但这带来了额外的计算开销和依赖。性能优化点对于非OpenAI的模型或者对绝对精确度要求不高的场景可以采用估算方式。一个常见的经验法则是英文文本1个Token约等于0.75个单词或4个字符中文文本1个Token约等于1.5到2个汉字。我实现了一个轻量的估算函数速度比调用tiktoken快一个数量级在大多数情况下误差在可接受范围内±5%。对于成本核算等需要精确计数的场景则记录下API响应中返回的准确usage数据用于校准和计费。重要提醒上下文管理是状态管理必须处理好并发问题。如果同一个sessionId的两个请求几乎同时到达都去读取-修改-保存上下文就会发生竞态条件Race Condition导致消息丢失或错乱。我的解决方案是使用数据库的乐观锁通过版本号version字段或者使用分布式锁如基于Redis的Redlock确保对同一个会话上下文的操作是串行的。 生产级LLM应用后端架构：模型调度、账号池与上下文守护实战
1. 项目缘起当AI应用从玩具走向生产最近在折腾一个AI应用的后端服务核心功能是处理用户提交的文本调用大语言模型LLM来生成回复。最开始这活儿看起来挺简单不就是写个接口收到请求后把用户输入和预设的提示词Prompt拼一拼然后调用某个LLM的API再把结果返回去嘛。我随手写了个handler.ts里面直接硬编码了OpenAI的API Key和模型名称gpt-4测试了一下功能跑得挺欢。但很快现实就给了我当头一棒。当我把这个服务部署上线准备迎接第一批真实用户时问题接踵而至单点故障与成本所有流量都走同一个API Key和同一个模型比如gpt-4。一旦这个Key因为额度用尽、频率限制Rate Limit或者服务商临时故障失效整个服务立刻瘫痪。同时gpt-4虽然效果好但成本高昂并非所有请求都需要如此“奢华”的配置。上下文管理混乱用户希望进行多轮对话我需要维护一个不断增长的对话历史Context。简单地把所有历史消息都塞进下一次请求很快就会触及模型的上下文长度上限比如GPT-4的8K或32K导致最开始的对话内容被“遗忘”或者直接因超长而请求失败。资源利用不均有些用户的问题简单用便宜快速的模型如gpt-3.5-turbo就能很好回答有些则需要gpt-4的深度推理能力。如何根据请求的复杂度动态分配最合适的模型成为一个必须解决的问题。这些问题让我意识到之前那个handler.ts只是一个“玩具”。要构建一个健壮、可用、经济的生产级LLM应用后端必须设计一套更复杂的调度与守护机制。这就是run.ts诞生的背景——它不是一个简单的函数调用而是一个负责模型调度、账号轮询与上下文守护的核心引擎。今天这篇“上篇”我们就来深入拆解这个引擎的设计与实现。2. 核心架构设计从混沌到秩序面对上述问题一个清晰的架构是解决问题的第一步。我们不能在handler.ts里堆砌越来越多的if-else和全局变量。我的设计目标是构建一个可扩展、可观测、易维护的调度中心。最终我抽象出了三个核心模块它们共同构成了run.ts的骨架ModelDispatcher模型调度器它的职责是充当“智能路由”。根据预定义的策略如请求内容复杂度、用户级别、成本控制为每个传入的请求分配合适的LLM提供商如OpenAI、Anthropic、国内某云和具体的模型如gpt-4-turbo,claude-3-sonnet。AccountPool账号池对于同一个模型比如OpenAI的gpt-4我们可能有多个API Key多个账号来分散风险和提高并发上限。账号池负责管理这些Key实现自动轮询、故障转移和负载均衡。当一个Key触发频率限制返回429错误或余额不足时自动切换到下一个可用的Key。ContextKeeper上下文守护者这是对话系统的“记忆管家”。它负责维护和优化与每个用户或会话关联的对话历史。核心任务包括对过长的历史进行智能摘要Summarization、选择性遗忘Token修剪或者采用更高级的“滑动窗口”等策略确保每次请求投喂给模型的上下文都在其能力范围内且保留了最关键的信息。这三个模块并非孤立存在它们在run.ts的主流程中协同工作。一个典型的请求处理流程如下 用户请求进入 -ModelDispatcher根据策略选择模型 -AccountPool为该模型提供一个健康的API Key -ContextKeeper获取或处理该会话的历史上下文 - 组装最终的API请求参数 - 调用LLM API - 处理响应 -ContextKeeper更新对话历史 - 返回结果给用户。接下来我们深入到每个模块的内部看看它们是如何具体实现的。3. ModelDispatcher详解不只是简单的if-else模型调度器ModelDispatcher的核心任务是做出“用哪个模型”的决策。这个决策不能是随机的而应该基于一套可配置、可评估的策略。3.1 策略模式的应用我首先摒弃了硬编码的if-else链采用了策略模式Strategy Pattern。我将不同的调度策略抽象为独立的类它们都实现一个共同的接口例如IDispatchStrategy。interface IDispatchStrategy { selectModel(request: UserRequest, availableModels: ModelConfig[]): PromiseModelConfig; }这样我可以轻松地扩展新的策略。目前我实现了以下几种核心策略基于内容复杂度的策略ComplexityBasedStrategy这是最常用的策略。我会对用户输入的文本进行快速分析例如计算长度、检测是否包含需要复杂推理的关键词如“比较”、“分析”、“推导”、或者使用一个轻量级文本分类模型来打分。根据复杂度分数将其映射到不同的模型梯队。例如简单问答分数0.3用gpt-3.5-turbo中等复杂度0.3分数0.7用claude-3-haiku高复杂度分数0.7用gpt-4-turbo。实操心得这里的“复杂度分析”不必过于复杂和耗时否则会成为性能瓶颈。我最初尝试用BERT做分类延迟太高。后来改用基于规则关键词长度分段和极轻量的模型如text-davinci-003的少量提示词调用或本地运行的TinyBERT在精度和速度间取得了平衡。基于用户等级的策略UserTierStrategy与用户系统结合。付费用户或VIP用户默认使用更高性能的模型免费用户则使用成本更优的模型。这直接与服务商业化相关。成本控制策略CostAwareStrategy设置每日/每月的模型调用预算。该策略会实时查询各模型的累计消耗优先选择成本更低且符合要求的模型当某个模型成本接近预算时自动降级。故障转移策略FallbackStrategy这不是一个独立的主策略而是一个“装饰器”或“后备链”。当主策略选定的模型在AccountPool中所有账号都不可用连续失败时自动按预定义的降级路径选择备用模型。例如gpt-4-turbo-claude-3-sonnet-gpt-3.5-turbo。3.2 配置化与动态更新所有策略和模型梯队哪个分数对应哪个模型的映射关系我都将其配置化放在数据库或像Consul、Etcd这样的配置中心里。这样做的好处是我可以在不停机的情况下动态调整调度策略。比如我发现claude-3-haiku对某种类型的问题效果意外地好我就可以通过修改配置提高它在复杂度策略中的权重立即生效。模型配置ModelConfig的数据结构大致如下interface ModelConfig { provider: openai | anthropic | azure_openai | local; // 提供商 modelName: string; // 如 gpt-4-turbo-preview apiEndpoint?: string; // 对于自托管或Azure需要自定义端点 maxTokens: number; // 模型支持的最大上下文长度 costPer1KInputTokens: number; // 每千输入Token成本 costPer1KOutputTokens: number; // 每千输出Token成本 capabilities: { // 能力标签 reasoning: high | medium | low; speed: high | medium | low; contextLength: long | medium | short; }; isActive: boolean; // 是否启用 }ModelDispatcher在初始化时加载这些配置并根据当前生效的策略进行调度。注意策略的复杂度需要监控。过于复杂的策略可能引入决策延迟和不可预测的Bug。我的经验是从简单策略开始通过A/B测试和日志分析逐步迭代优化。同时一定要为调度决策打上详细的日志包括请求ID、选择的策略、候选模型列表、最终选择模型及理由这是后期排查问题和优化策略的黄金数据。4. AccountPool实战构建高可用的密钥管家账号池AccountPool要解决的是“用什么钥匙开门”的问题。目标是让多个API Key像一组热备的电池一样工作一个没电了自动切到下一个。4.1 数据结构与健康检查我为每个API KeyApiAccount维护了一个状态对象interface ApiAccount { id: string; apiKey: string; provider: string; model: string; // 这个Key绑定的模型一个Key可能只用于特定模型 priority: number; // 优先级用于负载均衡 quotaTotal?: number; // 总配额 quotaUsed?: number; // 已使用量 lastUsed: Date; // 最后使用时间 lastError?: { // 最后一次错误信息 code: number; // 如429 500 message: string; timestamp: Date; }; consecutiveFailures: number; // 连续失败次数 isActive: boolean; // 是否活跃手动或自动禁用 coolDownUntil?: Date; // 冷却截止时间触发频率限制后 }核心在于健康状态的维护。我定义了几个关键规则失败熔断当一个Key连续失败次数consecutiveFailures超过阈值如5次且错误码是4xx或5xx非临时的网络抖动则自动将其isActive设为false并发出告警。频率限制冷却当收到明确的429Too Many Requests错误时除了记录失败还会解析响应头如Retry-After或根据经验值如默认冷却5分钟设置coolDownUntil时间。在冷却期间该Key不会被选用。定期唤醒对于被熔断或冷却的Key会有一个后台任务定期比如每10分钟进行“探活”。方法是使用该Key发送一个非常简单的、低成本的API请求例如向OpenAI发一个只包含“ping”的ChatCompletion请求。如果成功则重置其失败计数和冷却状态重新激活。4.2 轮询算法不仅仅是Round Robin最简单的轮询是依次使用Round Robin。但这不够智能。我实现了一个加权的轮询算法综合考虑了优先级priority手动配置给更稳定、额度更高的Key更高优先级。使用频率倾向于使用最近使用次数较少的Key实现更均匀的负载。剩余额度如果能从API提供商处查询到额度部分提供商支持则优先使用剩余额度比例高的Key。回避刚失败过的Key即使一个Key刚从冷却中恢复也会暂时降低其权重观察一段时间。算法的大致逻辑是从所有isActive且不在冷却期的Key中根据上述因素计算一个动态权重然后按权重概率进行选择。这比简单的轮询能更好地应对不同Key的不同状态。4.3 与ModelDispatcher的对接AccountPool是ModelDispatcher的下游。调度器决定了用gpt-4模型后会向AccountPool请求“给我一个健康的、用于gpt-4的OpenAI API Key”。AccountPool则在其管理的、绑定到openai提供商和gpt-4模型的账号列表中运行上述加权算法选出一个返回。如果AccountPool发现某个模型的所有Key都不可用全部熔断或冷却它会立即向上游ModelDispatcher或run.ts主流程抛出一个明确的错误如AllAccountsUnavailableError。这触发了整体的故障转移流程ModelDispatcher可以据此执行降级策略FallbackStrategy换用其他模型。踩坑记录初期我把所有Key都放在一个池子里通过model字段区分。但在高并发下为每个请求筛选特定模型的Key带来了额外的性能开销。后来我改为按provider_model如openai_gpt-4为维度建立子池SubPool每个子池管理自己的一批Key选择算法在子池内运行性能提升显著。同时务必做好密钥的加密存储绝不能明文写在代码或配置文件中推荐使用Vault或云服务商的密钥管理服务。5. ContextKeeper设计与遗忘对抗的艺术上下文守护者是保证对话连贯性的核心也是最容易出性能问题和逻辑Bug的地方。它的核心挑战是如何在有限的模型上下文窗口Token数内保留对话中最有价值的信息。5.1 上下文存储与索引首先需要决定对话历史存在哪里。对于简单的、用户量不大的场景可以存在服务器的内存或Redis中以sessionId为Key。但对于生产环境考虑到持久化、扩展性和可靠性我选择了数据库如PostgreSQL或MongoDB。每条消息Message的结构如下interface Message { id: string; // 消息ID sessionId: string; // 会话ID role: user | assistant | system; content: string; // 消息内容 tokens: number; // 该条消息的Token数估算或实际值 createdAt: Date; // 可选用于高级修剪策略 importanceScore?: number; // 重要性分数 isSummary: boolean; // 是否为摘要消息 }每次用户发起新请求ContextKeeper需要做的是取出该sessionId下的所有历史消息经过处理组装成LLM API要求的格式如OpenAI的messages数组。5.2 上下文窗口优化策略直接取出所有历史消息计算总Token数如果超过模型上限如gpt-4-32k的32768就需要进行裁剪。我实现了以下几种策略可以单独或组合使用简单截断Truncation这是最粗暴但最有效的方法。直接从最旧的消息开始丢弃直到总Token数低于上限。但这会直接丢失早期的对话信息可能导致AI“失忆”。仅作为最后兜底方案。滑动窗口Sliding Window只保留最近N条消息或最近N个Token的消息。这符合大多数对话“近期内容更重要”的直觉。实现简单效果尚可。N的值需要根据模型上下文长度和平均对话长度来调优。关键信息提取/摘要Summarization这是更智能的方法。当历史消息过长时调用LLM本身通常用一个更便宜、快速的模型对超出窗口的部分或整个早期历史进行摘要生成一段浓缩的“背景摘要”。然后将这段摘要作为一条system或user消息放在上下文的最前面替代原来的详细历史。具体实现我会设置一个阈值比如当历史Token数超过最大限制的70%时触发摘要流程。摘要的目标是压缩到原有Token数的20%-30%。摘要提示词Prompt需要精心设计要求模型保留事实、用户意图和决策逻辑。示例Prompt“你是一个对话摘要助手。请将以下对话历史压缩成一段简洁的摘要保留用户的核心问题、已做出的关键决定和重要事实。摘要语言需简洁、客观。对话历史[...]”注意摘要本身也有成本和时间开销需要权衡。我通常会异步执行摘要操作不影响本次请求的响应速度。本次请求可能仍使用滑动窗口而摘要结果用于后续的对话。基于重要性的动态修剪Dynamic Pruning这是一种更前沿的思路。为每条历史消息计算一个“重要性分数”。分数可以基于规则例如包含用户明确指令的消息分数高AI的简单确认消息分数低或者用一个小型神经网络来预测。在需要修剪时优先丢弃分数低的消息。实现复杂度高但理论上效果最好。在我的run.ts第一版实现中我采用了滑动窗口为主摘要为辅的混合策略。我为每个会话维护两个版本的历史rawMessages原始消息和summarySoFar当前累计摘要。每次组装请求上下文时逻辑如下// 伪代码 function assembleContext(sessionId, newUserMessage) { const maxTokens 模型上限 * 0.9; // 留10%余量给本次交互和回复 let finalContext []; // 1. 加入系统提示词如果有 finalContext.push(systemPrompt); let usedTokens systemPrompt.tokens; // 2. 加入累计摘要如果存在 if (summarySoFar) { finalContext.push({role: system, content: 背景摘要${summarySoFar}}); usedTokens summarySoFar.tokens; } // 3. 从原始消息中从新到旧选取直到用完Token预算 const recentRawMessages getRecentMessages(sessionId, maxTokens - usedTokens); finalContext.push(...recentRawMessages); usedTokens recentRawMessages的总tokens; // 4. 加入新的用户消息 finalContext.push(newUserMessage); usedTokens newUserMessage.tokens; // 5. 检查是否需要触发新一轮摘要 if (usedTokens maxTokens * 0.7) { // 如果用了70%以上 triggerAsyncSummarization(sessionId); // 异步触发更新summarySoFar } return finalContext; }5.3 Token计数与性能准确的Token计数是这一切的基础。不同模型的Token化方式不同如GPT系列使用cl100k_baseClaude使用不同的分词器。我最初使用OpenAI官方tiktoken库的Node.js版本来计算但这带来了额外的计算开销和依赖。性能优化点对于非OpenAI的模型或者对绝对精确度要求不高的场景可以采用估算方式。一个常见的经验法则是英文文本1个Token约等于0.75个单词或4个字符中文文本1个Token约等于1.5到2个汉字。我实现了一个轻量的估算函数速度比调用tiktoken快一个数量级在大多数情况下误差在可接受范围内±5%。对于成本核算等需要精确计数的场景则记录下API响应中返回的准确usage数据用于校准和计费。重要提醒上下文管理是状态管理必须处理好并发问题。如果同一个sessionId的两个请求几乎同时到达都去读取-修改-保存上下文就会发生竞态条件Race Condition导致消息丢失或错乱。我的解决方案是使用数据库的乐观锁通过版本号version字段或者使用分布式锁如基于Redis的Redlock确保对同一个会话上下文的操作是串行的。