👦🏻 作者: GaKi
🥷 编辑: Koji
🧑🎨 排版: NCon
10 月 31 日，DeepSeek Harness 团队发布了一篇《Super-agent 设计探索》，直指过去一年很多人用 Agent 的切身痛点：可同时使用的 Agent 越多，人反而越忙。
在同时运行的多个 Agent 之间，人类用户像「人肉路由器」一样在窗口间来回切换、搬运 Context。
为此，DeepSeek 描绘了一种理想的 Super-agent 形态：
DeepSeek 把这篇文章定位为「设计探索」，文中的很多能力还停留在构想阶段。
但当我们把视线转向产品端，就会发现昔日的开源聊天界面 LobeChat，在今年升级为多 Agent 协作平台 LobeHub 后，已经把其中的许多构想变成了可以直接上手、与 Super-agent 概念形态相似的功能。
接下来，我们先梳理 DeepSeek 提出的设想，再用我们在 LobeHub 里搭建的一个「AI 选题编辑部」，聊聊这些设想在真实产品里到底做到了哪一步，Super-agent 形态又会在未来带来什么样的提升。
现在，大部分 Agent 仍然围绕一个单独的对话来工作。
如果要让十几个 Agent 同时工作，人就需要处理十几个对话，花费大量时间分配任务、传递信息和检查结果。这是 DeepSeek 在《Super-agent 设计探索》中探讨的核心问题。
在 DeepSeek 的设想里，未来的 Super-agent 应该能够持续在线，主动发现和管理任务，还能协调多个 Agent 一起工作。
DeepSeek 产品部的崔添翼（他也是这篇文章的最终审稿人之一），随后也在知乎上解释了 Super-agent 这个名字的由来。
「Super」在这里表示「上层」，与 Sub-agent 的「Sub」相对应。简单来说，就是在原有 Agent 之上增加一层协调机制，统一管理和分配任务。
他还特别强调，目前这套架构仍处于原型探索阶段，只在 DeepSeek 内部的小规模环境中得到验证，距离真正的大规模落地还有不少问题需要解决。
《Super-agent 设计探索》文中的部分设计已经在 DeepSeek 开源项目「 dsh-superagent-prototype 」中实现
在这套体系之下，用户只需要告诉 Super-agent 最终想完成什么，剩下的任务拆分、执行和进度管理，都尽可能交给 Agent 自己处理。
为了描述这种 Agent 应该具备什么能力，DeepSeek 提出了四个判断标准：连续、高效、主动、持久。
围绕这四个标准，DeepSeek 提出了整体架构以及五个设计观点。
DeepSeek《Super-agent 设计探索》
其中三个和日常使用的关系最大：
【1】Router/Worker 双层架构
在 Super-agent 内部，Router 常驻在线，负责接收用户需求、协调和分派任务；多个 Worker 则在独立的上下文中并行执行，最终由 Router 统一向用户反馈结果。
简单理解的话，就是 Super-agent = Router + 多个 Worker + 事件驱动、记忆管理等底层机制。
用户只需要和 Router 对话，具体工作交给 Worker，避免大量执行细节占用 Router 的上下文。
【2】事件驱动和两级过滤
Agent 不必等人 @，群里出现与自己职责相关的消息，也能主动接手。
【3】面向信道的输出，以及计算、状态、环境的分离
Agent 在群里只汇报重点和需要人决策的事，完整执行记录留在任务里。
同时，Agent 在云端持续运行，本地程序负责实际操作。即使用户关掉电脑，云端 Agent 仍然在线。
DeepSeek 提出的部分设计，已经能在 LobeHub 中看到相似的产品形态，不过两者是各自独立的探索。本文仅叙述产品体验，不涉及底层技术架构。
LobeHub 的前身是 LobeChat。
2023 年 5 月，LobeChat 在 GitHub 开源，最初是一个可以自己部署的大模型聊天界面。用户填入 API Key，就能在同一个网页里使用多家模型。
2024 年 6 月，LobeChat 1.0 加入多端同步、知识库和团队共享。2026 年初更名为 LobeHub，转向多 Agent 协作。
5 月，LobeHub 推出 CAO（首席智能体运营官），负责拆解任务、分派工作和跟进进度。
据官方披露，项目在 GitHub 上已有超过 8.3 万 stars、300 多位贡献者，Docker 部署超 700 万次，支持 20 多家模型服务商，可自托管或直接使用云端版本。
LobeHub 可以直接下载本地 APP 使用，下载页为：
我们在 LobeHub 里搭建了一个「十字路口 AI 选题编辑部」，用来为这篇文章准备资料。
编辑部有三位 Agent 成员：
【1】主编运行在 LobeHub 云端，负责接收需求、拆分任务、分派和汇报，自己不做具体工作。
【2】调研员也运行在云端，负责联网检索、核实一手来源。
【3】素材管理员是我 Mac 上的 Claude Code，负责整理本地文件夹里的截图。
创建主编和调研员 Agent 的步骤很简单，在桌面端点击「创建助理」，写好系统提示词、选择模型即可。每个 Agent 都可以单独开启任务工具、消息工具、联网搜索等，支持高度个性化。
素材管理员的接入方式稍有不同。
LobeHub 支持扫描这台电脑上已安装的 Agent。勾选 Claude Code 后，它就成为团队里的一员：
这些 Agent 也可以用 LobeHub 的命令行工具管理。
安装 LobeHub CLI 后，执行
lh agent list 能查看团队成员，执行
lh device list 能查看已接入的设备。调研员就是我用命令行创建的。
创建这些 Agent 成员的最后一步，是把 Agent 接入团队平时使用的聊天工具。LobeHub 的每个 Agent 都可以接入 9 个聊天平台。我们选择了 Slack，在频道 #选题编辑部 里为三个 Agent 各配置了一个机器人。
可以直接连接进 Slack、飞书、Discord、Telegram 这些 IM 里：
作为一个 Bot 出现：
团队搭建好之后，我在 #选题编辑部 里 @ 主编，发送了下面这段需求。
@主编 我要写一篇关于 LobeHub 的公众号稿，切入点是 DeepSeek 10 月 31 日发布的《Super-agent 设计探索》。请安排两件事： 1. 调研：这篇文章的核心观点，以及国内外媒体和开发者的讨论，至少 5 个一手来源。 2. 素材整理：把我 Mac 上 ~/Desktop/LobeHub实测/截图 里的图片按时间排序，生成一份「素材索引.md」，每张图写一句说明。 今晚 10 点前给我结果。群里只告诉我进度和需要我决定的事。主编收到消息后，先加了一个 🤔 表情，之后就创建好了两个任务。T-1 是调研，指派给调研员；T-2 是素材整理，指派给素材管理员。
每个任务都写明了目标、背景、要做的事、输出格式和完成标准，截止时间设在当晚 21:30，并且自动开启了交付验收。
在 LobeHub 的任务列表里，可以看到两个任务由不同的执行者同时推进。打开任务详情，创建者是主编，执行者是对应成员，T-2 的执行位置显示为本地设备。
LobeHub 任务列表中，两个任务同时进行：
素材管理员最先完成。它在我的 Mac 上生成了一份素材索引，逐张查看文件夹里的截图并写好说明：
调研员交付的报告里，还单独列出了 7 条存疑点。
整个过程中，主编只在线程里发送了 3 条消息，分别是已派出的任务、进度和待决定的问题、最终结论。频道主界面没有被刷屏，完整的调研报告留在任务详情里。
主编还负责沟通和分派，具体工作由成员完成，需要判断的事交还给人。
这和 DeepSeek 设想的 Router/Worker 分工、面向信道的输出，形态很接近。
后来我们又试了另一种做法，让三个 Agent 在频道里互相交流。
主编收到需求后，在线程里 @ 调研员和素材管理员说明分工，同时在 LobeHub 里为两人各创建一个任务。成员完成后，用各自的 Slack 机器人把结果发回频道，并 @ 主编。主编收齐两份汇报，再发一条汇总。
主编 @ 两位成员分派任务，素材管理员用自己的机器人 sucai @ 主编汇报：
调研员看到素材管理员发给主编的汇报后，还主动说明「这条是发给主编的，我这边不用处理」。
素材管理员是本地的 Claude Code，它在终端里调用
lh bot message send 命令发送消息。所以从外部接入的 Agent，也能用自己的身份在团队频道里发言。
LobeHub 的 Slack 渠道支持监听关键词。我们为主编设置了「选题」「能写吗」「值得写」三个词。设置可以在 App 里完成，也可以用
lh bot watch-keywords add 命令添加，App 的配置页会同步显示。
之后我在频道里发送了一条消息，没有 @ 任何人，只提到 LobeHub 开源了内部使用的验收工具 Acceptance，问这个值不值得写。
主编被关键词唤醒，1 分钟内在频道里给出了选题判断，并创建了两个任务。T-3 交给调研员核实信息，T-4 交给素材管理员盘点素材。
两个任务创建后都放在待办里，主编先问我「现在两个都开始吗？」。毕竟执行任务会消耗积分，由人确认后再开始更稳妥。
在 Discord 和飞书上，LobeHub 的主动参与还能再细一层。用户可以写清楚 Agent「负责的事」，并调节职责灵敏度。消息先经过频道范围和关键词筛选，再由模型按职责判断要不要接手。
每次唤醒都会留下记录，显示原因、置信度和结果，用户还可以标记这次判断对不对。这套流程和 DeepSeek 提出的两级过滤，形态相近。
追问也会回到原来的任务。
我在主编的线程里回复了它之前提的问题，同样没有 @ 任何人，要求调研员补一张 DeepSeek 设想和 LobeHub 功能的对照表。
主编随即回复「调研员已经在 T-1 开始做对照表」。T-1 的状态从已完成变回进行中，我的追问被写成一条「追加需求」评论，附在 T-1 下面，没有新建任务。
同一件事的后续消息会回到原来的任务和 Agent，上下文也保留在一起。
编辑部里，主编和调研员运行在 LobeHub 云端，素材管理员运行在我的 Mac 上。
LobeHub 把 Agent 的主循环放在服务端，所以关掉网页或桌面端，云端的 Agent 依然在线，Slack 里的消息照常有人处理。连接中断后，任务也会自动恢复。
需要用到本地文件时，云端通过「执行设备」调用我的电脑。设备页里能看到这台 Mac 的在线状态和绑定的 Agent。素材文件始终留在本地，不需要上传。
Agent 还可以按计划工作。在任务详情的自动化设置里，可以让调研员每天 8:30 整理前一天 AI Agent 领域的重要发布，第二天早上人只需要查看结果。
这对应 DeepSeek 提出的计算、状态、环境分离。Agent 和它的状态留在云端，文件和工具链留在原来的机器上。
前面的实测里，LobeHub 中多个 Agent 可以分工，也可以在满足条件时主动接手任务。
Agent 能完成的工作越来越多，人的工作重心就会转移到定目标、看结果和处理例外上。所以，人需要一个地方，能看到 Agent 做了什么、做得对不对。
在 LobeHub 里，这个地方叫做：Task。
T-1 的对照表一共做了三轮。
第 2 轮，调研员虽然交出了对照表，但交付验收的 4 项里有 1 项没有通过。原因是它只提交了对照表，没有和原来的报告合并。
主编看到结果后，在 T-1 里写了一条返工说明，让调研员重做，在第三轮里验收 4 项才全部通过。这几轮返工都由主编和调研员完成，我没有介入。
素材管理员首轮验收其实也没有通过，返工后第 2 轮全部通过，它还在验收阶段自动更新了一次索引，把任务进行中新增的截图也纳入进来。
主编发出最终结论时，还特意提醒我，稿子里只能写「产品形态相近」，不能写「技术架构相同」。
换到开发团队，任务的交付物通常是 PR，但流程基本一致。
据 LobeHub 披露，他们的团队每天在 Discord 里与 Agent 协作。主管 Agent 查清问题后创建任务，交给 Claude Code 担任的 Worker 执行，最终提交 PR 并通过 CI。
GitHub 事件也能接入这套流程。比如 PR 出现新评论或状态变化，就可以唤醒对应的 Agent 继续处理。
Agent 说任务完成了，作为用户还得确认结果是否符合要求。比如代码测试通过了，页面却可能出现菜单截断、文字看不清、按钮溢出等问题。
为此，LobeHub 开源了内部验收工具 Acceptance，采用 Apache-2.0 协议。
它会把需求拆成多个检查项，在真实产品中逐项验证，并附上截图、录屏和日志，生成一份在线验收报告。
不满意的部分可以单独退回，已经通过的检查项继续保留。返工原因也会被记录，供 Agent 下次自查。设计、产品和工程团队还能在同一份报告里讨论问题。
相比前面 T-1、T-2 使用的任务验收清单，Acceptance 更进一步，让每个验收结论都有可以查看的证据。
DeepSeek 在其报告中留下了一个开放问题：
LobeHub 提供了 Workspace 和 Task 两套功能。
团队成员可以在同一个工作区共享 Agent、文件、知识库和积分，并通过角色权限控制访问范围。
每项任务的需求、执行记录、进度和评论都保存在 Task 里。新加入的同事打开任务，就能了解之前发生了什么，不需要重新交代背景。
据 LobeHub 披露，这套协作方式已经在内部使用了半年。多个 Agent 可以同时推进任务，人只在关键节点介入。
回看这次搭建编辑部的过程，多 Agent 协作带来的变化主要有三点：
【1】人只面对一个入口
需求交给主编，拆分、分派和跟进都由主编完成。人不再需要在多个窗口之间搬运上下文。
【2】Agent 持续工作
任务可以跨对话、跨天推进，追问会回到原任务，关掉电脑也不影响云端的 Agent。
【3】人的工作转到两端
任务开始前，人定目标；交付之后，人看证据、做验收。中间遇到需要判断的事，Agent 会停下来问人。
当然，据我们实测，目前这套协作方式还有一些限制。
比如在 Slack 上，三个 Agent 虽然能互相 @，但任务的衔接仍然需要主编来完成。
LobeHub 创始人也在 X 上提出了一个他们思考了三个多月的问题：
尤其当 Agent 的创建者和任务发起者是不同的人时，问题会更加复杂。
这些问题，DeepSeek 还没有给出完整答案，LobeHub 的 GitHub 集成等功能也仍处于 Alpha 阶段。
或许，下一代 Agent 最值得期待的变化，就是人终于不再需要管理每一个 Session。
人负责提出目标、审核结果，具体工作交给一支能够持续在线、自主协作的 Agent 团队。
当然，距离真正实现这一点，还有很多问题需要在实际使用中解决。
