大模型流式输出与工具调用之间如何保持状态一致？

核心回答

AI 代码生成平台把普通代码文本流和带工具调用的 Vue 工程生成分开处理。HTML、多文件模式边展示边收集文本，流结束后统一解析并保存；Vue 模式使用 LangChain4j 的 TokenStream，分别处理文本片段、工具请求和工具执行回调，再转换成页面可读内容，通过 SSE 推送。

这个版本的关键是：部分工具请求只驱动展示，真正执行发生在完整模型响应形成之后。 工具结果按原请求写入模型记忆，再继续调用模型。展示层按工具 ID 避免重复提示，但这还不是完整的执行幂等机制；流结束也不代表工程一定构建成功。

聊天请求经过哪些层

AppController 接收应用 ID 和用户消息，调用 AppServiceImpl.chatToGenCode()；服务层校验应用与用户，先记录用户消息，再进入 AiCodeGeneratorFacade.generateAndSaveCodeStream()，按生成类型选择对应的 LangChain4j 服务。这里的聊天链路直接进入模型和工具循环，不需要经过另一个 LangGraph4j 工作流。

HTML 和多文件模式返回 Flux<String>。门面类收集全部文本，在正常结束时调用代码解析器和文件保存器；简单流处理器再收集展示文本，写入聊天记录。这条路线没有把每个文本片段当成一次文件写入。

Vue 模式则把三类回调转换成内部 JSON 消息：AI_RESPONSE 携带模型文本，TOOL_REQUEST 携带工具请求信息，TOOL_EXECUTED 携带执行请求和返回结果。随后交给 JsonMessageStreamHandler，处理器把它们转成展示字符串，控制器再以 {"d": "展示片段"} 包装成 SSE 数据，并在正常结束后追加 done 事件。浏览器接收的不是这三类原始工具消息的直接透传。

部分工具回调为什么不会直接执行

项目内包含自定义的 dev/langchain4j 实现，回调语义需要沿这层看。在 OpenAiStreamingChatModel 中，工具片段到达时会保留调用 ID、名称并追加参数；传给 onPartialToolExecutionRequest() 的 arguments 是本次参数片段，不是已经拼好的完整参数。对应实现说明了这一点。

模型响应收集完成后，AiServiceStreamingResponseHandler.onCompleteResponse() 读取完整 AiMessage 中的工具请求，逐个交给 ToolExecutor。执行返回后，先把对应的 ToolExecutionResultMessage 加入记忆，再触发 onToolExecuted()，并带着更新后的消息请求下一轮模型；模型不再要求调用工具时，才回调应用层的最终完成处理。完整请求执行分支与部分回调是两条不同职责。

所以，参数分成多块时，应用层只是不断获知“这个工具正在形成请求”，不会由展示处理器拿半段参数重复执行工具。

展示状态与真实执行还有哪些区别

JsonMessageStreamHandler 在一次流处理内维护 seenToolIds。首次看到某个工具 ID 时，返回该工具的调用提示，后续同 ID 的请求片段返回空字符串，避免页面反复展示同一条提示。这个集合控制的是本次流内的提示去重，不能证明跨请求重试时工具只执行一次。

收到 TOOL_EXECUTED 后，处理器解析请求参数，调用工具的 generateToolExecutedResult() 生成展示内容，并追加到聊天记录缓冲区。虽然内部消息包含实际 result，当前展示分支没有读取它，而是依据参数格式化内容。例如写文件工具会根据文件路径和内容生成代码块；工具方法即使返回“文件写入失败”，该展示分支也没有据此明确标成失败。处理器和写文件工具共同体现了这个区别。

最终完成状态也有类似边界：Vue 的完成回调调用 buildProject()，但没有检查其布尔返回值，随后仍结束流；HTML 和多文件模式的解析保存异常也只记录日志。因此，当前 done 可以表示响应流正常走完，不能据此确认文件保存或构建一定成功。

进一步完善时，应把工具实际返回结果中的成功或失败传给展示层，构建失败也要进入明确的失败状态，再决定是否发送业务完成事件。这样模型记忆、页面提示与工程产物才能依据同一份执行事实更新，而不是都依据一段“看起来成功”的文字。