Router + Worker 双层架构解析：DeepSeek 为什么认为 AI Agent 不应该只有一个 Session 的 4 个关键设计

作者注：解读 DeepSeek Super-agent 的 Router + Worker 双层架构，说明它如何把全局协调与独立执行分离，以及开发者什么时候值得在自己的 Agent 系统中采用类似设计。

如果你同时开着四五个 Coding Agent 窗口，就会遇到一个很现实的问题。一个窗口在修登录 Bug，一个在跑数据库迁移审查，另一个在等 CI 结果。你要记住每个窗口在做什么、谁在等你回复、哪两个任务之间有关联。模型确实越来越能独立干活，但管理这些会话的负担落在了人身上。

2026 年 10 月 31 日，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时以 MIT 协议开源了研究原型 dsh-superagent-prototype。其中最核心的设计是 Router + Worker 双层架构：一个常驻的 Router 负责全局协调，多个隔离的 Worker 负责具体执行。

这不是“让一个 AI 同时做更多事”的噱头。Super-agent 的重点在于用系统架构把全局协调与独立执行拆开，从而减轻人类管理多个会话的负担。本文按“问题—机制—证据—工程价值”的顺序，拆解这套架构的设计动机、关键机制、官方实验数据，以及它对 API 调用和成本管理的启示。

核心价值：读完本文，你将理解 Router + Worker 双层架构真正解决的问题，并能判断自己的 Agent 系统什么时候值得采用类似设计。

Router + Worker 核心信息速览

在深入架构之前，先把这次发布的基本事实对齐。需要强调的是：DeepSeek 开源的是研究原型，不是正式商业产品，也不是新的基础模型。

官方为 Super-agent 提出了四个目标特征：Continuous（跨渠道上下文连续）、Productive（多任务并行）、Proactive（在授权范围内主动响应事件）、Persistent（持续在线、可从部分异常中恢复）。这些是设计目标，不代表开源原型已全部实现。

为什么 AI Agent 不应该只有一个 Session

DeepSeek 团队的判断是：AI 编程工具的瓶颈正在从“模型能力”转向“人类注意力”。根据团队的日常观察，一个人通常只能有效跟进约 3—5 个活跃 Agent Session。这是团队经验判断，不是公开的大规模用户统计，但它准确描述了很多开发者的真实体感。

单 Session 与多 Session 的两难

常见的两种做法各有硬伤，Router + Worker 正是为了兼顾“全局上下文连续性”和“后台并行处理能力”而提出的。

单 Session 的问题是“堵”，多 Session 的问题是“散”。前者让一个上下文窗口承担所有任务的中间步骤，后者把协调成本全部转嫁给人。DeepSeek 的思路是在系统层面引入一个专门负责“记住全局”的角色，让执行者专心执行。

Router + Worker 双层架构如何工作

Router：只做协调的全局调度层

Router 是长期运行的逻辑层。在官方当前的架构探索中，它主要由一个常驻 LLM Session 实现，但概念上不必严格等同于一个模型会话。它的职责集中在“管”而不是“干”：

• 统一接收用户消息与 GitHub、IM、CI 等外部事件；
• 维护全局任务关联，判断是否需要建立新工作；
• 检查授权并向 Worker 分配任务，处理跨任务协调；
• 汇总需要交付给人类的信息，必要时召回旧任务上下文。

一个很关键的细节是：官方认为 Router 甚至可以不具备 Bash 工具。不让 Router 亲自执行复杂编程，就能避免它被长时间的工具调用阻塞。同时，Router 的任务往往不需要最强的推理模型，较轻量的模型有时就能满足交互与分派需要，这为“不同角色配置不同模型”提供了技术依据。

Worker：隔离执行的任务层

Worker 负责具体工作。在公开原型中，一个 Ticket 对应一个 Executor Session，每个 Ticket 拥有独立的工作目录。Worker 在授权范围内修改代码、运行测试、处理后续反馈，完成后形成 Report；需要人工决策时设置 Attention 状态，结果通过原始渠道（例如 GitHub PR）交付。

不同 Worker 的模型上下文相互独立，这解决了多任务中间步骤混杂在同一窗口的问题。但要注意，独立 Session 与独立目录不等于强安全隔离。官方部署文档说明，Worker 默认以操作者的操作系统用户身份执行命令。

一个 GitHub Issue 如何走完 Router + Worker 流程

根据开源实现的 Domain Model，任务链路可以概括为 Source → Trigger → Eval → Decision → Ticket → Assignment → Executor → Report。以“授权用户在 GitHub Issue 中请求修复 Bug”为例：

1. GitHub Source 收到 Issue 评论，产生 Trigger；
2. 系统先用确定性规则做权限过滤，再由模型判断是否符合接单规则；
3. Router 接受任务并创建 Ticket，Ticket 中记录任务范围与授权（Mandate）；
4. 系统为 Ticket 建立 Assignment，分配给对应 Worker；
5. Executor 在独立目录和独立 Session 中执行修复；
6. Worker 汇报进度或提交结果，生成 PR；
7. 系统通过原始 Issue 或 PR 线程把结果交付给用户。

如果用户随后在这个 PR 里提出修改意见，新消息可以自动关联到原任务。用户不需要再翻找“当时是哪个 Agent 会话在处理这件事”，这正是双层架构减轻人类管理负担的具体体现。

Router + Worker 的 4 个关键设计

双层架构本身只是骨架，真正让它可用的是几个针对性的工程设计。每个设计都对应一个具体问题：

Thread 订阅直通：减少 Router 的重复分派

假设 Worker A 负责某个 PR，那么这个 PR 的后续评论和 CI 结果可以按 Thread 归属直接交给 Worker A，Router 不必为每条关联消息重新决策。这是一个典型的“把高频低价值决策从中心节点卸载”的设计。

但订阅直通有明确的权限边界。官方授权文档写明：订阅消息可以提供上下文，不能扩大原 Ticket 的 Mandate。如果后续评论要求做授权范围外的新工作，Worker 应交回系统重新评估。这一点对防范外部评论中的越权指令很重要。

Router 批处理：应对突发事件

当 Router 正在进行一轮推理时，新到达的 Trigger 会先积压，下一轮作为一个批次统一分析。这相当于把“每条消息一次模型调用”变成“每轮推理处理若干消息”，在事件密集时显著摊薄单个决策的推理开销。

Inline & Spill 与链式召回：把上下文当缓存

DeepSeek 把上下文窗口视作一种缓存。Inline 是把近期很可能用到的信息直接放进窗口，例如当前任务的最新评论、相关代码行及必要的周边代码；Spill 是把不常用或过长的内容留在窗口外，只保留摘要、关联 ID 和读取入口，例如很长的历史讨论。不相关的历史消息则不必每次注入。

在此基础上延伸出 Chain of Recall（链式召回）：模型可以顺着 Trigger → Thread → Ticket → Worker 的对象关联，按需逐步找回历史信息。这比“每次塞入完整历史”更节省上下文，也更接近数据库按索引查询的思路。不过官方也承认，跨月乃至更长期的记忆仍是未解决的问题。

Router + Worker 实验数据解读

DeepSeek 做了一组初步的合成负载实验。每次模拟运行约 300 条消息，其中约 20 条是工作请求，其余是闲聊、后续反馈、取消请求和 CI 消息；每种方案运行 5 次。编程工作由耗时的模拟工具替代，所以这组数据衡量的是调度系统表现，不是代码生成质量。

端到端调度对比

与中性提示的单会话方案相比，Super-agent 的 P50 完成时间降低约 39%，P95 降低约 47%。与优先委派的单会话方案相比，P50 只有小幅优势，但 P95 长尾明显更短。也就是说，双层架构最大的收益在于让最慢的那批任务不再拖很久。

代价同样清楚：Super-agent 的缓存读取量约为中性单会话方案的 3.8 倍。它是用更多并行会话和推理资源换来更短、更稳定的完成时间。但这不等于总费用增加 3.8 倍，实际花费还取决于模型单价、缓存命中、普通输入与输出 Token、Router 与 Worker 的模型选择以及工具调用。官方也尚未公布真实工单的平均 API 花费。

订阅直通的消融实验也值得细看。移除订阅直通后，Router 需要处理的决策数增加约 30%，缓存读取 Token 增加约 37%，但完成时间几乎不变。结论是：订阅直通在该测试中主要节省 Router 的模型调用与上下文开销，而不是直接提速。

Router 批处理压力测试

这组测试中 Router 使用真实模型，Worker 使用模拟模型：

事件密度升高时，单次请求变慢了，但每个决策分摊的推理时间反而下降，说明批处理提高了有效吞吐。官方的结论很克制：在当前团队规模下单个 Router 暂时够用，但这不能推断为一套 Router 可以无限处理消息。

Router + Worker 对开发者的影响

模型分层：Router 用轻量模型，Worker 按任务选模型

双层架构最直接的工程启示是：不同角色不必使用同一个模型。Router 的工作以分类、分派和摘要为主，适合快速、低成本的模型；Worker 则根据任务复杂度选择推理能力更强的模型。原型本身也支持为 Router 和 Worker 分别指定模型提供方与模型。

下面是一个最小示意，用同一个 OpenAI 兼容接口让 Router 做分派判断：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 统一接口，一个 Key 切换多家模型
)

ROUTER_MODEL = "your-fast-cheap-model"   # 替换为控制台中可用的轻量模型名

resp = client.chat.completions.create(
    model=ROUTER_MODEL,
    messages=[{"role": "user", "content": "判断这条 Issue 评论是否需要新建 Ticket:修复登录页 500 错误"}]
)
print(resp.choices[0].message.content)

import json
import openai
from typing import Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# 角色与模型分层:模型名请替换为你实际可用的模型
ROLE_MODELS: Dict[str, str] = {
    "router": "your-fast-cheap-model",
    "worker_simple": "your-mid-tier-model",
    "worker_complex": "your-strong-reasoning-model",
}

usage_log = []  # 按 Ticket 记录 Token 消耗

def call(role: str, ticket_id: str, prompt: str) -> str:
    resp = client.chat.completions.create(
        model=ROLE_MODELS[role],
        messages=[{"role": "user", "content": prompt}],
    )
    u = resp.usage
    usage_log.append({
        "ticket": ticket_id, "role": role,
        "input": u.prompt_tokens, "output": u.completion_tokens,
    })
    return resp.choices[0].message.content

def router_dispatch(ticket_id: str, event: str) -> str:
    prompt = (
        "你是任务调度器,只做分类,不执行任务。"
        "输出 JSON:{\"accept\": bool, \"complexity\": \"simple\"|\"complex\"}\n"
        f"事件:{event}"
    )
    decision = json.loads(call("router", ticket_id, prompt))
    if not decision["accept"]:
        return "ignored"
    role = "worker_complex" if decision["complexity"] == "complex" else "worker_simple"
    return call(role, ticket_id, f"在授权范围内处理任务:{event}")

print(router_dispatch("T-001", "CI 失败:单元测试 test_login 超时"))
print(usage_log)

🎯 技术建议：搭建分层 Agent 时，建议先通过 API易 apiyi.com 用同一个 API Key 分别测试轻量模型与强推理模型在 Router、Worker 角色上的表现，再决定最终配置，避免给所有角色都使用最昂贵的模型。

成本控制：按 Ticket 记账，而不是看总账

官方实验显示双层架构会消耗更多推理资源，因此成本管理必须更细。比较实用的做法包括：

• 按 Ticket 记录 Token：区分 Router 决策开销和 Worker 执行开销，定位哪类任务最贵；
• 区分费用类型：模型费用、工具费用（如搜索、网页获取）和执行环境费用分开统计；
• 关注缓存命中：Super-agent 的 Token 大头是缓存读取，而缓存命中与未命中的单价差异可能很大，以 DeepSeek 官方价格为例，两者相差数十倍；
• 减少无效决策：借鉴订阅直通思路，让后续事件直达负责的 Worker，砍掉 Router 的重复分派。

💰 成本优化：多 Worker 并行意味着调用量会成倍增加。通过 API易 apiyi.com 按量计费调用多家模型，可以在同一账单里对比不同角色、不同模型的实际花费，更方便做分层成本优化。

什么时候值得采用 Router + Worker

双层架构不是越复杂越好。可以参考以下判断：

• 适合采用：同时存在多个相互独立的工作事项（如 Ticket A 修 Bug、Ticket B 审迁移、Ticket C 处理 CI），且事件来自多个渠道、需要持续在线响应；
• 可以暂缓：任务数量少、彼此强依赖，或主要是围绕单个复杂任务分工，单 Agent 或传统 Agent Team 更省资源；
• 需要先补基础设施：权限隔离、文件修改冲突处理、按任务计费日志还没就绪时，贸然并行反而放大风险。

还要注意，Router + Worker 和普通 Agent Team 的侧重点不同。普通 Agent Team 往往把一个复杂任务拆成研究、编码、测试等角色；Super-agent 的 Router 更强调在多个独立事项之间协调，而不深入每项任务的技术细节。官方也说明，如果普通 Agent Team 的主会话只做统一交互与跨任务分派，同样能形成类似结构，双层架构并不是 DeepSeek 独占的概念。

Router + Worker 架构的局限与原型边界

写这类架构解析，最容易犯的错误是把设计文章里的完整蓝图当成开源原型的现有功能。按资料严格区分：

• 原型已支持：监听单个 GitHub 仓库、可选飞书接入、Ticket 管理、独立 Worker 会话与目录、生成 PR、管理面板展示待人工处理任务、按后续消息继续工作；
• 设计中但未证明完整实现：多仓库自动管理、生产级云端持续运行与跨设备环境、完整的独立 Watchdog 自治修复；异步 ReAct Loop 已在 Harness 中实现但尚未默认启用；
• 主动性有边界：推断出的工作默认使用 observe 模式，只记录不执行；PR 自动合并默认关闭。

架构层面仍有几个公开承认的难题。第一是单 Router 扩展，官方只说当前团队规模下够用，更大规模如何分片尚无答案。第二是长期记忆，Inline & Spill 和链式召回解决了中短期上下文，跨月记忆仍未解决。第三是权限边界，Router 与 Worker 的预设运行在 danger-full-access 模式，默认以操作者系统用户身份执行，官方建议使用独立系统用户；外部评论带来的 Prompt Injection、凭证管理也列在待解决问题中。社区还出现过针对特定 commit 的第三方源码审计报告，但完整攻击过程未被独立复现，只能视为潜在风险。

社区实测也印证了“原型”定位：有用户按 SETUP.md 从全新克隆成功跑通了 Issue 到 PR 的端到端流程，同时也报告了 Node.js 24 进程识别、GitHub 通知延迟漏消息、中文系统语言导致测试断言失败等问题。

常见问题 FAQ

Router + Worker 核心要点 Key Takeaways

• 核心定位：Super-agent 是模型之外的系统架构，开源的是研究原型而非商业产品；
• 问题本质：瓶颈从模型能力转向人类注意力，单 Session 会“堵”，多 Session 会“散”；
• 职责分离：Router 只做全局协调甚至不配 Bash，Worker 在隔离会话中独立执行；
• 关键机制：订阅直通卸载 Router 决策，批处理摊薄推理开销，Inline & Spill 把上下文当缓存；
• 数据边界：调度实验显示长尾完成时间更短，但 Token 消耗更高，且不代表编码能力；
• 上手方式：可借助 API易 apiyi.com 统一接口为不同角色配置不同模型，按 Ticket 管理成本。

总结

DeepSeek 用 Router + Worker 回答了“AI Agent 为什么不应该只有一个 Session”：

1. 架构价值：把全局协调与独立执行拆开，让系统记住任务关系，而不是让人记住；
2. 工程设计：订阅直通、批处理、Inline & Spill 和链式召回，分别对应中心负载、突发吞吐、上下文容量和历史召回问题；
3. 理性看待：实验证明的是调度效率与资源开销的权衡，单 Router 扩展、长期记忆和权限隔离仍待解决。

如果你的系统已经需要同时处理多个独立事项，双层架构值得借鉴；如果任务少而集中，单 Agent 依然是更经济的选择。无论采用哪种结构，模型分层和按任务记账都是控制成本的关键。

推荐通过 API易 apiyi.com 快速验证不同模型在 Router 与 Worker 角色上的效果，平台提供 OpenAI 兼容接口、按量计费和新用户免费测试额度。

📚 参考资料

1. DeepSeek 官方架构文章：Super-agent 设计探索：迈向更自主的 Agent 系统
2. 链接： x.com/DeepSeekHarness/article/2116857257245987236

3. 说明： 双层架构、五大模块、实验数据与未解决问题的一手来源

4. DeepSeek 官方 GitHub 仓库：dsh-superagent-prototype

5. 链接： github.com/deepseek-ai/dsh-superagent-prototype

6. 说明： 项目状态、源码、协议与当前适用范围

7. 开源 Domain Model 文档：任务对象与流转模型

8. 链接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md

9. 说明： Source、Trigger、Ticket、Assignment 等核心概念定义

10. 授权与订阅文档：Mandate 与 Thread 订阅规则

11. 链接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md

12. 说明： 订阅消息不能扩大授权范围的官方说明

13. 部署文档：依赖、账号与安全提示

14. 链接： github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md

15. 说明： 高权限运行模式与独立系统用户建议

16. DeepSeek API 官方定价：模型与工具价格

17. 链接： api-docs.deepseek.com/quick_start/pricing
18. 说明： 缓存命中与未命中价格差异，成本估算参考

作者: APIYI 技术团队
技术交流: 欢迎在 API易 apiyi.com 网站首页联系我们交流 Agent 架构与多模型调用实践，更多资料可访问 docs.apiyi.com 文档中心

延伸阅读

• 一个人最多盯 5 个会话？拆解 DeepSeek 超级智能体五大模块:解读 DeepSeek Harness 团队的超级智能体（Super-agent）架构文章：五大模块、实验条件与数据、四个开放问题、小团队落地清单，以及 Router 与 Worker 的模型搭配和成本估算。