智能体运行中追加输入：怎样避免重试变成重复任务？

用户在任务运行中补充了一句话，服务端可能已经收到，客户端却因断网没拿到响应。直接再次发送，可能重复；直接显示失败，又可能让用户误以为从未提交。要解决这个问题，需要明确输入身份、目标执行轮和回执含义。

Tansr 的同轮追加接口把补充绑定到指定执行轮，不因目标关闭而自动开始下一轮。它适合“仍属于这次任务”的补充，不是一个通用的耐久消息队列，也不是对已执行业务动作的撤销接口。

先固定请求，再发送请求

客户端应取得当前目标，保留输入编号、目标和正文，然后提交。目标包含 historyEpoch 与 turnId；只有会话 ID 不足以识别历史替换前后、不同执行轮之间的输入归属。

在 Tansr 会话服务中，能力查询、输入提交和状态查询有独立入口。客户端继续使用本部署的业务鉴权，服务端根据已认证身份校验会话归属。知道另一个 sessionId 不能获得访问它的权限。同轮追加协议文档列出了对应接口。

如果先发请求、收到响应后才保存编号，网络在中间断开时就可能丢掉查询依据。因此，草稿保存不是收到成功后的装饰步骤，而应在提交前完成；它属于应用职责，不是一个自动附带的 SDK 存储保证。

查询和重试始终指向原输入

响应丢失后，先用原编号和原目标查询。需要重试时保留原请求内容；同编号、同目标、相同规范化文本可以获得原回执，内容变化则可能返回 input_conflict。

不要每次重试都生成新编号，也不要悄悄换成当前最新目标。前者可能变成新的输入，后者可能把上一次任务的要求投递到另一轮。目标关闭时，应明确告知用户，并由用户决定是否开始新任务，而不是退回普通消息接口继续发送。

展示状态时，不能只看“提交成功”

accepted 说明输入已被内存接纳；consumed 说明输入进入本轮历史。二者都不能证明模型已经完成新增要求。重复提交返回的原回执还可能已处于 consumed 或 closed 状态，不能只看到外层 accepted 就再次显示“等待处理”。

界面应分别展示输入状态与任务终态。若输入已进入历史，但任务触达预算限制而结束，用户需要看到这个组合，而不是一个统一的成功勾选。

未找到与未发生，不是一回事

回执只保留当前轮和最近结束轮。状态查不到，可能是超过窗口，也可能是运行时重建，不能据此断定从未执行。会话不存在、认证失败和输入回执未找到，也要按不同错误处理。

该接口目前提供 memory 确认。即使配置了 SessionStore，也不能把它当成跨重启保证送达。重连到仍在运行的会话，与服务重启后重建会话，是不同恢复条件。面对无法确认的输入，应保留原草稿和未确认状态，不自动重放业务工具。

因此，Tansr 的这组接口适用于需要严格同轮归属、可查询内存回执的交互；如果业务要求持久投递或外部写操作的严格去重，还需应用自己的存储和业务幂等机制。接入验收可从响应丢失、原轮刚关闭、回执过期三类场景开始，重点检查是否意外产生新任务。