DeepSeek Super Agent原型实测：个人Agent与超级Agent的核心差异

在AI Agent的演进历程中，我们见证了从简单的聊天机器人到能使用工具、调用记忆的Agent Harness，再到始终在线的个人Agent。而DeepSeek近期开源的一个原型项目——DSH-superagents-prototype，提出了「超级Agent」（Super Agent）的概念，试图重新定义Agent的触发与协作方式。B站UP主Sean通过一个GitHub issue修复的实战案例，对比了个人Agent与超级Agent的运作差异，并梳理了Agent架构的演化路径。

从Agent Harness到超级Agent：一段架构演化史

要理解超级Agent，得先回顾它是怎么一步步演化来的。Sean在视频中给出了清晰的脉络：最基础的形态是Agent Harness，你向Claude Code或Codex提问，它调用工具、检索记忆、返回结果。随后出现了子Agent（Sub-agent），让一个worker在旁并行处理任务，与主任务互不干扰。再往前一步是深度研究Agent（Deep Research Agent），用户查询经过澄清Agent、研究简报Agent，最终到达监督者Agent，由它把任务分派给各个研究员。之后是群体智能（Swarm），没有老板，任务分发给一群worker同时工作，再通过某种机制达成共识。

这些形态的共同点是：Agent的组织方式在变，但触发逻辑没有本质突破。直到个人Agent出现——Meta、X、Cursor、Claude都推出了类似能力，Muse和Gronkbot则率先将其推向市场。个人Agent的核心是「始终在线」：一封邮件、一个日历提醒就能唤醒它，它记得你是谁，能在你接孩子或看视频时继续处理任务。

超级Agent在此基础上再进一步：它同样始终在线，但触发它的不再是人类的指令或定时任务，而是「事件」本身。一个GitHub issue被创建、一条评论被追加，就能唤醒路由器（Router），由路由器决定是否接单，再分派给worker执行。Sean在视频中强调，这个项目目前还只是原型，并非官方正式发布，但概念本身值得关注。

Agent Harness 是本文反复出现的核心术语，指承载大模型并为其提供工具调用、记忆检索、会话管理等运行时能力的「外壳」或「脚手架」。模型本身只负责推理与生成，Harness 则负责把用户输入、工具接口、上下文记忆串联成一次完整任务循环。Claude Code、Codex CLI、Waku Agent 都属于这一类。它的关键价值在于把「模型能力」工程化为「可执行任务」，因此 Harness 的质量直接决定了 Agent 在实际工作流中的可用性。理解这一点，才能明白后文的超级 Agent 本质上是把 Harness 从「被动响应」升级为「常驻监听」。

群体智能（Swarm） 是一种去中心化的多 Agent 协作模式：没有中心调度者，任务被广播给一组 worker，各 worker 并行处理后通过投票、共识或共享黑板等机制收敛结果。它与「监督者—研究员」的层级式深度研究 Agent 形成对照，前者强调弹性与并行，后者强调可控与分工。Swarm 的局限在于共识成本高、责任边界模糊，因此在实际产品中往往与路由器、工单等机制结合使用，这也解释了超级 Agent 为何选择「路由器 + 工单」而非纯 Swarm 结构。

实战对比：同一仓库，两种Agent如何修Bug

Sean用一个名为Tiny Invoices的GitHub仓库做了对照实验。该仓库用于计算发票金额，存在几个issue，比如金额格式错误（应显示为$1050 USD，却显示成了错误的格式）、到期日早了一天等。

他先在issue中@了Waku Agent（连接到自己笔记本上的DeepSeek^广告超级Agent），要求尽快修复。随后在另一个issue中@了Claude——这是Claude的GitHub Action集成方式。两边同时开工，差异立刻显现。

Claude的响应非常直接：被@后立刻在GitHub的机器上启动一个全新任务，直接开始修改并提交Pull Request，没有路由、没有工单，任务完成即结束。

而DeepSeek超级Agent的流程要复杂得多：被@后先进入路由器，路由器判断是否要处理这个事件，然后创建工单（Ticket），再分派给worker执行，最终才产出Pull Request。Sean坦言这个原型存在明显问题——他@了三次Agent才真正开始工作，路由器的「忽略」行为让人抓狂。此外，实时流式反馈的缺失也让整个过程像个黑盒，他不得不切回本地localhost才能确认Agent到底有没有在干活。

在后续的评论跟进中，两者的差异更加清晰。在Claude修复的issue下留言「进展如何」，由于Claude是标签触发机制，没有常驻进程监听后续事件，因此不会自动响应。而在超级Agent处理的issue下留言，路由器会再次被唤醒，worker重新接单并作出回复。Sean还做了个「讲个笑话」的测试，结果超级Agent的worker一本正经地跑去搜索整个互联网，最后回复「这是一个自动化Agent，不是人类」，完全没理解笑话的意图。

核心差异：谁启动工作

Sean把两者的本质区别归结为一个问题：谁启动工作？

个人Agent由人类启动工作——你提问、你设置cron job（比如每周一早上7点发送公司简报），触发后Agent才行动。超级Agent则由事件或任务本身启动工作——有人在GitHub上评论、有工单被创建，路由器就自动运转。

这个差异带来的影响是深远的。Claude的Tag机制本质上是「一次性任务」：每次@都是全新作业，没有持久会话，也不会跟踪后续讨论。超级Agent则维护长生命周期的会话，只要本地harness不关闭，它就能持续监听并响应新事件。当然，这也意味着如果笔记本关机，会话就没了——要真正实现「始终在线」，需要把Agent托管在云端或一台常开的Mac mini上。

Sean也承认，理论上个人Agent通过精心编排、连接GitHub MCP并设定规则，也能实现类似效果。但超级Agent框架的聪明之处在于，它极其克制地聚焦于编码任务。他的判断是：当下大量AI创新首先发生在编码场景，如果能把编码任务解决好，设计工作、幕僚长类工作都能顺延解决，编码是通往AGI路径的核心。

GitHub App 与 GitHub Action 的授权差异 是理解两种部署路径的关键。GitHub App 是平台级的安装式集成，通过细粒度权限和短期 token 代表应用身份操作仓库，适合多仓库、可审计的自动化场景；GitHub Action 则是仓库内的事件驱动工作流，由 issue 评论、push 等事件触发一次性 job。Claude 走的是后者，因此每次 @ 都启动一个独立 job，天然不具备长会话。超级 Agent 采用「独立账号 + 本地登录」的模式，绕开了 App 的权限模型，换来持续监听能力，但也把可用性绑定在了本地机器的在线状态上。

部署方式与工程细节

两种方案的配置路径截然不同。Claude走的是GitHub App模式：安装应用、分配授权token，之后每次@都会启动一个jobs。超级Agent则要求为Agent单独创建一个GitHub账号，邀请该账号对仓库拥有写权限，再在本地机器上登录DeepSeek harness和Agent的GitHub账号，让超级Agent接管这个新账号，所有操作都在本地完成。

Sean特别提到该项目完全开源，你可以在GitHub上看到每个worker的prompt、工单目录、上下文读取和范围评估的技术细节。项目本身是Waku Agent的一部分，后者是一个开源的本地Agent harness，目前有2.2k stars。Sean表示团队正忙于记忆层的开发，未能及时合并所有PR，但仍在尽力维护仓库。

从个人助理到团队协作者

Sean对超级Agent的兴奋点在于协作属性。个人Agent的深度用户往往是企业主、超级忙碌的人或处理复杂任务的人，而这些人恰恰需要与团队协作。超级Agent从设计之初就面向团队协作：GitHub issue、团队聊天、Waku Board上的消息，都可以成为触发源。

他把Agent的演进总结为四个阶段：聪明的聊天Agent、能使用工具和检索记忆的Agent、始终在线的个人助理（像幕僚长或行政助理）、以及真正的队友——在你还没意识到某个事件或任务被分配时，它已经开始干活了。这种协作模式带来的生产力提升，Sean的形容是「如果不是100倍，至少也是10倍」。

当然，原型的问题也如实存在：路由器的误判、缺乏实时流式反馈、笑话理解能力为零。但正如Sean所说，这个概念本身很有意思，值得大家动手部署试试——把超级Agent托管到云端或常开设备上，把它接入你的日常工作流，在实践中理解Agent协作的边界与可能。