LangChain deepagents 推出子智能体上下文模式 isolated 与 fork

TL;DR

大多数 harness 都支持 subagents 功能，可以从 supervisor agent 派生出新任务。Subagents 支持 并行推理和上下文隔离，让 supervisor agent 可以委派工作而不污染上下文窗口。

Supervisor agents 指定任务，subagents 通常在全新的上下文窗口中完成任务。这可能导致浪费：subagents 可能会重复 supervisor 已经做过的上下文收集操作，比如读取文件。

对于 subagents 可以从 supervisor agent 的上下文中获益的场景，我们构建了 forked subagents。Forked subagents 继承 supervisor 的完整对话，而不是从零开始。Forking 可能比隔离的 subagents 更快、更便宜，因为复用 supervisor 的对话可以利用 prompt caching 并减少重复工作。

带有 subagents 的 Harnesses

将任务委派给 subagents 是 agent 管理自身上下文的一种有效方式。Subagents 提供 上下文隔离，从而可以将各个任务的细节排除在 supervisor agent 的上下文窗口之外。如果你想了解更多，我们详细写过不同的多 agent 架构！

supervisor 是最具通用性的模式之一，大多数 coding harness 都采用了它。在这里，supervisor 维护一个计划并将工作委派给专门的 subagents。例如，

• Workers：处理一些范围明确的实现工作。
• Reviewers：对已完成的工作做出独立判断。

Supervisor agent 通常只从 subagents 接收任务的结果；它们的中间推理被排除在其上下文窗口之外。然而，subagents 应该从 supervisor 接收什么上下文，取决于 subagent 的用途。

Subagents 的上下文模式

为了帮助明确这一点，我们在最新版本的 deepagents 中引入了上下文模式。上下文模式指定 subagents 可以从 supervisor 接收什么上下文。支持的值为 "isolated" 和 "fork"。

隔离的 subagents

这是 Deep Agents 中 subagents 的默认且原有的行为。Subagents 以全新的上下文窗口启动，只接收 supervisor 指定的任务描述。

Forked subagents

设置 "mode": "fork"，supervisor 的当前状态会传播到 subagents，而不是以空状态启动。这实际上是当前线程的一个分叉延续——附带一条由 supervisor 编写的附加指令——最终被展开为 supervisor 读取的单个工具结果。

具体来说：

• Supervisor agents 生成一个工具调用，用任务描述调用 subagent。
• Subagent 接收整个 supervisor agent 的状态，包括对话历史。末尾的工具调用被移除，其任务描述被格式化为一条用户消息，并附带一段固定的 preamble 以说明其角色。
• 当 subagent 完成时，supervisor 会收到它的最终消息，作为对最初工具调用的响应。

尽管 forked subagents 比隔离的 subagents 被注入了更多上下文，但 prompt caching 在设计上得到了尊重。在 subagents 需要详细上下文才能正确执行任务的情况下，forking 可以省去重复的工具调用和上下文收集。

选择上下文模式

上下文模式的正确选择取决于子代理与工作的关系。一个有用的思考方式是用两种常见模式：继续主管工作的执行者，以及独立评估工作的验证者。

执行者代理：继续已在进行中的工作

执行者在主管已经收集上下文或做出决策后，执行一项工作。例如，主管可能检查一个错误，将其追溯到某个特定函数，然后委托实施并测试修复方案。

让执行者在隔离状态下启动会迫使它重新发现证据。使用fork时，它会收到主管的历史记录，并能从调查中断的地方继续。当某项工作需要完成，但主管不一定关心得出结论所经历的中间步骤时，主管会调用它。

const fixerSubagent: SubAgent = {
  mode: "fork",
  name: "fixer",
  description:
    "Use when a problem has already been diagnosed and the remaining work is to implement and test the fix",
  systemPrompt: "...",
}

主管可能会用这样的任务来调用它：

根据我们发现的超时问题更新重试逻辑，然后添加一个回归测试

验证者代理：独立评估工作

验证者根据某些标准审查另一个代理的工作——例如，检查一个 diff 的正确性、向后兼容性和测试覆盖率。

在这种情况下，继承主管的推理可能会适得其反。验证者应该评估工作本身，而不是被主管的诊断或预期所锚定。isolated模式给它任务和相关的审查材料，而不包含之前的对话。

const reviewerSubagent: SubAgent = {
  mode: "isolated",
  name: "reviewer",
  description:
    "Use after an implementation is complete and needs an independent review",
  systemPrompt: "...",
}

主管可能会这样调用它：

审查这个 diff 的完整性、向后兼容性和充分的测试覆盖率。

我们之前写过关于RubricMiddleware的文章，它是使用独立验证者的另一个实例！

专精子代理

除了工具和中间件之类的东西，上下文模式也是你可以用来让子代理专精于某项任务的杠杆之一。以下是我们认为专精的几个子代理及其与上下文模式的关系：

研究员代理：调查一个问题

研究员调查一个问题，并向主管返回一个精简的答案。例如，主管可能会委托调查关于一个不熟悉的库、一个竞争对手或某项技术决策历史的独立问题。

当问题可以独立成立时，研究员不需要主管的对话。使用isolated可以让它的上下文专注于手头的问题。当多个研究员并行运行时，这尤其有用：为每个研究员分叉会复制主管的历史记录，即使每个研究员只需要其被分配的问题。

const researcherSubagent: SubAgent = {
  mode: 'isolated',
  name: 'researcher',
  description:
    'Use to investigate a self-contained question and return a condensed, well-sourced answer',
  tools: [search_engine],
};

主管可能会这样调用它：

确定 API 在 1.2 和 1.3 版本之间是否发生了变化，并链接到相关的发布说明。

我们可以给子代理提供自己的能力（比如一个search_engine工具）来帮助它完成任务。

记忆代理：保留对话中的信息

记忆代理从一次交互中识别出以后应该可用的信息——例如，用户偏好、架构决策或对话期间确立的约束。

在这里，对话就是代理需要分析的材料。使用fork时，记忆代理会收到完整的交互，并可以决定哪些值得保留，而不需要主管在任务中重述。

const memorizerSubagent: SubAgent = {
  mode: "fork",
  name: "memorizer",
  description:
    "Use when the conversation contains durable decisions, facts, or preferences worth saving to memory",
  permissions: [
    {
      operations: ["write"],
      paths: ["/**"],
      mode: "deny",
    },
    {
      operations: ["read"],
      paths: ["/AGENTS.md", "/docs/**"],
      mode: "allow",
    },
  ],
};

主管可能会这样调用它：

记住这次对话中确立的决策和偏好。

因为我们想要精确限制记忆代理可以编辑的内容，我们可以通过设置它在工作时可以编辑哪些文件的限制来专门化这个子代理。

试一试

deepagents 是我们正在构建的一个框架，它汲取了我们与数千个不同团队合作交付代理的经验教训。你可以通过安装以下内容来尝试子代理上下文模式（参见文档 此处），以及更多功能：

# Python
uv add deepagents
# Typescript
pnpm i deepagents

通过 GitHub issues、论坛，或在 X / LinkedIn 上告诉我们你的想法！