DeepSeek 刚提出的 Super-agent 新架构，LobeHub 已经做成了产品

DeepSeek Harness 公布的 Super-agent 架构，用 Router 与 Worker 双层分工把调度负担从人身上挪走。LobeHub 已把这套设计做成产品：一个入口交代需求，后台多个 Agent 并行推进，进展还能汇报到 Discord。

“人将设定目标、提出假设、确定标准，并进行评估。”——J. C. R. 利克里德，《人机共生》

10 月 31 日，DeepSeek Harness 团队公布了一套 Super-agent 架构设计，采用 Router/Worker 双层分工：常驻的 Router 负责与人沟通、派发工作和协调进展，多个 Worker 则在独立上下文中执行任务。用户通过一个入口交代要求，后台可以同时推进多项工作。

这套设计针对的是多 Agent 使用中的调度负担。执行工具增加了，人仍要在不同会话之间切换，交代背景、追问进度、转交结果。多项工作并行时，协调本身就会占用不少精力。DSH 希望将其中一部分工作交给系统，让人更多地参与决策和交付确认。

同一天，LobeHub 团队成员在朋友圈转发了这篇文章，写道：“ 本文的大部分设计已在 Github 仓库项目 lobehub 中实现。”他还补充，该仓库公开的就是 LobeHub 线上产品所使用的那套代码。

这条转发提供了一个可以具体观察的案例：Super-agent 进入真实的研发流程后，会怎样工作？

LobeHub 团队已经在用 LobeHub 开发 LobeHub，相关实践持续了半年左右。他们把需求交给主管 Agent，由 它拆解任务、协调执行，再由人参与关键决策和最终验收。 围绕多 Agent 的调度与协作，也已经成为这个超过 8 万 GitHub Stars 项目的产品功能。

具体来说， LobeHub 是一个组织不同 Agent 协作的工作平台。主管 Agent 承接用户目标、分派工作，并根据执行结果决定下一步；任务较大时，可以组建子 Agent 小队，遇到需要人作出取舍的问题时暂停，等待确认。

具体执行既可以使用平台内的 Agent，也可以接入 Codex、Claude Code 等编程工具。这些工具继续在各自的项目环境中处理文件和代码，LobeHub 则提供共同的沟通与协调入口，让用户能够在同一处交代需求、查看进度和确认结果。

用 Lobehub 开发一款游戏

资料研究、文档协作和软件开发，都涉及要求传递、工作分派与结果检查。LobeHub 将这些环节放进共同的工作空间，尝试组织不同 Agent 接续工作。

开发工作提供了一个值得观察的切面。GitHub 在 10 月 28 日发布的《Octoverse 2026》中披露，截至今年 9 月，平台上的中国开发者达到 1240 万；同期，GitHub 上超过四成代码修改申请以 Agent 生成的初稿开始。开发者已经在将具体工作交给 Agent，之后的审阅、修改和整合，仍然需要继续推进。

在一次 2D 弹弓游戏开发项目中，LobeHub 展现了处理、交接任务上下文的能力。 项目中的交流放在 Discord，任务组织和工具调用由 LobeHub 承担。LobeHub 可以接入团队群聊，让授权成员在其中提出要求、接收进展。

游戏目标通过 Discord 交给 Agent 后，需求被整理成文档，再展开为需求分析、游戏设计、工程搭建、弹弓实现和测试等 Task。 主管 Agent 安排任务顺序，将代码工作交给 Codex，并把已完成、未完成和需要人决定的事项汇报到 Discord。

各任务之间存在紧密的联系，当前置任务完成或进入代办区供人决策时，后续任务会由主管 Agent 判断是否具备启动条件、未明确的要求是否需要负责人补充。在明确启动条件后，主管 Agent 会跟进执行后续任务。

LobeHub 还运用 Linear 式 Task 管理 Agent 协作，这正是此前 Deepseek 正在探索尚未得到解决的问题，Task 保存了这些工作的要求、状态和评论。 项目发生变化时，执行者可以回到已有记录查阅依据，负责人也能核对当前进展。一次讨论由此能够延续到后续实现和修改，不必只依靠群聊里不断向前滚动的消息。同时，主管 Agent 会根据需求检查并优化代码，保证能合理调用 AI 工具。

第一阶段后，观察可运行的原型发现：游戏已经初步实现鼠标拖拽弹弓、松手小鸟发射的功能，但是小鸟和木板撞上猪后，猪没有触发预期的爆炸消失效果。

管理 Agent 发现的问题会在 Discord 中反馈，随后通过输出 PR 并交给 Codex 修复，相关调用继续由 LobeHub 承接。主管 Agent 继续跟进这项修改，将新的执行结果返回讨论中。

修订后的版本会被重新交付。运行视频显示，原先的碰撞反馈问题得到修复。即使一个问题消失，主管 Agent 会继续根据需求文档对完整项目进行检查。

随后，LobeHub 会调用 Acceptance，这是 LobeHub 开源的一款 Agent Loop 工具，它可以收集 AI 交付后的证据并反馈给负责人。 将检查内容与截图、录屏等证据整理成报告。负责人可以逐项审阅，对不符合要求的部分提出反馈，决定继续修改还是接受交付。报告也能够经由 Discord 返回，让结果与此前的讨论衔接起来。

LobeHub 因此将原本分散在群聊、编程工具和检查过程中的工作联系起来，尝试减少负责人在这些位置之间反复传话的负担。

从 LobeChat 到 LobeHub

LobeHub 团队早期推出的是开源 AI 聊天应用 LobeChat。产品最初围绕不同助手组织交互，当时助手之间的差异主要来自提示词。随着模型工具调用能力的发展，LobeChat 也逐渐成为开发者体验和测试不同模型能力的平台。

包括 DeepSeek 在内的模型厂商，曾多次选用 LobeChat 进行官方功能演示。

2024 年 7 月，DeepSeek 在发布 Function Calling 能力时，使用 LobeChat 展示了模型调用插件、获取并总结网页内容的过程。到了 2025 年 12 月，DeepSeek-V3.2 正式发布，官方再次使用 LobeChat 演示模型将深度思考与工具调用相结合的能力。

除了提供模型交互入口，LobeHub 团队也逐渐深入 Agent 能力评测。他们与新加坡国立大学 NUS TRAIL 联合发起了 MCPMark，通过 127 个真实场景任务，评估模型在 MCP 工具调用中的表现；随后又推出 IBench，从用户体验出发，评估 Coding Agent 能否发现并修复真实产品中的可用性问题。

这些工作也涉及一个更实际的问题：当模型开始调用工具、编写代码，甚至独立完成任务之后，如何保证整个执行过程可靠，最终交付的结果又该如何验证？

随着 Agent 能够承担越来越复杂的工作，单纯的聊天交互已经难以满足持续执行的需要。 产品需要保存的内容开始从一段对话，扩展到长期任务所需的背景、状态与决策。

LobeChat 随后引入服务端数据库，让对话、助手和知识能够脱离单个浏览器长期保存，用户管理则划定了多人使用时的账户与访问边界。

当多个 Agent 开始共同完成一项工作，新的问题随之出现：谁来分配任务，谁来跟踪进度，不同 Agent 之间如何交接上下文，执行结果又该如何验收？

L obeHub 因此逐渐将任务管理、主管 Agent、外部执行工具接入等能力整合到同一个 Workspace 中，让 Agent 能够在共享的工作环境中持续协作。

创始人、LobeChat 核心作者徐文彬，自己也在使用 Claude Code、Codex 等执行工具。他曾描述过一种工作状态：多个 Agent 各自执行任务，使用者却要不断切换窗口、同步背景、检查进度。他将这种负担称为「人肉调度员」，并把承接调度工作作为 LobeHub 转向主管 Agent 的直接原因。

在维护 LobeChat 时，团队也需要处理 AI 生成结果的后续工作。多语言维护就是一例：团队开发了 AI 翻译工具，再将其接入仓库的定期更新流程，生成修改申请，交给维护者审阅。模型输出需要经过整理、检查，才能成为产品的一部分。

协作机制成为产品能力

将多个 Agent 用于日常工作之后，企业也开始调整原有流程。埃森哲 10 月 19 日发布的调查显示，在 3,000 名受访员工中，82% 认为 AI 提高了生产力，50% 表示工作速度和检查 AI 输出的要求也在提高。在另外 3,000 名受访高管中，15% 表示正在重设计端到端流程，20% 正跨职能部署 Agent。个人使用已经深入，组织对工作流程的调整仍在推进。

更长的工作过程，会把交接问题进一步放大。a16z 普通合伙人 David Haber 在 10 月 14 日的文章中，将持续数周、涉及多名参与者的业务比作接力：每次交接都可能发生等待、遗漏和信息流失，而客户需要的结果往往到流程末端才实现。他认为，能够持续保存背景、跟进事件并协调后续工作的长程 Agent，有机会承担更完整的业务过程。

把这样的业务交给 Agent，需要持续安排任务接手、同步需求变化，并在验收未通过时跟进修改。 LobeHub 希望由项目中的主管 Agent 承担这些工作，个人的 Agent 则过滤消息，把需要本人判断的事项带回来。执行者之间直接传递要求和反馈，减少等待人工转述的时间。

验收和修改留下的记录，还可以成为下一次交付的检查依据。团队设想，让 Agent 在提交结果前，对照以往的易错点和遗漏项先检查一遍。反馈留在工作流程中，也有助于减少反复解释和重复返工。

用户逐步交出更多执行工作，仍要设定目标、划定授权范围，并为关键决定和最终结果负责。产品则持续保存已有决定、跟进任务变化，遇到超出授权或需要取舍的事项，再把问题交还给人。

随着模型和执行工具的能力提升，分工、信息传递、反馈和验收，也会越来越影响一项工 作能否完成。LobeHub 正在尝试把这些依赖人工协调的环节，做成软件可以持续承担的工作。