deepseek吧 关注:277,721贴子:946,265
  • 9回复贴,共1页

dsh-superagent-protocol使用体验

只看楼主收藏回复

标题为“Superagent:迈向更自主的Agent”原型插件,由dsh在今晚的文章中首次公开,并且在31日20时左右推送github仓库。
安装方式同样是全程交给agent完成,需要填写相关信息,目前可选github和飞书进行配置。
简单说,就是将agent,如DeepSeek harness由孤立的对话+被动的接收用户请求,转向更高一级的主动获取用户反馈,接收开发者许可的用户需求。其一使用场景如 遇到的明确bug问题将会立刻派发排查任务,完成后提交PR甚至直接合并。
我试用了一下,首先呢,你要单独给他弄个github账号,因为他会忽略自己提交的issue或者commit,也就是不方便测试了。建议在Linux环境下进行,不过Windows也能走完全程,让agent多费两下周折罢了。然后给他项目地址,账号权限和认证,确保这个账号在shell中登录并且有权限提交。
让agent配置完成后,你就可以用自己的账号发布一个issue。然后如果想要观察的话,可以打开3082端口(带access token,让帮你部署的agent获取),我发现没有同步自定义模型过去,但是账号是登录的,可以用账号自带的模型。
在3082窗口的dsh上,多了一个superagent,就可以看到每60秒定时获取新issue或者commit,然后判断是否需要接单。如果接单,就会在特定工作区,开始整个任务,完成后提交PR,失败也能看到对应提示。
时间匆忙,没有测试跨工作区效果。似乎只是分配了一个不在工作区的会话作为接单代理,然后派发任务这是单独工作区+会话窗口,但是在从github拉取的源代码在同一个文件夹下。通过这种方式,由会话子代理判断是否派发任务,应该派发给哪个会话,最终完成整个流程。
当然,superagent目前只是原型验证阶段,我也完全没有用到官方文章提及的更深层的效果,可以小小体验一下,目前看来是不影响主程序正常使用的!


IP属地:江苏来自Android客户端1楼2026-11-01 01:51回复
    不理解为什么被归入插件/资源


    IP属地:江苏来自Android客户端2楼2026-11-01 01:57
    收起回复
      2026-11-02 18:29:25
      广告
      不感兴趣
      开通SVIP免广告
      哦对了,3082端口应该是必须要打开的,第一次要现拍配置一下模型,不然请求会全部报错


      IP属地:江苏来自Android客户端3楼2026-11-01 09:22
      回复
        看仓库感觉很像github的copilot自动代理功能的升级版,能自动合并pr这些


        IP属地:四川来自Android客户端4楼2026-11-01 09:48
        收起回复
          其功能原理说起来还是比较简单的。但是其思想值得稍作研究。从被动到主动的过程,router从派出定时探针主动获取任务,派发给worker,外挂看门狗监控端口,长程记忆管理消息。
          这个superagent核心是什么?核心是多agent协作吗?现在的agent外接一个工具,定时获取github api提供的更新,然后转发给主agent,然后agent派发给可连续多次使用的子agent,也可以模仿式完成任务。但是,有一句话很重要:
          将限制生产力提升的瓶颈,从人的注意力转移到系统调度层。
          (说到这里,不知道有没有人了解过openai的数学研究,证明类文章。似乎我听说大部分都是一些高阶的问题被证明。但是人类为什么不行,因为人类的注意力不够去思考高阶问题)


          IP属地:江苏来自Android客户端5楼2026-11-01 10:10
          回复
            人的注意力,最多同时跟进3-5个会话。你可以在某个会话继续你的修改,也可以开新的会话。那么这个superagent面临一个问题:如何解决独立Session中,代码不同步的问题(比如两个会话,都进行了几次任务后,A会话进行了对系统结构的修改,但是B会话记忆中,还是原来的结构)。人类往往会开新Session解决,而不是复用旧会话,让AI的思维还停留在陈旧的代码上。但是如果一直开新会话,那么“把限制生产力提升的瓶颈从“人的注意力”转移到系统调度层”不就失去意义了吗?Router就变成了传话筒。就算模型修改时发现不对劲重读了代码,重读代码本身就会消耗大量的注意力,直接影响就是任务完成情况和token消耗量。考虑长程任务,缓存过期后,其成本等等都是需要考量的地方。
            这是一个进行了一定处理还是没有完全解决的地方(比如共享订阅,按需读取等等)
            假如router是一个项目经理。那么worker就像是相互之间不能沟通,各自对着同一份文件干活,干活时发现文件被改了就需要重读的苦苦打工人。
            原文提及:worker间直接通信将在什么情况下进行,采用什么方式,都是有待校验的。


            IP属地:江苏来自Android客户端6楼2026-11-01 10:23
            回复
              作为一个试验品,在第八章中提出了一些“委婉的说法”。比如单router怎么面对时间跨度大上下文内容极长的情况,如何切分各层。再加上人类的外部监控功能在此被削弱,还有安全凭据等问题,这是文章明确提及的。其中本身系统架构层次让我就带有一定疑问,因为这里的router层太万能了,使得整个系统的智能过于依赖router(架构建立在模型比较强的情况下,但是又说对router的智能性要求没有那么高)。从目前看来,我没有看出除了实现了自动化之外,对于任务本身效果的提升。
              仅个人观点:也许现阶段,md文档预读+代码仓库索引+新窗口+自动获取issue的定时器,可以实现相似效果的同时,token消耗量更低(原文提及了此工程导致token消耗变大的问题)。也许未来有什么力大砖飞的更好方案,也许dsh团队能够进行下一步的改进,将其从玩具变成真正进入生产的工具


              IP属地:江苏来自Android客户端7楼2026-11-01 10:38
              回复
                我理解是开发团队的 personal agent。openai的dots 也有个类似的router来分配任务,然后在codex 中能看到新分的任务会话。奔着全自动化去了,真追着程序员杀啊,跑不过哈哈哈,从开源的视角看真的很期待。


                IP属地:山东8楼2026-11-02 09:37
                回复