你是不是也发现：一旦在系统中引入“主控调度多个子智能体（Supervisor-Subagents）”，响应变得奇慢无比，Token 账单更是直线飙升？

不是多 Agent 架构不行，而是你的上下文传递模式完全搞错了！

LangChain 官方团队刚刚发布了一篇深度长文：《在多智能体调度框架中治理上下文（Organizing Context in a Multi-Agent Harness）》，直接戳中了当前绝大多数团队的致命死穴：

过去大家为了“保护主控上下文不被污染”，每次派生子 Agent 都给它一个全新的、空白的上下文窗口（Isolated Mode）。
结果呢？主控刚刚辛苦排查了 10 轮日志、读了 5 个文件才定位出 Bug，转头派一个 Worker 去修复，这个“纯洁”的 Worker 啥都不知道，只能把代码翻找、报错追踪全部重新再做一遍！这在工程上叫“重复探索浪费（Rediscovery Waste）”。

为了彻底解决这个痛点，LangChain 在新一代框架 deepagents 中正式确立了两种核心上下文模式：

1. 分支继承模式（Fork Mode）：
子 Agent 直接“带薪入组”，完整继承主控截至当前的所有对话上下文。更反直觉的是，很多工程师以为传递长上下文会变贵，但现代大模型（Claude、GPT-4o、DeepSeek）都有 Prompt Caching（KV 缓存）！因为前缀完全一致，缓存命中率接近 100%，输入 Token 成本立降 50%~90%，首字延迟极低。干活的 Worker 顺着断点立刻写代码，中间过程折叠为一条干净的工具结果返回给主控，主控上下文依然干净！

2. 物理隔离模式（Isolated Mode）：
既然 Fork 这么好，能不能全用 Fork？绝不能！
像“独立审查员（Verifier）”这种负责检查代码 Diff、安全性和向后兼容性的角色，如果继承了主控的历史，就会产生“先入为主”的偏见和锚定效应，丧失客观性。此时必须物理隔离，只给它 Diff 和判定准则！

一句话总结选型口诀：
👉 接力干活的工人（Worker）与长期记忆（Memory）——坚决用 Fork，白嫖缓存，杜绝重复返工；
👉 独立把关的门禁（Verifier）与并发多路调研（Researcher）——坚决用 Isolated，斩断偏见，防止上下文雪崩！

你在做多 Agent 开发时，子任务之间是怎么传上下文的？是每次全清空，还是全堆在一起？

程序员 AI编程 大模型落地 软件架构