托管 agent 也能自己开浏览器了：LangChain Managed Deep Agents v0.10 的两处关键变化

一句话先说清楚

LangChain 在 2026 年 10 月 29 日发布了 Managed Deep Agents v0.10，进入公开测试。这次更新只有两个主角：一个是托管 agent 自己的浏览器，另一个是可以在后台跑的子 agent。前者让 agent 能对付那些没有 API、只能靠人点页面才能办成的事；后者让一次长任务不再堵住整场对话。两个功能都不花哨，但都戳在托管 agent 一直以来的两个痛点上：够不着网页，以及等不起长活。

需要先说明这篇的定位：它不是一次产品发布会式的转述。Managed Deep Agents 是 LangChain 的托管 agent 服务，跑在 LangSmith 上：开发者写一叠文件、一条命令部署，服务器、线程、沙箱都由平台托管。v0.10 仍然是公开测试版，没有公布正式版时间，价格也未最终确定。所以下文会把官方说法和尚未确定的部分分开写：凡是官方博客原文有的，照原文讲；凡是官方没给的，比如正式版日期和最终定价，明确写“未知”，不替厂商补全。

浏览器：agent 终于能对付没有 API 的网站

订机票、取消订阅、提交理赔，这些事大多发生在给人设计的网页上，而不是 API 后面。LangChain 在博客里把这个矛盾说得很直白：agent 也许能想明白步骤，但没有 API 就动不了手；直接用 curl 抓页面也不行，抓到的是 JavaScript 渲染之前的 HTML，而且什么都点不了。

v0.10 的解法是给托管 agent 配一个浏览器。这个浏览器跑在它自己的 LangSmith 沙箱里，声明方式只有几行：在项目根目录写一个 browser.py，用 define_browser 声明一个浏览器，默认每个对话独享一个，跨轮次复用，起手没有任何来自其他对话的 cookie 或登录态。声明里的两个参数值得注意：scope 决定浏览器属于一次对话还是属于一个人，idle_ttl_seconds 决定闲置多久后关掉，默认 600 秒，也就是 10 分钟。

声明之后，agent 会自动获得四个浏览器工具。browser_snapshot 读页面的无障碍树并给元素编号，browser_run 靠 JavaScript 或按编号批量操作页面，browser_screenshot 截图，必要时存进沙箱，browser_handoff 把窗口交还给人。这四个工具的分工其实透露了设计者的判断：浏览器操作的主力不是“看截图猜坐标”，而是读结构化页面树、按元素编号下指令，截图只是辅助证据。

scope="user" 是另一个关键细节。默认的 thread 作用域下，每个对话的浏览器互不相干；换成 user 作用域后，同一个登录用户在所有对话里共用一个浏览器，某个网站只用登录一次。这个取舍很真实：thread 作用域更干净、更不容易串数据，但用户每次换对话都要重新登录；user 作用域更顺手，但一个浏览器的登录态横跨多场对话，权限边界就得由开发者自己想清楚。官方文档建议有 API 时优先用 API，浏览器只补没有 API 的缺口，这句话应该被当作默认原则，而不是可有可无的提醒。

登录墙的解法：把窗口交还给人，而不是把密码交给模型

浏览器 agent 最常见的死法是卡在登录墙和二次验证前面。过去常见的 workaround 是把账号密码塞进提示词或工具参数，让模型替人登录——这在安全上几乎是最差的做法，密码会出现在消息记录和追踪日志里。

v0.10 的 browser_handoff 换了一个思路：agent 在需要登录时调用 browser_handoff 并说明原因，Slack 或 Studio 里会出现一个链接，人点开就能直接操作那个远程浏览器，输完密码点“交还”按钮，控制权回到 agent 手里。agent 随后会自己检查页面，确认登录是否成功，再继续往下走。几个实现细节值得记下来：交接链接 15 分钟后过期；handoff 调用会立即返回，agent 可以在等待期间先干别的活；密码从头到尾不进模型的消息和追踪记录。

这个设计的判断是：登录不应该由模型代劳，而应该由人亲自完成一次，模型只接手登录之后的操作。对做内部工具的团队来说，这意味着一种新的分工：agent 负责跑腿，人只在必须出面的关口出现一次。但它也有边界：交接链接只有 15 分钟，超时就得重来；如果业务流程里登录关口特别多，频繁交接本身就会变成新的打扰。把 handoff 当成万能钥匙之前，先数一数你的流程里到底有几道登录墙。

后台子 agent：长任务不再堵住对话

v0.10 的第二个主角是异步子 agent。子 agent 的概念并不新：主 agent 把一个聚焦的任务交给一个有独立上下文窗口的帮手。但在 v0.10 之前，托管服务里的子 agent 是同步跑的——主 agent 发起调用就得等答案，长任务会把整场对话连同用户一起晾在那里，多路并行更是无从谈起。

新版本允许在子 agent 定义里加一个 async 标记。加了这个标记的子 agent 会在自己的线程上跑，主 agent 可以继续和用户说话；主 agent 有一套异步任务工具，可以启动、查看、更新和取消这些后台任务。每个已部署的 agent 还会自带一个通用后台子 agent，运行时可以自行决定把委派的工作放前台还是后台。异步子 agent 不会让主 agent 陷入轮询：它完成时会自己通知，至于主 agent 当时在干什么，处理方式也分三种情况——正在跑，就在下一次模型调用前顺带检查未完成任务；闲着，就被一次新的运行唤醒；停在审批关口，就先不动，等用户答复后再把结果送达。

共享沙箱是这个设计里容易被忽略的一环。异步子 agent 和主 agent 用同一个沙箱，所以主 agent 已经写好的文件，子 agent 可以直接接着用；在 Slack 里，子 agent 的审批会发回原始对话串，在那里答复就能让子 agent 继续跑。这些细节拼起来才是一个可用的后台模式：后台不是“扔出去就不管”，而是任务、文件、审批都还在同一条对话上下文里流转。

但后台化也有代价。任务一多，状态就复杂：哪个子 agent 在跑、哪个卡在审批、哪个已经超时，都需要被看见。LangChain 这次顺带补了几个配套能力：runtime.thread 让每个线程都带上“从哪里来、谁在里面”的记录，Slack 对话串里有了原生的停止按钮，Studio 也能取消 Slack 线程上的运行。这些不是主角，却是后台模式能不能落地的前提——没有可观测、可取消的后台，所谓异步只会变成失控。

迁移成本：一次不小的破坏性变更

v0.10 里有一处必须单独提醒的破坏性变更：旧的 connectors.mcp() 和 connectors/ 目录布局被移除了，MCP 服务器必须改在 tools/mcp.ts 或 tools/mcp.py 里声明；沙箱的 scope 选项也被移除；LANGSMITH_ 开头的环境变量现在以 shell 环境为准，优先于项目里的 .env 文件。

对已经在跑 v0.9 的项目来说，这意味着升级不是改个版本号就能完事，MCP 声明要搬家，环境变量的优先级要重新核对。好消息是官方把这处变更写在了发布博客的显眼位置，没有藏在脚注里；坏消息是它恰好发生在公开测试阶段——公开测试的本意就是接口还可能变，现在升级付出的迁移成本，未来可能还要再付一次。评估是否现在上车时，这一点应该和功能收益放在同一杆秤上。

给 vibe 开发者的判断

如果你正在用 vibe 方式搭一个带 agent 的小产品，v0.10 的两个功能对应两种不同的采用姿势。浏览器功能适合这样的场景：你的 agent 必须去某个没有 API 的网站办事，而且办事流程里登录关口不多、一次登录能管一阵子。先按官方建议做一次判断：这个网站真的没有 API 吗？如果有 API，浏览器方案就是绕远路，还多一套登录态和沙箱要管。

异步子 agent 适合另一种场景：你的产品里有“用户说一句话、后台要干半小时”的任务，比如批量调研、跨多个来源整理材料。采用之前先问自己三个问题：第一，任务状态用户看得见吗？第二，用户能不能中途取消？第三，子 agent 卡在审批时，主对话会不会显得像死机了？这三个问题在 v0.10 里都有对应的机制，但机制存在不等于默认配置就够用，Slack 停止按钮、审批回帖、线程记录这些都需要你在部署时实际接好。

还有一个更宏观的判断。LangChain 在博客里引用了一个第三方数据：某安全厂商观测到 agent 浏览器请求在 9 月单月增长了 4.7 倍。这个数字是厂商引用的第三方观测，不是 LangChain 自己的实测，读的时候要打个折。但它指向的方向是真实的：越来越多 agent 开始直接操作网页，而网页恰恰是为人类点击设计的。浏览器工具、登录交接、后台任务，这些基础设施的成熟程度，正在决定 agent 能走多远——不是模型更聪明一点，而是 agent 能在真实世界的界面上走完最后一公里。

最后回到版本状态本身。v0.10 是公开测试版，部署需要加入测试计划，正式版时间与最终价格都未知。对于生产项目，更稳妥的姿势是先在非关键流程里试用浏览器与异步子 agent，验证登录交接和后台任务在你的场景里是否顺畅，等接口稳定后再扩大范围。公开测试的价值在于提前验证，而不是提前依赖。

三种浏览器配置，对应三种真实场景

光讲参数容易让人觉得这只是又一个开关，实际上 scope 与闲置超时的组合会直接决定产品体验。第一种是默认的 thread 作用域，适合一次性代办任务：用户让 agent 去某个公开网站查资料、比价格，办完即走，不需要登录，浏览器用完即弃，干净且没有跨对话串数据的风险。闲置 10 分钟自动关闭在这里是优点——沙箱不会被遗忘的浏览器会话悄悄占着资源。

第二种是 user 作用域，适合“替我盯着、替我办事”的长期助手：比如每周帮用户登录供应商后台下载对账单。用户只登录一次，之后每次对话都能复用登录态，体验顺滑得多。但代价是责任变重了：这个浏览器的登录态横跨多场对话，一旦某个网站的会话被盗用或过期，波及面不止一场对话；而且“用户”这个粒度的隔离是否等于“账号”粒度的隔离，取决于你自己的身份映射做得对不对——resolveUser 这个配套能力正是为此而来的，它把 Slack 里的发信人映射到你自己系统的用户，再由工具去查这个人的账号与权限。如果身份映射没接好，user 作用域的便利就会变成越权敞口。

第三种是刻意不复用的短命浏览器：把闲置超时设得很短，或者每次任务都起新浏览器，适合处理敏感操作，比如涉及支付、医疗、法务文件的页面。每次操作都从一张白纸开始，登录态不残留，事后审计也简单：一次任务对应一个浏览器生命周期，出了问题能精确还原。这三种配置没有优劣之分，只有场景之别；选错配置的成本往往不在功能上，而在安全复核时才暴露出来。

还有一个容易被低估的点：浏览器跑在沙箱里，意味着页面里的下载、上传、弹窗、文件读写都发生在沙箱内，而不是用户的电脑上。agent 下载的对账单、截图、导出的文件，先落在沙箱里，再由你的应用决定如何呈现给用户。文件从沙箱到用户手里的这一段，恰恰是需要你自己设计的：直接透传沙箱文件，还是先转存到对象存储再给链接？文件里会不会夹带页面注入的恶意内容？官方博客没有展开这一段，但任何把浏览器交给 agent 的产品都绕不过它。

异步任务上线前，先把这张清单走一遍

异步子 agent 最容易踩的坑不是技术，而是“用户以为它死了”。主 agent 在前台继续说话，后台任务却悄无声息地跑了半小时，用户没有进度、没有取消按钮、没有失败通知，最后只会得到两种结果：重复下单，或者直接弃用。所以上线之前，建议按下面这张清单逐项核对。

第一，状态可见。用户能不能在对话里问一句“那个任务到哪了”，就得到一句靠谱的回答？主 agent 的异步任务工具提供了查看能力，但这需要你把它暴露成用户可问、可看的界面，而不是只存在于开发者日志里。第二，取消可达。Slack 原生停止按钮与 Studio 取消能力是现成的，但如果你的 agent 跑在自研客户端里，取消路径就得自己接——没有取消按钮的后台任务，本质上是把用户锁在了一次无法反悔的等待里。

第三，失败有交代。子 agent 可能超时、可能被审批卡住、可能在中途遇到需要人确认的步骤。每种结局都应该有对应的用户侧文案：超时了是重试还是放弃，审批卡住了是等谁、等多久，失败了是给出部分结果还是明确说没做成。第四，审批不丢上下文。子 agent 的审批发回原始对话串，这个设计的好处是上下文不丢；但如果原始对话串已经沉底、用户正在聊别的事，审批消息就可能被淹没。审批提醒是否需要额外的推送通道，取决于你的产品里审批出现的频率。

第五，成本有上限。后台任务跑得越久、扇出越多，token 与沙箱资源的消耗就越难预估。公开测试阶段价格未定，更需要在应用层给后台任务设上限：单任务最长跑多久、一次对话最多扇出几个子 agent、超时后是自动取消还是先问用户。这些上限现在不设，等账单来了再设就晚了。把这张清单走完，异步才算从“功能存在”变成“产品可用”。

划界与来源说明

本文的一手来源是 LangChain 官方博客《Managed Deep Agents v0.10: Browser Use and Async Subagents》，页面标注发布于 2026 年 10 月 29 日 16:54（UTC），10 月 30 日有过一次更新。文中所有功能描述、工具名、参数名、默认超时与过期时间均以该文为准；DataDome 的 4.7 倍数据为该文引用的第三方观测，已在正文标注口径。需要区分的一篇站内旧文是 LangChain 的支付与 x402 结算层报道，那篇讲的是 agent 如何付钱，本篇讲的是 agent 如何操作网页与后台任务，两者不在同一条线上。