1. 项目概述当用户改变主意时我们如何评估智能体在构建基于大语言模型的智能体时我们常常醉心于其完成复杂任务的能力比如让它去网上订一张机票、查找某个产品的价格或者撰写一份报告。我们设计精妙的提示词构建复杂的工具调用链并为其设定一个明确的终点目标。然而现实世界中的交互尤其是像网页导航这类长流程任务充满了不确定性。最典型、也最容易被忽视的一个场景就是用户中途改变主意了。想象一下你让一个智能助手帮你查找“从北京到上海最便宜的航班”。当它正在搜索页面中翻看结果时你突然想起下周有个重要会议于是补充了一句“等等还是帮我查一下高铁票吧。” 一个理想的智能体应该能像人类助手一样从容地停下当前的搜索动作理解你的新意图并转向高铁票查询。但如果它“一根筋”地继续搜索航班甚至因为你的打断而陷入逻辑混乱、报错或死循环那么这个智能体的实用性和鲁棒性就大打折扣。这正是《When Users Change Their Mind: Evaluating Interruptible Agents in Long-Horizon Web Navigation》这篇工作所关注的核心问题。它不再仅仅测试智能体能否“走到终点”而是深入拷问当任务目标在过程中被动态修改时智能体能否被优雅地“中断”并灵活地“转向”新任务这项工作提出了一个名为InterruptBench的评估基准专门用于衡量智能体在长视野网页导航任务中的“可中断性”。对于所有正在开发或应用LLM智能体的开发者、研究者和产品经理而言理解并解决“可中断性”问题是将实验室原型推向真实、可用产品的关键一步。2. 可中断智能体的核心价值与挑战2.1 为什么“可中断性”至关重要在传统的智能体评估中我们通常设定一个静态的、单一的任务指令然后看智能体能否成功完成。这就像给学生一张固定的试卷只关心最终得分。但现实的人机协作是动态的、多轮的、充满变数的。用户可能因为获取了新信息、改变了偏好或者单纯就是有了新的想法而随时调整任务目标。可中断性的价值体现在多个层面用户体验这是最直接的。一个不能被中断的智能体会让用户感到挫败和失控仿佛在与一个固执的、听不懂人话的机器对话。而一个能流畅处理中断的智能体则能提供类似与真人协作般的自然和舒适感。系统效率当用户改变主意时一个可中断的智能体能立即停止无用的计算和操作如继续加载无关网页、调用无效API节省计算资源和时间快速响应新的有效指令。安全性与可靠性在某些场景下不可中断可能导致严重后果。例如一个正在执行“删除所有日志文件”的自动化智能体如果用户紧急喊停却无法中断就会造成数据丢失。可中断性是一种重要的安全机制。智能体进化的必经之路要实现真正自主、长期运行的智能体如自动运营社媒、持续监控数据的Agent它们必须能处理来自环境或用户的外部干预和指令更新。可中断性是实现长期自主性和人机协同的基础能力。2.2 实现可中断性面临哪些技术挑战让一个基于LLM的智能体变得“可中断”远非在代码里加一个break语句那么简单。它涉及到智能体架构、记忆管理、状态重置等多个层面的复杂问题上下文理解与意图切换这是最核心的挑战。智能体必须准确理解用户的“中断指令”是一个全新的、替代性的任务还是对原任务的补充或修正它需要对比新旧指令的差异并据此决定是彻底转向还是合并执行。例如“查航班”变成“查高铁”是任务替换“查最便宜的航班”变成“查明天早上最便宜的航班”则是任务细化。复杂状态的管理与重置在长视野网页导航中智能体已经执行了一系列动作点击、输入、滚动其内部可能维护着一个复杂的“状态”包括当前的URL、页面DOM的解析信息、历史动作序列、临时目标等。当任务中断时这些状态哪些需要保留如登录状态哪些必须清空如针对旧任务的页面元素定位需要精细的设计。工具执行的中断与回滚智能体可能正在调用一个耗时较长的工具如执行一个复杂的数据库查询。如何安全地中止这个正在进行的调用如果工具调用已经产生了一些副作用比如在测试环境中创建了一个临时文件是否需要以及如何进行回滚操作提示工程与思维链的中断许多高级智能体采用CoT或更复杂的推理框架。当用户中断时智能体正在进行的“思考链”可能已经部分偏离了新任务。如何设计提示让智能体能果断地放弃无效的旧推理基于新指令重新规划评估指标的缺失在InterruptBench出现之前业界缺乏一个系统化的方法来量化评估智能体的可中断性。我们无法回答“智能体A比智能体B在应对用户变卦方面好多少”这个问题。3. InterruptBench一套系统化的评估基准为了应对上述挑战特别是解决评估指标缺失的问题InterruptBench应运而生。它不是一个单一的测试集而是一个精心设计的评估框架和一套标准化的任务集合。3.1 基准的核心设计思想InterruptBench的构建遵循了几个关键原则真实性中断场景来源于对真实人机交互行为的模拟和分析确保评估的是实际会遇到的问题。多样性涵盖了不同类型的中断包括任务替换完全转向新任务、任务细化增加约束条件、任务泛化放宽约束条件以及任务纠正修正原指令中的错误。可度量性设计了一套清晰、可计算的指标使得不同智能体的表现可以客观比较。基于现有生态它建立在成熟的网页导航仿真环境如WebShop、MiniWoB等之上利用这些环境提供的网页交互模拟能力来构建长视野任务。3.2 任务结构与中断注入一个典型的InterruptBench任务流程如下初始任务智能体接收到一个长视野的网页导航指令例如“在购物网站X上找到品牌Y的无线耳机将其加入购物车”。任务执行智能体开始执行进行搜索、筛选、浏览商品详情等操作。中断点在智能体执行过程中的某个预定义或随机的关键时刻系统会向智能体注入一个中断指令。例如当智能体刚进入耳机列表页时中断指令到来“等等我改主意了帮我找品牌Z的有线耳机。”后续执行智能体需要处理这个中断指令并继续操作直至达到新任务的终点或失败。3.3 核心评估指标详解InterruptBench的评估不仅仅看最终新任务是否成功它从多个维度进行精细化度量中断成功率这是最直接的指标。智能体在接收到中断指令后是否成功停止了针对旧任务的行为如果一个智能体在被告知“别找耳机了”之后仍然继续点击耳机的购买按钮那么其中断成功率就是0。任务转向成功率智能体在成功中断后能否正确理解并执行新任务最终完成它这衡量了智能体的意图切换和再规划能力。综合成功率将上述两者结合即智能体既成功中断了旧任务又成功完成了新任务的比例。这是衡量可中断智能体整体效能的黄金指标。效率指标冗余步骤数中断后智能体继续执行的、与新旧任务都无关的或纯粹浪费的动作数量。恢复步数从接收到中断指令到智能体执行第一个明确针对新任务的有效动作所经历的步骤数。这个值越小说明智能体转向越快。健壮性指标在多次运行中智能体表现的一致性如何是否有些中断类型会导致其完全崩溃注意评估时基准会严格区分“智能体主动确认中断”和“智能体默默执行转向”。前者可能更安全如回复“好的已停止查找无线耳机现在开始为您查找有线耳机”后者则更高效。不同的设计哲学可能会在指标上有所体现InterruptBench通常能兼容这两种模式。4. 构建可中断智能体的关键技术方案了解了评估标准我们来看看如何从技术层面构建一个能够通过InterruptBench考验的智能体。这通常需要在智能体的架构层面进行增强。4.1 架构模式监控-执行分离一种有效的模式是引入一个独立的“监控模块”或“中断处理器”。这个模块与核心的任务执行模块并行运行或处于更高层级。职责持续监听用户输入和环境反馈。一旦检测到可能的中断指令可通过关键词触发、意图分类模型或始终将最新用户输入与当前任务对比立即向执行模块发送高优先级的中断信号。优势职责分离使系统更清晰。执行模块可以专注于规划步骤而监控模块专注于响应用户的动态干预。实现示例在每次LLM调用进行下一步规划前先检查“中断信号队列”。或者设计一个专门的“中断判断”提示让一个小型LLM或分类器快速判断最新消息是否为中断指令。4.2 状态管理显式任务栈与上下文切换这是实现优雅中断和转向的核心。智能体需要维护一个显式的、结构化的任务状态。任务栈将任务建模为一个栈结构。初始任务入栈。当收到一个明确的新任务中断时可以将旧任务挂起压入栈底或保存到旁路新任务入栈并成为当前焦点。如果新任务完成可以弹出栈理论上可以恢复旧任务虽然在实际网页导航中较少恢复但架构上支持。上下文隔离与保存为每个任务维护独立的上下文窗口。当任务切换时当前LLM的对话历史、工具调用记忆等可以被打包保存起来然后为新任务加载一个干净的或基于新指令初始化的上下文。这能有效防止新旧指令相互干扰。全局状态与局部状态区分哪些状态是全局的如用户登录会话、网站偏好设置哪些是任务局部的如当前要搜索的商品关键词。中断时全局状态保留局部状态重置。4.3 提示工程强化中断意识与元认知通过精心设计的提示词让LLM内核具备处理中断的能力。在系统提示中明确能力在给智能体的初始指令中就明确告知“你是一个可以随时被用户新指令中断的助手。当用户提出明显不同于当前任务的新要求时你应该立即暂停当前计划优先响应用户的最新指令。”结构化输出以包含状态标识要求LLM在每一步的输出中不仅包含要执行的动作还包含当前正在服务的“任务ID”或“目标摘要”。当处理新输入时可以快速对比新输入的目标与当前任务目标从而判断是否为中断。设计“中断判断”与“任务对比”链在收到用户新输入后不直接将其作为下一步的指令而是先让LLM运行一个快速的子步骤“请判断用户的最新消息1. 是对当前任务的补充说明吗2. 是一个全新的、替代当前任务的要求吗3. 还是一个无关的闲聊” 根据这个判断结果再决定后续流程。4.4 工具层的中断支持智能体依赖的工具如浏览器操作、API调用也需要支持中断。可取消的异步调用将工具调用设计为异步操作并暴露取消接口。当监控模块发出中断信号时执行模块可以尝试取消正在进行的耗时工具调用。原子操作与副作用管理尽量将工具设计为原子操作并明确其副作用。对于有副作用的操作如“提交订单”需要更谨慎的中断逻辑可能需要引入确认机制或回滚操作在仿真环境中测试时尤为重要。5. 实操基于现有框架实现一个基础可中断智能体让我们以流行的LangChain框架为例勾勒一个基础可中断智能体的实现思路。这里我们假设一个简单的网页导航场景。5.1 定义智能体状态与记忆首先我们需要扩展智能体的记忆使其能保存多个任务上下文。from typing import Dict, Any, Optional from pydantic import BaseModel class TaskContext(BaseModel): 单个任务上下文 task_id: str original_instruction: str current_goal: str # 当前目标可能会被细化 history: List[Dict] # 该任务下的对话和动作历史 status: str # “running”, “paused”, “completed”, “aborted” class InterruptibleAgentMemory(BaseModel): 可中断智能体的记忆体 current_task_id: Optional[str] tasks: Dict[str, TaskContext] {} # 任务ID到上下文的映射 global_session_info: Dict[str, Any] {} # 全局信息如登录cookie5.2 构建中断处理器实现一个简单的中断处理器它比较用户新输入与当前任务目标。class SimpleInterruptHandler: def __init__(self, llm): self.llm llm def detect_interrupt(self, current_goal: str, user_new_input: str) - Dict: 检测用户输入是否为中断指令并返回中断类型 prompt f 当前任务目标{current_goal} 用户最新消息{user_new_input} 请分析用户的最新消息 1. 如果它是当前任务的细化、澄清或补充回答“REFINE”。 2. 如果它是一个全新的、替代当前任务的要求回答“REPLACE”。 3. 如果它与当前任务无关或意图不明回答“OTHER”。 只输出一个单词REFINE, REPLACE, 或 OTHER。 response self.llm.invoke(prompt).strip() return {type: response, new_input: user_new_input}5.3 集成到智能体执行循环修改智能体的主循环在每个步骤前检查中断。class InterruptibleWebAgent: def __init__(self, llm, tools, interrupt_handler): self.llm llm self.tools tools self.interrupt_handler interrupt_handler self.memory InterruptibleAgentMemory() def run(self, initial_instruction: str): # 初始化第一个任务 task_id task_1 self.memory.tasks[task_id] TaskContext( task_idtask_id, original_instructioninitial_instruction, current_goalinitial_instruction, history[], statusrunning ) self.memory.current_task_id task_id while True: current_task self.memory.tasks[self.memory.current_task_id] # 1. 获取用户输入在实际中这可能来自一个监听器 user_input self._get_user_input() if user_input: # 2. 检测是否为中断 interrupt_result self.interrupt_handler.detect_interrupt( current_task.current_goal, user_input ) if interrupt_result[type] REPLACE: # 处理任务替换型中断 print(f[中断] 检测到新任务正在切换...) # 暂停旧任务 current_task.status paused # 创建新任务 new_task_id ftask_{len(self.memory.tasks)1} new_task TaskContext( task_idnew_task_id, original_instructioninterrupt_result[new_input], current_goalinterrupt_result[new_input], history[], statusrunning ) self.memory.tasks[new_task_id] new_task self.memory.current_task_id new_task_id # 更新当前任务引用 current_task new_task # 将用户输入作为新任务的起始指令 user_input_for_execution interrupt_result[new_input] elif interrupt_result[type] REFINE: # 处理任务细化更新当前任务目标 current_task.current_goal f{current_task.current_goal}。额外要求{interrupt_result[new_input]} user_input_for_execution interrupt_result[new_input] else: # 其他情况如闲聊可能忽略或简单回复 user_input_for_execution None else: user_input_for_execution None # 3. 执行当前任务的一步基于当前任务上下文 if current_task.status running: # 构建包含当前任务历史的提示 prompt self._build_prompt_for_task(current_task, user_input_for_execution) llm_response self.llm.invoke(prompt) # 解析响应调用工具... action, action_args self._parse_response(llm_response) if action FINISH: current_task.status completed break # 执行工具调用这里应是可取消的 result self._execute_tool(action, action_args) # 将这一步记录到当前任务历史中 current_task.history.append({action: action, args: action_args, result: result}) else: # 没有运行中的任务可能等待或结束 break5.4 关键参数与配置心得中断检测阈值在更复杂的实现中中断检测可能不是一个非此即彼的分类而是一个置信度分数。你需要设定一个阈值来决定何时触发任务切换。设置过高会导致对用户新指令反应迟钝设置过低则容易因用户的随口一提或细化提问而频繁切换任务造成混乱。历史上下文长度每个TaskContext中保存的历史长度需要限制以防超出LLM上下文窗口。对于被暂停的旧任务可以只保存关键摘要而非完整历史。工具调用的超时与取消在_execute_tool函数中需要实现超时机制并在收到中断信号时尽可能优雅地终止正在进行的工具调用例如关闭网络请求。6. 常见问题与实战避坑指南在实际开发和评估中你会遇到各种各样的问题。以下是一些典型问题及解决思路。6.1 智能体对中断“反应过度”或“反应不足”问题现象用户只是对当前任务问了个细节问题如“这个商品有红色吗”智能体就判定为全新任务重置了所有状态或者用户明确说了“不要这个了换一个”智能体却无动于衷。排查与解决优化中断检测器问题通常出在中断检测的提示词或模型上。尝试用更多、更高质量的例子用户消息 中断类型来微调一个小模型做分类或者设计更精细的提示词链让LLM先判断用户意图是“询问”、“修正”还是“替换”。引入置信度与确认机制当检测到可能是“替换”型中断但置信度不高时可以让智能体进行确认“您是想让我停止寻找XX开始寻找YY吗” 这虽然增加了一步交互但能大幅减少误判。分析错误案例在InterruptBench上运行你的智能体仔细分析那些“中断失败”或“误中断”的案例看看用户指令和智能体判断之间的具体差异从而有针对性地调整。6.2 任务状态污染与残留问题现象智能体切换到新任务后其对话或思考中仍然残留着旧任务的词汇、目标或逻辑导致执行混乱。例如从“找耳机”切换到“找书包”但智能体仍在对话中提及“蓝牙”、“降噪”等词。排查与解决严格上下文隔离确保在架构上实现彻底的任务上下文切换。切换任务时发送给LLM的提示词应该是一个“干净”的开场只包含新任务指令和必要的全局信息绝不混入旧任务的历史。使用系统角色强引导在每次任务切换后的第一条系统提示中强烈声明“你刚刚完成了一个任务。现在请完全忘记之前的一切专注于以下全新任务[新任务指令]”。验证状态重置在仿真环境中设计测试用例专门检查智能体在中断后执行的第一步动作是否完全符合新任务而与旧任务无关。6.3 在复杂、多步骤任务中中断点难以确定问题现象InterruptBench中的中断点是预设的但真实场景中用户可能在任何时刻打断。智能体如何在一个长链条的推理和操作中找到一个“安全”的停顿点来响应用户排查与解决设计“可中断”的原子动作将智能体的规划粒度细化。不是规划一个“购买商品”的宏动作而是规划一系列“搜索关键词-点击商品链接-选择颜色-加入购物车”的原子动作。在每个原子动作执行后都检查一次用户输入队列。这增加了响应频率。异步监听实现一个真正的异步输入监听线程。当用户输入到来时不是等待当前动作完成而是立即设置一个“中断请求”标志。当前原子动作一旦完成智能体在规划下一步前检查该标志并优先处理中断。权衡响应性与效率更频繁的中断检查意味着更多开销。需要在架构设计上做出权衡例如在关键决策点如页面加载完成时进行检查而不是在每一个微操作之后。6.4 评估结果与真实体验不符问题现象智能体在InterruptBench的自动化评估中得分很高但在真人测试中用户仍觉得它“笨拙”或“不理解我”。排查与解决评估指标的局限性自动化指标如成功率、步骤数无法完全捕捉交互的流畅度和自然度。一个智能体可能机械地完成了任务切换但它的回应如“已中断旧任务开始新任务”非常生硬。引入人工评估与用户体验指标除了自动化测试必须进行小规模的真人测试。关注定性反馈智能体的回应是否令人满意切换过程是否感觉自然用户是否需要进行额外解释丰富中断类型InterruptBench的覆盖度可能不足。收集真实用户与智能体的对话日志从中挖掘更复杂、更模糊的中断案例并补充到你的测试集中。构建一个真正鲁棒、可中断的智能体是一个持续迭代的过程。InterruptBench为我们提供了宝贵的“标尺”和“训练场”但最终我们需要将智能体置于更开放、更动态的真实用户环境中去打磨。从关注“能否完成任务”到关注“能否优雅地应对变化”这标志着智能体技术正从演示走向实用。