业务数据变化后，AI 助手应继续原来的任务，同时重新查询影响当前判断的事实。对话可以保留“用户想做什么”，却不能证明库存、交期、负责人或审批状态仍与上次一致。可用的产品需要区分已确认的用户要求、上次查询的业务事实和此次新取得的依据，再明确哪些结论需要更新。
Tansr 的 @tansr/sdk 可以在自有应用中组织模型与工具之间的连续运行、会话和过程事件。用户补充要求后，运行链能够继续使用业务工具；但数据何时失效、哪些内容必须重查、如何保留人工确认，由接入方的业务函数和应用规则决定。SDK 不会自动把聊天历史同步成最新业务数据。SDK 的职责与运行条件
同一个任务，第二天可能需要不同答案
假设企业已有项目台账、测试记录和验收工作台。项目负责人周一提出：“整理本周待验收项目，按材料缺口给我一份准备清单。不要替我提交申请。”以下项目和时刻都是设计示例，不代表真实客户记录。
应用在周一 10:00 查询得到：P-31 计划周四验收，测试报告已通过，尚缺归档附件。负责人随后确认：“由质量负责人甲补附件；保留周四目标，先不送审。”应用应把这项确认作为有归属的业务记录保存，而不是只让它留在聊天里。
周二用户继续问：“附件现在补齐了吗？如果齐了，把送审准备清单更新一下。”此时仅凭周一的工具返回不能回答。业务系统可能已经补齐附件，也可能改变了验收日期或负责人。
| 信息 | 继续任务时怎样处理 | 原因 |
|---|---|---|
| 用户仍在准备 P-31 验收、尚未授权提交 | 保留，除非用户明确修改 | 这是任务目标与动作边界 |
| 周一查询到附件缺失 | 重新查询当前附件状态 | 这是可能变化的业务事实 |
| 负责人确认由质量负责人甲补附件 | 保留确认记录；与当前台账核对 | 新查询不应悄悄覆盖人工决定，实际职责也可能已经调整 |
| “尚不具备送审材料”这一结论 | 按新附件及当前验收条件重新判断 | 结论依赖的事实可能失效 |
如果周二 09:30 查询显示附件已归档，但台账把验收日改为下周一，应用就应说明两项变化：材料缺口已补齐，原定周四的安排已经变更。用户可以继续准备下周一的验收，或核实排期变更；助手不能仍然输出“本周可以送审”，也不能擅自撤掉此前确认的处理人。
让每项结论知道自己依赖什么
应用保存的业务清单，可以按项关联以下信息：业务对象标识，结论所用字段，来源入口与查询时刻，待核事项，以及人工确认内容。这是一种应用设计，用于判断旧依据还能支持什么，不是 Tansr 自带的验收管理模块。
例如，“P-31 缺归档附件”依赖附件记录；“本周应完成验收”依赖当前排期；“已批准提交”则必须依赖真实批准记录。三者不能合并为一个笼统的“任务完成”。模型可以组织表达，应用需要保留可核对的对应关系。
更新时可以按影响范围处理：附件状态变了，就重新核对材料齐备判断；排期变了，就更新本周清单范围；负责人变了，就提示与人工确认的差异，由有权限的人确认。若无法可靠判断哪些依据受影响，应重新查询相关范围，不能为了少调用一次而沿用不明状态。
人工确认也应有修改入口。新生成的是修订建议，只有得到确认或符合既有业务规则后，才替换正式清单中的相应内容。这样保留的是人的有效决定，而不是让全部旧信息永久不变。
在已有 Node.js 后端中，可以把会话运行和业务查询接在同一应用的不同职责入口：会话关联用户任务，业务函数每次依据已验证的登录上下文读取当前记录，应用保存清单和人工确认。把这三类对象分别管理，才能避免恢复聊天时把旧查询结果当成实时事实。下文说明的是这种集成分工，不依赖特定云产品能力。
Tansr 怎样连接“继续讨论”和“重新查证”？
开发团队通过 defineTool 声明“读取项目台账”“查询附件”“读取批准记录”等工具，说明它们的用途与参数。业务函数的 handler 按当前登录身份查询原系统，返回必要字段、记录标识和来源信息。SDK 组织模型调用工具、接收结果并继续回答；实际数据是否最新、是否允许访问，由业务接口负责。自定义工具与业务实现
这给持续任务提供了具体的接入位置。自行调用模型时，团队需要组织后续请求、工具执行、结果回传和会话上下文；采用 Tansr，可以复用这段运行链，把开发重点放在查询契约、更新规则和已有工作台的交互上。生成判断的能力仍来自所选模型，验收规则和数据仍来自企业系统，不应把它们都归为 SDK 自带能力。
createSessionView 可以把会话事件投影为消息、工具卡、待办、用量、错误和连接状态，供界面呈现“正在重新查询附件”。查询时刻、依据变化、人工确认和正式清单的保存，需要应用另外组织；状态投影不是自动合并业务数据的结果编辑器。会话事件与状态投影
会话历史本身也要按宿主需求保存。SDK 默认使用内存会话，跨重启继续讨论需要接入 SessionStore 等恢复机制；恢复后继续保存仍需配置存储。即使历史恢复成功，取回的也是过去讨论和返回过的信息，不能据此认定业务系统仍处于原状态。会话存储与恢复
准备提交时，再检查当前业务条件
“材料已经补齐”可以支持更新准备清单，但不自动授权提交申请。正式提交时，业务系统仍需根据当前身份、项目状态、审批结果和完整材料校验操作；查询期间发生的变化，不能只靠早先的模型回答排除。
工具运行许可与业务授权同样要分开。模型提出提交、用户在助手中确认调用，都不能赋予用户原本没有的验收权限。提交后也应以申请编号和业务回执展示状态，不能把工具结束显示成验收已批准。工具装配和权限边界
哪些产品需要这套分工？
用户会隔一段时间继续同一任务、根据新事实调整方案，并需要保留自己的业务界面和人工决定时，Tansr SDK 可以承担连续运行层。项目需要匹配的 Node.js／ESM 环境或 Electron 主进程，业务接口必须提供可信的当前状态，应用也要能关联清单、来源和确认记录。
如果需求只是每天定时生成一张固定报表，现有查询与调度加一次模型说明可能已经足够。已有工作流能够处理全部更新和确认时，应先比较沿用它的完整方案；业务接口没有可靠当前状态时，引入运行库也不能解决事实不可信的问题。
评估可以选一个真实只读任务：保存第一次清单，改变一项业务事实，再让用户继续追问。检查新答案是否重新取得相关依据、明确哪些判断变了、保留人工确认，并在无权访问或查询失败时显示待核。这样的结果才能支持采用判断，不能仅凭对话可以继续，就认为业务也已同步。
