agentic

DeepSeek Super-Agent:它是什么,它是如何工作的,以及仍然缺少什么3 min read

Reading Time: 2 minutesDeepSeek 的超级代理设计及其 dsh-superagent 原型指南:路由器和工作线程如何组合在一起、基准测试显示什么以及运行之前要检查什么。

DeepSeek Super-Agent cover: a GitHub issue routed to three worker sessions that end in a pull request

DeepSeek Super-Agent:它是什么,它是如何工作的,以及仍然缺少什么3 min read

Reading Time: 2 minutes

一下子打开三个编码代理就可以感觉到问题了。一个正在等待决定,一个在二十分钟前完成,而您已经忘记了哪个具有身份验证修复。 DeepSeek 的 Harness 团队给出了一个数字:根据其经验,一个人一次只能关注三到五个活跃的代理会话。过了这个点,模型就不再是瓶颈了。你是。

2026 年 10 月 31 日,该团队发表了一篇名为“超级代理”的设计文章,并开源了一个名为 dsh-superagent 的原型。它是一个 GitHub 存储库的主动编码代理。一个长期存在的路由器会话与人们交谈并分发工作,每个接受的请求都有自己的工作会话,以拉取请求或问题结束。该存储库在大约两天内就超过了 12,000 颗星。它的自述文件直言不讳地说这是研究代码而不是官方的 DeepSeek 产品。

本指南适用于想要了解原型的作用、路由器和工作器设计如何工作、基准测试数据能证明什么和不能证明什么以及在将其指向真实存储库之前需要检查什么的工程师和团队领导。

在详细信息之前先注释一下。工作人员对“修复此错误”的回答是拉取请求,而 GitHub 是一个很好的家。代理围绕代码生成的其余内容更难放置:根本原因记录、测试摘要、审阅者要求的比较表。AgentGrid.io是一个共享工作空间,人们和人工智能代理可以在其中创建、编辑和共享文档、应用程序和文件,并具有一个实时版本、归属和历史记录。我们回到接近尾声的地方。

什么是 DeepSeek Super-Agent?

两件事同时出现。第一篇是一篇很长的设计文章,“探索超级代理设计:迈向更自治的代理系统”。 Harness 团队用中文编写了它,并于 11 月 1 日在 X 上发布了机器翻译的英文版本。该版本的浏览量已超过 220 万次。第二个是代码:deepseek-ai/dsh-superagent-原型,根据麻省理工学院许可发布。

这不是一个新模型。 dsh-superagent 是一个捆绑包DeepSeek 线束,DeepSeek 的开源代理工具,该公司将其描述为在全球范围内公开预览。该捆绑包监视一个 GitHub 存储库,如果您将其打开,Feishu 会进行聊天。当允许列表中的某人向代理请求工作时,它会打开一个工作项,在自己的会话和目录中运行它,并在原始对话中进行回答。网络面板仅显示需要人员的内容。

这个名字比听起来更容易。 DeepSeek 产品部门的崔天一(也是该文章的最终审稿人之一)在知乎帖子中解释说,“超级”的意思是上标与下标。超级代理在执行工作的代理上方添加了一层,与子代理相反,子代理在其下方添加了一层。这并不是声称拥有卓越的智力。

自述文件开头有一条值得完整阅读的警告:“研究原型仅供参考,不是官方 DeepSeek 产品。”它补充说,大部分工程是由编码代理完成的,代码可能包含错误,并且文章中的一些设计是未来工作的方向,并未实现。

一目了然 dsh-superagent-原型
它是什么 用于一个 GitHub 存储库的主动编码代理,打包为 DeepSeek Harness 捆绑包
状态 根据自述文件,研究原型“不是生产就绪的软件”
许可证 麻省理工学院
语言 打字稿
听 GitHub 问题、拉取请求、评论和 CI。 Feishu 聊天是可选的
已创建 2026 年 10 月 31 日。到 11 月 2 日,已有超过 12,000 个 star 和 1,200 个分叉
如何设置 请您的编码代理阅读 SETUP.md 并与您一起进行设置

为什么DeepSeek说瓶颈是人类注意力?

文章从一个简单的观察开始。在过去的一年里,编码代理已经足够好了,单个任务受到模型的限制。但是,一旦您同时运行多个任务,限制就会转移到您身上。每个会话都是隔离的,因此您可以手动在它们之间切换并跟踪每个会话所了解的内容。将 CLI、MCP 或聊天连接器连接到一个本地会话可以让它听到新事件,但它仍然会阻塞长命令,混合来自不同任务的上下文,并在笔记本电脑休眠时停止。

DeepSeek 的答案是停止将会话视为您管理的单位。它列出了超级特工应具备的四个特征:

  • 连续的。您可以在已经工作的地方与它交谈,例如聊天或 GitHub 评论,它的行为就像一个代理。如果您在聊天中询问计划 A 并在拉取请求评论中切换到计划 B,则会出现以下情况。
  • 富有成效。它并行运行多个复杂任务,并在最后一个指令完成之前执行下一条指令。
  • 积极主动。它观察事件,对值得处理的事情采取行动,否则保持安静。
  • 坚持不懈。它会保持在线状态并从故障中恢复,而无需您重新启动它。

作者认为,没有一个 ReAct 循环可以提供所有四个功能,因此质量必须来自模型周围的架构。这是本文的真正主题,Hesam 分享的下面的视觉解释器是在一页上查看整个设计的快速方法。

路由器和worker设计如何工作?

想象一下一位优秀的工程经理,他在站立期间从不编写代码。的路由器是一个长期会话,接收来自每个通道的每条消息。它不运行任务。它决定消息的要求,将新工作交给工作人员,并将每条回复写给相关人员。文章称它完全可以在没有 shell 工具的情况下运行,并且更轻、更快的模型通常就足够了。

一个工人是一个单独的会话,具有隔离的上下文和一整套工具,专用于一项任务。工人从不直接与人交谈。它们向路由器报告状态,路由器以一种声音进行答复。在原型中,每个票证都有自己的会话和自己的目录(通常是 git 工作树),并且工作人员数量是有上限的。默认值是一次三个,可在 1 到 16 之间调整,并保留一个额外的插槽,以便一个人的消息始终可以通过。

有两个细节使其不仅仅是一个任务队列。

后续跳过路由器。一旦工作人员拥有拉取请求或聊天线程,它就会订阅该线程。后面的评论直接进入它,没有在路由器上进行额外的模型调用。如果评论结果是关于其他事情,工作人员会将其退回。

突发被分批处理。在一个模型期间到达的触发器会排队并一起注入到下一个调用中。作者测量了效果,我们看一下下面的数字。

dsh-superagent 的图表:源提供一个门,然后是一个路由器会话,然后由在原始线程上回复的单独工作会话处理的票证
基于项目文档的一个请求如何通过 dsh-superagent 的原始图表。

又一个对比点。本文将其与代理团队区分开来。在代理团队中,领导者将一项复杂的任务分解为多个步骤并协调处理该任务的角色,这是一项繁重的推理负担。超级代理路由器仅分派独立任务并跟踪它们如何在高层关联。它不会分解工作本身。

当没人问时它会做什么?

这就是该项目的理念变得实用的地方。存储库中的第一个文档用一句话阐述了这一原则:尽可能少地关注人类,并提供尽可能多的价值。代理发送的每条消息都会引起同事的注意,因此只有当一个人必须采取行动或可以使用结果时它才会说话,并且只有在被询问或团队编写的规则允许时才会采取行动。

强制执行此操作的门是纯代码,而不是模型。它检查谁在团队的允许列表中提出请求,并记录请求的强度:

实力 文档中的示例 会发生什么
显式的 允许列表中的人员提及代理,或跟进已拥有票证的线程 代理接受各种模式的工作
推断 来源机器人列表中的机器人,或未列出的人员的后续机器人。团队选择接收的未寻址消息 根据团队的书面规则进行评估。在默认观察模式下,仅记录为“愿意接受”
未被录取 任何其他机器人,准入表忽略的任何内容 在调用任何模型之前删除

观察模式是我最喜欢的部分。代理首先记录它会做什么,这样团队就可以在 Eval 选项卡上读取这些记录,并仅在它们看起来正确时扩大其权限。消息、评论和引用的文件被视为决策的输入。他们不能改变代理人被允许做的事情。

设计文章展示了主动工作在实践中的样子。在内部 DeepSeek Harness 用户组中,团队配置了“静默重现和修复”策略。当有人报告问题或讨论提议的更改时,代理会尝试重现该问题并在后台找到修复程序,并且只有在确认问题并找到简单的修复程序后才会提供结果。否则它会保持安静。文章还对聊天频道给出了一条直言不讳的规则,作者称他们已经验证过:每个回复的字数上限为 100 个字。相比之下,在 GitHub 上,拉取请求应该是密集的,包含问题背景、变更描述和验证结果。

默认情况下,代理发布的每条 GitHub 消息都以“这是由自动代理发送,而不是人类发送的”行开头。团队可以编辑该内容以及其余提示。

基准数字是否成立?

这篇文章包括一个小实验,作者谨慎地称其仅供参考。四种设计在群聊和 CI 消息流上并排运行:每次运行大约 300 条消息,其中大约 20 条是实际工作请求,每次运行 5 次。编码工作是通过一个简单消耗时间的工具来模拟的,因此测试衡量的是调度和协调,而不是任何人代码的质量。

设计 任务完成时间,p50 / p95(分钟) 每次运行缓存读取令牌
超级经纪人 12.4 / 15.7 23.2M
超级代理无需直通 12.6 / 15.5 31.8M
使用子代理工具的单个会话,中性提示 20.4 / 29.5 6.1M
使用子代理工具的单个会话、委托提示 13.8 / 29.0 10.8M

请阅读该表格两遍,因为标题并不是故事的全部。路由器设计将 p95 完成时间减少到单个会话的一半左右,但它使用了大约两到四倍的缓存读取令牌。最有趣的一行是第二行:删除直通快捷方式并不会使任务完成得更快或更慢,它只是使路由器多做约 30% 的决策并多消耗 37% 的代币。

我的解读是,真正的发现位于单会话行中。在中性提示的情况下,该模型在五次运行中从未调用过子代理。它自己完成工作,新消息不断打断它,最慢的任务需要 29.5 分钟。在提示让它进行委派的情况下,它在五次运行中进行了四次委派,在剩余的运行中,模型判断工作“小”并自行完成。单次训练取决于模特的心情。不允许运行代码的路由器不会犯这样的错误。

仅对路由器进行单独的压力测试就将需要做出决策的事件的到达率从每分钟约 1 个提高到约 40 个。平均批次从 1.0 个事件增长到 2.8 个事件,每个请求的时间仅从 2.5 秒增加到 3.9 秒,每个决策的摊余时间从 6.4 秒下降到 1.6 秒。事件堆积得越多,每个事件的成本就越低,作者表示,其上限取决于上下文长度以及模型在一轮中可以准确处理的事件数量。

这些是综合工作的自我报告结果。他们表明调度想法是合理的。它们并没有表明原型可以更快地修复错误。

熟悉该项目的人士对其局限性有何评价?

发布后不久,来自DeepSeek产品部门、设计文章最终审稿人之一的崔天一写下了他对设计的看法。他的框架很有用,因为它很谦虚。他将核心权衡称为任务的连续性与任务吞吐量。

对于限制,审查是直接的。该原型仅实现了所提议设计的一部分。根据他的审查,DeepSeek Harness 没有跨会话的内置长期记忆。而且该系统仅在公司内部的小型可信环境中得到验证。本文自己的开放问题部分列出了路由器的扩展、几个月的内存、无会话工作、代理之间的上下文边界以及隔离的代理应如何相互通信以及安全性。

运行之前应该检查什么?

该文档比大多数发布帖子更加坦率,值得将其警告视为要求。

  • 工人有广泛的接触机会。路由器和工作人员的两个权限预设都运行danger-full-access作为运营商的操作系统用户。帐户包装器选择代理使用的 GitHub 凭据,但文档称它们是默认值,而不是安全边界,因为工作人员仍然可以通过绝对路径运行程序或读取您的主目录。建议使用仅保存代理凭据的专用操作系统帐户。
  • 不受信任的输入是开放的安全问题。该文章警告说,如果即时注入或服务器入侵损害了云代理循环,则每个连接的设备都可能被访问,并且进入模型上下文的凭据可能会泄漏。
  • 人类默认会合并。代理永远不会在自己的帐户下启用自动合并。自动合并需要在交付要求提示中指定第二个帐户的 CLI,并且默认说明仅允许在 200 行更改以下的小型、已批准的拉取请求。
  • 它是围绕一个存储库构建的。每个设置都会监视一个 GitHub 存储库,而 Feishu(中国常见的工作场所聊天工具)是另一个一流的源。
  • 您需要 DeepSeek 线束和模型提供商。安装程序列出 Node.js 22.19 或更高版本、pnpm、git 2.32 或更高版本、tmux、Python 3.8 或更高版本以及 GitHub CLI 2.48 或更高版本。配置模型提供者是操作员步骤。
  • 噪音是一种成本。哲学文件说不要使用代理来产生体积。大量拉取请求和广播消息使您的团队付出的代价比他们付出的要多。

您将如何尝试而不冒主存储库的风险?

设置有很多步骤,因此该项目要求您让编码代理与您一起完成。根据自述文件,代理一次询问一个简短的问题,显示一次完整的计划,然后安装和配置所有内容。谨慎的第一次运行如下所示:

  1. 选择一个一次性存储库以及专用机器用户或操作系统帐户。不要使用您自己的登录名。
  2. 为代理创建单独的 GitHub 帐户。它所写的所有内容都出现在该名称下。
  3. 在编码代理中打开存储库并粘贴下面的提示。一次回答一个问题。
  4. 将允许的列表保留给您自己并将接受模式保留为观察。
  5. 要求一些小东西。从允许的帐户发表评论@<agent login> <request>在一个问题上。大约一分钟内,票证就会出现在面板的概述中。
  6. 阅读 Eval 选项卡一周。仅当“愿意接受”记录看起来正确时才扩大列表或切换到自动。
项目自述文件中的设置提示
Read SETUP.md in this repository and set up dsh-superagent with me.

该项目的理念文件为运营商提供了四条值得重复的规则:开始范围狭窄,调整噪音较小,不要使用代理来产生音量,并以你的名义拥有它所说的一切。

代理的其余工作应该去哪里?

假设一名工作人员花了一个小时进行不稳定的集成测试。拉取请求就是修复。但其背后的调查,哪些测试失败了,哪些假设被排除了,时间表显示了什么,不属于 PR 描述,而这正是审稿人想要挑战的。如果这仅存在于聊天回复中,那么下一个代理或队友将从头开始。

AgentGrid.io是为这种切换而构建的。人类和人工智能代理处理相同的实时文档、应用程序和文件,具有一个稳定的地址、受控的访问和版本历史记录。 AgentGrid.io 的文档描述了通过运行来连接具有命令功能的代理npx @animaapp/cli@latest login。人工批准代理的名称、团队及其可以执行的操作:阅读、写作、共享或发布。之后,代理的更改会以自己的名义出现在历史记录中。该原型没有内置的 AgentGrid.io 集成,因此请将其视为与其工作人员一起尝试的模式,而不是记录的功能。

在实践中,工作人员将其调查写入 Markdown 文件,审阅者对表行进行评论,另一位助手收紧摘要,拉取请求链接到一个当前版本而不是三个粘贴的副本。

对于多人共享一个代理的另一种看法,请参阅我们的指南Grok Bot 团队机器人。如果您想知道托管代理下面运行什么,我们的指南Claude Managed Agents查看 Anthropic 的相同大脑和双手分裂的版本,DeepSeek 的文章引用了这一点。

什么时候应该使用 dsh-superagent,什么时候应该使用其他东西?

  • 使用dsh-superagent从严肃的、记录的设计中学习,在低风险存储库上运行包含的实验,或者借用其想法:从不运行代码的路由器、具有规定范围的票证、在自动模式之前的观察模式。
  • 使用单个交互式编码代理当您一次执行一项任务并希望逐步指导时。超级代理是针对相反的情况而构建的。
  • 使用 AgentGrid.io当输出是文档、报告或应用程序时,需要多个人员和代理进行审查、编辑和发布,无论是哪个代理生成的。

常见问题

什么是 DeepSeek Super-Agent?

它是一个名为 dsh-superagent 的研究原型,由 DeepSeek 的 Harness 团队于 2026 年 10 月 31 日在 MIT 许可下发布。它是一个 GitHub 存储库的主动编码代理。长期存在的路由器会话接收请求并将每个接受的请求分配给自己的工作会话,该工作会话在原始对话中进行应答,通常使用拉取请求。

DeepSeek Super-Agent是DeepSeek官方产品吗?

不。自述文件称其为仅供参考的研究原型,而不是官方的 DeepSeek 产品,并表示在您自己的环境中使用它之前要对其进行审查和调整。它也与内部版本或设计文章描述的实现不同。

超级代理与次级代理有何不同?

子代理在工作代理下面添加了一层。超级代理在其之上添加了一层。在这种设计中,路由器位于许多工作人员之上,与人们交谈并分派任务,而每个工作人员独立处理一项任务。这个名字是关于地位的,而不是声称更高的智慧。

需要Feishu还是只需要GitHub?

单独使用 GitHub 就足够了。 Feishu 是可选的第二源,文档称 Feishu 设置失败仅禁用 Feishu 源。

在公司存储库上运行安全吗?

不是原样。文档称,工作人员以操作员操作系统用户的完全访问权限运行,并且包装器帐户不是隔离边界。他们建议使用专用操作系统帐户、GitHub 上的专用代理帐户、简短的允许列表和观察模式,同时您可以了解代理的行为方式。

它比单个编码代理会话更快吗?

在作者自己的模拟测试中,路由器设计使用更多令牌,在 15.7 分钟内完成了最慢的任务,而使用子代理工具的单个会话则需要 29.5 分钟。该测试使用模拟编码工作,每个设计运行五次,因此它显示了调度优势,而不是代码质量。