2 篇博文 含有标签「Supervisor」

上一篇记录了官方的推荐变更：从 createSupervisor（worker 是图节点）改成 subagents pattern（子 agent 包成 tool）。这篇回答「为什么」。

⚠️ 更正说明（2026-09-21 追加）​

本文初版把「context engineering / context isolation」当成了官方的理由来引用。这是错的：我后来拿到了官方迁移文档的原文（用 curl 直取，此前误判为被网络策略挡住），逐字核对后发现——

• 官方文档里 context engineering 出现 0 次、context isolation 出现 0 次、more control 出现 0 次；

• 官方给出的理由只有一句，而且纯粹是维护状态（原文逐字）：

  The langgraph-supervisor package is no longer actively maintained. Instead use the subagents pattern: a main agent coordinates specialized workers by calling them as tools.

• 「context engineering / isolation」那些措辞来自第三方社区资料（搜索命中的 skill 文档与技术 PDF），不是 LangChain 官方。

因此本文的定位是：官方没有给技术论证，只说了「不再积极维护」——为什么该换，官方是留白的；下面全部机制解释都是本文自己的实测分析，不是官方立场。

官方没给理由，那理由得自己找。下面用实测数据给出一个工程师视角的解释：

我的结论是：在旧模型里，框架会产生一批「你并不想要」的消息，然后用一堆参数让你把它们再弄出去。新模型从构造上就不产生它们。

注意这句是我的分析，不是官方说法。 但它有官方文档的间接印证——迁移文档里那句关于 output_mode 的原文（见 §二 末），说的正是同一件事。

环境：Node v24.14.1 / @langchain/langgraph@1.4.16 / @langchain/langgraph-supervisor@1.1.2 / langchain@1.5.11。用脚本化模型（自定义 BaseChatModel 按次序返回预置响应）替代真实 LLM——无需 API Key、执行轨迹完全确定。脚本留档在 source/langgraph-supervisor/context-growth.mjs。

Supervisor-Worker 是中心化调度最典型的形态：一个调度者负责「派活」，若干专家负责「干活」。听起来像个新概念，但把它拆开只有四件事——而且我用大约 40 行手写代码复现了官方库完全相同的执行轨迹，这就是「它内部到底做了什么」最直接的证据。

更值得一看的是后半篇：这套架构有两个成本旋钮，实测能把共享上下文从 16 条消息压到 4 条（字符数 -71%），而执行轨迹一字不变。

但请先看下面那段更正：这套架构依然有效，官方的推荐实现却换了——从 createSupervisor（worker 是图节点）换成了 subagents pattern（子 agent 包成 tool）。我在 §五 把新写法实现并实测了，结论对新写法有利。

环境：Node v24.14.1 / @langchain/langgraph@1.4.16 / @langchain/langgraph-supervisor@1.1.2。为了让执行轨迹完全确定、可复现，我用脚本化模型（按调用次序返回预置响应的自定义 BaseChatModel）替代真实 LLM——无需 API Key，全部输出都是本机真实运行结果。脚本留档在 source/langgraph-supervisor/。

⚠️ 更正说明（2026-09-20 追加）​

本文初版把 createSupervisor 当作 Supervisor-Worker 的标准做法来推荐，这一点需要更正：官方已经改了推荐路径。

• LangChain 官方文档已把新代码导向 subagents pattern——把子 agent 包成一个 tool，交给一个普通的 createAgent 调度；Python 侧另有专门的迁移文档 Migrate from langgraph-supervisor，给出了逐项映射（output_mode → 在工具包装层里自己格式化输出、create_handoff_tool → 自己写一个调用 subagent.invoke() 的 tool）。
• 同时，createReactAgent → createAgent 也是 JS v1 的既定迁移方向（见 JavaScript v1 迁移指南）。本文初版的示例两个都用上了，等于踩在两条旧路径上。

一个精确措辞上的澄清（核实依据分两层）：官方文档的原话是「no longer actively maintained」（不再积极维护）——注意它说的是「不积极维护」，不是「已废弃」。工程上的旁证是我自己核对的 npm 元数据：该包没有 deprecated 标记，最近一次发版是 2026-09-12 的 1.1.2（本文写作前 8 天），仍由 LangChain 官方维护者发布。所以：

• 存量代码不必惊慌，它不是"弃用炸弹"；
• 但新代码确实不该再用——这不是"选哪个都行"的偏好问题，官方已明确表态推荐变了。

我把 subagents pattern 也实现并实测了，结论对它有利：同一个任务、路由用的 LLM 调用次数完全相同（都是 3 次），但共享上下文只有 6 条消息，不到库版本默认值（12 条）的一半，而且不需要调任何参数。完整实现与对比见下文「五、官方已改推荐：subagents pattern」。

本文仍然值得读的部分：§三 把 supervisor「拆成四件事」的机制分析依然成立——理解机制才能看懂两种实现的关系；§四 的两个成本旋钮实测也依然有效，但请注意它的定位变了：在新范式里，这件事由「你的工具包装层返回什么」直接决定，比调库参数更自由。读的时候请把 §二/§三 当作"存量代码的长什么样"，把 §五 当作"新代码该怎么写"。