LangChain on X: "The runtime behind production deep agents "

文章

对话

支撑生产级深度智能体的运行时

本文由

和

撰写，

。

• 一个优秀的封装框架能为你的智能体提供恰当的提示、工具和技能。但要在生产环境中部署长时间运行的智能体，还需要持久化执行、内存管理、多租户支持、人类参与循环（HITL）以及可观测性。这些基础设施位于封装框架之下，确保智能体在崩溃、部署和长时间任务中仍能稳定运行。

• 持久化执行是所有其他功能的基础。那些运行数分钟或数小时、需暂停等待人工审批、或能在运行中完成部署的智能体，都依赖于可检查点（checkpoint）的执行机制——该机制支持跨进程边界停止、恢复和重试。流式处理、人类参与循环、定时任务和并发消息处理，都构建在这一机制之上。

• 生产级智能体需要开放且与模型无关的基础设施。Deep Agents 采用 MIT 许可证，智能体通过开放协议（MCP、A2A）暴露接口，内存存储在你自己的 PostgreSQL 中。团队可以完全掌控智能体的工作机制，并在无需重写的情况下对其进行修改。

在生产环境中部署长周期智能体，需要专门构建的基础设施。本指南涵盖持久化执行、内存管理、HITL、可观测性，以及 DeepAgents 如何将这些能力打包并部署上线。

要构建一个优秀的智能体，你需要一个优秀的封装框架；要部署该智能体，你需要一个优秀的运行时。

封装框架是你围绕模型构建的系统，帮助智能体在其领域内取得成功。它包括提示词、工具、技能，以及支撑智能体定义的模型与工具调用循环的所有其他组件。而运行时则是其底层的一切：持久化执行、内存管理、多租户、可观测性——这些机制确保智能体在生产环境中稳定运行，无需你的团队重复造轮子。

本指南将带你了解部署智能体后浮现的生产需求、满足这些需求的运行时能力，以及

如何将这些能力打包为可交付的产品。

在本节中，“运行时”指的是

及其

：LSD 在生产环境中运行智能体，Agent Server 是用于助手、线程、运行、内存和计划任务的接口。下表将每个生产需求映射到对应的运行时原语。

智能体通过循环工作：给定一个提示，模型进行推理、调用工具、观察结果，并重复此过程，直到判断任务完成。

📷

与通常在毫秒内返回的典型 Web 请求不同，此循环可能持续数分钟甚至数小时。一次运行可能涉及数十次模型调用、启动子智能体，或无限期等待人工批准草稿。循环中任何位置的崩溃、部署或临时故障都不应抹去此前的所有工作。

实际上，你会在两个地方感受到这种需求：

长时间运行的任务必须能抵御基础设施故障。一个耗时二十分钟收集资料并综合结论的研究型智能体，无法承受因工作进程崩溃而从头开始重启：它已经支付了令牌费用并执行了工具调用。你真正需要的是从上一个完成的步骤恢复，保留所有先前状态。

智能体需要能够暂停并等待。一个为人工审批交易而暂停的智能体，无法预知人类会在三十秒内响应，还是三天后才回复。在整个等待期间占用一个工作进程或客户端连接是不可行的。智能体必须真正停止：释放资源、释放工作进程，然后在之后从完全相同的位置继续执行。

这两个需求都由同一机制解决：持久化执行。

• 智能体运行在受管理的任务队列上，具备自动重试机制，因此任何运行都可以从中断的确切位置重试、重播或恢复。
• 每次图执行的步骤都会将检查点写入持久层（默认为 PostgreSQL），并以 thread_id 作为持久游标进行索引。
• 当工作进程崩溃时，该运行的租约会被释放，另一个工作进程会从最新检查点处接手。

• 当智能体等待人工输入时，其进程会交出槽位，运行进入无限期休眠，直到被恢复。

• 可配置的

可控制每个节点的退避策略、最大重试次数及触发重试的异常类型。

持久性是本列表其余部分的基础。由于执行支持跨进程边界暂停与恢复，智能体可以无限期等待人工输入、在后台运行、在运行中存活部署，并在不破坏状态的情况下处理并发输入。

智能体需要两种不同类型的内存，且这种区分至关重要。

短期记忆是智能体在单次对话中累积的信息：交换的消息、调用的工具、运行过程中构建的中间状态。这些信息存储在线程的检查点中，作用域为 thread_id，当对话结束时（概念上）消失。同一线程的后续消息可以查看该线程之前的所有内容。

长期记忆是智能体跨对话携带的信息。这可能包括跨对话学习的用户偏好、项目规范与最佳实践，或通过每次新查询增强的知识库。这些信息不属于任何单一线程，而是用户级或组织级上下文，应在智能体的所有对话中持续存在。仅靠检查点无法实现这一点，因为检查点状态仅限于单一线程。

长期记忆正是 Agent Server 内置的

所负责的。它是一个键值接口，记忆按命名空间元组（例如 (user_id, "memories")）组织，并跨线程持久化。你的智能体在一个对话中写入该存储，在下一个对话中读取。默认由 PostgreSQL 支持，可通过嵌入配置支持

，使智能体能根据语义而非精确匹配检索记忆；若需不同存储特性，你也可以

。命名空间结构灵活：可按用户、助手、组织或任何符合你数据模型的组合进行作用域划分。

由于跨数月累积的记忆是系统产生的最有价值的数据之一，其存储位置至关重要。该存储可通过

直接查询，若你自托管，则数据存储在你自己的 PostgreSQL 实例中。将这些数据保存为你可控的标准格式，使你能够跨模型迁移、分析数据，或在智能体之外构建其上层应用。

一旦你的智能体服务超过一个用户，就会出现单用户模式下不存在的一系列问题。这些问题可分解为三个独立的关注点，Agent Server 为每个问题提供了专属原语。

隔离不同用户的数据。用户 A 的运行只能访问用户 A 的线程，只能读取用户 A 的记忆。

在每个请求上作为中间件运行：你的

.authenticate 处理程序验证传入凭证并返回用户身份和权限，这些信息会被附加到运行上下文中。

通过

.on.threads、

.on.assistants.create 等注册的处理程序，会在创建资源时打上所有权元数据标签，并在读取时返回过滤字典，从而强制执行谁可以查看或修改什么。处理程序按从最具体到最通用的顺序匹配，因此你可以从单个全局处理程序开始，随着模型规模扩大逐步添加资源特定的处理程序。

允许智能体代表用户执行操作。智能体通常需要使用用户的凭证调用第三方服务——读取其日历、向其 Slack 发帖、在其仓库中打开 PR。

为这种模式处理 OAuth 流程和令牌存储，使智能体在运行时获得用户范围的凭证，而无需你自行管理刷新流程。用户只需认证一次，智能体即可在后续运行中代表其执行操作。

控制谁可以操作系统本身。除了终端用户访问权限外，还涉及你的团队中哪些成员可以部署智能体、配置它们、查看追踪记录或更改认证策略。

处理这种操作员级访问控制。

这三层结构相互组合：终端用户通过你的认证处理程序认证，智能体通过 Agent Auth 调用第三方服务，你的团队则在 RBAC 策略下操作部署。

智能体通过循环工作：给定一个提示，模型进行推理并决定调用工具，观察结果，重复此过程，直至判断任务完成。大多数情况下，你希望这个循环不间断运行——价值正源于此。但有时，你需要在关键决策点插入人工干预。

常见场景有两种：

1. ‍审查拟议的工具调用。在智能体执行重要操作前（发送邮件、执行金融交易、删除文件），你希望人工能确切看到它即将做什么，并决定如何响应。以邮件为例：智能体起草了一封邮件，但在发送前暂停。你可以直接批准，编辑主题或正文后再发送，或拒绝并附上理由和具体修改请求，以便智能体修订后重试。‍

1. 智能体提出澄清性问题。有时智能体到达一个无法自行解决的决策点，不是因为缺少工具，而是因为正确答案取决于人类的判断或偏好。与其猜测，智能体可以直接提出问题：“我找到了三个符合该模式的配置文件，我该修改哪一个？”或“这次部署应到预发布环境还是生产环境？”你的回答将成为中断的返回值，智能体将从完全停止的位置继续执行。

Agent Server 通过两个原语处理此需求：

暂停执行并向调用方暴露有效负载；

使用人类的响应继续执行。二者结合，使你能够构建审批网关、草稿审查循环、输入验证，以及任何需要人工在执行中途介入的工作流。

底层机制中，interrupt() 会触发运行时的

将完整图状态写入持久化存储，以 thread_id 作为持久游标索引。随后，进程释放资源并无限期等待。与在特定节点前/后暂停的静态断点不同，interrupt() 是动态的：你可以在代码任意位置放置它，用条件语句包裹，或嵌入工具函数中，使审批逻辑随工具一起流动。当 Command(resume=...) 到达——无论几分钟、几小时还是几天后——resume 值即成为 interrupt() 调用的返回值，执行从完全停止的位置继续。由于 resume 接受任何可 JSON 序列化的值，响应不限于“批准/拒绝”：评审者可返回修改后的草稿，人类可提供缺失上下文，下游系统可