交互式与后台 Agent 怎么选：中途决策和完成通知分开
比较持续对话执行与后台任务，说明输入澄清、状态查询和结果取回应如何设计，并检查超时后是否真的完成。
怎样选择更合适
需要随时澄清条件或让使用者检查中间结果时，保留交互式执行；要求已明确、运行较久且可以稍后领取结果的任务，可以评估后台方式。后台不等于无限运行，也不代表任务会自动成功。必须给出完成状态和结果取回方式，不能把浏览器页面关闭当作业务已经结束。
后台执行改变等待方式而非成功标准
OpenAI 的 background mode 说明允许受支持的长请求在后台处理，并通过查询状态等方式取回结果。Agents SDK 的运行说明也区分运行过程和结果。具体支持由接口决定，不能把普通同步请求简单断开就当作后台任务。
交互式任务可以在输入缺少条件时及时追问，后台任务则需要预先约定缺失信息的处理。若下一步取决于人的判断，可以暂停并保存状态，而不是让模型自行猜测。操作权限和完成要求也不会因为后台执行而自动改变。
同一资料任务检查等待与恢复
用一份固定资料生成报告，分别记录实时执行和后台执行的任务标识。人为中断客户端等待后，检查是否仍能查询任务状态并取回同一份结果。若出现失败，应能看出是任务报错还是只是客户端没有等到。
再用缺少关键资料的样本检查行为，要求明确返回未完成原因。后台结果到达后也要核对文件可打开和内容范围，不只确认收到通知。此处是验证设计，没有启动任何长期任务，也没有测试某服务的完成率。
把查询状态和通知重复计入维护
后台方式需要维护状态查询与完成通知，重复通知应指向同一个任务，而不是重新执行。交互式方式则要处理连接中断与会话继续。比较总耗时之外，还要记录用户为找回结果付出的操作，避免只优化服务器处理时间。
先定义任务最长等待和失败后的恢复方式，再考虑自动调度。能明确说明“已完成”“失败”或“等待补充”的系统，才便于持续使用。若接口的保留时长或数据条件不适合任务，应选择其他执行方式，不能照搬演示配置。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。