DeepSeek Super-agent：把人的注意力当作稀缺资源的 Agent 架构

一句话定义（stated）：Super-agent 是一套全天候运行、主动发现工作、自主分派并持续跟进多任务的 Agent 系统。它的设计目标不是让单次对话更聪明，而是尽量少占用人的注意力，尽量多交付价值（take as little human attention as possible, and give as much value as possible）。

背景：瓶颈从模型能力转移到人的注意力

DeepSeek 在文章开篇给出了整个设计的出发点：

一个人通常只能同时跟进 3 到 5 个活跃的会话。在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

今天的 Chat 式 Agent 有一个共同结构：所有工作的起点都是人。打开窗口、输入任务、盯着执行、检查结果、再给下一个任务。模型再强，能同时推进的事情仍然只是"人盯得过来的那几个窗口"。于是人从执行者变成了项目经理，注意力成为系统吞吐量的硬上限。

Super-agent 要改变的是这个起点：让事件而不是人触发工作，让系统自己决定谁来做、做到哪一步，只在必须由人拍板时才把人拉回来。DeepSeek 内部实例的典型行为是：群里有人报了一个问题但没有 @ 机器人，Agent 自己判断值得处理，后台复现、定位、起草修复 PR，等人 review。

需要说明的是，DeepSeek 明确把这一定位为系统工程层面的组合创新，而非新的理论突破：多 Agent 分工、事件触发、异步执行都是成熟思想，难点在于把它们组织成一套能长期承载多任务、又不淹没团队的运行时。

整体架构：Router + Worker 两层

        群聊 / GitHub / 邮件 / CI / 告警
                    │
                    ▼
            ┌───────────────┐
            │    Router     │  接收消息、理解任务关系、分派、订阅
            └───────────────┘
                    │ Assignment
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   ┌─────────┐ ┌─────────┐ ┌─────────┐
   │ Worker A│ │ Worker B│ │ Worker C│   每个 Ticket 独立会话与工作目录
   └─────────┘ └─────────┘ └─────────┘
        │           │           │
        └───────────┴───────────┘
                    │ 结果 / 提问 / PR
                    ▼
              回到原会话或面板

• Router 长期在线，负责接收消息、理解任务之间的关系、把工作分派给 Worker。
• Worker 执行具体任务。每个工单拥有独立的执行会话和工作目录，避免不同任务的上下文互相污染。
• 复杂任务可以由 Worker 再调用子 Agent。
• 订阅机制把后续讨论接回原工单：PR 上的 review 意见、群里的补充说明，会路由回负责它的 Worker；超出工单范围的新请求则退回协调层重新判断。
• 为控制上下文成本，排队消息会批量处理，旧记录按需检索，而不是每次把全部历史塞给模型。

领域模型：把"谁可以做、做到哪"写进系统

官方原型最值得学习的部分，不是 Router/Worker 这个直觉结构，而是它把授权与生命周期做成了显式的领域对象。核心流转是：

Source → Trigger → Thread → Eval → Ticket(Mandate) → Assignment(Executor) → Channel

概念	通俗解释	关键规则
Source	事件来源，如 GitHub、飞书	记录自己的读取位置；重启不重放事件；丢弃机器人自己的消息
Trigger	一条不可变事件	同一事件被接受两次也只生成一个工单（幂等）
Thread	按时间排列的事件流	同一 Thread 同时只跑一个 Eval；可以有多个工单
Eval	对一批事件做判断	两层：gate（程序化准入）+ assessment（模型判断）；无状态
Ticket	一个被授权的工作单元	只有 Eval 能创建；有自己的生命周期，不跟随 Executor
Mandate	这次授权允许做什么、做多远	不可变；范围扩大就要新开工单；只有人能撤回
Assignment	工单与某个执行器的绑定	一个工单可先后有多个 Assignment；执行器在领域之外
Subscription	工单与 Thread 的多对多订阅	后续讨论自动到达执行器，但不授予新权限
Channel	Thread 的写侧	确认、回复、PR、review 都通过它写回原处
Policy	版本化的准入规则	规则变更影响在途工单，但不会静默撤销已有 Mandate

这套模型解决的是自动化系统最容易失控的两个问题：

1. 上下文串味：一个工单一个会话、一个目录，讨论靠订阅而不是靠把所有历史塞进一个巨长的 context。
2. 权限漂移：消息、评论、引用文档都只是决策输入，不能改变权限；能不能做、做到哪一步，由 Mandate 和 Policy 决定。

准入：先程序化过滤，再让模型判断

Super-agent 面对的第一个工程现实是：绝大多数消息是闲聊。如果每条群消息都叫醒模型，成本和噪音都会失控。原型的做法是两层过滤：

1. Gate（程序化）：看来源、发送者是否在白名单、消息是否 @ 了 Agent 或属于私聊、来源的准入表怎么配置。
2. Assessment（模型）：只对通过 gate 的候选做判断，输出 accept / stop / ignore / unavailable。

准入强度分三档：

强度	典型情况	含义
explicit	白名单成员直接 @ Agent 或私聊	明确请求，可以直接开工
inferred	未在白名单的人在某工单 Thread 下追问；白名单机器人发来的候选	推断出的候选，是否执行取决于 accept mode
not admitted	其他机器人消息、被准入表忽略的消息	不进入执行

几个容易被忽略但很关键的设计：

• 白名单机器人只能产生 inferred 候选，不能产生 explicit 请求，也不能停止工单。
• 观察模式（observe / off）：规则允许的主动工作，可以先只记录"Agent 本来会做什么"，不真正执行；确认行为符合预期后再放开。
• Policy 版本化：规则收紧不会立刻掐断已经开工的工单，但工单恢复前会用当前 Policy 重新验证 Mandate。
• 只有人能 stop：Agent 可以结束自己的工作，但不能撤销自己的授权。

事件触发与"静默复现"

事件可以来自群聊里的 bug 报告，也可以来自失败的 CI。对于没人明确要求的工作，团队必须预先写下允许执行的规则。DeepSeek 内部使用的典型策略叫**「静默复现并修复」**：

1. 有人报告问题但没有 @ Agent；
2. Agent 在后台尝试复现、定位；
3. 只有在问题被确认、且存在简单解法时，才提交结果（例如 PR）。

文章把这种"先花一点算力，提前准备可能有用的结果"称为投机执行（speculative execution）。它和盲目自动化不同：执行是投机的，对外说话仍然受严格约束。

反馈纪律被写进了哲学文档：

• 收到明确请求时，简短确认一次，说明要做什么；
• 工作期间保持安静；
• 只在三种时刻再说话：结果可用、需要人决策、无法完成；
• 一个具体问题用结构化形式一次问一个，避免埋在长报告里；
• 按影响面停止，而不是按工作量停止：本地改动做到可 review 为止；需要设计决策的改动带着清晰问题停下。

异步、恢复与看门狗

长任务不能阻塞会话。原型的阈值很具体：命令运行超过 5 秒就转入后台，Worker 继续接收后续消息；新需求在当前推理步骤结束后处理，而不是等后台任务跑完。

更值得注意的是计算与存储分离。系统把三样东西拆开：

1. 驱动 Agent 运行的程序；
2. 保存任务进度的记录；
3. 存放代码和工具的电脑。

程序可以在云上，进度记录可以单独存储，代码可以留在用户自己的机器上，需要时再连回来。这样运行时可以重启或替换，任务从记录恢复；需要离线机器时，工作就等那台机器重新上线。这解决了"Agent 必须 7×24 在线"和"代码与凭证必须留在内网"之间的矛盾。

此外还有一个独立监督者 Watchdog：周期性检查其他 Agent 是否已经失败、是否在重复无效动作、是否偏离任务，并尝试干预和恢复。

工程实现状态与边界

项目	状态
官方仓库	deepseek-ai/dsh-superagent-prototype
许可证	MIT
定位	研究原型（research prototype），不是官方产品
公开能力	面向单个 GitHub 仓库；可选飞书集成；带 Web 面板
未实现	文章中的部分设计只是未来方向，原型并未全部落地
文档	编号文档 000–008，按顺序阅读，每篇只依赖前一篇

官方 README 特别提示：代码大量由 coding agent 写成，可能存在 bug，工程风格不一定统一，使用前需要自行审查和适配。

它的局限也需要诚实标注：

• 它是系统集成创新，不是新算法或新理论；
• 公开原型只覆盖单仓库场景，组织级多项目调度尚未验证；
• 可靠性、运行成本、是否真的节省人的时间，仍需真实场景检验；
• "一切都用 Prompt 表达策略"很灵活，但也意味着策略的可测试性和可审计性要额外补足。

与 Harness 的关系

层	解决的问题	典型对象
Harness	一个 Agent 如何在上下文、工具、权限、生命周期约束下持续工作	会话、工具调用、沙箱、审批、事件、持久化
Super-agent	一群 Agent 如何在一个组织里持续接活，而不淹没组织	事件源、路由、准入、工单隔离、验收、注意力预算

换句话说：Harness 让一个 Agent 能干活；Super-agent 让一群 Agent 在组织里持续干活，而人只需要批奏折。

关联词条

• Harness（智能体执行框架）（concept）
• 从一次 LLM 调用到完整 Harness（concept）
• 卡兹克的 Agent 系统（case-study）
• Super-agent 专题总览