DSH Super-agent: open-source team collaboration agent design explained
The admission layer being pure rules with zero model involvement is the most transferable idea here — it cuts cost and false triggers before the LLM ever runs. Builders working on team-facing or multi-agent systems can borrow the ticket-state model and write-ahead logging for their own orchestration stacks. The project is open-source and came from the Chinese community, so it can be studied and self-hosted anywhere without waiting on a commercial release.
DSH Super-agent is an open-source team collaboration agent that extends the Personal agent pattern by initiating work on its own, listening in on team discussions instead of waiting for users to trigger it. Its architecture has six layers: a multi-source event ingestion layer for code hosting and messaging platforms, a rule-based admission layer that authorises tasks without any model involvement, a model-driven orchestration layer that only judges and dispatches, a task layer where each ticket carries a persistent state like 'awaiting review' or 'blocked', an execution layer with isolated parallel workspaces on separate branches, and a delivery layer that routes replies back to the originating conversation. The design treats human attention as the scarcest resource, surfacing only a few key messages from dozens of internal actions. All outbound actions are written to persistent storage before execution, following a write-ahead-log approach so crashes can be replayed and recovered.
关于DSH Super-agent 的一些解读 其实和目前的 Personal agent 有异曲同工之妙：用户侧尽量极简，之后怎么做、开几个 worker或bot 来干，由代码和模型分工决定，必要时才打扰用户。不同的是，Super-agent 连"发起"都不用人做，它会旁听团队讨论，自己发现该做的事。
它意在做团队协作 agent。我也做过一段时间协作 agent，到一定规模后最需要解决的是高效：不能大家都在群里和 agent 聊个不停，重点是克制、简单、高效和主动。
没想到国内Personal agent还没兴起，开源的先来了，值得好好学习下
设计原则是把人的注意力当作最稀缺的资源：内部可能有几十个动作，人只看到几条关键消息
1️⃣接入层（多源事件接入） 对接代码托管平台和即时通讯平台：前者定时拉取通知，后者实时订阅事件，断线后会补齐历史消息。 所有外部消息都被统一成标准化的"触发事件"，并归入所属的会话线程。
2️⃣ 准入层（确定性授权） 由纯规则引擎决定一条消息能不能成为任务，完全不经过模型。 判断依据有三个：发送者是否在授权名单上、是否点名了智能体、该渠道的准入策略。
3️⃣ 研判与编排层（模型决策，受约束） 一个长期在线的编排会话担任调度者，只做判断和分派，不直接干活。 判断三件事：与本项目是否相关、是否确实有人想做、方向是否已经明确。 研判通过后，编排会话选择三种处理之一：新建任务、并入已有任务、只做答复。
4️⃣ 任务与授权层（状态中枢） 每件事对应一张任务工单，生命周期可以跨天、跨周。每张工单任意时刻只处于一个阶段，例如等人交付确认、等人回答、等人评审、受阻、排队、执行中、空闲。这样能一眼看出"现在在等谁"。 所有对外动作（研判、启动执行、交付、转发、通知、答复）都先写入持久化存储再执行，类似预写日志的思路，保证崩溃后可以重放、恢复。
5️⃣ 执行层（隔离的并行执行单元） 每张工单分配一个独立的执行会话和一个独立的代码工作区（独立分支）。多张工单之间完全隔离，可以并行。
6️⃣ 交付层（原路回写，注意力预算） 所有对外消息都经过统一的发件队列，送回最初发起任务的那段对话。 只有几种情况才会触达人：受理确认、结果交付、需要人决策或回答、执行受阻。其余内部动作对人不可见。
