多智能体的上下文，从来不是「越多越好」
大多数多智能体框架支持子智能体（subagents）：主管智能体把任务派给下属，下属在独立上下文里干完，只把结果交回。这能隔离上下文、并行推理，却有一个常被忽略的浪费——子智能体可能把主管已经做过的事重做一遍，比如重新读同一批文件。LangChain 近期在 deepagents 里引入 context modes，正是为了精细控制「子智能体该继承主管多少上下文」，而不是一刀切地全隔离或全共享。
context modes：fork 与 isolated 两种选择
context modes 给每个子智能体一个 mode 字段，取值为 isolated 或 fork。isolated 是默认行为：子智能体从空白上下文启动，只拿到主管给的任务描述，看不到主管的对话历史。fork 则相反：设置 mode 为 fork 后，主管的当前状态（含完整对话历史）会传递给子智能体，相当于把当前线程分叉出去继续跑，再以一个工具结果的形式收回到主管那里。需要留意，fork 模式下子智能体不能声明自己的 skills——它继承主管的 skills；如果子智能体用的模型和主管不同，还可能带来提示缓存未命中。LangChain 的参考文档明确：fork 会在继承主管历史的同时，镜像主管的提示构造中间件（skills、memory、自定义中间件），从而重建一份等价的系统提示。
fork 为什么更快也更省
fork 的设计意图很务实：复用主管的对话，既省了重复的工具调用，又因复用上下文而享受提示缓存。对一个「主管已诊断出问题、剩下的活是去实现并测试修复」的 worker 来说，从空白起步意味着它得自己重新找证据；fork 让它直接接过调查现场，从断点继续。代价是缓存可能失效，但只要子智能体需要的上下文确实详细，省下的重复检索往往更划算。与之相对，isolated 适合 verifier 这类角色——它要独立评估主管的产出，若继承了主管的推理，反而会被锚定，给不出独立判断。所以选哪种模式，取决于子智能体和这项工作的关系：是接着干，还是独立查。
worker 与 verifier：两种模式各自的归处
LangChain 在官方博客里给了两个典型范式。worker 模式：主管先定位错误、追踪到某个函数，再把「实现并测试修复」派给一个 fork 子智能体，让它接着干。verifier 模式：主管完成实现后，把一个 reviewer 子智能体设成 isolated，只给它任务与评审材料、不带前面的对话，让它独立检查 diff 的正确性、向后兼容与测试覆盖。这两个范式其实对应着多智能体设计里的基本分工——有人推进、有人挑刺。context modes 把「推进者继承上下文、挑刺者保持独立」这件事，从约定俗成变成框架级的一行配置。
Connections：把凭证请出代码库
与 context modes 同期，LangChain 为 Managed Deep Agents（v0.7.0 及以上）推出 Connections，解决的是另一个生产痛点：凭证管理。今天的智能体但凡要替人办事——搜网页、开工单、提 PR——往往意味着一个 API Key 写死在每处部署里，所有动作都挂在同一个服务账号下。Connections 的做法是：把凭证作为命名凭据存在你的 LangSmith 工作区，而不是 .env、也不是构建产物；工具在运行时按 slug 通过一次调用 connections.get 读取。要轮换或吊销密钥，改工作区里的凭据即可，不用碰代码、也不用重新部署。
两种归属与两种凭据：owner 与 credential type
Connections 有两个相互独立的轴。其一是 owner（归属）：agent-owned 或 caller-owned。agent-owned 凭据属于这次部署，所有调用方共享，适合不因人而异的能力，比如网页搜索、地理编码、价格源。caller-owned 凭据在运行时按调用者解析——同一个工具，A 用户调它走 A 的身份，B 用户调它走 B 的身份，于是智能体替你提的工单上写的是你的账号，而非某个机器人的账号。其二是 credential type（凭据类型）：静态密钥或 OAuth 授权。两者正交，创建时固定，connections.get 只在已存在的凭据里挑选。
对用户拥有的 OAuth，省掉一整段授权 plumbing
对 caller-owned 的 OAuth，Connections 替你跑完了授权的来回：没有回调路由、没有 token 存储、没有刷新逻辑、也没有你项目里的同意页。Managed Deep Agents 负责驱动 OAuth 流程，工具侧只需一行 connections.get。GitHub 已随同另外 22 个服务进入连接目录，你带上 client ID 与 secret 即可，授权地址、token 地址、鉴权方法都不用自己查；任何提供 OAuth 的供应商，带上自己的元数据也能接。对开发者，这意味着「谁能调用、以谁的名义调用」从散落在代码里的硬编码，变成工作区里可审计、可治理的一项配置。
对做多智能体的团队，这是治理的一步
把 context modes 与 Connections 放在一起看，LangChain 这步的方向很清楚：多智能体不再只是「能并行」，而是要在上下文与身份两个维度上都可管理。前者解决「信息怎么流动才不会重复或泄露」，后者解决「动作以谁的名义发生、密钥放哪里」。对要把智能体放进生产的团队，这两项恰好对应两个常被忽略的合规要求——上下文隔离（避免把 A 客户的对话泄露给 B 的子智能体）与身份可审计（每次动作能追溯到具体的人）。这些不是炫技，而是多智能体从 demo 走向生产必须补的底座。
结语
context modes 与 Connections 看起来是两篇独立博客，实则点向同一个命题：多智能体的成熟度，正从「能不能协作」转向「协作是否可控」。fork 让 worker 接过上下文继续干、isolated 让 verifier 保持独立判断；Connections 把凭证与身份从代码里请出来、钉到每一次调用上。对构建者，这提醒我们：编排的下一步竞争，不在模型多强，而在上下文与身份这两根治理的线，能不能被框架级地画清楚。