DeepSeek与LangChain异步Agent实践：从会话循环到后台工作系统

DeepSeek Harness 团队提出了 Super-agent 设计，核心是 Router + Workers 的两层结构，强调事件驱动、主动发现与持续推进；LangChain 则正式发布了《Agents Are Going Async》，并在 Deep Agents 中落地了 Async Subagents。乍看之下，前者偏研究与系统愿景，后者偏工程实现与可控调度，但把二者放在一起，一条清晰的演进路径便浮现出来：Agent 正在从"单 Session 的阻塞式执行循环"走向"可并行处理多项长任务、且人随时能介入的后台工作系统"。

这不是功能层面的简单叠加，而是交互范式与系统边界的一次重新划分。

当前真实痛点：人还在"盯着 Session"

今天的 Agent 已经足够能干——写代码、做研究、改文档、跑测试，很多任务它能独立完成相当一部分。但真正高频使用后，不少人会感受到一种隐性摩擦：

• 长任务一旦启动，Session 就被占住。
• 人几乎无法同时安排其他工作，只能干等。
• 中途想改方案，往往只能硬打断或者等它跑完再重启。
• 任务一多，人自己就变成了调度员，不停切换窗口、记状态、盯进度。

根本原因在于传统的 ReAct 循环是同步阻塞的：工具调用或子 Agent 一旦启动，主循环就必须等待结果返回。人能同时盯住的活跃 Session 通常只有 3–5 个，瓶颈早已从模型能力转移到了人类注意力。

LangChain 的工程解法：Async Subagents

LangChain 在 Deep Agents 中给出的方案，核心是把交互层与执行层解耦。

主 Agent（Orchestrator）负责与用户持续对话、维护上下文、决定任务分配；耗时任务被委托给异步子代理（Async Subagents）。子代理运行在独立线程上，拥有自己的状态与工具，启动后立即返回 Task ID，主循环不再被阻塞。主 Agent 可以同时启动多个后台任务，自己则继续与用户交互。

更关键的是中途可控性。任务跑起来之后，主 Agent 仍可通过工具发送新指令：默认策略是 interrupt（中断当前运行并用新指令重启），也可以选择 enqueue（排队等待当前工作完成后再执行）。后台任务状态被单独保存在专用状态通道中，避免因主对话的 Context 压缩而丢失记录。任务完成后，SubAgent 会主动通知主 Agent——无论主 Agent 当时是忙碌、空闲，还是在等待人工审批，都有对应的处理机制。

这套能力建立在 Agent Protocol 之上。SubAgent 可以与主 Agent 同部署（ASGI 传输，进程内调用），也可以远程部署（HTTP 传输，指向 LangSmith 或自托管服务），甚至使用不同模型与硬件。主 Agent 通过五个标准工具管理它们：start_async_task、check_async_task、update_async_task、cancel_async_task、list_async_tasks。LLM 像调用普通工具一样调用这些接口，中间件负责线程创建、状态持久化与生命周期管理。

技术上，任务元数据存在独立于消息历史的 async_tasks 通道里。这解决了实际工程中的关键痛点：深度 Agent 会在上下文接近满时做摘要，如果任务 ID 只写在 ToolMessage 里，摘要后就会丢失。专用通道保证主 Agent 始终能找回自己派出去的所有任务。

通知机制也考虑了真实场景：主 Agent 忙碌时在每次模型调用前检查未完成任务；空闲时 SubAgent 会主动唤醒它；等待审批时则不打断审批流程。SubAgent 如果进入 waiting 状态（需要用户输入或审批），请求必须在它自己的线程上由用户/应用处理，主 Agent 不能代为回答。

整体来看，LangChain 把"fire-and-forget"升级成了"fire-and-steer"——发出去之后还能随时调整方向。

DeepSeek Super-agent：更高层的系统愿景

DeepSeek 的 Super-agent 与上述思路高度接近，但视角更偏向系统级。

它同样采用两层结构：Router 负责与人交互、接收事件、分配任务；Workers 在独立环境中并行执行具体工作。Router 故意不执行重任务（甚至可以没有 Bash），可用更轻的模型；Workers 使用强模型与完整工具集。设计额外强调事件驱动（GitHub、飞书等外部事件作为 Trigger）、订阅机制（后续相关事件可直达已有 Worker，跳过 Router）、状态持久化、Watchdog 监控，以及计算/状态/机器分离。

目标很明确：尽可能减少人类注意力的消耗，让 Agent 只在人必须行动或能使用结果时才开口，其余时间在后台持续推进。公开的是研究原型，部分设计尚未完全落地，但它清晰指出了方向——Agent 应从"一次对话的执行器"变成"长期存在于团队工具链中的工作系统"。

两者共同指向的趋势

把两边放在一起，共同点非常清晰：

1. 主交互层与执行层解耦，前台始终保持对用户的响应。
2. 任务状态独立管理，不再完全依赖单次对话的 Context。
3. 从阻塞等待转向异步可控，人可以放心交任务，也能随时介入。
4. 系统能承载的工作量开始随后台 Worker 数量扩展，而非被单循环长度限制。

Claude Code 默认后台跑子 Agent、OpenAI 的 dots 也采用类似后台 Worker 模式，说明这个方向是生态自然收敛的结果。以后判断一个 Agent 好不好用，可能不再只看单次任务完成质量，而要看：你能不能放心把长任务交出去？交出去后是否还能随时知道进度、随时调整方向？它会不会在你忙别的事情时，主动把结果或需要决策的点推送给你？

对异步 Agent 的构思

结合两边的实践与当前工程边界，我对异步 Agent 的下一步有几个具体构思。

第一，把"任务"提升为一等公民。 现在的异步 SubAgent 已经把任务从对话循环中剥离出来，但任务本身仍偏轻量。我希望任务拥有更完整的生命周期元数据：目标描述、优先级、依赖关系、预估耗时、失败重试策略、断点位置、人工介入点。主 Agent 不应只是"启动一个 SubAgent"，而应能像操作系统调度进程一样，维护一张动态任务图。任务之间可以声明依赖（A 完成后才能启动 B），也可以声明互斥或资源约束。这样系统才能从"并行跑几个独立任务"升级到"有结构的工作流"。

第二，主动通知与事件驱动应成为默认能力，而不是可选插件。 LangChain 目前的通知机制已经很好，但大多仍依赖主 Agent 轮询或被唤醒。DeepSeek 强调的事件驱动（外部系统事件直接触发或更新任务）更值得成为一等能力。理想状态是：GitHub PR 评论、CI 失败、飞书消息、日历提醒、甚至用户在其他渠道的指令，都能以标准化事件进入系统，自动匹配到已有任务或创建新任务，并决定是否需要唤醒 Router。主 Agent 不应只活在当前对话窗口里，而应成为跨渠道的持续存在实体。

第三，中途干预要更细粒度，并支持"人机协同编辑"。 当前的 interrupt / enqueue 已经能处理"换方案"或"追加要求"，但还不够。我希望支持更细的干预：暂停某一阶段、注入新约束、要求 SubAgent 输出中间产物供人审核、甚至让人直接编辑 SubAgent 的中间状态再继续。这需要任务状态可被外部读写，且有清晰的版本与冲突处理。最终目标是：人把 Agent 当成可以随时插手的同事，而不是只能"启动—等待—验收"的黑盒。

第四，上下文与记忆的边界要重新设计。 isolated 与 fork 两种启动模式已经区分了"干净上下文"和"继承上下文"，但在长时间多任务场景下还不够。我构思的是分层记忆：任务级短期工作记忆、跨任务共享的项目记忆、以及用户级长期偏好记忆。主 Agent 负责维护全局视图，SubAgent 只加载自己需要的切片。同时，摘要与压缩策略要和任务生命周期绑定——已完成任务的细节可以大幅压缩，进行中任务的关键决策则必须保留。

第五，可观测性与失败恢复必须从第一天就内建。 异步系统一旦并行度上去，最大的风险是"不知道它在干什么、卡在哪里、为什么失败"。我希望每个任务都有可查询的执行轨迹、资源消耗、决策节点，并且支持从任意检查点恢复。Watchdog 不应只是可选监控，而应成为系统的一部分：定期检查任务是否真正在推进，发现停滞或异常时主动升级或请求人工介入。

第六，从"SubAgent"走向"角色与能力市场"。 今天我们手动声明 researcher、coder 等 SubAgent。下一步可以演化成动态能力注册：系统维护一组可用能力（或外部服务），主 Agent 根据任务需求动态选择或组合。能力本身也可以是异步的、可计费的、可版本管理的。这样异步 Agent 就不再只是内部架构优化，而成为可扩展的协作网络。

总的来说，异步 Agent 的本质，是把"人类注意力"从执行循环中解放出来，同时保留足够的可控性与透明度。LangChain 已经把调度与中途干预做得相当扎实，DeepSeek 指出了事件驱动与长期存在的方向。真正把两者结合，并补上任务一等公民、细粒度协同、分层记忆与内建可观测性，才有可能让 Agent 从"高级工具"变成真正可靠的工作伙伴。

以后 Agent 好不好用，很大程度上取决于：你能不能放心把任务交出去，又能在需要时随时介入，并且系统本身会主动帮你盯着进度。

这条路才刚刚开始。