一个知识助手已经显示“请求超时”，后台却还在检索、生成和重试。对用户而言，这次交互已经结束；对基础设施而言，它可能仍是一项活跃工作。本文讨论企业 AI 从单次调用走向多阶段服务之后，如何为这些无人等待的工作划清资源与责任边界。这是长期有效的工程专题，不是某项新产品发布的解读。
交互结束与工作结束，是两个不同的事实
已有的多智能体可靠执行专题讨论了幂等、检查点与副作用恢复。本篇进一步聚焦另一个问题：请求失去使用价值后，怎样确认它不再占用执行资源。二者有关联，但验收证据不同；操作没有重复，并不能证明无用计算及时停止。
gRPC 的取消指南指出，取消信号通常不能直接中断应用正在执行的处理逻辑，应用需要配合停止工作。[1] 因此，网关结束响应、客户端停止接收、工作进程停止计算，应分别观察。跨过进程、队列或第三方接口后，更不能凭一个本地异常推断整条链已经退出。
这会影响容量规划：如果超时请求仍运行到自然结束，新请求就会与旧工作争用资源。这里的因果判断有前提——确实存在持续占用的后端工作，且它占用了当前瓶颈资源。若请求本来只在等待、共享计算仍服务于其他用户，或服务商已完成取消，影响就不同，不能一概按完整推理成本估算。
先决定哪些工作应该随用户离开而停止
建议把服务契约分成两类。交互型工作以本次回答被接收为目标，例如临时文档问答；持久任务以已受理的业务交付为目标，例如用户明确提交的离线报表。前者通常应传播取消，后者不能仅因浏览器断线就被撤销。这是本文提出的划分方法，不是框架自动提供的业务语义。
持久任务应先返回可查询的任务标识，明确受理、运行、完成和取消的含义。断线后继续执行，需要可恢复的状态、结果保留期限和明确的交付方式。取消任务则是一个独立且经过权限检查的业务操作；界面关闭不等于用户表达了撤销已受理任务的意图。
混合场景需要显式选择。交互问答超过等待窗口后，若要转成后台任务，应有事先约定或清楚的用户选择，不能在超时页面背后静默延长执行和计费。多个请求共享一次检索或推理时，也要按仍有效的使用者判断是否停止，避免一个用户取消导致其他请求失败。
总截止时间必须覆盖排队，而不是每一跳重新计时
gRPC 的截止时间文档说明，调用可设置结束等待的时间边界，并在受支持的语言和实现中向下游传播；应用仍应检查实际传播行为。[2] 本文建议在入口定义业务等待预算，再把剩余预算传给每个阶段，而不是让检索、生成和校验各自获得一整份入口预算。
以下为构造示例，并非推荐默认值：用户可等待 20 秒，排队已经耗去 3 秒，检索耗去 4 秒，还要为结果校验和交付预留 2 秒，则生成及其重试最多只剩 11 秒。若生成服务此时重新获得 20 秒，本地配置虽各自合法，整体交互仍会超期。预算应根据业务可接受等待、负载试验和依赖延迟确定。
排队中的任务在出队前就应检查是否过期；没有足够时间完成最小有用工作时，及时拒绝或按契约转交后台。流式响应还应分别定义首段输出、连续输出停顿与完整交付的边界。发送一个字符只能证明开始输出，不能把完整结果的截止时间无限延长。
实施时核对计时范围是否包含连接建立、排队和退避；跨服务传递时避免直接比较未校准的机器时钟。由所用协议和客户端处理剩余时间的转换，并做端到端验证。给每一阶段留出预算有治理价值，但过细的静态切分可能浪费余量，应允许受控共享剩余预算。
取消要有执行证据，重试要有共同预算
建议分别记录取消请求时间、工作者观察到取消的时间、最后一次下游活动时间与资源释放时间。取消已受理只是控制面事实；资源释放需要工作者、队列或服务端状态佐证。若第三方只提供接收确认而没有停止回执，应把实际停止时间标为未知，不能自动填成取消请求时间。
合作式取消需要在可中断边界检查信号，停止新子任务，并清理连接、缓冲和临时资源。长时间不让出控制权的处理逻辑可能延迟响应；强制终止进程虽然更直接，却可能影响同进程其他任务并丢失必要状态。取消响应上限应通过代表性负载下的演练确定，而不是只在空闲机器上测试。
AWS 的超时与重试文章说明，重试会增加服务端负载，超时也不能证明远端副作用没有发生。[3] 本文建议由一个明确层次管理重试，所有尝试共用剩余时限和次数预算。构造两层各最多三次尝试的链路，底层调用最多可达九次；这里的三次包含首次调用，不能与“额外重试三次”混用。
对于只读生成，超期后通常不应再启动尝试；对已发送的业务写入，则先按稳定操作标识查询结果，保留未知状态并交由既定恢复流程处理。取消计算、撤销业务操作和退还费用是三项独立能力。没有提供方的明确规则与回执，不能把其中任何一项当成另外两项的证明。
用可解释的成本账替代一个取消成功率
一个构造算例：100 个已经放弃等待的请求，各继续运行 12 秒，合计为 1,200 请求秒。它可以描述残余工作的时间规模，却不是 1,200 GPU 秒，更不是某个金额。共享批处理、并行度、实际设备占用和服务商计费粒度都会改变成本，必须用相应资源记录与账单核对。
建议分别看交互放弃率、取消传播延迟、取消后仍活跃的任务数、残余资源消耗和结果未知的业务操作数。分母应写清是全部受理请求、发出取消的请求，还是有停止证据的请求。只对有回执的样本计算停止速度，会遗漏最需要处理的未知情况。
优化时同时观察成功交付比例。过短的时限可能减少单次残余消耗，却提高用户重复提交量；过于激进的取消可能毁掉一个即将完成、仍有价值的持久任务。应在同类任务和可比负载下比较用户层面的完成、总尝试量和资源消耗，不能只挑一条变好看的曲线。
上线验收应覆盖五个边界
第一，在排队时取消，检查任务不会在稍后被执行。第二，在只读生成中取消，核对工作者观察信号与实际停止的间隔。第三，在调用子服务后取消，检查是否还会创建新的子任务。第四，让一个依赖不响应取消，确认系统能标明限制、隔离迟到结果并保留待核对状态。
第五，在模拟业务写入已经发生、回执尚未返回时取消，检查系统不会把未知误记为未执行，也不会自动换标识重做。演练应使用隔离环境和模拟服务，不能为测试制造真实订单或通知。每项都保留开始条件、预期不变量、实际观察和未覆盖路径。
验收门槛由业务后果决定：交互型助手关注停止新工作与资源回收；持久任务关注可查询状态和可靠交付；含写入的流程还要核对外部事实。采购或扩容之前，要求供应方说明哪些阶段支持取消、哪些只能停止等待、哪些无法提供停止证据。明确这些差异，才能判断成本控制承诺是否有可检验的基础。