AI 工具调用接回多轮对话 怎样处理

AI 工具调用接回多轮对话，关键不是把工具输出粘到聊天框，而是保留模型发出的调用记录、应用执行得到的结果，以及二者在当前会话中的归属。随后按目标模型要求重新组织输入，让模型基于结果继续回答；用户下一轮追问时，也要保留必要的结果上下文。

工具结果不等于用户消息，调用请求不等于执行成功。把协议记录、执行状态和用户可见回答分开保存，才能处理重复回调、并行查询和历史裁剪。

本文以 Transformers 的工具使用与聊天模板为协议参考，讨论服务端的衔接设计，不提供适配所有模型的通用请求体。官方入口：https://huggingface.co/docs/transformers/en/chat_extras。以下订单查询场景、编号与状态均为原创设计示例，不是真实客户数据或上线复盘。

先确定一次调用属于哪轮对话

设想用户先问“查询演示订单 D482 的配送状态”，模型提出只读查询；应用拿到“运输中”的演示结果后生成回答。用户再问“刚才那个订单预计哪天到”，这次请求必须明确沿用 D482，不能从另一个会话最近一次查询中拿结果。

当系统只有单请求、单工具时，把若干字符串拼接进提示词看起来可以工作。并发量增加后，真正先暴露的通常是状态归属问题：浏览器重试提交、两个标签页同时追问、慢查询结果晚于新一轮请求返回。这些是工程风险假设，不是本文测得的性能瓶颈。

建议先为对话、用户轮次和工具调用建立内部关联。业务标识不替代模型协议要求的字段；模型是否要求调用 ID、工具名称和特定排列方式，需要按其文档映射。不要强行给所有模型套一种接口格式。

把聊天展示记录与协议记录分开

聊天页面可以只展示“正在查询”和“订单运输中”，服务端不能因此只留下这两段话。页面展示是阅读视图，协议记录是继续推理的输入，执行记录则回答“工具到底做过没有”。三类信息职责不同，建议至少在逻辑上独立。

这样做会增加存储与组装成本，但故障恢复时可以只补缺失环节，而不靠重新执行工具来猜测历史。保留内容仍应最小化，令牌、个人信息和完整服务端日志不应无差别进入模型上下文。

为调用和结果保留稳定的对应关系

以内部调用标识 q-41 表示“查 D482 状态”，q-42 表示另一笔订单查询。即使 q-42 更早返回，也只能关联到自己的调用，不能按回调到达顺序给两条结果配对。同名工具和相似参数都不是可靠的唯一关联依据。

服务端接收结果时，先按内部记录确认所属会话、轮次、工具和当前执行状态，再构造目标协议的工具响应。若模板要求调用 ID，就精确保留它；不要求该字段的模板，也可以在业务存储中保留内部标识，但不应向模型消息随意添加不受支持的结构。

这里的状态核对是应用设计建议，而非 Transformers 自动提供的持久化保证。工具超时、失败、成功但回包丢失，应区分记录；不能把“没有收到结果”直接翻译成“查询结果为空”。

按模型模板恢复下一次输入

Transformers 工具文档说明了基本职责分工：模型生成调用请求，应用处理后把助手调用与工具结果加入历史，再继续生成。聊天模板文档则说明，不同模型可能使用不同控制标记。因而适配层应负责协议映射，业务层不要手写一串特殊标记作为跨模型通用方案。

对于本例，下一次输入应能表达：用户问了 D482，助手请求了相关工具，工具返回了对应结果；模型读到这些事实后才回答。接入具体模板时，还要按要求提供工具定义及生成提示设置。不要只保留工具结果、删掉其对应调用，也不要把工具输出伪装成用户授权。

第二轮追问时，若完整历史仍在，可继续携带与追问有关的记录。若需要裁剪，应把工具调用与对应结果作为关联单元处理，避免孤立残留；摘要里注明结果对象和查询时间，并保留可恢复的业务引用。对时效敏感的状态，应根据产品规则重新查询，不把旧摘要当作当前事实。

用失败与重试场景检查状态设计

先用三类输入演练设计：重复收到 q-41 的完成通知、D482 查询失败、用户已开始新一轮而旧工具结果才返回。预期不是“全部重试”，而是根据记录决定去重、报告失败，或保留迟到结果但不写进错误轮次。

建议把模型生成与工具执行拆成可恢复的阶段。若工具已成功而最终回答生成失败，优先复用已存结果继续生成；不要无条件再次执行业务动作。涉及写操作时，调用关联标识也不天然等于业务幂等键，业务系统需自己的防重复机制与授权检查。本文只用只读查询说明衔接，不扩展写入工具的权限设计。

工具输出属于外部数据。结果中的任意文本不能自动升级为系统指令，更不能因为模型据此提出新调用，就跳过服务端的工具允许名单、参数范围与身份授权。把每次请求能用的工具范围收窄，通常比给模型一组无限能力更容易维护。

扩容前记录衔接指标并限制循环

这套拆分是否值得，应看真实运行信号，而不是宣称它能提升某个固定百分比。可以记录关联失败数、重复完成通知数、迟到结果数、每轮工具次数和上下文长度；日志使用脱敏标识，不保存密钥或完整敏感结果。本文没有上线测量数据，不给性能提升结论。

同时设置单轮工具次数、累计耗时和结果长度预算。达到上限时由应用明确结束或请求用户缩小问题，不允许模型与工具无限往返。扩展到并行调用之前，先确认所选模型确实支持相应格式；文档中的单调用示例不能证明所有模型都有多工具并行能力。

为什么工具成功了，模型还要求再查？

先看续接输入是否保留了助手调用和对应结果，再检查模板是否匹配，以及结果是否足以回答问题。也可能是模型确实需要更新信息；不能只凭“重复工具名”认定协议故障。

跨模型迁移时，只换模型名称可以吗？

不宜这样假定。需要核对工具调用输出如何解析、参数对象如何表达、结果角色与关联字段如何组织，以及聊天模板是否支持。内部业务记录可以稳定，外部协议适配应可替换。

直接把工具输出当成最终回答，能省一次生成吗？

若产品本来就是确定性查询展示，可以由应用模板直接呈现结果，但这属于另一种交互选择。若需要模型解释或接续追问，仍需维护一致的协议与业务历史；省略一轮生成不能成为丢弃调用记录的理由。

参考：Transformers 工具使用文档、聊天模板文档。消息持久化、去重、预算与并发控制是本文提出的应用层设计建议，不是文档承诺的自动能力。