Agent Runtime 如何实现和维护？

核心回答

Agent Runtime 是驱动一次任务真正运行的执行层：接收目标和运行上下文，组织模型与工具调用，维护任务状态，处理等待、重试、取消和结束，并管理相关资源。

实现上可以围绕五项职责组织：

1. 创建运行实例：关联用户、会话和本次任务，准备依赖、工具范围、工作目录及预算。
2. 驱动执行：组装上下文、调用模型、处理工具请求，再把真实结果交回模型或下一个节点。
3. 维护权威状态：记录进度、调用结果、产物、失败与等待原因，明确哪些内容需要持久化。
4. 控制故障和生命周期：分类重试、遵循总预算、传递取消，恢复时处理可能重跑的步骤和外部副作用。
5. 支持长期维护：关联代码、模型配置、提示和工具版本，观察执行轨迹，验证升级兼容并清理过期资源。

可以基于 LangGraph 等框架实现这些职责，再补业务执行策略；Runtime 不一定要单独部署成一套平台。

展开说明

1. Runtime、Workflow 和 Node 怎样分工？

Workflow 描述任务有哪些节点、依赖及分支；Node 执行某个步骤；Runtime 提供它们运行时所需的状态、依赖、调度、工具和事件机制。框架本身可能已经承担其中一部分，应用无需重复实现。

模型输出是决策或调用请求，Runtime 才把它变成真实执行：确认工具存在、校验参数和权限、设置超时，执行后关联原调用并写回结果。上下文组装、结果外置、预算检查也可以通过中间件或明确的执行阶段接入。

还要区分广义执行层与具体 SDK 对象。LangChain 文档中的 Runtime 对象提供上下文、Store、流式输出及执行信息等访问能力，它是执行系统提供给工具和中间件的接口，不能把这个对象本身当成完整调度器。

2. 每次运行应有明确的状态和资源归属

可以分别标识长期会话、本次运行和子任务，关联当前阶段、已完成步骤、待办、产物位置、累计消耗及失败原因。用户身份和可访问范围由可信入口注入，不让模型生成的字段决定授权。

状态按职责更新：模型可以提出计划，实际工具成功与否以执行结果为准；并发分支各自保存结果，再由规定的归并逻辑更新最终状态。数据库连接等依赖可以通过运行上下文传递，避免多个请求读写同一份全局可变变量。

工作目录、子进程、网络连接和临时文件也需要绑定到本次运行。若允许执行不可信代码，应按实际风险配置受限进程、容器或沙箱等执行环境；仅在提示词里写一个目录，并不能形成文件系统权限隔离。

3. 恢复能力必须覆盖状态与外部执行之间的空隙

瞬时网络错误可以有限重试，参数错误、业务拒绝或确定性代码问题则需要不同处理。模型、工具适配器和外层流程要明确谁主要负责重试，避免一层超时后多层同时重试，放大调用量。

需要重启恢复时，用持久化 checkpointer 保存图状态，并保存关键产物和外部操作的业务标识。恢复可能重新运行节点，而不是从任意代码行继续。例如外部建单已经成功、checkpoint 尚未写入就宕机，重试时应凭业务幂等键或查询结果确认原操作，不能只看检查点里“还没完成”就再建一单。

取消也需要传到正在执行的模型、工具和子任务；最终状态、在途结果及资源清理要配合。迟到结果不能覆盖已经取消或被新执行接管的任务。等待输入则保存进度后暂停，和成功、失败、取消分别表示。

4. 用研搜入口说明已有代码怎样承担运行职责

研搜参考实现中，run_deep_agent 接收问题和 session_id，准备会话目录与上传文件，设置运行上下文，并用同一标识作为 thread_id 调用主 Agent。流式过程中，它识别子 Agent 调用与最终文本，通过 monitor 报告事件；捕获取消或异常，最后在 finally 中恢复 ContextVar。

这是会话组织、执行入口、事件反馈和清理的具体分工。其 checkpointer 使用 InMemorySaver，保留的是进程内状态。用于多人长期任务时，可以继续增加持久化运行记录、独立执行标识、并发调度与资源回收策略；业务产物也应保存在生命周期合适的位置，不能随临时执行环境销毁。

5. 维护时，既看行为变化，也看状态兼容

一次运行应能关联提示、工具 Schema、模型配置和 Runtime 版本，执行记录保留必要输入摘要、结果引用、错误、消耗和状态变化。排障时据此区分模型选错动作、工具故障、数据变化、状态冲突和程序错误，而不是统一归为“模型不稳定”。

升级可能影响尚未结束的任务。可以让在途任务继续使用兼容版本，或在可恢复边界迁移；状态字段和工具契约变化时说明兼容方式。验证应覆盖正常执行、工具超时、取消、恢复后重复执行，以及旧状态读取等受影响路径。

日常还需设置检查点、临时文件和日志的保留策略，回收超时任务的资源。清理执行资源时保留仍需使用的产物和恢复依据，避免任务恢复到了正确节点，却找不到上一步文件。

常见追问

Runtime 一定要自己写完整 Agent Loop 吗？

不一定。框架已经提供模型与工具循环、状态和中间件时，可以直接使用，再实现业务权限、预算、产物和事件适配。自封装要明确解决哪些缺口，避免在框架外再做一套相互独立的重试和状态管理。

存了 messages，就能恢复整个任务吗？

messages 主要承载交互轨迹，完整恢复还可能需要当前节点、未完成依赖、产物引用、预算和外部操作状态。具体由框架和应用分别保存。是否能跨进程恢复，还取决于存储实现；内存 checkpointer 不具备重启持久化。

如何判断 Runtime 维护得好不好？

看代表性任务能否稳定交付、失败原因能否定位、取消后是否继续消耗、恢复会否重复副作用，以及版本升级是否破坏在途任务。再结合延迟、成本和资源泄漏情况评估，不能只统计模型接口调用成功率。

对应教程

参考资料