核心命题：注意力是瓶颈，架构是答案
现有主流 Agent 以单一 Session 为基本单位、互相独立；一个人实际只能同时跟进约 3–5 个活跃会话。 Super-agent 的出发点是：约束多任务扩展的从来不是模型能力，而是人的注意力与系统架构。
“单任务的上限取决于模型能力，
多任务的上限取决于架构。”
“尽可能少地占用人的注意力，
尽可能多地创造价值。”
跨会话、跨信道保持上下文，不再被“聊天窗口”切碎。
多任务并行推进，响应快，长命令后台化不阻塞对话。
观察环境事件自主“找活干”，无需介入时保持安静。
常驻在线，状态持久化，异常自动检测与恢复。
一句点题：“Session 是系统实现细节，不应是用户认知负担”——手动管理会话被视为 LLM API 时代的设计惯性，Super-agent 把 Session 从用户面前拿走。
架构总览：一个 Router，多个 Worker
双层调度 + 事件驱动是整套设计的骨架：Router 只分派不执行（防止自身成为瓶颈），Worker 在隔离会话中并行干活； 同一话题（Thread）的后续消息经订阅直通直达 Worker，不再打扰 Router。底部为存算分离与 BYOM，右侧为 Watchdog 外部控制回路。
orchestrator，Worker = 执行会话 worker（src/core/engine.ts 为唯一状态写者）
六大关键机制
文章把成熟系统的思想搬进 Agent：调度学操作系统，上下文学缓存，交互学全双工通信，部署学云原生。
事件驱动：Trigger 取代 Prompt
- 输入是环境中的半结构化 Trigger（群消息、邮件/日程、PR 评论、CI 结果），而非一次性 prompt。
- Fast Path：确定性代码先筛（来源、白名单、忽略规则），成本≈0；Slow Path：LLM 语义研判，策略用自然语言书写。
- 投机执行（借鉴 CPU）：收到信号先在后台干——群里讨论 bug 时“静默复现”，确认有问题且有简单修复才交付，否则全程安静。
双层调度：Router / Worker
- Router 承接全部人类交互，只分派不执行——可以连 shell 都不配，轻量模型即可，保持“薄”以防瓶颈。
- Worker 上下文隔离、并行执行，用最强模型挂全工具；可再派 subagent。
- 触发器在 Router 思考期间排队合批——拥堵被转化为批处理效率（见实验 ③）。
订阅直通：后续消息绕过 Router
- 同一话题/PR 的事件流定义为 Thread；Router 只做“冷启动”判断，Worker 创建后订阅自己的 Thread。
- 后续消息由程序直通（pass-through）送达 Worker——不再消耗 Router 的模型决策。
- 订阅是多对多：多个 Worker 订阅同一 Thread 时可自行发现冲突、移交（handback）。
上下文当 Cache 管
- “浪费上下文窗口，就是浪费模型的智能”——太多挤占注意力，太少迫使反复调工具。
- Inline：近期大概率用到的直接入窗；Spill：完整内容留窗外，只留 ID/摘要，按需读取——即缓存局部性。
- 每个对象有唯一 ID，内联引用形成引用图，支持 Chain of Recall 链式召回：消息→Thread→Worker 会话→评审 Thread，多跳按需展开。
全双工交互 & 多信道
- 同步
run()改为异步start()/stop()：长命令立即返回“已启动”，结果作为新事件投递；输入在下一个推理边界处理。 - 多信道分级：IM 低打扰（硬性 ≤100 词）；GitHub/邮件/文档承载结构化高密度交付；推理过程隔离在 Worker 内。
- 只在“人必须行动或能用上结果”时说话；一次确认、明确对象与预期结果。
存算分离 + Watchdog
- 计算与状态分离：Agent Loop 跑云端无状态弹性容器；Session 状态存数据库，连续性由持久化保障。
- 计算与环境分离（BYOM）：重状态留在本地（未提交修改、私有凭据、内网依赖），端侧只放一个不存状态的轻量 daemon；设备离线任务排队、上线补跑。
- Watchdog：系统外的独立 Agent 会话，定时驱动，判断 Worker 是否有“实质进展”并尝试修复，还能在线改提示词、调规则。
授权链与工单生命周期（原型的核心领域模型）
原型把“谁能让 Agent 干活”做成一条由代码强制的流水线——消息只是数据，永远无法改变权限。每一步在代码中都有对应实体（src/core/）。
名单内的人 @ Agent = 明确请求（explicit）；其余按准入表逐格判定；名单内机器人只能产生推断候选。
主会话读取有界线程窗口（前 5 条 + 前后各 5 条），对每条启用规则恰好判断一次，必须给出方向与意图证据。
接单在一个事务里原子创建：Ticket + Mandate + Assignment + 订阅 + 对外确认（ack ≤100 词）。
阶段自管理：待答复 / 待评审 / 受阻 / 排队 / 空闲 / 执行中；人的消息可恢复（resume）已结束工单——除非被人停止。
每个工单一个 worker-<id> 会话 + 一个独立目录（prepare 命令通常用 git worktree 建检出）；人的消息可占用“插队槽”。
Worker 只向内汇报；回复经 Outbox 保序送达原会话。PR 全部关闭/合并则工单结束，人的后续评论可唤醒。
三种接单模式（Accept mode，策略的一部分）
关闭主动：一切推断候选不产生，只有明确请求能开工。
推断候选照常研判，但积极评估结果只记录为 “would accept”——先观察它会做什么，不真做。
研判通过即接单。官方建议路径：先 observe 审阅记录，再切 auto。
核心术语速查（原型 docs/001，代码与面板统一用语）
| 概念 | 中文 | 一句话解释 |
|---|---|---|
| Source | 来源 | 事件流（GitHub / 飞书…），持有读位点与 bot 身份，重启不重放事件 |
| Trigger | 触发 | 一条不可变事件，审计与幂等的单位（重复接收只建一张工单） |
| Thread | 线程 | 按时间排序的触发序列；Eval 串行运行、订阅挂在其上 |
| Eval | 评估 | 把一批 Trigger 变成决定：Gate 准入（代码）+ Assessment 研判（模型） |
| Mandate | 授权 | 接单授予的“为什么能干、能干到哪”：策略版本 + 范围 + 强度，不可变 |
| Ticket | 工单 | 授权工作单元，只有 Eval 能创建；定义自己的状态而非跟随 Executor |
| Assignment | 派工 | 工单与一个 Executor 实例（会话+目录）的绑定 |
| Subscription | 订阅 | 工单↔线程的多对多关系；扇出只给上下文、不给新权限 |
| Channel | 渠道 | 线程的“写侧”：确认、回答、结果、提问都从这里发出 |
| Attention | 待人工决定 | 工单上等待人回答的问题（经 human_action 结构化上报） |
值得注意的拒绝设计（docs/001 Rejected concepts）：不做跨渠道身份映射（那是提示词的事）、不允许“向工单追加”这类决定（订阅扇出就够了）、Eval 永不等待（等待条件属于 Source）、禁止 Executor 自称“人让我停了”——停止与否只能由 Eval 决定。
实验数据：架构约束 > 提示词自觉
合成负载消融实验：每轮约 300 条消息（约 20 条真实工作请求，其余为闲聊、跟进、叫停、CI），用“只耗时的假工具”代替真实编码，四种方案各跑 5 次，时间按 1/4 缩放。它测的是调度能力，不是代码质量。
① 任务完成时长对比
关键洞察：中性提示下单会话 Agent 从不委派、被消息打断；改为“委派优先”提示后 5 次里仍有 1 次自判“活太小”亲自上手、长尾翻倍。Super-agent 取消了这个判断本身——Router 根本没有执行工具，想干也干不了。
② 缓存读取 Token（上下文经济学）
直通的真相：去掉订阅直通后完成时间几乎不变（12.6 vs 12.4 分钟），但 Router 决策次数 +30%、缓存读取 23.2M→31.8M。直通省的是 token，不是时间。
③ Router 批处理压测
结论：触发器风暴没有拖垮 Router——“拥堵”被转化为合批效率，单位决策成本降至 1/4。
开源原型实现细节（读码所得）
TypeScript · 深度集成 DeepSeek Harness（dsh）作为运行时；单 SQLite 状态库；文档-代码-测试三方互相引用（有测试强制文档索引完整、每个类必须有 JSDoc）。源码结构清晰：核心无 I/O、依赖单向、每类状态只有一个写者。
模型可见的工具面
| 角色 | 工具数 | 应用工具 | 约束 |
|---|---|---|---|
| Router 主会话 | 14 | orchestrator_readorchestrator_routeticket_retryticket_request_statusticket_notetrigger_requeueeval · eval_read · eval_decidereplythread_unsubscribesettings_save · policy_sync · prompts_save | 禁 sleep；shell 超时 ≤30s、job 等待 ≤5s；路由注记 ≤30 词；一次 route 可带 1–20 个决策 |
| Worker 执行会话 | 6 | orchestrator_readorchestrator_ackorchestrator_reportthread_unrelatedthread_followtrigger_handback | 无“问人/展示 UI/改配置”类工具；工单结束后工具调用被拒；报告摘要 ≤600 字符（带续读指针） |
关键数字速览
orchestrator.sqlite（schema 11）承载全部状态：触发、处置、工单、决定、效果、回执scripts/dsh-superagent status，按退出码 0/1/2/3 决定静默 / 重启 / 上报工程与安全要点
ARCH架构纪律（代码层面）
src/core除 Node 哈希外零外部依赖、无 I/O；Engine 是触发/工单/决定的唯一写者。- Effects 持久副作用队列：中继、启动、投递、回复先入库后执行，崩溃可接续；每类状态只有一个写者。
- Passes 每 2 秒驱动一次到期工作；域事件（ticket.created 等 12 种）驱动通知。
CREDS凭据与执行隔离
- Setup 清除含 KEY/PASSWORD/SECRET/TOKEN 的环境变量；worker 通过
worker-bin命令垫片用专属凭据，git 配置强制指向 agent 账户。 - 阻断名单可禁命令（如个人 gh CLI）；工单目录若被仓库 git 配置注入凭据则直接失败。
- 变量不含凭据；个人 git 设置（如代理）不生效。
⚠ WARN官方明确的安全警告
- 两个预设均以操作员 OS 用户 + danger-full-access 运行：目录不是沙箱，worker 可按路径执行任意程序、读家目录——官方建议使用只含 agent 凭据的专用 OS 账户。
- 文章态度直白：云端 Loop 若被提示词注入攻破，所有连接的机器都会失守；“完全不接触凭据却能使用凭据”仍是开放问题。
- 安全不解决，Super-agent 只能在小范围、高信任环境工作。
文章愿景 vs 开源原型：一张表看清边界
官方明确声明：原型是研究代码，文章中部分设计属于“未来方向、尚未实现”。两者的范围差异本身就传递了重要信息。
📄 文章《Super-agent 设计探索》
- 跨多任务、多信道的通用超级智能体：聊天、评审、CI、邮件统一接单
- 全双工交互（start/stop）、投机执行、Chain of Recall 链式召回
- 存算分离 + BYOM：云端 Loop + 个人设备 daemon
- Watchdog 独立会话：判断实质进展、在线改提示词
- Router 可用轻量模型，甚至不配 shell
- 实验为合成负载：假工具、约 20 个请求规模，验证调度而非质量
🐙 dsh-superagent-prototype
- DeepSeek Harness bundle：3 个插件（主插件 + github-watch + feishu-watch 可选禁用）
- 监听 GitHub 事件（+可选飞书）：名单内的人 @ 即开工单 → 独立会话/目录干活 → 原线程回 PR
- 已实现：Gate/准入表/mandate、订阅直通、handback、observe 模式、Web 面板（只显示需要人的事）
- 哲学：只在被要求或书面规则允许时行动；未被请求的工作一律先“仅记录”
- Agent 预设 danger-full-access（需专用 OS 账户）；Watchdog 简化为每小时脚本检查
- 内部实例已在 DeepSeek Harness 中日常运行（参与问题复现等），未来计划开放
四个开放问题（文章自述，语气最重的是安全）
双层架构的扩展
单 Router Session 何时水平切分？Worker 间要不要直接通信？方向包括面向 Router 任务的“系统与模型协同设计”和跨月级长程记忆。
脱离 Session 的人机协作
以聊天窗口为中心可能是路径依赖，交互或转向 Issue/PR 等领域特化界面；人类如何中途介入、接管一个“看不见的会话”待解。
上下文边界与 A2A
多个隔离实例在互不共享底层模型、不同权限边界时如何安全协同？个人 Agent 与团队 Agent 的记忆边界在哪里？
安全与隐私
事件驱动放大不可信输入面；云端 Agent Loop 连着全部端侧设备，一旦被注入攻破即全端失守；凭据一旦进入模型上下文就有泄露风险。原文结论：安全不解决，Super-agent 只能在很小且可信的范围内工作。