大叔自由人
编辑插画：右侧深色调度台写着 Router（接活·拆活·派活，人是唯一对它点头的人），三根线连向左侧三个白色工位 Worker A/B/C（修 Bug、写文档、盯 CI），右上有 GitHub 与飞书入口徽章；大标题「让 AI 自己接活」、副标题「DeepSeek 开源 Super-agent 双层架构」。
技术分享

让 AI 自己接活：DeepSeek 开源 Super-agent 双层架构——「AI 越能干、人为什么越忙」有了第一个架构级答案

写代码、修 Bug、连续干几个小时——今天的 AI Agent 都能做到。但一个矛盾的现象越来越明显：AI 越能干，人反而越忙了。

开发者可以同时启动十几个 Coding Agent，分别做需求开发、代码审查、测试和文档，然后在无数个窗口之间来回切换：查进度、处理报错、回答问题、决定下一步。原本为了减负的 AI，制造出了一份新工作——管理 AI。本栏前两周写过这道算术的两个侧面（个体的验证成本、组织的评审墙），10 月 31 日，DeepSeek 给出了第三个答案——这次是架构级的。

不是新模型，是新分工

DeepSeek Harness 团队公开了一项名为 Super-agent 的设计探索，并同步开源研究原型 dsh-superagent-prototype（MIT 许可证，基于此前开源的 DeepSeek Harness，可连接 GitHub 和飞书）。值得先划重点：这次没有发参数量更大的模型，没有晒新的推理基准——它试图解决的，是一个比模型能力更难的问题：当 AI 可以承担越来越多的工作，怎样设计一套系统，让人类真正从「管理这些工作」中解放出来。

核心思路一句话：让 Agent 从「等待指令的执行工具」，变成「能感知环境、自己接活、持续执行、必要时才找人的协作者」。

一条任务从进门到交付

Super-agent流水线

把原型拆开，一条任务要过四道关：

**第一道，Source（入口）。**GitHub、飞书等工作入口被抽象为「源」——源不只收消息，还维护事件读取位置、识别来源，并把消息归入对应的工作线程。这解决的是最日常的烦恼：你在 GitHub Issue 里提了需求，第二天又在评论里补充条件——系统不会把每条消息都当成全新任务，而是接回原来那件事。

**第二道，Eval（评估）。**外部消息先进评估流程：根据发送者身份、规则和已有任务状态，判断这项工作该不该接。接受之后才创建 Ticket，并生成 Mandate——任务的授权依据和执行边界。「该不该做」和「怎么做」被拆成两个问题，不让执行者一起答。

**第三道，Executor（执行）。**独立的执行会话、独立的工作目录，沙箱隔离、互不污染上下文，只向 Router 汇报「进行中 / 已完成 / 需人工确认 / 失败」。

**第四道，也是最容易被忽略的：Ticket 与会话分离。**传统 Agent 一次会话结束，任务就结束了；但真实的研发里，PR 提交后还有审查意见、测试失败还要返工——Super-agent 里任务的生命周期不依赖任何一次对话，执行阶段结束，新事件来了，同一张 Ticket 可以被再次唤醒。

设计原则：注意力是硬通货

整个设计文档里最值得抄的一句话是：「尽可能少地占用人类注意力，同时提供尽可能多的价值。」

它的执行标准细到什么程度？系统里的一条消息、一次通知、甚至管理界面上的一个元素，都要先回答「是否值得占用人的注意力」。Super-agent 不鼓励 Agent 勤汇报——恰恰相反，**只在三种时刻才允许打扰用户：结果已经可用、确实需要人类决策、任务无法继续。**对研发团队来说，理想状态不是每天收几十条「正在分析代码」，而是打开工作界面时，只看到真正需要自己处理的事。

这条设计哲学其实已经是行业共识的三张面孔：Claude Duet 用「节制的主动」做主动智能体（每几小时巡检一次、危险动作必须确认）；腾讯生态大会给 Agent 上岗定了三条件（入口近、系统通、治理稳）；Super-agent 把它写成了架构原则。当生成能力过剩，注意力就成了 Agent 时代最稀缺的资源——谁能替用户省注意力，谁的产品就赢。

安全件：Mandate 是新的「点头」

Agent 安全领域反复讨论的那个老问题——钥匙与点头——在这个架构里有了新的对应物。Eval 决定接不接活，Mandate 划定执行边界——人不再是给每个动作点头，而是给每张 Mandate 点头：授权范围划在哪里，Worker 就只能在哪里干活。这把此前 NUS 论文实证的「授权规则被诱导放宽 58%」的风险，从逐次审批升级成了边界管理——点头的次数变少了，但每一次的分量更重了。做企业落地的同行，值得把「Mandate 怎么定、谁能改、怎么审计」当成部署清单的第一行。

读数须知

其一，这是设计探索 + 研究原型，不是生产系统——文档里也明说了面向软件开发场景的验证，距离通用还有距离；其二，自媒体流传的「内部运行 180 天、日均 4700 次触发」等运营数字均为单一来源转述，本文一概未采用，只引用了项目仓库与设计文档可核实的部分；其三，「主动接活」的边界最终取决于 Mandate 的设计质量——架构给了安全件，装不装得好是使用者的事。给政企校做流程自动化的一个直接启示：先把「任务接收的评估规则」和「执行的授权边界」分开设计，这两张清单的清晰度，决定了你敢不敢让它无人值守。

参考来源