长任务说停就停?大部分 Agent 框架根本做不到

📅 2026/7/8 7:52:25
长任务说停就停?大部分 Agent 框架根本做不到
「Regnexe 实战系列」第 8 篇共 10 篇对应仓库ExampleReadme08PauseResumeTest。上一篇07. 三层记忆模型。一个生产环境绕不开的需求任务跑到一半用户突然要补充一条信息或者干脆想先暂停去做别的事——这个需求在 Demo 阶段基本不会被考虑但只要 Agent 真正跑起来处理稍微长一点的任务说停就停、说续就续几乎是刚需。很多框架的暂停本质上是杀掉进程/线程恢复就是重新跑一遍——上下文全丢等于没有暂停。这正是 harness 该管的事Regnexe 把暂停恢复做成了一等公民能力pause()可以从任意线程调用状态会持久化resume()能带着新的上下文接着跑。实战代码用 CountDownLatch 精确控制时序暂停功能不好写单测——你怎么保证恰好在工具执行中间调用pause()仓库ExampleReadme08PauseResumeTest给出了一个很实用的技巧用两个CountDownLatch卡住时序不依赖真实网络延迟去赌时间窗口。CountDownLatchtoolStartednewCountDownLatch(1);CountDownLatchpauseSignalednewCountDownLatch(1);ToolslowWeatherToolTool.builder().name(get_weather).description(Get todays weather for a city.).params(city: String -- city name).func(city-{toolStarted.countDown();// 告诉外面工具已经开始执行try{pauseSignaled.await(15,TimeUnit.SECONDS);// 卡住等外面发出暂停信号}catch(InterruptedExceptione){Thread.currentThread().interrupt();}returnBeijing: sunny, 22 C, excellent air quality.;}).build();RegnexeAgentagentregnexeAgentBuilder.withDefaultModel(Vendor.ALIYUN,deepseek-v4-flash).withTool(slowWeatherTool).withTaskStore(newInMemoryTaskStore())// 暂停/恢复必须有持久化状态这一行不能省.withEventListener(newConsoleEventListener()).withMaxRounds(3).build();TaskRequestrequestnewTaskRequest();request.setSessionId(UUID.randomUUID().toString());request.setGoal(Check todays weather in Beijing. Is it good for running?);// 后台线程发起执行ExecutorServicepoolExecutors.newSingleThreadExecutor();FutureAgentResultfuturepool.submit(()-agent.execute(request));toolStarted.await(30,TimeUnit.SECONDS);// 确认工具已经在跑agent.pause();// 在任意线程调用——这里就是主测试线程pauseSignaled.countDown();// 放开工具让它正常返回AgentResultpausedfuture.get(30,TimeUnit.SECONDS);// paused.getStatus() PAUSEDAgentResultresumedagent.resume(request.getSessionId(),Also factor in todays air quality index.);// resumed.getStatus() FINISHED关键点拆解pause()不是立刻杀死任务。它设置的是一个停止信号正在执行的工具调用会自然走完下一次是否继续的检查点才会真正让任务停下来状态落到PAUSED并持久化进TaskStore。这是故意设计的——粗暴中断一个正在写数据的工具调用比等它跑完更危险。resume()不是从头再来一遍。它会找到该sessionId下最近一次可恢复的任务带着你传入的补充上下文Also factor in todays air quality index.接着跑之前几轮的执行记录也就是上一篇讲的 Task 账本会被自动注入进续传的 Prompt——模型知道之前已经做了什么不会从零开始重复劳动。withTaskStore(new InMemoryTaskStore())这一行不能省。暂停状态总得存在某个地方默认的InMemoryTaskStore够本地测试用生产环境想要跨进程、跨实例恢复就得换成自己的持久化实现——这个接口和前面讲的Marketplace、ConversationStorage是同一套设计哲学默认内存实现关键扩展点全部接口化。适用场景长耗时任务用户中途想插入新信息“等一下预算改成 5000 了”需要人工审批介入的流程——跑到某一步先停下等审批通过再resume系统资源紧张时主动暂停低优先级任务腾出资源给高优先级任务这套机制配合上一篇的 Task 账本本质上是把任务执行从一次性的方法调用变成了一个可以被外部干预、随时查看进度、随时打断又能无损续上的有状态过程——这正是企业自动化流程真正需要的能力不是调一次大模型能解决的。 上一篇07. 三层记忆模型 下一篇09. 别让 Agent 是个黑盒可观测性怎么做 项目地址https://github.com/flower-trees/regnexe-agent