范式审视：到底是全新的流派与方法论，还是“旧瓶装新酒”？

独创一：反传统的“无偏路由（Unbiased Routing）”——为什么严禁主 Agent 做技术规划？

在几乎所有现有的多 Agent 框架（如 MetaGPT、CrewAI 或常规 Manager-Worker 架构）中，主控 Agent（Orchestrator/Planner）的职责都是：先阅读用户需求，编写一份详尽的实施计划（Implementation Plan）和验收清单，然后拆分成子任务发给 Worker。

dsh-superagent 对此进行了彻底的否定！ 在 prompts/orchestrator.md 与 prompts/dispatch.md 中，系统用极其严厉的指令约束主 Session：

// 源自 prompts/dispatch.md 第 14, 38-41 行：
"Do not expand a request's scope, add implementation plans, acceptance criteria or policy checklists: workers derive requirements from the original source."
"Do not paraphrase a short request into a work plan, pick examples or categories, invent requirements..."
"For example, 'Could we add a dark mode?' should arrive as that original request and its source reference, without router-selected color schemes or a maintenance plan."

不仅如此，在代码层（src/app/tools/main.ts 与 src/limits.ts），主会话在派单时附带的 note（路由备注）被硬编码限制在 最多 30 个词（routingNoteWords: 30，支持中日韩分词统计）！

独创二：订阅扇出（Subscription Fan-out）与追问所有权移交（Follow-up Ownership & Handback）

在真实的 GitHub Issue 或飞书群话题中，对话是连续且发散的。假设用户 A 提了一个修 Bug 的请求（生成了 Ticket #1），随后在该线程下：

• 场景 1：用户 A 补充了一句“顺便把报错日志也改一下”（属于原工单范围）；
• 场景 2：同事 B 插话问“这个模块是不是还存在另一个性能问题？帮我顺便重构了吧”（超出原工单范围）；
• 场景 3：CI 机器人自动评论了一条“Build Failed”（机器反馈）。

传统的 Bot 要么每次被人评论都傻傻地重新跑一遍完整路由（导致创建一堆重复 Ticket），要么把所有回复无脑塞给同一个 Session（导致上下文爆炸且越权）。看看 dsh-superagent 在 src/core/model.ts（followupOwners）与 src/core/intake.ts 中设计的精妙协议：

更精妙的是防漏读兜底机制（Release on End）：如果一个 Ticket 刚好在结束的瞬间，有一条人类消息投递进来但 Worker 还没来得及读取（readAt === null）或未做任何响应（既未 ack、未 answer 也未 handback），当该 Ticket 终结时，引擎会自动释放这条孤儿消息并将其送回 Eval 队列，确保人类的任何一句话既不会被两个 Agent 重复抢单，也绝不会掉在地上无人理睬。

独创三：不可变授权凭证（Immutable Mandate）与动态策略重校验（Revalidation）

在安全领域，Coding Agent 最大的隐患是间接提示词注入（Indirect Prompt Injection）：攻击者（或外部无权限路人）在一个公开 Issue 或引用的文档里写下恶意指令，诱导正在读取该 Issue 的高权限 Agent 执行非授权代码修改。

dsh-superagent 在内核层（src/core/model.ts 与 src/policy.ts）构建了一套严密的形式化授权模型（Mandate）：

1. 权限与数据彻底隔离：所有外部消息、评论、文档在代码和 Prompt 中均被定性为不可信数据（Untrusted Data）。唯有 Engine 在 Eval 通过时颁发的 Mandate 对象才代表合法的行动边界。
2. 权限不可篡改与不可传递：Mandate 一旦生成即不可变（记录了当时的 policyVersion、strength、basis、actor 和 scope）。当 Worker 为了参考背景而调用 followForContext 订阅另一个 Issue 时，该线程被打上 context: true 标记——那里的消息可以给 Worker 看，但绝对不具备任何授权效力，也不能唤醒已结束的工单。
3. 策略变更的温和处理与唤醒重校验（Policy.revalidate）：当管理员在后台修改了白名单或关闭了某条主动规则，policyVersion 哈希值立即改变。此时：
   • 正在运行的 Eval 立即作废并按新策略重排（防止旧策略下的评估结果生效）；
   • 正在编码中的活跃 Ticket 不会被粗暴强杀（防止留下半截坏代码），而是收到一条精确计算出的 policy-changed Input（告知某规则已禁用或发起人已移出白名单，要求仅收尾当前范围内工作）；
   • 当一个已结束的 Ticket 因人类新评论准备自动唤醒（Resume）时，必须先过 policy.revalidate(ticket.mandate)——如果发起人已被移出白名单或主动模式已关闭，唤醒直接被拒，消息退回 Eval 重新走门禁！

独创四：从被动工具到受控主动（Observe Mode & Would-Accept 影子机制）

市面上许多号称“Proactive（主动式）”的 Agent 一旦开启，就会在代码库里到处乱提 PR。dsh-superagent 给出了一个工程上极其优雅的渐进式方案：默认开启 observe（影子观察模式）。

查看 src/policy.ts 第 55-58 行的核心代码：

if (strength === 'inferred' && settings.eval.mode !== 'auto') {
  const proposal = { title, scope, worktree_name: name }
  return { kind: 'ignore', audit: { ...audit, would_accept: true, proposal }, reason: { code: 'observed', values: { text: assessment.reason } } }
}

在 observe 模式下，主 Session 依然会对群聊或 Issue 中的潜在缺陷进行完整的上下文读取与规则研判。如果研判通过，系统不会真正去拉分支写代码，也不会在群里发任何消息打扰团队，而是在 SQLite 数据库和 Web 面板的 Eval 页面中静默记录一条带有 would_accept: true 标记的决策提案！团队管理员可以先观察一周，看看 Agent “本来打算主动接哪些单”，调优规则与提示词直到准确率令人满意，再一键切到 auto 模式。

独创五：5 秒非阻塞运行时与“人类优先 +1 并发槽位（WorkerSlots）”

在 src/executor/dsh.ts 的 WorkerSlots 类（第 171-199 行）中，隐藏着一个极具人文关怀的并发调度算法：

reserve(ticketId: string, by: 'launch' | 'wake' | 'person'): void {
  if (this.starting.has(ticketId)) return
  if (this.used() >= this.max() + (by === 'person' ? 1 : 0)) throw new Later('No worker slot is free')
  this.starting.set(ticketId, by)
}

• 假设团队配置的最大并发 Worker 数 maxWorkers = 3，且当前 3 个槽位全部被正在跑重任务的 Ticket 占满；
• 此时如果来了一个新工单（launch）或一条 CI 失败通知（普通 wake），它们都会抛出 Later 异常并在队列里安静排队；
• 但如果是一位人类同事在某个空闲工单下回复了一条消息或点击了状态查询（by === 'person'），系统允许瞬间突破并发上限，启用专属的第 4 个特权槽位（max() + 1），并且人类唤醒请求在释放槽位时永远排在新工单启动之前！这从调度底层保证了：后台繁重的自动化任务永远不会卡住人类与 Agent 的实时对话。

独创六：三方合并式 Prompt 版本管理与自动化 Review Bot 三轮熔断

仓库中还有两处体现深度实战经验的细节设计：

1. Built-in Base 追踪与升级差分（src/app/prompts.ts）：
   当团队在 Web 面板修改了某段内置系统提示词时，系统不仅保存团队修改后的文本 text，还会同时快照保存它所基于的原始官方默认文本 base（存储在 KV.prompts.builtIn）。当未来升级 dsh-superagent 版本、官方更新了默认 Prompt 时，面板会自动比对并在 UI 上高亮标记 “Default updated（默认内容已更新）”，并排展示“旧版默认 vs 新版默认 vs 团队自定义文本”的 Diff，彻底解决了 Agent 框架升级时“自定义 Prompt 被覆盖或与新版工具脱节”的痛点。
2. 自动化 Code Review Bot 三轮硬熔断（prompts/team/communication.md 第 92-95 行）：
   在真实研发中，像 CodeRabbit、Copilot Review 等 AI 评审机器人经常与 Coding Agent 陷入无限互相回复的死循环（Agent 改完 → Review Bot 又挑新刺 → Agent 再改）。dsh-superagent 明确规定：把 AI Review 视为可能出错的参考建议而非权威门禁，每个 PR 针对每个自动化 Reviewer 跨所有回合最多只处理 3 轮（record the bot run/version identifier, round count... After the third round, do not request another bot review or wake a worker），满 3 轮后立即停止纠缠并交付人类评审。

判断一个架构是否成熟，不仅要看它包含了什么，更要看它刻意拒绝了什么。在 docs/001-domain.md 的 Rejected concepts 章节中，作者列出了 12 个在常规企业级系统或 Agent 框架中极为常见、但被本项目坚决砍掉的设计。这正是其代码库如此精悍、逻辑无死角的原因：

正如仓库 README.md 开篇所声明的，本仓库是从 DeepSeek 团队日常研发内部版本中剥离并适配公开发布的研究原型（Research Prototype），与技术文章《Exploring Super-agent Design》中探讨的终极蓝图相比，当前代码库在以下方面存在明确的边界与妥协：