在多数智能体 harness 中，subagents（子代理）已经是常见能力：主管代理可以把具体任务委托出去，让子代理在独立的上下文窗口里工作。这样做既能并行思考，也能避免把大量中间推理塞回主管的上下文。deepagents 团队在博文中进一步提出：子代理并非只有“从零开始”这一种方式，还可以选择是否继承主管的对话历史，这就是新的 context modes（上下文模式）。
目前支持的两种模式分别对应两类典型场景。isolated（隔离）是默认模式，子代理只收到主管下发的任务描述，在全新上下文中行动；fork（继承）则会把主管代理当前的状态传播给子代理，相当于当前对话的一个分支继续推进，最后再把结果作为一次工具调用的返回值交还给主管。fork 模式看起来会让子代理拿到更多上下文，但实现上仍然考虑到了 prompt caching，因此当子代理确实需要掌握先前细节时，它往往比 isolated 更快、更便宜，也少做很多重复的上下文收集。
那么应该如何取舍？文章用几类常见子代理给出了判断框架。像 worker 这样负责“接着做”的代理适合 fork：主管已经定位问题、形成判断，worker 可以直接基于这些上下文实现和测试修复，而不必重新读文件、重新追溯证据。相反，像 verifier 这样负责“独立评审”的代理适合 isolated：如果评审者继承了主管的推理和预期，就容易失去独立判断，它更应该只拿到 diff 和评审标准。
除了这两类，文章还展示了 researcher 与 memory agent。researcher 通常调研一个可以独立成立的问题，用 isolated 可以避免多个并行研究者各自复制主管的完整历史；memory agent 则要把对话中形成的决定、偏好和约束保存下来，fork 模式能直接让它看到完整互动，再挑选值得记忆的内容。
上下文模式并不是孤立存在的，它可以和 tools、middleware、permissions 等机制共同使用，把子代理打磨得更适合具体任务。例如 researcher 可以额外配备搜索引擎工具，memory agent 则可以限制可读写路径。对开发者而言，关键是思考子代理与当前工作的关系：是需要它继续主管的工作，还是需要它独立判断。deepagents 已经可以通过 uv add deepagents 或 pnpm i deepagents 安装体验，官方也提供了文档和 GitHub、论坛、X / LinkedIn 等反馈渠道。