我最近遇到一个很容易误判的场景：同样是给 AI 发了一句话，有时它会马上回一段完整答案，有时当场只留下很短的返回，甚至界面看起来只有提问，没有回答。前一种情况，人通常会顺手把当场看到的文字当成结果；后一种情况，很多人第一反应是“任务失败了”，然后重发一次。
但这次追查发现，第二种判断并不成立。一次本地工作任务已经生成了完整文档，只是调用方当场拿到的回答很短，完整内容要按照会话标识再取回。表面上看，这是返回长度的问题；实际上，它考验的是我们有没有先分清：眼前是一场同步对话，还是一个需要在后台工作的 Agent 任务。
**同步对话验收的是当场回答，异步工作任务验收的是会话中的新增回合和最终产物。**如果把这两种会话压成同一套规则，系统就会在最不该重试的时候重试，在已经完成的时候再次派发。
当时的问题，不是回答短
这次的起点，是想让一个工作任务继续回答关于作图、做视频和参数选择的问题。前面一轮已经把相关方法查成了文档，后面又希望在原有上下文里追加一轮提问。这个需求很自然：既然同一个 Agent 已经理解了前文，就没有必要每次重新开一个会话，把背景再讲一遍。
真正麻烦的是，工作任务的回合并不像普通聊天那样即时完成。调用方发出追问以后，返回值里有一个回答长度字段，但它很小。若只看这个数字，很容易得出“没有回答”的结论。可再按同一个会话标识取回内容，就能看到新增的用户回合和 Agent 回合，完整答案也已经落盘。
这里有一个很重要的区别：问题是否送达，和回答是否已经完整生成，不是同一个时刻发生的事。提问已经进入会话，并不意味着 Agent 此刻已经把长答案写完；当场返回了一小段，也不意味着后面不会继续生成。
如果不处理这个区别，后果不只是多跑一次任务。重复派发会造成上下文分叉，两个 Agent 可能同时处理同一个问题；调用方还可能把两份结果混在一起，最后不知道哪一份才是最新答案。更糟的是，重试行为会掩盖真正的慢，而不是解决慢。
表面信号为什么会骗人
我一开始也会下意识看“这次返回了多少字”。这个信号在普通聊天里确实有用，因为聊天的目标就是让当前请求尽快得到完整回答。当场没有答案，通常就是没有完成；当场有答案，通常可以直接交给后续流程。
但工作任务多了一层执行过程。它可能需要读取资料、调用本机能力、写文件，再把结果整理回会话。界面先显示提问，或者调用接口只返回开头预览，并不奇怪。服务端和界面之间还可能有过滤、延迟或展示不同步，界面上的“看到了什么”不能自动等同于“模型侧完成了什么”。
这件事让我重新意识到，验收不能只盯着最后一个可见文本。一个工作系统的状态，至少包含派发是否成功、会话是否匹配、有没有新增回合、产物是否存在，以及回答是否已经完整取回。把这些状态都缩写成一个长度字段，当然简单，却把最有价值的区别丢掉了。
**短预览是展示状态，不是失败结论；只有结合会话性质和后续取回结果，长度才有解释力。**同样的 20 个字，在同步聊天里可能意味着回答严重不完整，在异步任务里却可能只是“任务已接收，完整结果稍后取回”。
先给会话分类，再决定怎么验收
我选择先判断会话性质，是因为验收规则必须跟执行机制相配。现在可以把会话至少分成 3 类：直接聊天、工作任务，以及暂时无法确认但疑似工作任务的会话。
直接聊天的特点是回答同步返回。当场拿到的文本就是主要结果，后续最多做格式检查，不需要为了一个短返回去另找一份后台转录。工作任务则相反，当场返回可能只是预览，完整答案要等 Agent 回合结束，再按会话标识取回新增转录。无法确认的会话不能贸然当成聊天处理，宁可按工作任务的保守规则多等一步。
分类不能主要靠人的记忆，也不能只靠页面长相。比较稳妥的做法，是在派发时留下台账，把会话标识和任务性质绑定起来。调用方后续追问时，先查这份确定性记录；如果没有命中，再用页面上的模式信号做回退判断。台账优先，是因为“这条会话由工作任务入口创建”比“页面现在看起来像什么”更可靠。
这里最容易走的错误捷径，是把所有会话都当成同步聊天，或者反过来把所有会话都当成异步任务。前者会在 Agent 尚未完成时重发，后者会让普通聊天变得迟钝，明明已经有完整回答，却还要走一遍等待和取回流程。分类不是为了增加字段，而是为了让后面的完成证据有正确的解释方式。
把“完成”拆成几种证据
分类之后，我会把验收拆成 3 层，而不是追求一个万能的“成功”标记。
第一层是送达证据：提问是否确实出现在目标会话里。只要会话里能看到新增的问题，就说明消息已经送到，不能因为回答还没出现就重派。第二层是执行证据：工作任务是否产生了新的 Agent 回合，或者完成了约定的产物。它回答的是“后台有没有做事”，不是“界面有没有马上展示”。第三层是交付证据：完整转录和需要的文件是否已经取回，并且内容能满足原问题。
同步聊天通常可以在第 3 层直接验收，因为送达、执行和回答几乎连续发生。异步工作任务则要把它们分开看：先确认送达，再等待执行，最后按会话标识取回完整转录。若只看到第 1 层，却没有新增回合，应该等待或查状态；若已经有新增回合但回答很短，应该继续取回，而不是重发；若转录完整但产物缺失，才需要进一步检查任务本身。
我还会在返回值里保留 3 个机器可读信号：会话类型、回答是否只是预览、下一步应该怎样取回。它们的意义不在于让返回值看起来更复杂，而在于把判断责任从调用方的临场猜测，移到系统可以执行的规则上。调用方不必记住每类会话的历史，只需按信号选择等待、直接使用或取回。
同一会话追问，改变了验收边界
同一工作任务可以继续追问，是这次方法变得更完整的地方。前一轮已经建立了上下文，后一轮只需追加问题，就能让 Agent 在原有语境里继续工作。这样做的价值不只是少写几句背景，更重要的是，前一轮的判断和资料不会被重新解释一遍。
但复用上下文也带来新的验收边界。追问成功，不等于新答案已经完整；会话标识保持不变，也不等于新增回合已经生成。每次追问都要记录“这次新增了什么”，取回时不能只看到旧回答就宣布完成。否则，系统可能把上一次的成功误当成这一轮的成功。
因此，工作任务的派发表和会话转录要能对应起来：这一次派发的问题是什么，复用了哪个会话，取回前后新增了哪些回合，最终产物对应哪一轮。这里不要求记录所有执行细节，但至少要留下能回答“这份结果是不是这次追问产生的”这件事的证据。
我没有把所有类型的工作任务都强行归成同一类，因为本地工作、云端工作可能有不同的完成信号。当前已经验证的是：有明确派发记录的工作会话可以确定分类；没有记录但缺少普通聊天模式的会话，先标为疑似工作任务并按保守路径处理。真正难的不是把标签写得漂亮，而是在证据不足时不做过度自信的判断。
这套方法还能用在哪里
这个方法不只适合 AI。凡是一个请求会先被接收、再被后台执行、最后异步回传结果的系统，都不应该把“接口当场返回了什么”当成“任务最终完成了什么”。文件转换、批量导出、数据分析和远程构建，都有类似的时间差。
可复用的流程可以这样记：先给请求标注同步或异步；同步请求验收当场完整响应；异步请求先记下派发表和会话标识，再确认问题送达；随后检查新增回合或产物；最后取回完整记录，按本轮新增内容验收。遇到无法分类的情况，采用异步的保守规则，直到出现足够明确的类型信号。
这套规则还有一个好处：它把“等待”变成了有证据的动作。等待不是盲等，而是在等新的回合、状态变化或产物出现；取回也不是重复请求，而是在按已知会话边界采收结果。一个流程成熟的标志，不是它能在顺利时马上报成功，而是它在慢、短、空和不确定时，仍然知道下一步该查什么。
下次我会怎么做
下次遇到任何 AI 返回，我会先问自己：这是一场直接对话，还是一个需要后台完成的工作任务？如果是直接对话，我检查当场答案是否完整；如果是工作任务，我先确认提问已经进入正确会话，再等待新增回合，最后按会话标识取回完整转录和产物。
我不会再把回答长度当成单独的成功标准。短返回只说明当前展示得少，究竟是完整回答、预览，还是尚未完成，要由会话类型和取回信号共同解释。若系统已经明确告诉我这是预览，我就不会因为着急看到长答案而重发；若它无法确认类型，我会选择更保守的取回路径。
**真正可靠的验收，不是更快地宣布成功，而是让每一种会话都有与它匹配的完成证据。**这件事让我看到，Agent 工作流的难点从来不只是“能不能调用”，还包括调用之后能不能知道自己究竟拿到了什么。把这个判断链留下来，下一次面对慢回答时，我就不必靠猜，也不会用一次错误重试制造更多混乱。