Managed Deep Agents 越省事，迁移可能越疼

mda deploy。

LangChain 刚把 Managed Deep Agents 推进公开测试，最抢眼的承诺就藏在这条命令里。用 Python 或 TypeScript 写一个 Deep Agent，本地跑通，然后敲一下，持久化执行、长期记忆、沙箱、身份、渠道、评测和追踪一起搬进 LangSmith。

好家伙，一个 Agent 团队几个月的脏活，表面上被压成了两个单词。

这事当然值得高兴。长任务暂停以后怎么恢复，进程重启会不会丢状态，同一个 Slack 事件重复送达两次该不该重跑，沙箱谁来创建和回收，用户 A 的记忆会不会串到用户 B，那些功能演示里看不见的边角，才是 Agent 真上线以后每天敲你脑门的东西。

Managed Deep Agents 愿意接走这些活，挺香。

可我看到「开源」「模型无关」「托管运行时」三个词同时出现时，还是想把兴奋往下压一点。模型能换，不代表整套 Agent 就容易搬。 当持久化、记忆、身份、沙箱和评测全由一个运行时接管，新的依赖不会消失，只会从模型 API 往上移动。

所以这篇不做功能清单。我更想聊聊一条 mda deploy 到底替团队省掉了什么，又把什么写进了未来的迁移账本。

Agent 上线最难的，从来不是那次模型调用

本地 demo 的世界很友好。

进程活着，内存就在。工具失败了，重新点一下。上下文太长，开个新会话。文件改坏了，开发者自己看着终端收拾。用户也只有一个，就是坐在电脑前的你。

生产环境没这么客气。

一个研究 Agent 可能跑几小时，中间等人工批准，第二天收到回复再继续。一个编码 Agent 可能先改文件，再装依赖，跑测试时容器重启了。一个运维 Agent 从 Slack 收到告警，动作做到一半超时，消息平台又把同一个事件重送一遍。此时简单的「失败就重试」很可能把数据库改两次，把通知发两遍，或者让两个恢复任务同时写同一份状态。

这玩意已经不只是调用 LLM，它更像一台会暂停、会忘事、会拿工具改世界的分布式应用。

LangChain 在官方说明里给出的能力，正好对应这串麻烦。Durable execution 负责暂停、重试和恢复，persistence 保存线程状态，streaming 把进度推给用户，sandbox 给文件和代码一个隔离工作区，tracing 记录模型、工具、文件与错误发生过什么。

LangSmith Deployment 是它下面那层运行底座。官方说，从零补齐这些生产模式，可能要花数月甚至数个季度。我觉得这个判断并不夸张。真正磨人的往往不是把状态写进 PostgreSQL，而是恢复以后从哪一步继续，旧工具调用是否已经产生副作用，取消请求到了时任务是不是还在后台跑，部署新版本能不能读懂旧状态。

Managed Deep Agents 的价值，是把一批大家都会踩的坑做成默认路径。小团队不用先养一套 Agent 平台，才能验证业务有没有人用。

这一下很实在。

图｜LangChain 官方列出的生产运行时能力，单个组件不难，难的是让它们在故障里一起工作。

官方还把 channels 做成了项目里的一级目录。以 Slack 为例，开发者声明监听 app_mention 和 direct_message，运行时就负责挂载事件端点、校验平台签名、附上身份标记，再把结果送回原会话。过去团队要单独写一层 webhook 服务，现在它可以和 Agent 一起部署。

听起来只是少写了点胶水代码，实际省掉的是一串很烦的协议细节。Slack 可能重送事件，GitHub webhook 也可能因为超时再次投递。同一个 mention 到了两次，Agent 要不要跑两遍。同一个代码评审被两个 worker 同时捡走，评论会不会重复发。用户在 Agent 等待批准时撤回消息，长任务该继续还是取消。

渠道一旦进入运行时，事件 ID、线程 ID、用户 ID 和任务 ID 就不再是四个随手拼起来的字符串。它们共同决定一次动作能不能安全恢复。

所以我会把 channels 看成持久化执行的入口合同，而不是聊天框插件。入口替你验签很好，业务仍要给外部副作用加幂等键。Agent 可以重试推理，可以重跑读取，已经创建工单、合并代码或发出通知的动作，必须知道自己做过没有。否则运行时越会恢复，重复执行就越稳定。

这也是托管平台最容易被低估的地方。它交付的不只是几个组件，而是一组组件如何配合的默认语义。你买到的是少踩坑，也同时接受了它对任务、线程、渠道和恢复的定义。

但默认路径也是路径依赖的起点。你的暂停语义、线程模型、追踪字段、记忆挂载和部署生命周期，一旦围着 LangSmith 长出来，未来要搬的就不只是几段模型调用代码。

开源脚手架能搬，运行时行为未必能原样搬

LangChain 这次有个设计我挺认同。

Deep Agents 本身是开源脚手架，模型也不绑死。模型、提示词、工具、中间件、子 Agent 和业务逻辑仍放在你的仓库里。项目目录甚至很朴素，agent.py、tools/、middleware/、skills/、sandbox/、evals/，一眼就能看懂谁归代码仓库管。

敲下 mda deploy 后，另一部分开始进入托管世界。部署会编译项目，把指令和 skills 同步到 LangSmith Context Hub，创建托管 deployment。运行时生成的记忆不会在重新部署时被覆盖，它们通过 /memories/ 留下来。

这里有一条很重要的分界线。

仓库里的指令和 skills 属于部署版本，运行中积累的记忆属于活状态。前者可以跟着 Git 回滚，后者要跨版本继续活着。划分得挺合理，但迁移时必须同时搬两套东西，代码资产和运行资产。

图｜官方架构里，业务逻辑留在 Agent Loop，Context Hub、Deployment、Sandbox、Channels 与 Evals 围在外层。

更麻烦的是，两套资产会互相解释。

假设旧版指令让 Agent 把客户偏好写成一段自由文本，新版代码却开始按结构化字段读取。部署顺利完成，记忆也一条没丢，Agent 反而可能理解不了自己留下的东西。数据库没有坏，业务已经坏了。

传统服务升级会给 schema 写 migration，Agent 记忆也需要同样的纪律。记忆格式要有版本，读取端要兼容旧数据，删除和保留周期要说清，敏感字段不能因为方便就永久躺在 /memories/。如果 Agent 可以自己改记忆，还要区分用户明确给出的偏好、模型推断出的偏好和工具返回的事实。三者混在一个文件里，过几个月谁都说不清哪句话该信。

很多朋友可能不知道，长期记忆最大的风险未必是忘掉，而是记住一个错误结论以后反复沿用。托管运行时能保证文件没丢，却不会替业务判断内容是否应该留下。这个验收仍然属于你的 Agent 设计。

很多团队评估锁定，只盯模型接口长得像不像 OpenAI。这个视角已经有点旧了。Agent 时代更难搬的，常常是运行时语义。

同样叫 memory，可能是一组文件，也可能是向量库里的片段，还可能是每轮自动注入系统提示词的用户偏好。同样叫 sandbox，有的平台按线程创建，有的平台按 Agent 共享，有的平台任务结束就销毁。Managed Deep Agents 默认每个 durable thread 一个沙箱，也允许把 scope 设成 agent。这一个配置，会直接改变文件隔离、并发冲突、缓存复用和清理成本。

模型从 A 换到 B，改一行 provider 也许就够了。把 thread-scoped sandbox 搬到另一套平台，还要保住原来的恢复、权限和文件生命周期，没那么潇洒。

这并不是说托管不能用。恰恰相反，托管值得用，但要把可迁移边界设计在第一天。 至少把业务状态的 schema、工具副作用的幂等键、记忆导出格式和评测任务放在自己能版本控制的位置。哪天真要换运行时，痛苦可以来自搬家，别来自考古。

沙箱解决了能不能跑，身份决定它该不该跑

Agent 拿到 shell 和文件系统以后，能力一下就从「会回答」变成「会动手」。

Managed Deep Agents 对 LangSmith Sandboxes 提供一等支持。默认按线程隔离工作区，Agent 可以检查文件、写产物、装依赖、调用 CLI、跑测试，平台负责沙箱创建、生命周期和回收，活动也会进入 tracing。

厉害了，过去需要自己接容器池、任务队列和清理器的一层，现在几行配置就能拿到。

可沙箱只回答「代码在哪里跑」，它不会自动回答「这段代码替谁跑」「可以访问谁的数据」。后两个问题落在 identity 和 credential 上。

公开测试目前提供的是基础身份模型。Agent 可以使用固定凭据，也可以在 identity.py 或 identity.ts 里接 OIDC provider，再按终端用户 ID 隔离线程。运行时还会给渠道事件加身份标记，而不是相信提示词里自报的用户名。这个方向是对的，身份必须来自可信边界，不能靠一句「我是管理员」决定权限。

但官方也写得很直白，更完整的认证和凭据流还在后续补。换成生产语言就是，当前 public beta 的身份层能起步，却不等于所有多租户场景都已经收工。

你如果要让 Agent 访问 GitHub、Slack、工单系统和内部数据库，至少还要问几句。固定凭据是整套 deployment 共用，还是按用户下发。访问令牌过期后，正在运行的任务怎么恢复。一个子 Agent 能不能继承主 Agent 的权限。记忆按用户隔离了，沙箱文件是否也使用相同边界。管理员撤权以后，排队中的任务还算不算数。

不是哥们，这些问题一点都不性感，却比多接一个模型重要多了。

如果你的业务只是团队内部研究助手，固定凭据加少量用户隔离可能已经够用。如果要碰客户数据、财务动作或生产变更，我会把身份和凭据成熟度放在模型效果前面。模型答错还可以拒绝执行，权限边界错了，沙箱跑得越稳，事故可能越完整。

最有价值的功能，反而可能是那个不负责打分的评测桥

功能表里我最喜欢的不是 memory，也不是 Slack channel，是 Harbor evals。

普通 LLM 评测很爱盯最终答案。回答像不像参考答案，事实有没有覆盖，语气是否符合要求。可文件型 Agent 真正的成果通常不在收尾那句话里。

它说「测试已通过」，仓库里可能还有三个失败用例。它说「报告生成完成」，文件可能放错目录。它说「依赖已经升级」，锁文件压根没动。文字很自信，工作区一片狼藉。

Managed Deep Agents 把 Harbor 接进来，mda evals init 生成可提交到仓库的任务，mda evals compile 打包 Agent 和适配器。Harbor 在隔离环境中执行任务，再让 verifier 检查文件或最终状态。评测仍由团队直接运行，可以放在本地 Docker 或自选环境里。

这个边界有点子牛逼。

托管平台帮你把生产 Agent 打包成可评测产物，但评测任务和验收器还能跟着仓库走。相比只在 LangSmith 页面里点几个分数，这种 state-based eval 更接近真正可迁移的质量资产。

做 Agent 的朋友可以把这个思路直接抄走。别只问最终回复好不好，去验收它碰过的世界。文件是否存在，diff 是否只改允许的目录，数据库是否出现预期记录，工具调用次数有没有超过预算，失败任务是否留下可恢复状态。

生产故障再变成新的回归用例。今天某次任务因为重试写了两遍，明天就加一个 verifier，要求相同幂等键只产生一份结果。这样评测才不是发布前演一遍节目，而是在给系统积累免疫记忆。

真准备上线时，我建议专门做几次不体面的测试。让任务刚写完文件就中断进程，看恢复后会不会重复写。把同一个渠道事件连续投递两次，看外部动作是否只发生一次。部署新版代码去读取旧记忆，看字段变了以后能否平稳降级。任务跑到一半撤销用户权限，再确认后续工具调用是不是立刻失效。

这些测试没有漂亮 benchmark，也很难截成产品宣传图。可它们会告诉你，托管运行时到底接住了哪些故障，哪些责任仍留在业务代码里。别等生产环境替你出题，那份试卷通常附带真实客户和凌晨告警。

故障注入跑不过，正常路径再顺也只能算演示。把恢复、撤权、重放和旧数据兼容测明白，Agent 才算真的离开开发者那台一直有人盯着的电脑。

一条命令之前，先把退出路线也写进 README

Managed Deep Agents 当前的适用边界其实很清楚。

想用代码优先的 Deep Agents，又不想自己维护持久化、执行、沙箱、渠道、调度和追踪，托管版很合适。需要自定义路由、在 graph 旁运行额外应用代码、自定义认证逻辑，或直接控制持久化层，官方建议用更底层的 LangSmith Deployment。想自己运营，则直接拿开源 Deep Agents。

公开测试也有三块醒目的施工牌，只支持 LangSmith Cloud 美国区域，当前以 CLI 为主，正式 API 仍在定型，更多区域和部署方式以后再来。

如果数据驻留、网络延迟或内部合规要求不允许美国区域，这不是「后面优化」，而是现在就不能选。CLI-first 也说明部署接口仍可能变化，自动化流水线别把 beta 命令焊得太死。

我自己的判断是，Agent 托管会越来越普遍。每支团队都重写持久化执行、沙箱编排、Slack 验签和状态追踪，确实有点浪费生命。能把几个月的基础设施压成 mda deploy，棒棒的，先跑起来往往比先造平台更值钱。

只是省事和可迁移从来不是同一条轴。

上线前留四样东西在自己手里就够了，业务状态的可读 schema，工具副作用的幂等规则，记忆的导出约定，以及能在别处运行的验收任务。它们平时看起来像多写了几页无聊文档，真正搬家时，却是你能找到岸的那几盏灯。

mda deploy 负责出发。

README 里那条退出路线，负责让你以后还能回来。