AI 工作流遇到信息不完整时，可以在依赖这些信息的步骤之前加入问答节点。校验发现字段缺失后，节点暂停当前运行，向用户说明需要补充什么；收到回答后，将内容写入流程变量，再次检查是否满足条件，满足后从暂停位置继续执行。设计重点包括任务状态、问题内容、回答格式、恢复条件和追问上限。

ZGI 的问答节点承接了这段交互链路。它能引用上游变量组织问题，支持直接回答、静态或动态选项，也能从自然语言回答中提取必填字段。回答进入后续节点使用，原来的工作流继续推进。

流程为什么会卡在信息缺口上

企业流程常把输入页面当作唯一的数据入口，用户提交后便直接进入识别、审核或写入环节。现实中的材料经常缺字段、附件或确认项。后续节点拿不到必要数据，只能报错、结束任务，或者转给业务人员手动联系用户。

这类问题很难靠提示词补救。模型可以猜测用户意图，却不应替用户填写税号、金额、日期和审批选择。更稳妥的处理方式是把“信息是否齐全”设为运行条件，缺少关键内容时允许流程停住，并保留已经完成的步骤和当前任务状态。

一次有效追问需要完成五个动作

问答节点接入工作流后，运行链路可以拆成五步：检查必填信息、暂停当前任务、发送具体问题、收集并校验回答、恢复后续执行。用户回答没有通过校验时，节点继续指出缺少的字段；达到追问上限后，再转人工处理或结束任务，避免流程无限等待。

问题内容要尽量引用已经确认的信息。系统已经识别出“购买方税号缺失”，提问就应直接写明需要补充购买方税号。只提示“材料不完整，请补充信息”，用户仍然不知道下一步该做什么，第二轮沟通很可能继续缺项。

回答方式要跟后续动作匹配

问答节点收集到内容后，后续节点还要读取和处理。回答方式应根据数据用途选择，不能一律使用自由文本。

自由文本方便用户表达，字段提取更适合后续自动执行。配置提取字段时，需要写清字段类型、是否必填和有效范围。涉及数据库写入或对外发送的内容，还应在服务端再次校验，不能只采用模型整理后的结果。

恢复流程前还要检查什么

流程能够继续运行，需要保留暂停前的节点结果、任务标识和变量版本。用户隔了一段时间才回答时，系统还要检查原任务是否仍然有效。例如订单已经关闭、审批状态已经变化，旧回答就不宜直接触发后续动作。

追问机制也要有退出路径。可以设置最大回答轮数、等待期限和人工接管条件，并记录每轮问题、回答、字段提取结果与恢复时间。出现争议时，业务人员能够还原系统为何追问、用户补充了什么，以及哪条回答推动了流程继续。

上线前可准备一组不完整输入做测试：缺一个字段、同时缺多个字段、回答格式错误、用户选择不存在的记录、回答超时，以及任务状态在等待期间发生变化。逐条检查流程是否停在正确位置，问题是否明确，旧步骤是否重复执行，恢复后的数据是否进入了正确节点。

GitHub：https://github.com/zgiai/zgi

Gitee：https://gitee.com/zgiai/zgi