Agent 学会后台干活了，人还是得盯失败日志
LangChain 把长任务丢给异步子 Agent，DeepSeek 也在做 Super-agent。被挪走的是人的等待时间，算力账单还在。断点续跑、状态持久化和交接，是下一道坎。
LangChain 发布《Agents Are Going Async》，DeepSeek 刚提出 Super-agent。两件事放一起看，Agent 架构的讨论重点变了：从一次会话里怎么跑完一个任务，转向一个系统怎么同时接住多项长任务。
旧问题很具体。标准 ReAct 循环里，一个长工具调用会卡住整个循环，后面的任务排队。用户得盯着 Session，等它跑完才能安排下一件事。Agent 越能干，这个等待越刺眼。
LangChain 在 Deep Agents 里给的方案是 async subagents。主 Agent 做 orchestrator，负责和用户交互；耗时任务交给后台 subagent，每个任务有独立 Thread，启动后立即返回，不阻塞主 Agent。
控制任务用五个工具：start_async_task 启动并立即返回，check_async_task 查状态和结果，update_async_task 给运行中的任务发新指令，cancel_async_task 停止任务，list_async_tasks 列出所有任务和状态。
任务跑起来后还能改。update_strategy 有两个值：interrupt 是默认策略，停掉当前运行，用新指令重启，适合“改用 Postgres”这种纠正；enqueue 把新指令排队，等当前运行结束再执行，适合“跑完把测试也跑了”这种追加。
工程细节里有一条：后台任务状态单独保存，避免 Context 压缩后丢失任务记录。任务完成后可以主动通知主 Agent。主 Agent 忙时，它在每次模型调用前检查未完成任务，运行中接结果；空闲时，子 Agent 唤醒它；暂停在审批时，审批不动，用户回答后结果再到达。子 Agent 需要审批时显示为 waiting，用户在子 Agent 自己的 Thread 里回答，不打断主 Agent。
这套设计和 DeepSeek 的 Super-agent 思路接近。区别在侧重点：LangChain 更关注任务执行过程中的异步调度与控制，DeepSeek 进一步探索通过 GitHub、飞书等事件主动发现和推进工作。两者都指向一个趋势，Agent 从单个 Session 的执行循环，走向能持续处理多项任务的工作系统。
但异步不等于随时可回。有网友指出边界：调度代理自己忙着，用户照样得等。等待成本从人身上挪走了一部分，没有完全消失。
更硬的争议在失败之后。有网友说，异步真正难的是跑挂之后从哪个 checkpoint 续；长任务超过单次上下文窗口，状态持久化和幂等重放才是硬骨头，否则只是把盯 Session 换成盯失败日志。还有网友补了交接问题：人回来得一眼看懂它这段时间干了啥。通知跑完容易，接着上次断的地方继续干才是真本事。
成本也容易被忽略。有网友算了一笔账：异步省的是人的等待时间，不是算力账单。后台 subagent 并行跑，一个请求可能变成 N 个会话同时烧 token。长任务中途失败后从头重跑，烧掉的是整轮成本。以后评价 Agent，可能得看它失败一次要花多少钱重来。
Claude Code 也被拉进讨论。有网友说 Claude Code 很早就在做类似逻辑，workflow 和 subagent 在 system prompt 里权重很高，orchestrate 时还会判断任务剩余 context 和时间，任务跑久了会催加速收尾。Xudong Han 回复说还没看到相关报道，会去查。另有网友说类似思路更早出现在 Openclaw，Codex 语音模式也用这种架构。还有网友提醒，DeepSeek 的 super agent 和 personal agent 表面上像，其实不是一个范式。
这些说法需要更多验证，但讨论方向很清楚：Agent 好不好用，接下来不只看它能不能把任务交出去，还看它失败后能不能续、人回来能不能读懂、并行烧钱能不能控制。
LangChain 原文：https://www.langchain.com/blog/agents-are-going-async
发布时间: 2026-11-08 00:26