隔离模式与分叉模式如何选择

在主管-子智能体架构中，主管负责维护整体计划并将具体任务委派给专门的子智能体，子智能体的中间推理过程通常不会回流到主管的上下文窗口。这种设计实现了上下文隔离，避免了无关细节污染主管的决策视野。然而，子智能体应该从主管那里继承多少上下文，并非一个固定答案，而是高度依赖于子智能体的具体用途。

deepagents 最新版本引入的上下文模式正是为了解决这一问题。isolated 是默认行为：子智能体以空白上下文启动，仅接收主管指定的任务描述。fork 模式则将主管当前的完整对话状态传递给子智能体，相当于在当前线程上创建一个分叉延续，子智能体完成任务后，其最终消息作为工具调用结果返回给主管。值得注意的是，分叉模式在设计上充分尊重提示缓存机制，能够有效降低重复上下文收集的开销。

选择哪种模式，取决于子智能体与任务的关系。执行类子智能体（Worker）适合使用 fork 模式：当主管已经完成错误定位、方案分析等前期工作后，将实现与测试任务交给执行者，分叉模式让执行者直接从调查结论出发，无需重新收集证据。相比之下，验证类子智能体（Verifier）更适合 isolated 模式：独立审查代码差异、向后兼容性或测试覆盖率时，继承主管的推理路径反而会引入锚定偏差，影响判断的客观性。

研究类子智能体（Researcher）是另一个典型场景。当主管需要并行调查多个独立问题时，每个研究者只需聚焦于自己被分配的问题，使用 isolated 模式可以避免将主管的完整历史复制到每个并行子智能体中，既节省上下文空间，又保持研究焦点清晰。此外，研究类子智能体还可以配备专属工具（如搜索引擎），进一步增强其独立完成任务的能力。

上下文模式与工具配置、中间件并列，成为专门化子智能体的核心调节手段之一。开发者可以根据子智能体的角色定位——是延续主管已有工作的执行者，还是对成果进行独立评估的验证者，抑或是聚焦单一问题的研究者——灵活选择合适的上下文策略。这一设计思路体现了多智能体系统工程中的一个重要原则：上下文本身也是需要被主动管理的资源，而非被动传递的副产品。

要点

• deepagents 引入 isolated 和 fork 两种上下文模式，让开发者可以精确控制子智能体能从主管处继承多少对话历史。
• fork 模式适合执行类子智能体，可复用主管已完成的上下文收集工作，并借助提示缓存降低成本；isolated 模式适合需要独立判断的验证类场景。
• 并行运行多个研究类子智能体时，isolated 模式可避免将主管历史重复复制到每个子智能体，显著节省上下文资源。
• 上下文模式与工具、中间件共同构成子智能体专门化的三大调节维度，是多智能体系统性能优化的关键杠杆。