解读 dsh-superagent：一个主动型 Coding Agent 的工程常识与后厨美学

为了折腾自己的贾维斯，周末看了下 DeepSeek 新开源的 dsh-superagent 的设计。
如果用一句话来定位它，这是一个真正奔着「主动干活」去研发的 coding agent 原型系统，宗旨是「尽量少占人的注意力，尽量多产出价值」。
为了把这句话兑现成可运行的工程，它没有搞那些花哨的提示词魔法，而是把经典分布式系统和操作系统里被验证过几十年的架构手段，老老实实搬到了 agent 工程里。我归纳了其中 5 个最实用的设计，并用餐厅后厨的比喻来逐个解释下。
推荐的 5 个实用设计 设计 1：Router-Worker 前后台分离 + 活人感注意力纪律 许多 agent 一旦接了个大任务（比如重构一个模块），它的会话就被完全占死了。你发新消息它不理，想中途调整方向只能强行掐断进程。
dsh-superagent 把交互和干活彻底拆成两拨会话：一个 Router（主会话）专门负责跟人对接，常驻在前面，维持用户的全局记忆、偏好和对话上下文；背后则挂着多个 Worker（执行会话），按需启动，并行去跑具体的代码修改、测试或者文档排查。
这种结构带来了天然的 sessionless 体验：用户无论什么时候在群里说话，Router 永远在场，随时都能搭理你，绝不会因为系统正在改代码就假死。
更绝的是它配套的一套近乎苛刻的「注意力纪律」：
绝对不在干活期间给用户发垃圾进度，只在「必须由人来拍板决断」或者「产出了可用阶段性成果」这两个节点开口； 每次需要人介入，严格限制只能问一个结构化问题，把选项列清，绝不抛大而化之的开放式反问； 过程保持极度安静； 汇报绝对诚实，草稿就是草稿、必须打上未完成标记，失败了就老老实实报失败原因，绝不掩饰。 这就像一家体面餐厅里的「前厅领班」与「后厨厨师」。
Router 就是那位穿戴笔挺、站在台前的值班领班。他脑子里记着你的口味偏好、忌口清单和上次来坐的哪张桌子。后厨的厨师们（Worker）则只管埋头颠勺切菜，根本不用直接跟食客废话。食客要是中途想加杯水或者问句菜品，领班立刻就能笑着回应，绝不会出现服务员全部缩进厨房、大堂空无一人的尴尬场面。
更关键的是这位领班极有教养：厨师在里面切葱姜蒜、热油锅的时候，领班绝不会每隔二十秒跑来桌边跟你念叨「先生，我们现在开始切葱了」「我们刚把锅烧热了」。他只有在两种情况下才会走近餐桌：要么菜端上来了请你品尝；要么后厨发现最后一份海鲈鱼卖空了，拿着菜单问你一句结构化的问题：「后厨的鲈鱼售罄了，我们为您换成石斑鱼还是红鲷鱼？」
设计 2：事件驱动 + 按来源分 Thread 串行处理（agent 界的 epoll） 传统的 agent 要么是一个单向循环（经典的 ReAct，即模型思考一步、调用一次工具、再观察结果的循环），一旦这个循环跑起来，外部来了个 GitHub issue 或者一条即时通讯消息，它根本插不进去；要么就是简单粗暴地为每个新消息起一个新 agent，结果多个 agent 读着不同时间点的截断上下文，各做各的决策，提交代码时互相踩脚、疯狂打架。
dsh-superagent 的解法是：做一套事件驱动架构。
任何外部输入（新提交的代码、issue、群聊消息）进入系统时，都被封装成一个 Trigger（不可变事件，指已经发生、不可篡改的事实记录）。系统会根据数据源把这些事件织进不同的 Thread（处理线程）里。
核心规则非常严密：同一个 Thread 在同一时刻只允许跑一个 Eval（评估任务）；如果当前 Eval 正在执行，新来的事件绝不丢弃，也不强行中断当前任务，而是暂存在队列中，等当前评估结束后合并进下一批批量处理；而不同 Thread 之间完全并行。