AI智能体怎样停下来问人：四种交互控制与适用条件

经营SaaS业务的Hacker News用户CuriousRose提出了一个具体问题：如何阻止AI在需要澄清时自行继续执行。原帖描述了大量想自动化的积压工作，以及对人应该在流程何处介入的困惑。这对应一个实际的接入问题：应用应在哪个环节获取人的决定或补充输入？

Anthropic的building-effective-agents指南提到智能体可在检查点或遇到阻碍时暂停，以获得人类反馈，但没有指定实现这一交互的具体API。本文进一步依据LangGraph和Claude Agent SDK的机制文档，说明可采用的实现路径。

该指南也建议从简单设计开始，并利用环境反馈评估进展。这些建议本身不能决定某个具体动作是否可以跳过人的判断，也没有测量人工澄清频率是否降低。这里的选择依据是应用需要哪一种交互，再结合文档中的前置条件和失败行为判断适用范围。

LangGraph的interrupt()函数允许在图节点代码的任意位置暂停执行并等待外部输入。与静态断点不同，interrupt()是动态的：可以放在代码任何位置，也可以基于应用逻辑条件触发。调用时，LangGraph保存当前图状态并无限期等待，直到通过Command(resume=...)恢复执行。

使用interrupt()有两个硬性前置条件：一个检查点存储器（checkpointer）用于持久化图状态，生产环境应使用持久化存储而非内存；一个线程ID（thread_id）告诉运行时从哪个状态恢复。线程ID是持久游标——复用同一ID恢复同一检查点，使用新值则启动一个空状态的新线程。恢复时必须使用与中断发生时相同的线程ID。

恢复语义是完整节点重放，不是从暂停行继续。运行时从包含interrupt()的节点开头重新执行，中断前的代码会再次运行。因此，中断前的副作用应设计为幂等操作，或分离到独立节点；例如使用相同键和相同结果的upsert，而不是每次创建新记录。否则恢复时可能重复写入或重做工作。

同一节点内的多个顺序中断按索引匹配：恢复时运行时从节点开头重放，每遇到一个interrupt()就检查任务恢复列表中是否有对应索引位置的值。因此中断调用的顺序在节点内必须保持一致，条件跳过或重排会导致索引错位。并行分支中的中断则使用ID映射：每个中断有唯一ID，恢复时将每个ID映射到对应的恢复值。

interrupt()通过抛出特殊异常来暂停执行。如果外围代码用宽泛或裸except捕获后吞掉该异常，中断就无法传回图，暂停失效。文档给出两种有效替代：一是将interrupt()调用与可能出错的代码分离到不同位置；二是只捕获不包含中断异常的特定异常类型，文档以NetworkException为例。从机制上看，重新抛出（re-raise）捕获到的中断异常也能让暂停生效，但文档没有明确列出这一做法，此处作为与机制一致的推断说明。

需要反复校验人工输入时，文档建议每次节点调用只执行一次interrupt()：校验失败就把新问题写入状态，再用条件边回到同一节点。在同一个节点内用while True反复调用interrupt()，后续恢复会重放此前的循环轮次，造成重复工作。设计校验位置和副作用时，应考虑这一重放行为。

Claude Agent SDK的权限评估不是线性管道，而是条件路由。当Claude请求使用工具时，SDK按六个步骤依次检查，但每一步的决策不一定终止评估流程——某些步骤的允许结果仍会继续后续检查，某些步骤的拒绝则直接终止。理解这一条件路由是正确配置暂停行为的关键。

第一步运行钩子。PreToolUse在其他权限步骤之前检查请求，可以拒绝、允许或修改请求。钩子返回allow不跳过后续deny和ask规则，这些规则无论钩子结果如何都会被评估；返回deny则阻止这一工具调用。此外，PreToolUse钩子的allow也不能批准关键路径上的rm或rmdir删除。需要在每次工具调用前执行的检查，应放在PreToolUse入口并实现所需的决策逻辑。

第二步是拒绝规则。如果拒绝规则匹配，工具被阻止，即使在bypassPermissions模式下也是如此。裸名称拒绝规则（如Bash）会在评估开始前将工具从Claude的上下文中移除，因此只有带作用域的规则（如Bash(rm *)）在这一步被检查。

第三步在前置拒绝检查之后处理ask规则和要求人工交互的工具。即使在bypassPermissions模式下，ask规则也可能把请求转向人工确认。AskUserQuestion、标记requiresUserInteraction的MCP工具及组织设为ask的连接器工具，不能按普通allow规则直接预批准。实际路径还受权限模式与SDK交互设置约束：dontAsk会拒绝这类请求；TypeScript的permissionPrompts:'none'会在最终回调步骤跳过canUseTool，PermissionRequest钩子仍有机会决定。

第四步应用权限模式。bypassPermissions批准到达该步骤的调用，但关键路径上的rm和rmdir删除除外。acceptEdits只在文档限定的工作目录或附加目录范围内自动批准文件操作和文件系统命令，受保护路径和关键路径删除不自动批准。plan模式的文件编辑和修改文件的shell命令仍需走回调确认路径。auto模式使用分类器模型审查shell命令和网络请求等操作，逐个允许或阻止；这是自动化操作审查，不是请求人类确认。如果会话在auto模式下切换到不支持auto的模型，会话会回退到default模式。

第五步检查allow规则。普通匹配可以批准调用，但四类操作永不自动批准：AskUserQuestion、标记requiresUserInteraction的MCP工具、组织设为ask的连接器工具、关键路径的rm/rmdir删除。网络路径读取也不由一般allow规则自动批准。这些例外接下来是要求人工确认还是直接拒绝，取决于具体权限模式。

第六步是留待决定的canUseTool回调。dontAsk不调用回调，而是直接拒绝原本需要提示的请求。在支持该选项的TypeScript SDK配置中，permissionPrompts:'none'会跳过这一步的回调，但PermissionRequest钩子仍有机会决定；如果钩子也不决定，则拒绝该调用。如果在预期会自动批准的配置中传入canUseTool回调（如bypassPermissions模式或裸名称allowedTools条目），TypeScript SDK会在查询构造时发出CLAUDE_SDK_CAN_USE_TOOL_SHADOWED警告。带作用域的条目（如Bash(ls *)）和acceptEdits模式不触发此警告，来自settings文件的allow规则对检查不可见。在dontAsk模式下，PreToolUse钩子的allow也不能清除关键路径删除或网络路径读取的限制。

AskUserQuestion是Claude SDK中模型主动发起澄清的机制。当Claude在任务执行中遇到多个有效方向需要用户选择时，它调用此工具生成结构化问题。每次调用支持1到4个问题，每个问题有2到4个选项，用户也可以选择自由文本输入而非预设选项。

AskUserQuestion的可用性需要单独核对。如果通过tools数组显式限制了工具集，就必须把AskUserQuestion列入数组，否则模型无法发起澄清提问。该工具当前也不可用于通过Agent工具生成的子代理。它不能被allow规则预批准，但前置拦截、dontAsk等模式以及适用的SDK设置仍影响实际交互路径。

模型主动提问不是获取用户输入的唯一途径。用户输入文档明确记录了替代方案：开发者可以在自己的应用逻辑中独立提问，不经过canUseTool流程；自定义工具可以构建表单、向导或多步工作流，超越AskUserQuestion的多选格式；流式输入允许人类在任务执行中途主动发送信息，无需等待模型请求。

对于长时间运行的进程，如果用户响应时间可能超过进程存活时间，文档推荐注册一个返回defer决策的PreToolUse钩子，而非在回调中无限等待。这允许进程退出并稍后从持久化会话恢复。文档没有详细说明持久化会话的序列化格式或恢复API。

Claude Agent SDK的流式输入模式提供了人类主动发起的中途干预能力，无需等待模型请求输入。文档列出三种使用场景：在Claude工作时发送取消信号或改变方向；在模型未主动询问时提供额外上下文；构建聊天界面让用户在长时间运行操作期间发送后续消息。流式输入模式把智能体作为长期运行的会话处理输入、权限请求和会话状态，消息可以排队顺序处理。

用户输入文档明确提到可以发送取消信号，但取消信号的具体格式、传递机制以及对正在执行的工具调用的影响，在已加载文档中均未说明。消息排队和取消正在执行的工具不是同一件事。单消息输入模式不支持动态消息排队和实时打断，适合一次性请求或不需要中途干预的环境；它仍可以通过会话状态和恢复继续对话，不能因此称为完全无状态。

流式输入有一个已记录的调试陷阱：在TypeScript SDK中，如果消息生成器抛出异常（例如读取的文件不存在），流会以'Claude Code process aborted by user'的错误信息结束，而非显示原始错误。遇到此消息时应先检查生成器内部代码。错误信息前可能有一行很长的压缩SDK源码，需要读到输出末尾才能看到实际错误文本。Python SDK中，生成器异常只在debug级别记录，会话会挂起而不抛出异常。

这里比较的是文档化行为与接入条件。引用资料没有给出可比的暂停频率、歧义识别率或机制有效性测量，因此不能据此断言哪种框架更可靠。选择依据是交互模式的匹配，不是性能排名。

编程门控只在覆盖的条件处停止。它们不能保证模型识别每一个歧义、不能保证需求本身是合理的、也不能保证完成的工作是正确的。Anthropic的building-effective-agents一文建议从最简单的方案开始，只在确实改善结果时增加复杂度，并强调智能体在每一步都应从环境获取真实反馈来评估进展。

暂停、任务结构设计和独立验证应互相补充。能独立核验结果的工作，可以通过测试或工具反馈补充门控；难以核验的工作，则应审慎决定哪些动作必须先获得人的判断。这是控制设计上的取舍，不是中断有效性的实测结论，也不能把一次暂停当作结果正确的证明。