等待最容易暴露一项工作的归属是否可靠。交办时上下文都在眼前，结果回来时，人可能已经处理过几件别的事，也关掉了原来的页面。此时再问用户“这份结果应该放在哪里”，就把等待期间本该由产品承担的责任交还给了人。
假设你交办了一项访谈整理：归纳几个主题，保留对应引用，交出一份可核对的说明。它需要一些时间，你先去做别的事。接下来值得关心的，是离开后它是否仍属于原交办，回来时能否找到准确状态，以及最后一步中断时是否需要全部重做。
异步执行的意义就在这段间隔里。人可以暂时把注意力移开，原目标、实际执行与返回结果仍需保持联系。
这种配合也改变了人安排工作的方式。访谈整理负责逐份核对材料，你可以先拟讨论议程；回来后从原会话查看进展和已保存成果，再判断议程是否需要调整。任务保存原要求，执行层承担等待与返回，概览减少追问，成果保存可取得的内容。后台运行只有接上这些环节，才会把等待时间真正还给用户。
离开页面，工作仍要有来处
访谈整理开始后，系统可能先得到几条摘录，再形成临时归类，最后才把主题与引用对齐。中途出现一份文件，仍可能只是未核对的材料。
如果这时就宣布交付，用户离开前看到的完成与回来后取得的内容会互相矛盾。负责这项工作的一方仍需等到对应执行结束，再检查返回是否满足本次要求。等待发生在后台，没有免去交付判断。
因此，开始、处理中、执行结束和成果可用需要各有依据。清楚地表示“已经开始”，让人可以移开注意力；只有真的具备交付条件，才适合告诉人结果已经可供检查。
回来以后，先找原工作
你重新打开原会话时，需要接回的就是刚才那项访谈整理。即使稍后又交办了另一项同名工作，两个结果也应该各自回到原处，而不是按标题或最近打开的页面猜测归属。
Teloa 保留原任务与对应执行的联系，按实际完成通知接回结果。子工作产生的材料回到负责整合的工作，后续整理继续沿原目标发生。名称方便人识别，可靠返回依靠的是已经建立的对应关系。
不同执行方式报告“已开始”和“已结束”的办法也可能不同。产品需要按各自的完成通知等待，把能确认的状态带回原工作。统一的展示应当帮助人理解结果，而不是把不同执行事实一律解释为已经交付。
回来时，原工作也可能已经被本人停止。迟到的结果可以保留记录，却不能借一次完成通知重新启动后续执行。能够收到结果，与仍然获准继续做事，是这段等待中需要分别核对的条件。
最后一步中断，重试的是保存
再往后一步：访谈归纳已经结束，引用也已核对，但在把结果保存成可预览、可下载的成果时发生了中断。此时研究并没有因此重新变成未完成。还没做完的是把已有内容交到用户手中。
当前社区版的独立通用工作，会在执行结束时保留待保存的状态。原执行记录和返回结果仍可读取时，保存失败或重启后可以接着保存同一份内容，无需重新调用模型生成一份替代品。
应该重试的是尚未完成的保存，而不是已经发生的推理与工具工作。否则，最后一步失败就会让前面的等待全部重来，还可能重复消耗费用或再次产生外部影响。
这也解释了为什么执行结束与成果可用值得分别显示。前者告诉人已有结果，后者告诉人内容已经保存并可以取得。把两者混成一个成功状态，用户要么提前取得缺失内容，要么在保存中断时误以为整项工作失败。
如果回来的是子工作的中间材料，原负责者还需完成整合；已经形成的成果，则保留对应版本和生产关系。异步返回的终点，是结果在原工作中有了准确归处。
没收到响应，先判断已经发生什么
等待还有一种更不舒服的情形：页面没有收到回应，人无法判断请求是否执行过。这时，两种状态有不同的下一步：
- 明确失败：根据实际失败处理，判断是否值得重试。
- 结果未知：先核对原请求与已有记录，避免把已经开始或已经完成的动作再做一次。
用户返回后最需要的往往不是一段安慰性的“正在处理”，而是一个可信的起点：这项整理仍在进行，还是已有内容等待保存，或者需要先查清原请求。产品把区别保留下来，人才能决定继续等、查看成果或处理问题。
从离开页面到回来检查，再到保存中断后继续，值得延续的是已经完成的工作。若每次失去回应都只能重新生成，用户得到的只是另一份看似相似的结果，先前花掉的时间和已经发生的行动就失去了位置。