标题为“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目前只是原型验证阶段,我也完全没有用到官方文章提及的更深层的效果,可以小小体验一下,目前看来是不影响主程序正常使用的!
安装方式同样是全程交给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目前只是原型验证阶段,我也完全没有用到官方文章提及的更深层的效果,可以小小体验一下,目前看来是不影响主程序正常使用的!










