外观
🚀 Super-agent：把人的注意力从执行循环里拿出来
一句话定义（本站归纳）：Super-agent 不是"更强的单个 Agent"，而是一套把 何时触发、由谁执行、做到哪一步、何时找人拍板 从人的注意力中剥离出去的调度系统。它优化的核心指标不是单任务正确率，而是"人每天被打断多少次"。
它在整个体系里的位置
模型提供能力，执行框架让模型能持续行动，智能体让一个执行单元对完整工作负责。Super-agent 在这条线的最后一段。
| 阶段 | 解决的问题 | 与本专题的关系 |
|---|---|---|
| 模型 | 一次调用能生成什么 | 提供能力上限 |
| 执行框架 | 如何让模型持续、可控地行动 | 提供单会话执行底座 |
| 智能体 | 谁对一件完整工作负责 | 提供可交付的执行单元 |
| Super-agent | 如何让多件事并行，人只做关键决策 | 本专题 |
Super-agent 不替代前面任何一段，它解决的是它们留下的新问题：单 Agent 的并发上限，最终由人的注意力决定。 这也是理解本专题两个样本的前提——DeepSeek 在组织级、卡兹克在个人级，做的都是同一件事：把"什么时候开始、交给谁、做到哪一步、何时找人"从人的注意力里拿出来。
完整的来龙去脉见 从模型到 Super-agent：能力是怎么一层层长出来的。
为什么现在讨论 Super-agent
Chat 式 Agent 的结构是：人打开窗口 → 输入任务 → 盯着执行 → 检查结果 → 再给下一个。所有工作的起点都是人。于是模型再强，系统的并发上限仍然是"人盯得过来的那几个窗口"。
DeepSeek 把这个上限写得很直白：
一个人通常只能同时跟进 3 到 5 个活跃的会话。单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
Harness 解决的是一个 Agent 怎么持续、可控地干活；Super-agent 要解决的是一群 Agent 怎么在组织里持续接活，而不把组织淹没。这是 Harness 之后自然浮现的下一层问题：从"执行框架"走向"调度系统"。
本专题用两个互补的样本展开：
- 组织级：DeepSeek Harness 团队的 Super-agent 设计（Router/Worker、事件准入、工单授权）；
- 个人级：卡兹克的 Agent 系统（自动化中台、模型分工、自建 CI、飞书批奏折）。
两个样本，一条主线
| 维度 | DeepSeek（组织级） | 数字生命卡兹克（个人级） |
|---|---|---|
| 场景 | 团队协作：GitHub + 飞书 | 一人多项目：AIHOT + 公司中台 |
| 调度核心 | Router + Worker | 自动化中台 + rules.json |
| 事件入口 | Source / Trigger | Webhook / 定时任务 / 统一事件格式 |
| 是否开工 | Gate 程序化过滤 + Eval 模型判断 | 规则匹配 + 明确的通知策略 |
| 隔离单位 | Thread / Ticket / Mandate | 每条事件单独一轮 + 中台去重 |
| 执行器 | DSH 会话，可再调子 Agent | 本地 Mac 上的 Claude Code / Codex |
| 验收 | PR review + CI | 自建 CI 五步：审查→检查→合并→发布→核实 |
| 人的接口 | Web 面板 / 飞书 | 飞书卡片"批奏折" |
| 决策沉淀 | Policy / Mandate | 「卡兹克定的事」「定了不做的事」 |
| 正式程度 | 研究原型，MIT，单仓库 | 个人生产系统，多项目实战 |
两者规模、严谨度、可复制性都不同，但结构惊人地一致：事件进来、统一判断、隔离执行、自动验收、只把决策递给人、把判断沉淀下来。
共性架构：六层
text
① 事件源 群聊 / GitHub / CI / 邮件 / 告警 / 定时任务
│
▼
② 统一入口 格式归一、去重、留痕、单一出口
│
▼
③ 准入与路由 程序化 gate →（必要时）模型判断 → 派给谁
│
▼
④ 隔离执行 一任务一会话/目录，权限受 Mandate/规则约束
│
▼
⑤ 验收与发布 审查 → 检查 → 合并 → 发布 → 核实（Agent 不能直达线上）
│
▼
⑥ 注意力收口 只有不可逆 / 高代价 / 对外的决策才找人
│
▼
⑦ 沉淀 事件库、决定台账、可观测面板① 事件源：让工作不必从人开始
定时任务解决"可预期"的工作；Webhook 解决"要及时"的工作。两者互补：轮询不及时，推送又需要公网入口。数字生命卡兹克用"Agent 主动长轮询中台（≤50 秒）"绕开了家庭内网不能暴露公网的问题。
② 统一入口：先收口，再谈智能
这是最容易被跳过、却最影响长期可维护性的一层。所有事件压成统一格式（来源、类型、对象、摘要、回链），才能做去重、规则匹配、审计和统计。没有这一层，接入第十个事件源时系统就会失控。
③ 准入与路由：先程序化，后模型
DeepSeek 的 gate 先看来源、发送者白名单、是否 @、准入表；通过后才让模型判断。数字生命卡兹克则用规则文件直接匹配。共同点是：不要用模型做本可以用代码做的过滤。模型只负责真正需要理解的判断。
同时要区分两类权限：
- 能不能开始做（准入）；
- 可以做多远（授权范围）。
DeepSeek 用不可变的 Mandate 表达后者；数字生命卡兹克的规则里用"只在需要决策时才通知"表达边界。
④ 隔离执行：上下文与权限都要隔离
一个任务一个会话、一个工作目录，避免上下文串味；后续讨论通过订阅回到原任务，而不是把所有历史塞进一个巨长的 context。执行器还需要被限制在最小权限内：只读审查、不能联网、读不到密钥。
⑤ 验收与发布：写代码的不能自己上线
两个样本都把"执行"和"验收"分开：
- DeepSeek：Worker 产出 PR，人来 review；
- 数字生命卡兹克：Agent 的工作到 PR 为止，后面五步全部交给 CI 中台，合并规则写死在 GitHub 上，任何 Agent 都绕不过。
数字生命卡兹克还给了审查一条很实用的约束：最多审 3 轮，且只报真会出错的问题，不报风格。否则审查者会无限挑错，系统永远收敛不了。
⑥ 注意力收口：只把"必须拍板"的递给人
值得递给人的，通常具备一个或多个特征：不可逆、高代价、对外可见、涉及权限或密钥、改变产品方向。其余事情 Agent 应全权做完。
这条原则在 DeepSeek 的哲学文档里被表述为一条预算：每条消息、每个通知、每个设置、每个面板元素都在消耗某人的注意力，必须带来超过成本的价值，否则删掉。
⑦ 沉淀：让同一个问题不问第二遍
- DeepSeek：Policy 版本化、Decision 历史、工单与 Mandate 可审计；
- 数字生命卡兹克：事件数据库 + 「卡兹克定的事」+「定了不做的事」。
沉淀的对象不只是日志，更是人的判断。把"我同意过什么、拒绝过什么"写成 Agent 可读的策略，才能真正减少重复打扰。
七条可复用原则
- 事件是起点，不是人。 先问"这件事能不能在我不打开窗口时发生"。
- 准入先于智能。 能用代码过滤的，不要叫醒模型。
- 一个入口，一个出口。 事件统一进中台，找人统一走一个通道。
- 执行与验收分离。 写代码的 Agent 不能自己上线。
- 隔离上下文与权限。 一任务一会话；权限按工单授予，消息不能改权限。
- 只为不可逆决策打断人。 并把打断次数当作可优化的指标。
- 把判断写下来。 决定、拒绝、规则都要可检索、可复用。
再加一条工程习惯：新自动化先跑观察模式。DeepSeek 的原型允许"只记录本来会做什么"，数字生命卡兹克也强调先小范围验证再放开。这比一上来就全自动安全得多。
代价与风险
| 风险 | 表现 | 缓解 |
|---|---|---|
| 注意力税 | 自动化越多，通知越多，人反而更忙 | 统一出口、决策分级、把通知量当指标 |
| 噪音与误触发 | 闲聊、重复事件、机器人消息叫醒 Agent | 程序化 gate、去重、白名单、观察模式 |
| 权限爆炸 | Agent 拥有仓库、发布、登录态浏览器 | 最小权限、只读审查、临时虚拟机、密钥隔离 |
| 静默失败 | Agent 说做完了，实际没上线或做错了 | 独立核实步骤、Watchdog、可审计记录 |
| 自动化偏差 | 人逐渐不检查，错误被放大 | 保留关键人工环节（如用户反馈）、抽样复核 |
| 成本失控 | Token 与算力随并发线性上涨 | 模型分工、按任务选推理深度、预算与配额 |
| 单点依赖 | 一台机器/一个人承担全部调度 | 备份、可恢复的记录、compute/storage 分离 |
最小落地路径
如果你只想先试一步，可以按这个顺序：
- 选一件每天/每周都重复的事，改成定时任务；
- 给它配一个 Skill / SOP，把规则、参考资料、脚本写进去；
- 加一个统一入口（哪怕先是一张表或一个队列），记录来源、类型、摘要、结果；
- 写一份规则文件：什么事件交给哪个 Agent、什么情况下才通知你；
- 用观察模式跑一周，对比"它本来会做什么"和"你希望它做什么"；
- 接上验收（测试、审查、发布核实），再逐步放开自动执行；
- 维护一份决定台账，让同一个问题只问你一次。
本专题词条
| 词条 | 类型 | 角度 |
|---|---|---|
| DeepSeek Super-agent：把人的注意力当作稀缺资源的 Agent 架构 | concept | 组织级架构：Router/Worker、事件准入、工单授权、异步恢复 |
| 卡兹克的 Agent 系统 | case-study | 个人级实践：自动化中台、模型分工、自建 CI、飞书批奏折 |
关联词条
- Harness（智能体执行框架）（concept）—— Super-agent 的执行底座
- 从一次 LLM 调用到完整 Harness（concept）
- Loop Engineering：让 AI 自主闭环运转（pattern）
- OpenAI 全面开源 Codex Harness（tool）