生产级 AI Agent 的底层架构:深度解析运行时的能力


快速阅读

构建一个优秀的 AI Agent 需要一套好的“脚手架”(harness),而将其部署到生产环境则需要一个强大的运行时(Runtime)。本篇文章深度解析了生产级 Agent 运行时的各项核心能力:

  • 持久化执行(Durable execution):应对漫长的执行循环、中断重启和长时间等待。
  • 记忆(Memory):区分短期会话记忆与跨会话的长期存储检索。
  • 多租户(Multi-tenancy):隔离数据、代理用户凭证授权、以及基于角色的访问控制(RBAC)。
  • 人在环路(Human-in-the-loop, HITL):动态中断与恢复,满足人工审批与问询需求。
  • 实时交互(Real-time interaction):支持流式输出与双重输入的并发冲突解决策略。
  • 护栏与可观测性(Guardrails & Observability):代码级的数据脱敏限制与覆盖全局的链路追踪。
  • 代码执行与集成(Code execution & Integrations):安全的沙箱环境与 MCP、A2A 开放协议集成。
  • 定时任务(Cron):支持睡眠期计算和健康监控等无用户触发的长期背景任务。

要构建一个出色的 AI Agent,你需要一套好的“脚手架”(harness)。而要把这个 Agent 部署出去,你则需要一个优秀的运行时(runtime)。

脚手架是你围绕模型搭建的系统,帮助 Agent 在其特定领域中成功执行任务。这包括提示词(prompts)、工具(tools)、技能(skills),以及支撑模型和定义 Agent “调用工具循环”的所有内容。而运行时则是这一切之下的基础设施:持久化执行、记忆、多租户、可观测性等。正是这些机制,让 Agent 能够在生产环境中稳健运行,避免你的团队去重复造轮子。

本指南将梳理当你部署 Agent 时会面临的生产级需求、满足这些需求的运行时能力,以及 deepagents deploy 是如何将这些能力打包成可交付成果的。

生产级 Agent 的运行时能力

本节中,“运行时”特指 LangSmith Deployment (LSD) 及其 Agent Server:LSD 负责在生产环境中运行 Agent,而 Agent Server 则是处理助手、线程、运行、记忆和定时任务的接口。

持久化执行 (Durable execution)

Agent 的工作模式是循环的:给定一个提示,模型进行推理,调用工具,观察结果,然后重复此过程,直到它认为任务完成。与在几毫秒内返回的典型 Web 请求不同,这个循环可能跨越数分钟甚至数小时。单次运行可能涉及数十次模型调用、生成子 Agent,或者无限期地等待人工审批。如果在这个循环的任何地方发生崩溃、部署或瞬时故障,都不应该让之前的努力付诸东流。

在实践中,持久化执行主要解决两个痛点:

  1. 长时间运行必须在基础设施故障中存活:如果工作进程死掉,之前消耗的 Token 和执行的工具调用绝不能从头再来。你需要它从最后一个完成的步骤恢复,并保留所有先前的状态。
  2. Agent 需要能够真正地暂停并等待:当 Agent 暂停等待人工确认交易时,人类可能在三十秒或三天后回复。一直占用工作进程是不现实的。Agent 需要释放资源,之后再精准地接着干活。

这两点都由持久化执行解决。Agent 运行在具有自动检查点(checkpointing)的托管任务队列上,因此任何运行都可以重试、重放或从中断的确切位置恢复。

  • 图执行的每个超步(super-step)都会将检查点写入持久层(默认为 PostgreSQL)。
  • 当工作节点崩溃时,租约被释放,另一个节点从最新检查点接手。
  • 当 Agent 等待人工输入时,进程会让出资源,然后无限期休眠直到恢复。
  • 灵活配置的重试策略控制回退时间、最大尝试次数以及触发重试的异常。

记忆 (Memory)

Agent 需要两种不同的记忆。

  • 短期记忆:Agent 在单次对话中积累的内容。它保存在线程的检查点中,当对话结束时(概念上)就消失了。
  • 长期记忆:Agent 跨对话携带的上下文。例如用户的偏好、项目约定、或是知识库的充实。

Agent Server 的内置 Store(存储)是一个键值接口,支持通过语义搜索(基于向量配置)而不是精确匹配来检索记忆。它让跨会话的信息存取变得简单而安全。

多租户 (Multi-tenancy)

当你的 Agent 服务于多名用户时,需要处理单人模式下不存在的问题:

  1. 数据隔离:使用自定义认证中间件,通过 @auth.authenticate 处理器在请求上附加用户身份,然后通过 @auth.on.threads 等拦截器验证。
  2. 代表用户操作:“Agent Auth”负责处理 OAuth 验证和 Token 存储,这样 Agent 就能拿着用户授权去调外部服务了。
  3. 控制系统操作权限:基于角色的访问控制(RBAC)决定谁能部署 Agent 或查看追踪信息。

人在环路 (Human-in-the-loop, HITL)

大多数时候你希望 Agent 循环不被打断,但关键决策点常常需要人工介入,比如:

  • 审查提议的工具调用:例如发邮件前让你看一下草稿。
  • Agent 提出澄清问题:“这里有三个配置文件,我该改哪一个?”

Agent Server 使用 interrupt() 暂停执行并将数据载荷抛出;使用 Command(resume=...) 携带人类的反馈来恢复它。这是一种动态机制,它可以放在代码的任何位置,触发时释放进程资源无限期等待。

实时交互 (Real-time interaction)

“实时会话”面临着流式反馈和并发输入的挑战。

  • 流式传输 (Streaming):三十秒的响应时间不能只给用户看一个加载动画。流式 API 支持每次图步骤的状态快照、逐个 Token 的输出以及自定义事件,甚至是携带 Last-Event-ID 恢复防丢包的连接。
  • 双重回复/双击抢答 (Double-texting):当旧的请求还在跑,用户发了新消息怎么办?运行时提供了四种策略:enqueue(排队,默认)、reject(拒绝)、interrupt(中断当前并保留进度)、rollback(彻底回滚,当作没发生过旧消息)。

护栏 (Guardrails)

策略和限制必须写在代码里,而不是仅仅靠提示词约束模型。例如:在模型看到 PII(敏感个人信息)前将其脱敏;或者对昂贵的外部 API 设定硬性调用上限。 这通过**中间件(Middleware)**实现。中间件包裹在模型和工具调用的生命周期周围,确保策略不论在后台任务还是交互流中都能 100% 确定性地执行。

可观测性 (Observability)

你无法仅凭阅读代码来了解 Agent 在生产环境中的行为,因为其执行路径取决于模型运行时的选择。当 Agent 在支持工单中卡死在一个死循环里,你需要看到完整的执行树。 所有运行都自动关联到链路追踪项目(Tracing),带有结构化元数据(耗时、成本、错误状态等)。配合类似 LangSmith Polly 的工具进行线上分析和评估(Evals),形成持续改进反馈闭环。

时间旅行 (Time travel)

可观测性告诉你发生了什么,时间旅行让你探索“如果……会怎样”。 因为所有的历史都是检查点,你可以明确地回到任意一个中间步骤,改变它的状态,然后再运行后续的过程。原始路径依然保留,修改后的路径作为一条新分支向前推进,非常适合做错误复盘或尝试不同提示词方案的 A/B 调试。

代码执行 (Code execution)

真正的执行力意味着 Agent 能够运行任意代码。为了保证不把宿主机玩坏,这需要极其严格的隔离。 深度 Agent 在沙箱后端(Sandbox backends)中运行,仅向 Agent 暴露 execute 工具。通过 LangSmith Sandboxes 的代理转发设计,API 密钥被注入在旁路上,沙箱内的代码和日志从头到尾都碰不到凭据本身,确保了高安全性。

集成与开放协议 (Integrations)

Agent 需要接入企业现有的工具链:

  • MCP (模型上下文协议):所有的部署都自动暴露一个 MCP 端点,任何客户端(如 Claude 桌面端或 IDE)都可以调用它,Agent 也可以通过 MCP 获取 GitHub 或 Notion 里的数据。
  • A2A (Agent-to-Agent):Agent 之间的跨部署标准化通信。
  • Webhooks:Agent 跑完后推送结果,以便触发下游自动化流程(例如给 Slack 发通知)。

定时任务 (Cron)

大量的 Agent 工作是没有人主动触发的,比如夜间总结、凌晨收集资料、每隔 15 分钟运行的监控分析等。 Agent Server 内置了 cron 任务系统,它们依然享有持久化和链路追踪的保护。有状态任务会被关联到指定的 thread_id;无状态任务则每次都起新线程。

deepagents deploy 与 Open Harness

deepagents deploy 是一个打包和部署工具,只需编写 deepagents.toml 和 AGENTS.md,它就能把沙箱环境、中间件、记忆插件等组装为完整的运行时投产部署。

这里最重要的是:它拥抱开放脚手架 (Open Harness)。所有的代码底层是 MIT 开源的,协议是公开标准(MCP/A2A),拒绝由于部署托管导致的黑盒效应(Vendor lock-in),确保开发者能时刻洞悉和把控 Agent 运行逻辑。

构建 Agent 是一个深度迭代的过程。强大的基础设施不仅仅是为了支撑当前的 Agent,它更是使它随着时间推移变得越来越好的基石。

🔗 原文链接:The runtime behind production deep agents