先有好 harness，再谈生产：LangChain 官方拆解 agent 运行时底座
LangChain 官方在 4 月发布了一篇分量很重的概念指南，讲的不是框架 API，而是更底层的一件事：harness 决定 agent 做得好不好，运行时决定它能不能活在生产里。prompt、工具、技能围着模型转，构成 harness；而崩溃恢复、持久记忆、多租户、人工审批、可观测这些”机器室”里的东西，全在运行时这一层——4 月 20 日发布的原文（Sydney Runkle、Vivek Trivedy 合著）干脆把标题写成”生产级 deep agents 背后的运行时”。
一张表：生产要求 → 运行时能力
指南的主干是这张对应表（运行时主体是 LangSmith Deployment 和它的 Agent Server，deepagents deploy 负责打包部署）：
| 生产要求 | 运行时能力 |
|---|---|
| 可靠性 | 持久执行 |
| 记忆 | checkpoints（短期）/ store（长期） |
| 护栏 | 中间件 |
| 多租户 | 认证 / 授权 / Agent Auth / RBAC |
| 人工监督 | 人在环（interrupt/resume） |
| 实时交互 | 流式输出 / 并发控制（double-texting） |
| 可观测 | tracing / 时间旅行 |
| 代码执行 | 沙箱 |
| 集成 | MCP / A2A / webhooks |
| 定时任务 | Cron |
下面逐项拆开。
持久执行：一切的地基
和毫秒级返回的普通 web 请求不同，agent 的一次运行按分钟到小时计：几十次模型调用、派生子 agent、等人审批一等多日。于是暴露出两个必须解决的痛点：
长任务要扛住基础设施故障。 跑了二十分钟的研究 agent，worker 进程一死不能从头再来——token 已经花了、工具已经调了。要的是从最后一个完成的步骤继续，前面状态原样保留。agent 还得能真的”停下来等”。 等一个人拍板，不知道对方 30 秒还是三天后回复，不可能占着 worker 或客户端连接干等：进程要交还资源，之后从断点原地复活。
解法是同一个：托管任务队列 + 自动 checkpoint。图的每个 super-step 向持久层（默认 PostgreSQL）写一个检查点，按 thread_id 索引——它是贯穿整次运行的持久游标。worker 崩溃，租约释放，另一个 worker 从最新检查点接手；agent 等人时进程让位，run 无限期睡眠，Command(resume=...) 到达再继续。重试策略可按节点配置退避、上限和触发异常。
指南把话说得很直白：持久执行是其余一切能力赖以成立的地基——能跨进程暂停恢复，才谈得上等人审批、后台运行、扛过中途部署、并发输入不坏状态。
记忆：线程内的，和跨对话的
两种记忆，界限分明。短期记忆是单次对话内积累的东西——消息、工具调用、中间状态，存在该 thread 的 checkpoint 里，跟着 thread_id 走，同一 thread 的追加点读得到之前的一切。长期记忆是跨对话带走的东西——用户偏好、项目惯例、随每次查询增厚的知识库，不属于任何一个 thread，是用户级或组织级上下文。checkpoint 天生管不了跨 thread 的事，所以得靠 store。
Agent Server 内置的 store 是个 key-value 接口：记忆按 namespace 元组组织（比如 (user_id, "memories")），跨 thread 持久化；这个对话里写入，下个对话就能读到。默认 PostgreSQL 支撑，配置 embedding 后支持语义检索——按意思取回而不是按字面匹配；还可以换自定义后端。指南特别强调了一点：沉淀了几个月的记忆是系统产出的最有价值数据，所以要存在你自己手里——自托管时它就在你自己的 PostgreSQL 实例里，标准格式、可直接查询，换模型、做分析、建周边工具都不受制于平台。
多租户：三层权限各管各的
agent 一旦服务第二个用户，单机时代不存在的问题立刻冒出来，指南把它们拆成三层：
用户之间隔离数据。 用户 A 的运行只能碰 A 的 thread、读 A 的记忆。实现方式是跑在每个请求上的认证中间件：你的 @auth.authenticate 校验凭据、返回身份和权限，随上下文注入运行；授权处理器按资源类型注册（@auth.on.threads 等），创建时打所有权标签，读取时返回过滤条件，handler 从最具体到最笼统匹配。agent 替用户行事。 用用户自己的凭据调第三方服务——读他的日历、发他的 Slack、在他的仓库开 PR。Agent Auth 托管这套 OAuth 流程和 token 存储，用户登录授权一次，后续运行 agent 自动拿到用户范围的凭据，你不用自己维护刷新逻辑。管系统的人还要再分一层。 谁能部署 agent、配置它、看 trace、改认证策略——团队运营者的访问控制交给 RBAC。三层叠加：终端用户走认证中间件，agent 走 Agent Auth 调第三方，你的团队在 RBAC 策略下运营。
人在环与实时交互：审批门、流式、双重发送
多数时候你希望 agent 的循环一口气跑完，但关键决策点需要人插话。指南举了两个典型场景：执行前审批工具调用——发邮件、转账、删文件这类要紧动作，agent 起草完先停住，人可以照单批准、先改再发、或者带理由驳回让它修订重交；agent 主动问——答案取决于人的判断而不是缺工具时，它不该猜，直接把问题抛出来（”匹配到三个配置文件，改哪个？”），人的回答成为 interrupt 的返回值，从停下的原地继续。底层就是 interrupt() 配合 Command(resume=...)，且 interrupt 是动态的：写在代码任何位置、包在条件里、甚至塞进工具函数内部，审批逻辑就能跟着工具走。并行分支各自 interrupt 时，所有待决项会一起抛出，可一次性恢复也可逐个恢复。
人在旁边、agent 干活时的”实时会话”另有两组问题。流式：三十秒才回完整响应的界面等于让用户对着转圈的图标猜，流式让部分输出边产生边送达，支持整步快照、增量更新、逐 token、自定义事件多种粒度且可组合，断线还能靠 Last-Event-ID 从最后一个事件重放、无空洞。双重发送（double-texting）：用户在上一次运行没跑完时又补一句新话——聊天界面里天天发生。运行时给出四种策略：enqueue 排队（默认，最稳）、reject 直接拒收、interrupt 停当前保进度从断点处理新消息（响应最快，但要求工具能干净处理半途状态）、rollback 连原 input 一起回退重跑。
护栏中间件：策略写进代码，别指望 prompt
有些生产要求没法用”把循环跑稳”概括——它们要改循环本身：拦截模型输入、过滤工具输出、给昂贵操作设上限。指南的两个例子很直白：客服 agent 处理含 PII（姓名、邮箱、账号）的消息，合规要求模型看到之前、日志记录之前就完成脱敏，每次都得执行，不能”模型记得才执行”；能调付费接口的 agent 必须给单次运行设硬调用上限，”否则一个犯迷糊的模型能在午饭前把预算调用光”。
落地形态是中间件：挂在 before_model、wrap_model_call、wrap_tool_call、after_model 等钩子上，围绕相关步骤确定性执行。官方内置已经覆盖常见场景——PII 脱敏、模型重试/回退、工具调用上限、摘要、人在环、内容审查——应用特有的策略自己写。
可观测与时间旅行：从 trace 出发的改进循环
“不把 agent 放进生产，你永远不知道它会做什么。”传统应用可以照着代码推行为，agent 的执行路径取决于模型临场选择——调哪个工具、传什么参数、怎么解读结果、何时罢手换路。工单说”agent 反复问同一个问题”，没有 trace 你只能猜；有了 trace 能看到整棵执行树，按成本筛烧钱的运行、按报错筛失败的运行、按用户回放单个客户经历的现场，还能在成千上万次运行里看出单条 trace 看不出的模式。每次部署自动接一个 tracing 项目，模型调用、工具调用、子 agent、中间件钩子全程入账。
trace 是改进循环的起点：AI 助手 Polly 分析 trace 归纳常见失败模式，在线评估用 LLM-as-judge 对生产 trace 自动打分、当场拦截退化。官方自己的例子：只改 harness、不动模型，Deep Agents 在 Terminal Bench 2.0 上涨了 13.7 分。
时间旅行则是可观测的下一步：知道”发生了什么”之后，还要能问”如果当时不这样会怎样”。每个 super-step 都落了检查点，历史里任何一点都可回到——挑一个检查点、（可选）改状态、从那里继续，这一下就把 thread 历史叉了出去，原历史不动，新路径作为自己的分支向前跑。重放会真触发 LLM 调用、工具调用、interrupt，跑的是完整 agent 循环而不是空壳。
沙箱与集成：通用执行力的代价是隔离
只会调预设工具的 agent 做不出你预料之外的事；能跑任意代码的 agent 才算通用——装依赖、clone 仓库、跑测试、做分析、生成文档、画图表。代价是隔离必须先行：agent 在你宿主机上跑一句 rm -rf / 就是灾难，读了环境变量就把 API key 带了出去。在 Deep Agents 里，配置一个实现 SandboxBackendProtocol 的沙箱后端，agent 自动获得 shell 执行工具；Daytona、Modal、Runloop、LangSmith Sandboxes（私有预览）可以一行配置互换。
沙箱这边最值得抄的是 auth proxy：agent 需要调带认证的 API，但把凭据放沙箱内就是安全风险——代理以 sidecar 形态拦截出站请求、从 workspace secrets 自动注入凭据，沙箱代码裸调 api.openai.com，正确的 Authorization 头在路上补上，密钥永不进沙箱。安全口径指南提醒得很重：沙箱保护的是你的宿主机，不是沙箱自己——被提示注入操纵的攻击者可以在沙箱里为所欲为，凡直接放进沙箱的东西（包括凭据）都视同沦陷，auth proxy 正是为此而生。
集成面默认给三个：每次部署自动暴露 MCP 端点（Claude Desktop、IDE、别的 agent、自建应用都免适配器接入），反向可调用任意 MCP 服务器；A2A 端点让跨部署的多 agent 架构成立，编排 agent 发现和调用工人 agent 用双方都懂的协议，不再手写 HTTP 契约；webhooks 处理出站——运行完成时把 payload POST 给指定 URL，研究跑完触发发布流水线、日报跑完通知 Slack、合规检查落审计日志。
Cron：让 agent 主动干活
前面都是”用户发消息、agent 接招”，但很多有价值的 agent 工作是主动的。闲置期计算：夜间跑的研究 agent 追上领域新论文，晨间 prep agent 审阅明天日程先写好简报，分诊 agent 把过夜工单排好优先级——活在不被等待的时候干完，用户到场即取。健康巡检：每十五分钟扫一遍告警的值班 agent、盯 staging 回归的 agent、按节奏扫合规违规的 agent。
Agent Server 内置 cron，定时运行与一切普通运行享受同样的持久化、tracing、认证待遇——不需要另养一套调度器，也不需要第二套观测。两种形态：stateful cron 绑定指定 thread，每次触发都续写同一场对话（适合”在昨日发现之上继续”的研究 agent）；stateless cron 每次开新 thread（适合批量事务，默认跑完即删，也可保留检索）。凌晨三点撞上模型服务抖动的 cron 不会静默失败，按重试策略正常重跑。运维口径一句话：cron 用完记得删，不然它一直跑、也一直计费。云端、混合、自托管三种部署形态能力一致。
deepagents deploy：把整套底座打包
指南最后一章回答”怎么拿走全套”：deepagents.toml 里定义 agent，CLI 打包部署，运行时能力开箱即带——记忆用可插拔后端的虚拟文件系统（临时的草稿区，跨对话的长期留着）；沙箱 provider 是一个配置值，skills 目录和 AGENTS.md 自动识别，MCP server 从 mcp.json 捡起来，必填项只有 name。
值得单列的是反锁定立场。当下一批托管 agent 方案的隐性代价是收窄选择权：绑单一模型商、闭源 harness、服务端压缩只生成生态内可读的加密摘要——团队渐渐看不见自己的 agent 怎么工作，想改都改不动。而这套的口径相反：harness MIT 协议、完全开源，agent 指令用开放标准 AGENTS.md，对外经 MCP、A2A、Agent Protocol 开放协议暴露，模型和沙箱都不绑定，限流、重试、回退、PII 检测、文件权限每层可查可改。
小夏点评
- 1. 这篇指南真正的分水岭是把”可中断、可恢复”抬成了入场券：持久执行是地基，记忆、人在环、cron 全都盖在上面。生产级 agent 基础设施与”能跑起来的框架”的差距，就在这台机器室值不值得单独建一层。
- 2. “沙箱保护宿主机，不保护沙箱自己”这句应抄送每个 agent 团队的周会：提示注入之下，放进沙箱的凭据视同沦陷，密钥要在沙箱外加注——auth proxy 这种 sidecar 思路会是未来所有 agent 运行时（不只 LangChain）的标配。
- 3. 对国内做自托管推理栈（vLLM/Dynamo 那一挂）的团队最有实际意义的是两个细节：长期记忆落在你自己的 PostgreSQL、标准格式可直接查询；对外走 MCP/A2A/AGENTS.md 开放协议。数据主权和协议主权都在自己手里，这层底座完全可以独立评估、独立选型。
来源
- – https://www.langchain.com/blog/runtime-behind-production-deep-agents
- – 文档：Deep Agents deploy 指南 https://docs.langchain.com/oss/python/deepagents/deploy
- – 文档：Agent Server 与 LangSmith Deployment https://docs.langchain.com/langsmith/agent-server
