在 AI Native Chat 产品中，当模型返回的不是纯文本，而是 Function Call / Tool Call（如 tool_calls），前端如何处理整个流程？从接收 tool_call → 执行函数 → 将结果回传模型 → 渲染最终回答，描述完整前端流程和 UI 交互设计。
用户未作答，由 AI 直接讲解。
这道题的核心不在于 API 对接的熟练度，而在于三个深层理解：流式 delta 需要按 index 拼合才能还原完整调用、messages[] 是前后端唯一的真相源（所有状态变更都必须反映在消息数组中）、工具调用本质上是一个有状态的多轮消息循环系统，而非一次性的 RPC 调用。原题偏向实现细节，换个合格的前端看一遍文档就能做，但考察 tool call 机制本身是更有区分度的问题。
对于 Function Calling 的机制层面，需要把握三个核心问题。首先是触发 tool call 的条件：必须在请求中传 tools 参数，tool_choice: "auto" 下模型自主判断何时调用——通常是数据超出知识边界、或有匹配能力的工具可用时，"none" 禁止调用，"required" 强制调用，没有 tools 参数模型永远不会主动调用。其次是 content 和 tool_calls 互斥，不会同一轮同时返回，看似"边说边调"的体验是多轮交替的结果：第一轮 assistant 返回 tool_call → 前端执行工具 → 第二轮 assistant 返回文本，前端需要维护消息数组的状态机来正确拼接这个多轮循环。最后，从接收流式 tool_call delta 到拼合、执行工具、追加 tool(result) 到 messages[]、重新请求模型、渲染最终文本的完整链路中，关键是理解 messages[] 是前后端唯一的真相源，所有状态变更都必须反映在消息数组中，而工具调用本质上是一个有状态的多轮消息循环系统，而非一次性的 RPC 调用。