AI 应用的状态管理：比 Redux 复杂 10 倍的挑战

AI 应用的状态管理比 Redux 复杂 10 倍的挑战本文是【高级前端的 AI 架构升级之路】系列第 04 篇。上一篇AI 网关层设计多模型路由、降级、限流、成本控制 | 下一篇AI Streaming 架构从浏览器到服务端的全链路流式设计为什么 AI 状态管理特别难你做过前端状态管理——Redux、Pinia、Zustand、Jotai、TanStack Query……工具链已经很成熟了。但到了 AI 应用场景你会发现这些方案应对不了新的挑战。传统前端状态管理假设请求是短暂的发出去几百毫秒就回来了响应是完整的要么成功拿到数据要么失败报错状态是确定的相同操作产生相同结果更新是离散的每次 setState 是一个明确的时间点AI 场景全部打破请求是长时间的一次流式请求可能持续 10-30 秒响应是增量的一个字一个字到达状态在持续变化状态是不确定的AI 可能回答到一半改变方向更新是连续的每秒可能触发几十次状态更新这篇文章帮你从架构层面设计一套适合 AI 应用的状态管理方案。AI 应用的状态全景一个典型的 AI 聊天应用需要管理的状态远比你想象的多interfaceAIAppState{// 对话层sessions:ChatSession[];activeSessionId:string;// 消息层messages:Message[];streamingMessage:StreamingMessage|null;// 正在生成的消息// 请求层isStreaming:boolean;abortController:AbortController|null;streamProgress:{tokensGenerated:number;estimatedTotal:number;elapsedMs:number;};// 上下文层contextWindow:Message[];// 实际发给 AI 的消息经过裁剪contextTokenCount:number;// 当前上下文 Token 数// UI 层inputDraft:string;isComposing:boolean;// 输入法组合中scrollPosition:number;showThinking:boolean;// 是否展示 AI 思考过程// 错误层lastError:AIError|null;retryCount:number;fallbackProvider:string|null;}这还只是单聊天窗口。如果涉及多 Agent、RAG、Tool Calling状态会再翻几倍。挑战一流式消息的状态更新流式输出意味着一条 AI 消息的 content 在 5-30 秒内持续增长。如果你用最朴素的方式处理// 每收到一个 token 就更新整个 messages 数组——性能灾难setMessages(prev{constupdated[...prev];updated[updated.length-1].contentnewToken;returnupdated;});问题每秒触发 20-50 次状态更新每次都创建新数组、触发 diff、重渲染整个消息列表。解决方案分离流式状态把正在流式生成的消息从消息列表中分离出来用独立状态管理// 方案流式消息独立管理interfaceChatStore{messages:Message[];// 已完成的消息streamingContent:string;// 正在流式生成的文本streamingRole:assistant|null;}// 流式进行中只更新 streamingContent轻量functiononStreamToken(token:string){store.streamingContenttoken;// 不触发 messages 数组的更新}// 流式结束一次性写入 messagesfunctiononStreamEnd(){store.messages.push({role:store.streamingRole,content:store.streamingContent,});store.streamingContent;store.streamingRolenull;}渲染时把两者合并function MessageList() { const messages useStore(s s.messages); const streamingContent useStore(s s.streamingContent); return ( {messages.map(msg MessageBubble key{msg.id} message{msg} /)} {streamingContent ( StreamingBubble content{streamingContent} / )} / ); }StreamingBubble组件可以用refrequestAnimationFrame来更新 DOM完全绕过 React 的状态管理和 diff 机制实现极致性能function StreamingBubble({ content }: { content: string }) { const ref useRefHTMLDivElement(null); const prevLength useRef(0); useEffect(() { if (!ref.current) return; // 只追加新内容不重新渲染整个文本 const newContent content.slice(prevLength.current); if (newContent) { ref.current.textContent newContent; prevLength.current content.length; } }, [content]); return div ref{ref} classNamemessage assistant /; }挑战二对话上下文管理AI 没有记忆每次请求都需要把对话历史带上。但历史太长会超出模型的上下文窗口也会导致成本暴涨。上下文窗口策略interfaceContextStrategy{maxTokens:number;// 上下文窗口上限reserveForResponse:number;// 给回复预留的 tokenmethod:sliding-window|summary|hybrid;}constSTRATEGIES:Recordstring,ContextStrategy{deepseek-chat:{maxTokens:64000,reserveForResponse:4000,method:sliding-window,},gpt-4o:{maxTokens:128000,reserveForResponse:4096,method:hybrid,},gpt-4o-mini:{maxTokens:128000,reserveForResponse:16384,method:sliding-window,},};滑动窗口实现最简单实用的策略——保留最近的消息超出时丢弃最旧的functionbuildContextWindow(messages:Message[],systemPrompt:string,strategy:ContextStrategy,):Message[]{constmaxAvailablestrategy.maxTokens-strategy.reserveForResponse;lettokenCountestimateTokens(systemPrompt);constcontext:Message[][];// 从最新的消息往前遍历for(letimessages.length-1;i0;i--){constmsgTokensestimateTokens(messages[i].content);if(tokenCountmsgTokensmaxAvailable)break;tokenCountmsgTokens;context.unshift(messages[i]);}return[{role:system,content:systemPrompt},...context];}functionestimateTokens(text:string):number{// 粗略估算中文 1 字 ≈ 2 tokens英文 1 词 ≈ 1.3 tokensconstchineseChars(text.match(/[\u4e00-\u9fff]/g)||[]).length;constotherCharstext.length-chineseChars;returnMath.ceil(chineseChars*2otherChars*0.4);}摘要压缩策略当对话特别长时可以用 AI 本身来压缩历史asyncfunctioncompressHistory(messages:Message[],keepRecent:number4,):PromiseMessage[]{if(messages.lengthkeepRecent2)returnmessages;consttoCompressmessages.slice(0,-keepRecent);constrecentmessages.slice(-keepRecent);constsummaryawaitcallAI({provider:deepseek,// 用便宜模型来做摘要messages:[{role:system,content:将以下对话历史压缩为一段简洁的摘要保留关键信息和结论。用第三人称描述。不超过 300 字。,},{role:user,content:toCompress.map(m${m.role}:${m.content}).join(\n\n),},],});return[{role:system,content:[对话历史摘要]${summary}},...recent,];}状态中的上下文管理interfaceContextState{fullHistory:Message[];// 完整历史持久化存储contextWindow:Message[];// 实际发给 AI 的裁剪后的tokenCount:number;compressed:boolean;// 是否已经过压缩compressionRatio:number;// 压缩比}前端需要展示上下文状态——让用户知道 AI 能看到多少历史function ContextIndicator({ state }: { state: ContextState }) { const percentage (state.tokenCount / maxTokens) * 100; return ( div classNamecontext-bar div classNameprogress style{{ width: ${percentage}% }} / span 上下文 {state.contextWindow.length}/{state.fullHistory.length} 条消息 {state.compressed (已压缩)} /span /div ); }挑战三分支对话用户在多轮对话中可能想回到第 3 轮重新问。这就产生了对话分支——和 Git 的分支概念很像。数据结构interfaceMessageNode{id:string;parentId:string|null;role:user|assistant|system;content:string;children:string[];// 子节点 ID 列表activeChild:string|null;// 当前选中的子节点timestamp:number;}interfaceBranchState{nodes:Mapstring,MessageNode;rootId:string;activeLeafId:string;// 当前对话路径的最末节点}获取当前活跃的对话路径functiongetActivePath(state:BranchState):MessageNode[]{constpath:MessageNode[][];letcurrentstate.nodes.get(state.rootId);while(current){path.push(current);if(!current.activeChild)break;currentstate.nodes.get(current.activeChild);}returnpath;}从某个节点创建分支functioncreateBranch(state:BranchState,parentId:string,newMessage:{role:string;content:string},):BranchState{constnewNode:MessageNode{id:generateId(),parentId,role:newMessage.role,content:newMessage.content,children:[],activeChild:null,timestamp:Date.now(),};constparentstate.nodes.get(parentId);parent.children.push(newNode.id);parent.activeChildnewNode.id;state.nodes.set(newNode.id,newNode);state.activeLeafIdnewNode.id;returnstate;}前端需要提供切换分支的 UI——类似 ChatGPT 的 1/3 箭头切换function BranchSwitcher({ node }: { node: MessageNode }) { const parent useNode(node.parentId); if (!parent || parent.children.length 1) return null; const currentIndex parent.children.indexOf(node.id); const total parent.children.length; return ( div classNamebranch-switcher button onClick{() switchBranch(parent.id, currentIndex - 1)} disabled{currentIndex 0}‹/button span{currentIndex 1}/{total}/span button onClick{() switchBranch(parent.id, currentIndex 1)} disabled{currentIndex total - 1}›/button /div ); }挑战四多 Agent 协作状态当你的系统有多个 AI Agent 同时工作比如一个负责搜索、一个负责分析、一个负责总结状态管理又上了一个台阶。interfaceAgentState{id:string;name:string;status:idle|thinking|executing|done|error;currentTask:string;progress:number;// 0-100output:string;dependencies:string[];// 依赖的其他 Agent IDstartTime:number;elapsedMs:number;}interfaceMultiAgentState{agents:Mapstring,AgentState;orchestrationMode:sequential|parallel|router;overallProgress:number;finalOutput:string|null;}并行 Agent 的状态同步functionupdateAgentProgress(state:MultiAgentState,agentId:string,update:PartialAgentState,):MultiAgentState{constagentstate.agents.get(agentId);if(!agent)returnstate;Object.assign(agent,update,{elapsedMs:Date.now()-agent.startTime});// 重新计算整体进度constagentsArray.from(state.agents.values());state.overallProgressagents.reduce((sum,a)suma.progress,0)/agents.length;// 检查是否所有 Agent 都完成了constallDoneagents.every(aa.statusdone||a.statuserror);if(allDone){state.finalOutputaggregateOutputs(agents);}return{...state};}前端需要可视化展示多 Agent 的工作状态function AgentPanel({ agents }: { agents: AgentState[] }) { return ( div classNameagent-panel {agents.map(agent ( div key{agent.id} className{agent-card ${agent.status}} div classNameagent-name{agent.name}/div div classNameagent-task{agent.currentTask}/div div classNameprogress-bar div style{{ width: ${agent.progress}% }} / /div div classNameagent-status {agent.status thinking 思考中...} {agent.status executing ⚡ 执行中 ${agent.progress}%} {agent.status done ✅ 完成} {agent.status error ❌ 出错} /div /div ))} /div ); }挑战五乐观更新 AI 回滚某些场景下用户操作先展示结果AI 在后台校验。如果 AI 发现问题需要回滚。典型场景AI 辅助表单填写。用户选了一个选项 → 前端立即更新 → AI 后台检查合理性 → 不合理则回滚并提示。interfaceOptimisticStateT{confirmed:T;// AI 确认后的值optimistic:T;// 乐观更新的值展示给用户的pending:boolean;// 是否在等 AI 确认rollbackReason:string|null;}functionapplyOptimisticT(state:OptimisticStateT,newValue:T,):OptimisticStateT{return{confirmed:state.confirmed,optimistic:newValue,pending:true,rollbackReason:null,};}functionconfirmOptimisticT(state:OptimisticStateT):OptimisticStateT{return{confirmed:state.optimistic,optimistic:state.optimistic,pending:false,rollbackReason:null,};}functionrollbackOptimisticT(state:OptimisticStateT,reason:string,):OptimisticStateT{return{confirmed:state.confirmed,optimistic:state.confirmed,// 回滚到上次确认的值pending:false,rollbackReason:reason,};}与 TanStack Query 的结合TanStack QueryReact Query本身不是为 AI 设计的但它的一些理念可以适配import{useQuery,useMutation}fromtanstack/react-query;functionuseChatMutation(){returnuseMutation({mutationFn:async(messages:Message[]){// 流式调用不适合直接用 mutation因为它期望一次性返回结果// 但非流式场景可以用returnawaitcallAI({messages});},onMutate:(messages){// 乐观更新立刻在列表里加一条空的 assistant 消息},retry:2,retryDelay:(attempt)Math.min(1000*2**attempt,10000),});}// 会话列表适合用 QueryfunctionuseSessions(){returnuseQuery({queryKey:[chat-sessions],queryFn:()fetchSessions(),staleTime:30_000,});}核心认知TanStack Query 适合管理请求-响应型的状态会话列表、历史记录加载不适合管理流式状态逐字生成的消息内容。两者结合使用才是正解。推荐的状态架构综合以上挑战推荐的分层架构┌─────────────────────────────────────┐ │ UI 组件层 │ │ (React / Vue 组件响应式绑定) │ ├─────────────────────────────────────┤ │ 状态管理层 │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ 全局状态 │ │ 流式状态 │ │ │ │ Zustand / │ │ Ref RAF │ │ │ │ Pinia │ │ (绕过框架) │ │ │ └──────────┘ └──────────────────┘ │ ├─────────────────────────────────────┤ │ 数据层 │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ TanStack │ │ IndexedDB │ │ │ │ Query │ │ (本地持久化) │ │ │ └──────────┘ └──────────────────┘ │ ├─────────────────────────────────────┤ │ 服务层 │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ AI Client │ │ Stream Parser │ │ │ │ (HTTP) │ │ (SSE 解析) │ │ │ └──────────┘ └──────────────────┘ │ └─────────────────────────────────────┘关键设计决策流式状态脱离框架管理——用 Ref requestAnimationFrame 直接操作 DOM避免高频 re-render全局状态用轻量库——ZustandReact/ PiniaVue不需要 Redux 的重量请求状态用 TanStack Query——管理会话列表、历史加载等标准请求长对话本地持久化——IndexedDB 存完整历史避免每次刷页面重新加载总结AI 状态管理的四大挑战流式更新、上下文窗口、分支对话、多 Agent 协作。流式消息独立管理——分离streamingContent和messages流式阶段用 Ref RAF 绕过框架渲染。上下文窗口管理——滑动窗口 摘要压缩前端展示上下文使用状态。分支对话用树结构——类似 Git 的节点 分支模型支持回到某一轮重新对话。多 Agent 状态需要独立追踪——每个 Agent 独立进度、状态前端可视化展示。TanStack Query 管请求状态Zustand/Pinia 管全局状态Ref 管流式状态——分层配合。下一篇我们从前端状态继续深入到全链路——AI Streaming 架构设计。下一篇预告05 | AI Streaming 架构从浏览器到服务端的全链路流式设计讨论话题你在做 AI 应用时状态管理最头疼的问题是什么用的什么方案评论区聊聊。