Android 开发者苦“接入AI”久矣。Xml布局时代我们习惯了找现成SDK塞进Activity里然后写一堆接口回调到了Compose时代一切都变成了声明式状态驱动可AI能力——尤其是流式输出、对话上下文、多模态卡片——还停留在“拿到String自己拼UI”的原始阶段。最近看到一套Compose原生的AI组件库思路终于有人把聊天、流式文本渲染、工具调用这些场景做成了开箱即用的可组合项这个方向值得好好拆一遍。这套组件库解决的核心问题很直接把对话式AI、流式渲染、语音输入这些能力封装成Compose组件让Android开发者不用自己从零造轮子。我把它理解成“声明式UI时代的AI脚手架”——你不需要管它是怎么接的协议、怎么处理增量文本拿到组件就能在项目里把对话、流式输出甚至工具调用页面搭起来。适合正在做AI落地App的团队也适合想给现有项目快速加AI功能的个人开发者哪怕你只是刚学Compose照着示例也能跑通一整套对话界面。1. 为什么AI能力在Compose里落地这么别扭1.1 传统接入方式的“命令式后遗症”以前在Android里接一个聊天机器人最常用的做法是加一个RecyclerView把历史消息塞进Adapter收到新消息时notifyItemInserted。这套在Xml时代没什么问题因为数据更新的入口是明确的——要么是按钮点击要么是网络回调。到了Compose里这套思维直接就崩了。Compose要求UI是状态快照消息列表应该是ListMessage这个状态的实时映射而不是“我给你打电话说我有新数据了”。最典型的矛盾是网络回调回来一个增量文本你得手动把它追加进某个ViewModel的列表然后祈祷重组发生得够快。如果只是简单字符串还好一旦涉及流式响应里偶发的格式标记、代码块高亮、引用块手动拼接很容易出状态不一致的bug。另一个别扭点是流式输出的性能。大模型API都是逐token返回的很多Demo直接拿mutableStateOf()存整个回复每收到一个token就整体赋值一次。消息一长重组次数暴涨低端机上肉眼可见的掉帧。这属于典型的“能用但不好用”。1.2 声明式AI组件库的设计目标所以这套Compose AI组件库的思路就非常对路它把AI交互中反复出现的高频场景全部抽象成了状态驱动的可组合函数。你声明一个ChatBox把消息列表和发送回调传进去剩下的渲染、滚动、流式增量更新全部由组件自己负责。我理解它的核心设计目标有三个声明式所有组件接收不可变状态输出UI不做任何命令式操作。可组合组件可以自由搭配比如聊天界面里既可以放纯文本气泡也可以放markdown渲染块还能插入工具调用卡片。可插拔底层接哪个模型服务完全由开发者定组件只负责UI和状态编排。第三点很关键。它没有绑定任何特定的大模型SDK而是定义了一套标准的数据流接口你只要把模型的响应流转换成组件需要的类型就能跑起来。这点让它的适用范围广了很多无论是接云端大模型还是私有化部署的模型都能用同一套UI层。1.3 这套东西到底适合谁我实际调研完的感受是它适合三类人第一类是做AI产品原型验证的团队。现在每周都有新想法要试如果每个Demo都要从零写聊天UI和流式渲染那基本不用干别的了。用组件库两小时就能搭一个能演示的对话界面先验证产品逻辑再回头打磨细节。第二类是要给存量App加AI功能的开发者。你的项目可能已经有成熟的设计规范了但AI入口从哪加、流式文本怎么展示、历史记录怎么管理这些模块可以直接用组件库的封装再通过主题定制适配现有风格。第三类是Compose技术栈比较新的团队。组件库本身就是一份很好的架构样例——怎么建模流式数据、怎么做增量渲染、怎么设计可组合的对话UI源码里全是能学的实践。2. 组件库的核心模块拆解2.1 聊天对话组件不止是“气泡ListView”很多人以为聊天组件就是把气泡样式封一下实际上这里面的门道不少。拿组件库里的对话组件来说它同时处理了消息列表的分组、时间戳、发送状态、失败重试、加载动画、自动滚动和输入框联动。我最喜欢的是它对“流式加载中”状态的处理。传统做法是消息列表底部放一个转圈等完整回复下来一次性渲染。但大模型接口是流式返回的用户希望看到字一个一个蹦出来。组件库的做法是把当前正在生成的这条消息单独建模成StreamingState内部维护一个增量缓存的文本缓冲然后用节流机制控制重组频率保证视觉上流畅又不至于每来一个token就全列表刷新。输入框也不是简单的TextField外包一层。它处理了多行输入的高度自适应、键盘弹出时列表的imePadding适配、发送按钮的可用状态切换以及“用户正在输入”的防抖逻辑。这些细节单独拿出来都很小但组合到一起就是Chat场景下最磨人的体验问题。2.2 流式文本渲染Markdown、代码块与“打字机效果”如果说聊天组件是骨架流式文本渲染就是灵魂。大模型的输出格式现在基本默认带Markdown标题、加粗、列表、引用、代码块、表格。如果直接用TextView显示满屏的**和#符号用户看一眼就觉得是半成品。组件库里做了一套逐段解析 增量渲染的机制。它不是拿到完整文本一次性转Markdown而是在token流到达的过程中维护一个“未闭合块”的缓冲区。比如用户看到的渲染结果里代码块还没结束组件就把已经解析出的部分先渲染剩余部分继续等后续token。这样能保证用户从头到尾看到的是“还是个Markdown文档”而不是前半段乱码、等到最后才突然变成格式化的文本。代码块的高亮渲染也是一个独立组件。它内置了几种主流语言的语法高亮不需要你引入额外的高亮库。实测里最让我惊喜的是它支持横向滚动的代码区和一键复制按钮这两点在移动端看代码的时候太常用了。2.3 多模态与语音组件从“打字对话”到“语音交互”现在的AI交互早就不是纯文字了。组件库在这一块也做了不少封装语音消息组件支持边录音边显示波形、录音时长、播放态和未读红点这些状态全部由组件的ViewModel管理不需要你手动去同步录音机和UI的状态。图片消息则支持多图九宫格展示、点击预览大图、图片加载失败占位和上传进度显示。我特别留意到它把上传进度做成了可取消的状态——长传大图时不满意可以随时取消这个细节很多自己写的聊天界面都会忽略。多模态方面它把“图片理解”类场景的UI也封装好了用户选图之后、发送之前会有一个预览确认卡片支持旋转、裁剪、添加描述文字确认后才构造多模态消息。这种“发送前确认”的交互设计很值得学习能避免用户误发图片。2.4 工具调用与状态展示AI不只是“聊天机器人”现在的大模型应用基本都带工具调用能力比如查天气、订机票、执行代码。工具调用的结果往往不是纯文本而是结构化数据。组件库为此提供了一套工具卡片渲染体系你可以为不同的工具类型注册对应的卡片UI组件根据工具名称自动匹配渲染。比如天气工具返回的数据可以渲染成一张带图标的天气卡机票工具返回的可以渲染成一张航班信息卡。组件库定义了一个标准接口ToolCard你只要实现这个接口并注册AI只要决定调用该工具UI就会自动切换到对应的卡片样式。这个设计把“AI能力展示”和“业务视觉效果”解耦了。模型的输出是确定的工具调用指令业务侧决定这张卡长什么样。组件库本身不限制你能渲染什么自由度很高。3. 架构层面的几个关键决策3.1 为什么用StateFlow而不是LiveData组件库的数据层全面采用了Kotlin的StateFlow和Flow完全绕开了LiveData。这其实是一个深思熟虑的架构决策而不只是“Kotlin优先”的偏好问题。核心原因是AI场景天然是流式的。大模型的token输出是一个真正的数据流LiveData这种“一次性值持有观察者模式”的设计应付起来很别扭。StateFlow天生支持collect挂起、背压处理和基于distinctUntilChanged的自动去重这些特性对高频流式更新特别重要。另一个原因是冷流和热流的灵活切换。聊天历史可以从数据库里以冷流的形式加载而正在生成的回复是一个热流。组件库通过StateFlow.combine把这两类流组合成单一的UI状态解耦得很干净。如果你用LiveData想组合两个数据源得自己写MediatorLiveData很繁琐。性能上StateFlow还有一个杀手级特性并发收集。同一个状态可以被多个Composable函数并发地收集而不会触发额外的通知开销。这在流式渲染场景特别有用因为Markdown正文、Token计数、滚动位置提示可能同时需要监听同一条消息流的状态变化。3.2 流式文本渲染时的重组优化策略直接mutableStateOf存整个字符串在流式场景下每一次赋值都会触发所有读取它的Composable函数重组。消息长到几千字时每来一个token就全量重组一次性能会迅速劣化。组件库的优化策略我梳理下来有三层第一层是状态细分。它把一条流式消息拆成多个独立的状态字段——纯文本缓冲、当前解析出的Markdown节点列表、渲染版本号。文本每更新一次只有真正依赖“完整文本”的少数节点需要重组大部分渲染逻辑只需要检查节点列表是否变化。第二层是节流。它不会每个token都强制重组而是在token到达时先把数据写进一个非响应式的缓冲区然后以约60~100ms为间隔触发一次UI快照。这样用户感知到的还是流畅的“打字机效果”但重组次数直接降到每秒10次左右性能压力小了不是一点半点。第三层是derivedStateOf的合理使用。很多开发者滥用derivedStateOf实际上它适合的是“从多个状态推导一个衍生状态”的场景。组件库在计算列表是否应该自动滚到底部时用到了它——只有当新的token让文本高度超过阈值时才触发滚动而不是每次文本更新都滚动。3.3 与ViewModel的边界和“平台无关核心”组件库的架构有个很有意思的取舍它把纯业务逻辑全部抽到了Kotlin/JVM层Compose UI只做了薄薄的一层壳。这意味着什么意味着如果你以后要复用这套逻辑到其他平台比如用Kotlin Multiplatform跑在iOS或者桌面端核心的会话管理、流式数据缓冲、Markdown解析器都不需要动只需要为对应平台写一套UI壳。组件库定义了一个叫AssistantEngine的接口——我理解它就像一个“AI大脑”的抽象层。你实现这个接口返回消息状态流组件库负责把它变成漂亮的UI。这个边界界定得非常好开发者既可以直接用内置的引擎实现支持标准流式协议也可以完全自研接入任何私有协议。这带来一个非常大的好处你可以用JVM单元测试来测试所有对话逻辑。因为核心引擎不依赖任何Android或Compose类跑测试不需要模拟器反馈速度极快。对于AI应用这种逻辑复杂度较高的场景这一点价值巨大。4. 实操从零搭一个可用的AI聊天组件4.1 项目依赖配置引入这套组件库在build.gradle.kts里加依赖就行// 根目录 settings.gradle.kts 配置仓库后 implementation(com.example.ai:components:0.1.0) implementation(com.example.ai:components-markdown:0.1.0)如果你还要语音功能再加一个可选扩展implementation(com.example.ai:components-voice:0.1.0)第一行是核心库包含聊天框架和基础组件第二行是Markdown渲染扩展如果不引入流式文本就只能以纯文本展示第三行是语音相关组件属于可选依赖。这种拆分的思路很合理按需引入不用的模块不占包体积。4.2 消息数据模型的建模在开始写UI之前要先建立消息模型。组件库定义了一套标准的事件抽象我在项目里直接用sealed interface ChatMessage { val id: Long val timestamp: Long data class User( override val id: Long, override val timestamp: Long, val text: String ) : ChatMessage data class Assistant( override val id: Long, override val timestamp: Long, val content: MessageContent, val status: Status ) : ChatMessage { enum class Status { Idle, Streaming, Completed, Failed } } }这个建模最大的好处是把“用户消息”和“AI回复”严格区分开。Assistant消息里的content用了一个密封接口MessageContent它既可以是一个纯文本也可以是一个Markdown文档甚至是一个工具调用卡片列表。这样消息列表才能支持混合内容而不是只能显示字符串。所有消息都有id和timestamp这不仅是为了显示时间更是为了给列表的key提供稳定值。Compose里LazyColumn如果不用稳定key增量更新时会有剧烈的动画错乱。4.3 流式输出的状态管理实现接下来是核心如何管理流式回复的状态。我写了一个简单的ChatViewModel关键代码如下class ChatViewModel( private val engine: AssistantEngine ) : ViewModel() { private val _messages MutableStateFlowListChatMessage(emptyList()) val messages: StateFlowListChatMessage _messages.asStateFlow() private val _isProcessing MutableStateFlow(false) val isProcessing: StateFlowBoolean _isProcessing.asStateFlow() suspend fun sendMessage(text: String) { val userMsg ChatMessage.User( id System.currentTimeMillis(), timestamp System.currentTimeMillis(), text text ) _messages.update { it userMsg } _isProcessing.value true val assistantId System.currentTimeMillis() 1 val assistantMsg ChatMessage.Assistant( id assistantId, timestamp assistantId, content MessageContent.Text(), status ChatMessage.Assistant.Status.Streaming ) _messages.update { it assistantMsg } try { engine.replyStream(text) .collect { delta: String - _messages.update { list - list.map { msg - if (msg.id assistantId) { (msg as ChatMessage.Assistant).copy( content MessageContent.Text( (msg.content as MessageContent.Text).text delta ) ) } else msg } } } _messages.update { list - list.map { msg - if (msg.id assistantId) { (msg as ChatMessage.Assistant).copy( status ChatMessage.Assistant.Status.Completed ) } else msg } } } catch (e: Exception) { _messages.update { list - list.map { msg - if (msg.id assistantId) { (msg as ChatMessage.Assistant).copy( status ChatMessage.Assistant.Status.Failed ) } else msg } } } finally { _isProcessing.value false } } }这里有几个细节值得展开update是MutableStateFlow的原子更新函数它在并发修改时是线程安全的。流式回调可能从网络线程发出如果在网络线程直接修改可变状态会引发并发问题用update这个原子操作就稳了。状态更新的粒度是整条消息列表看起来好像会引发大范围重组但实际上Compose只重组那些读取了被修改项的函数。LazyColumn在item key不变的情况下不会重排整个列表只会刷新内容变化的item所以性能没问题。我用System.currentTimeMillis()做id其实只是个简单方案生产环境建议用自增或UUID避免两条消息在同一毫秒内产生相同id导致key冲突。4.4 消息列表UI编排有了状态UI部分反而很简单组件库已经把底层的列表编排全部封装好了Composable fun AIChatScreen(viewModel: ChatViewModel) { val messages by viewModel.messages.collectAsStateWithLifecycle() val isProcessing by viewModel.isProcessing.collectAsStateWithLifecycle() ChatScreen( messages messages, isStreaming isProcessing, onSendMessage { viewModel.sendMessage(it) }, streamingRenderer { content - // 根据内容类型选择渲染器 when (content) { is MessageContent.Text - MarkdownRenderer(content.text) is MessageContent.ToolCall - ToolCardRegistry.Render(content) else - GenericContentRenderer(content) } } ) }看到这里你就能感受到组件库的威力了你不需要关心气泡怎么对齐、时间戳在哪、滚动到底部的逻辑怎么处理这些全部被封装在ChatScreen里。你只需要关心两件事——消息怎么来ViewModel以及每条消息的内容怎么渲染streamingRenderer。ToolCardRegistry是工具卡片的注册中心比如我接入天气工具时会这样注册ToolCardRegistry.register( toolName query_weather, cardContent { data: ToolCallData - WeatherCard( city data.param(city), temperature data.param(temperature), condition data.param(condition) ) } )注册完之后只要AI返回的回复里声明调用了query_weather工具组件库就会自动用WeatherCard渲染对应的卡片区域完全不干扰对话流的整体布局。这种“按工具名注册UI”的模式让多轮工具调用和混合渲染变得非常优雅。4.5 主题定制与暗黑模式适配组件库另一个很实用的设计是AIChatTheme。它不是一个新的蜜罐主题框架而是提供了几个默认的CompositionLocal让你能精准覆盖关键节点的颜色CompositionLocalProvider( LocalBubbleColors provides myBubbleColors, LocalStreamingIndicator provides myStreamingStyle, LocalCodeBlockStyle provides myCodeBlock, LocalInputBarStyle provides myInputBarStyle ) { AIChatScreen(viewModel) }LocalBubbleColors控制气泡配色LocalCodeBlockStyle控制代码块的字体背景和主题色LocalInputBarStyle控制输入框的圆角、高度、光标颜色。每个组件都有一套默认值所以你不配主题也能正常工作配了就能融入你现有的设计体系。暗黑模式这块做得尤其到位。组件库里所有颜色都是用MaterialTheme的动态颜色推导出来的不是写死的色值。测试下来从浅色切到深色整个对话界面的气泡、输入框、代码块高亮都会跟着变不会出现那种“UI一半亮一半暗”的撕裂感。我强烈建议你在接入时用液胶态预览先跑一遍深浅色切换确保你的自定义主题在两种模式下都有足够对比度。代码块高亮在深色模式下尤其容易翻车——如果用的是浅黄底色的Katex高亮配色在深色模式下会亮得刺眼。5. 性能与避坑记录5.1 流式刷新的“重组风暴”我在用组件库跑一个2000字长回复的压测时遇到过掉帧。后来定位发现是我自己覆盖了默认的streamingRenderer在渲染器内部读取了整个消息文本导致每个token都触发整条消息的重组。解决办法是把渲染器内部的文本读取缩小到必要的范围。比如Markdown渲染只读取“已解析的节点列表”而不是每次都读“完整字符串”。组件库默认的MarkdownRenderer就是这么实现的你如果要自定义渲染器一定注意遵循同样的原则。另一个坑是在collectAsStateWithLifecycle()之外又对同一状态做了一次collectAsState()导致两个收集器分别触发重组。这个问题排查起来很隐蔽因为表现只是偶尔卡顿。后来严格约定一个页面里对同一句话只有一个收集器要么用带lifecycle的要么用普通的混用就是在给自己挖坑。5.2 长对话的列表性能与自动滚动聊到50轮以上的长对话时LazyColumn的构建开销会明显上升。组件库默认做了消息分页加载——ChatScreen接收一个无限列表内部用LazyColumn按需加载过去的消息不会一次性把所有历史消息全部组合。但分页加载和自动滚动之间存在一个天生的矛盾如果你滚到了历史区域新消息到来时就不应该强行把用户拽回底部。组件库通过derivedStateOf判断“用户是否接近底部”只有接近底部时才自动滚动否则只更新一个“新消息提示条”。这个交互细节非常加分我在自己的项目里也沿用了这个逻辑。实现上要注意判断是否接近底部不能用lastVisibleItemIndex totalCount - 1这种“正好到底部”的严格条件。实测中用户在底部区域停留但没完全到底时新消息来了也应该触发滚动。一般用“最后可见索引大于等于总数减3”作为阈值。5.3 协程取消与页面销毁的竞态我在测试时发现一个偶发崩溃页面销毁后网络的流式响应还在回调_messages.update被继续调用虽然StateFlow本身不崩溃但对MutableStateFlow的引用在ViewModel clear之后继续持有会导致内存泄漏。组件库在ChatViewModel基类里默认做了协程取消处理所有的sendMessage工作在viewModelScope中执行ViewModel销毁时会自动取消发送和接收流。但如果你自己写了额外的引擎调用——比如把回复同时转发到日志系统——则需要自己判断协程是否取消try { engine.replyStream(text).collect { ... } } catch (e: CancellationException) { // 这里必须重新抛出去不能吞掉 throw e }吞掉CancellationException是协程开发中最大的坑之一。如果你在catch里直接return协程的取消状态就被破坏了后续的挂起点都可能不响应取消导致资源长期不释放。组件库的源码在这块的写法很标准直接throw e而不是静默处理。5.4 键盘弹出与输入框抖动聊天界面最容易出bug的就是输入框和键盘的交互键盘弹起时输入框要不就顶得太高、要不就被列表盖住有时还会因为imePadding和navigationBarsPadding叠加出现抖动。实测下来最稳定的做法是在ChatScreen外围只保留imePadding()这一个修饰符navigationBarsPadding交给全局的主题去处理不要在聊天页面内部重复叠加。组件库默认的实现就是这个逻辑我在自定义的时候试过“为了保险”多加一层navigationBarsPadding结果iOS风格的手势条和键盘之间出现了间隙和跳动去掉之后一切正常。输入框本身建议用BasicTextField而不是TextField因为TextField的填充色、边框样式在聊天场景下经常需要自定义用BasicTextField为载体做样式扩展反而更灵活。组件库底层的输入框就是基于BasicTextField封装的自带多行自适应高度的逻辑。5.5 消息重试与失败恢复流式接口天然有失败概率——网络抖动、服务端超时都会导致回复中断。这时如果只是把消息状态标成“失败”用户体验会很差。组件库提供了重新生成的重试APIviewModel.retryLastMessage()这个API会找到最近一条失败的Assistant消息移除它然后重新发起一次流式请求。实现时需要注意重试不应该重复追加用户消息只重新请求AI回复否则历史消息里会出现一模一样的用户消息。另外建议在UI上把“停止生成”和“重新生成”分开。流式生成中显示停止按钮生成失败后才显示重试按钮这两个按钮的状态不能混。我在接组件库的时候就踩过这个坑最初给发送按钮做了一个“长按停止”的逻辑结果用户经常误触后来老老实实按组件库的建议——发送和停止是两个独立的UI状态。6. 常见问题与排查技巧6.1 常见问题速查表问题现象排查思路解决方案流式文本卡顿掉帧检查是否每来一个token就整条消息重组确认使用组件库默认的节流渲染机制自定义渲染器时只读取“增量节点”深色模式代码块亮得刺眼代码块高亮配色没适配暗色主题用LocalCodeBlockStyle覆盖暗色配色或者用动态颜色推导长对话滑动越来越卡历史消息没有被分页处理确认接入的是无限列表接口而不是把全部消息一次性塞进List键盘弹起时输入框跳动imePadding和navigationBarsPadding重复叠加只保留imePadding全局导航栏内边距交给主题处理页面销毁后回调仍在触发协程未随ViewModel销毁而取消确认所有引擎调用都跑在viewModelScopeCancellationException要重新抛出消息id冲突导致列表动画错乱使用了时间戳或同一毫秒生成多条消息用自增id随消息数量递增或UUID保证id全局唯一工具卡片一直显示“未知工具”工具名没有注册到ToolCardRegistry检查工具调用的名称与注册名称是否完全一致注意大小写和命名空间流式回复中途变成“Failed”网络中断或服务端断流查看引擎的错误码区分超时、限流、连接中断分别配置重试策略6.2 几个独家避坑经验第一个经验是关于预览函数调试。流式组件和普通UI组件的最大区别是状态来源不定你在Preview里没法直接模拟流式过程。我的做法是写一个假的Engine用一个flow { emit(Hello) ; delay(200) ; emit( World) }来模拟流式响应然后传给组件库的ViewModel。这样一眼就能在预览面板里看到流式效果不用每次跑真机。第二个经验是用“第一条消息的最小时延”来选设备测试。流式渲染对手机性能很敏感我测试过骁龙和天玑的中端机型差距非常大。如果你手头设备有限建议用开发者选项里的“模拟辅助显示设备”来压低帧率模拟中端机体验。如果模拟器里流畅真机上一般问题不大如果模拟器都卡真实设备基本没救。第三个经验是流式渲染的Markdown解析器要关注内存峰值。大模型输出一段超长代码块时解析器会先在内存里构建一个完整语法树。如果你看到OutOfMemoryError发生在渲染代码块的瞬间多半是解析器的缓存策略过于激进。组件库的处理是把解析器设为有界缓存状态超过阈值时暂停增量解析等用户滚动到对应区域再恢复。这块逻辑涉及平台级优化不建议普通业务直接改。6.3 扩展方向把组件库融入现有MVVM架构组件库本身是状态驱动设计的所以接入现有MVVM架构非常顺滑。唯一需要统一的是消息数据的持久化策略。我目前的做法是ViewModel负责把收到的完整回复写入数据库UI只响应内存中的StateFlow。这样App重启后可以加载历史会话。组件库提供了ChatDbHelper的接口你只要实现存储和读取ChatScreen会自动判断加载历史记录的时机。如果你们后端有自己的会话同步协议可以再封一层RemoteDataSource。核心原则是UI组件库只负责显示数据仓库层负责同步两者通过消息流通信不要在UI代码里直接访问网络层。这条边界守住了组件库替换或者升级的时候业务代码几乎不用动。7. 我实际体验下来的几个感受组件库用了一周最大感受不是“省了多少代码”而是它逼着我把AI交互按状态去思考。以前我写聊天界面脑子里全是“收到回调之后我要更新哪个控件”换成这套思路之后自然就变成了“每条消息的状态是什么UI怎么映射这个状态”。这种思维转变的价值比省的那几千行业务代码大得多。其次流式渲染的节流机制我是真的服气。自己写的时候怎么看流畅度都觉得差口气但看了它源码里那个throttle(100)conflate()的组合一下子就想通了——不是每次都刷新才算实时关键帧够多人眼感知不到中间丢失的中间帧反而整体更稳定。如果你打算在项目里引入我提三点建议一是先跑通官方Demo再把它换成你们自己的模型接口二是把工具卡片和业务建模先想清楚别急着接入UI三是一定要测试长时间挂机对话的内存表现有些内存泄漏是跑一晚上才会暴露的。做AI应用UI这层真的只是开胃菜状态管理、异常恢复、性能调优才是真正花时间的地方。