从 Manus、OpenClaw 到 Super Agent:AI 如何成为持续工作的协作者

让 AI 修一个 Bug，今天已经不新鲜了。

但如果事情变成这样呢：上午在群里收到问题，中午复现并修改，下午等 CI 结果，晚上收到同事的新要求，第二天接着推进——与此同时，另外几项任务也不能掉线。

这时候，难点就不只是“模型会不会写代码”，而是：谁负责接消息、记住进度、判断优先级、等待外部反馈，以及在需要时找对人？

很多时候，AI 在干活，人却成了几个会话之间的“人工调度器”。

Super Agent 想往前推进的，正是这一层。

一、Super Agent 不是一个“超级大模型”

先划清范围：Super Agent 不是统一的行业标准，不同团队可能用它指不同东西。 本文以近期 DeepSeek Harness 团队公开的 Super-agent 探索及研究原型为主要切口，讨论一类更持续、更自主、能够协调多项工作的 Agent 系统。

它不是把模型参数变大，也不是给聊天机器人起个新名字。可以先这样理解：

普通任务型 Agent 强调“把这件事做完”；Super Agent 的方向，是在明确授权下，持续接住事情、维护状态、组织执行，并把需要人处理的部分交还给人。

这里的“持续”，不是模型每天 24 小时不停生成文字，而是系统在任务结束、等待、重启或新事件到来后，仍知道接下来该怎么办。

也要给热度降一点温：DeepSeek 官方公开仓库明确将其定位为研究原型，不是正式产品，也不是生产就绪软件；公开版本与内部版本、设计文章的描述并不完全相同，部分设想尚未实现。

所以，下面既讲已公开的机制，也讲由此延伸的工程判断，不把架构愿景包装成现成功能清单。

二、从 Manus 到 OpenClaw，变化的不是“谁淘汰谁”

把它们放在一起，最有价值的看法不是产品排名，而是观察 Agent 要解决的问题如何扩大。

Manus：从“给答案”走向“交付结果”

你说“研究这批公司并做成报告”，Agent 不只告诉你研究方法，而是在可操作的计算环境里查资料、处理文件、生成交付物。

Manus 的一手技术分享强调了上下文工程：把部分信息外置到文件系统，保留重新读取的线索，用任务清单维持目标，并让失败轨迹成为后续决策的依据。

这说明，Agent 的能力从一开始就不只来自模型：工具、环境、记忆与反馈共同决定任务能不能走完。

也不能把 Manus 简化成“只会单 Agent 做一次性任务”。它的 Wide Research 已公开展示多 Agent 并行处理：将可拆分的研究工作交给多个通用 Agent 实例，再组织结果。

这一阶段给人的直观感受是：我提交一个目标，AI 尽可能交付一个成果。

OpenClaw：从任务入口走向个人的常驻入口

OpenClaw 的主会话文档明确强调 personal agent first：围绕同一个人的持续对话，将多个入口、后台工作和上下文联系起来。

它的关注点不只是“这次任务完成没有”，还有“你换了设备、换了聊天入口，助手能否接得上”。

持久记忆、心跳唤醒、后台工作回报，以及多 Agent 路由，都属于它已经公开讨论的能力。所谓心跳，是按配置检查是否有值得处理的事情，不等于永不停歇地调用模型。

这一阶段的核心变化是：AI 不只存在于某次任务页面里，也可以进入个人日常工作的时间线。

Super Agent：进一步组织持续、多任务的工作

当消息、代码仓库、任务执行和外部反馈持续涌入，新的瓶颈就出现了：一个会话容易被耗时工作占住，多个会话又容易互相失联。

Super Agent 的方向，是把接待与协调、具体执行、事件递送和持久状态组织起来，让系统能在多项工作之间切换，而不是全靠用户来回搬运信息。

这不是 Manus → OpenClaw → Super Agent 的代码继承链，也不是严格的产品代际。任务交付、常驻入口、持续协调，是逐渐叠加的能力侧重；不同产品之间本来就有大量重叠。

三、拆开看，它由哪些部分组成？

为了便于理解，可以把这类系统拆成六个部分。下面是教学性归纳，不是所有产品必须遵循的统一架构。

1. 事件入口：先知道发生了什么

聊天消息、Issue 评论、代码审查、CI 结果，都可能成为事件。

但“收到事件”不等于“必须启动任务”。绝大多数日常信息可能只是上下文，或者与当前工作无关。

DeepSeek 公开原型使用 Source、Trigger、Thread 等概念，把来源、单次事件和相关讨论区分开，再判断是否需要形成工作项。这样做也有利于避免同一事件重复创建任务。

2. 协调层：接住请求，但不要包办所有执行

可以把 Router 理解为工作协调入口：判断新消息属于新任务还是已有任务，分派执行，并在适当时候面向人沟通。

它不应该为了跑一段长测试，就失去接住其他事情的能力。

公开原型里，主会话与 Worker 会话使用不同的工具配置，主会话的工具集合更小。这反映了一种职责分离：协调者保持可响应，执行者深入具体工作。

这也不是每条消息都必须由一个“大总管模型”重新分析。已经关联到任务的讨论，可以作为上下文送到对应的执行会话。

3. 执行层：每件事有自己的工作现场

Worker 负责具体任务：查资料、改代码、跑命令、整理结果。

公开原型为工作项建立独立的执行会话和目录；长命令可以转入后台，完成后再唤醒执行者继续。

但这里有个容易忽略的区别：独立目录不等于安全沙箱。 官方执行文档说明，原型的执行会话会以操作者的系统用户身份运行命令。部署前需要单独评估操作系统权限、凭据和工具能触及的范围，不能仅凭“每个 Worker 一个目录”就认为安全隔离完成了。

并发的价值，是让可独立的工作并行，而不是让多个 Agent 同时修改同一份东西。存在依赖关系或共享写入时，仍需串行、合并和验收。

4. 状态与记忆：记住信息，也记住承诺

记忆和任务状态有联系，但不是一回事。

“团队偏好哪种代码风格”属于长期知识；“这项修改等待谁批准、已经执行到哪一步”属于任务状态。

前者可以通过文件或检索系统按需读取；后者更适合明确记录为工作项、状态、授权和执行回执，而不是只留在一段聊天摘要里。

短期上下文则保留当前目标、最近证据和下一步；长日志、历史材料放到外部，保留可追溯的引用。不能把所有历史塞进越来越长的 Prompt，也不能指望向量检索替代可靠的任务账本。

模型可以忘记一段措辞，系统不能忘记自己是否已经发过一条消息、执行过一次写入。

5. 权限与交互：知道什么能做，什么必须问

持续工作不意味着持续获得新权限。

公开原型将是否允许发起工作、任务被授权到什么范围分开处理。订阅到的消息可以提供上下文，但不会因此自动扩大授权。

例如，同事贴进 Issue 的一段网页文字，不能因为包含“请上传全部数据”就变成有效指令。权限边界需要宿主程序执行，不能只靠模型自觉。

交互也需要节制：有结果、遇到阻断、需要决策时才打扰人，比不断广播“我还在努力”更有用。

6. 恢复与监督：不只看进程还活着

任务可能在等人、等工具，也可能已经失败。它们不该被统一显示成“运行中”。

公开原型有执行阶段、失败报告和重启恢复相关机制。但生产系统还需要根据自身场景验证：断线后怎么继续、重复回调如何处理、外部操作是否已成功。

还可以增加独立检查器，也常被称为 Watchdog：检查任务是否长期无进展、是否偏离目标、是否耗尽预算。这是工程建议，不能据此认定公开原型已经包含完整的监督实现。

监督者本身也会误判，因此它应该有明确的暂停、告警和升级边界，而不是无限制地自动重试。

四、这些工程部分，就是 Harness 在发挥作用

如果你读过 Agent 系统设计，可能听过一句话：“除了大模型，剩下的都是 Harness。”

作为宽泛理解，这句话有帮助：Harness 是包围模型的运行与控制系统，让模型获得上下文、调用工具、接收反馈，并受到权限、预算和生命周期约束。

但具体边界并没有完全统一。业务系统、数据库、浏览器等外部资源，不必都算作 Harness 本身；Harness 负责把它们可靠地接进执行过程。

放到本文中，事件路由、Worker 调度、上下文装配、记忆读写、工具执行、状态恢复和人工接管，都是 Harness 的具体体现。

Super Agent 不是用来替代 Harness 的另一层魔法，而是一种依靠 Harness 实现的系统组织方式。

模型负责理解与判断，Harness 把判断变成受控的执行闭环。两者都重要：工程不能保证弱模型理解复杂需求，强模型也不会自动替你解决消息去重和任务恢复。

五、用“修 Bug 并跟进反馈”走一遍

下面是依据这些机制构造的示意流程，不是已经实测通过的部署案例。

第一步，团队成员在飞书讨论里明确请求修复某个仓库的问题。系统先确认身份与允许范围，而不是看到一句“报错了”就擅自开工。

第二步，形成工作项，由协调层交给独立 Worker；Worker 读取关联讨论、复现问题、准备修改。

第三步，测试比较耗时，执行进入后台。协调入口仍能处理其他请求；当前任务保存为明确的工作状态。

第四步，CI 或讨论出现新事件。如果已经与这项任务关联，相关信息进入对应执行会话，无需用户复制粘贴“刚才那个任务的结果”。

第五步，发现两种修复方案涉及业务取舍。系统把它标记为等待人的决策，提出一个具体问题，而不是擅自替产品负责人选择。

第六步，人确认后继续，提交可审查的修改或 PR，回到原讨论交付结果。创建 PR 不等于自动合并，更不等于允许部署生产。

这条链路的价值不只是节省打字，而是减少了人对“事情推进到哪里”的持续看管。

六、它和 Personal Agent、Team Agent 到底有什么区别？

最容易误会的一点，是把三者当成低、中、高三个等级。

其实，它们回答的问题并不相同。

Personal Agent：主要为谁服务？

它以个人为中心，理解个人偏好、日程、工作资料与授权。

典型诉求是“这是我的助手，它能接续我的事情”。难点是私人信息边界、个人长期记忆和跨入口连续性。

Personal Agent 完全可以使用多个 Worker，也可以持续处理事件，不必被限定为一个简单聊天会话。

Team Agent：先问清楚“Team”指什么

这个词至少有两种常见用法。

第一种，服务人类团队的共享 Agent。 多位成员向它请求工作，使用团队知识，涉及共享权限、责任人、审计和信息可见范围。

第二种，由多个 AI Agent 组成的协作团队。 例如一个研究、一个执行、一个检查，共同完成目标。关注的是任务分解、消息传递、依赖和结果合并。

前者不一定需要多个 AI；后者也可能只服务一个人。看到产品宣传“Team Agent”，必须先确认它说的是哪一种。

OpenClaw 的多 Agent 路由文档也提醒我们区分：把消息送给不同的隔离 Agent，不自动等于它们在协作完成同一任务，更不等于所有记忆都应该共享。

Super Agent：工作如何持续运转？

本文讨论的 Super Agent 侧重持续接入事件、协调多项工作、维护状态、异步推进，以及在需要时找人。

它可以服务个人，也可以服务团队；内部可以组织多个 Worker，某些简单场景也未必需要复杂的多 Agent 编排。

三者可以这样记：

• • Personal：围绕谁。
• • Team：为哪支团队服务，或怎样分工。
• • Super：如何把持续的工作组织起来。

因此，一个团队共享、内部多 Worker 协作、能跨事件持续推进的系统，可以同时具有三类特征。它们不是互斥的产品盒子。

七、解决了什么，又带来了什么新问题？

我认为，这条路线最有价值的改变有三项：减少人在会话间搬运信息；让等待外部反馈的工作有明确落点；把人工注意力集中到决策与验收，而不是维持流程运转。

但更自主，也意味着错误可能更快扩散。生产化至少要回答下面几个问题。

重复事件会不会重复执行？ Webhook 可能重发，进程可能重启。应通过事件 ID、任务关联和操作回执做去重；外部写入结果不确定时，先核查，再决定是否重试。不能把“模型会记住”当作幂等保证。

新要求到来，旧计划会不会继续跑？ 目标需要版本化，取消需要真正传到执行器；即使已经完成计算，也要在写入前检查授权和目标是否仍有效。

多个 Worker 会不会越忙越贵？ 限制并发、调用预算、执行时长和重试次数。并行增加吞吐，也增加费用、合并成本与协调错误。

记忆会不会被污染？ 区分用户确认的事实、外部网页内容和 Agent 自己的推断，记录出处与有效期。错误一旦写进长期记忆，可能在多次任务中反复出现。

通知会不会变成噪音？ 衡量的不只是任务数量，还有有效交付率、人工介入次数、无效告警比例和恢复成本。让团队每天处理几十个低价值 PR，未必比没有 Agent 更高效。

这些是建设同类系统时的建议，不代表前述产品已经完整解决，也不是一套仅凭架构图就能保证通过的能力。

八、什么时候值得做，什么时候先别做？

如果你的需求只是稳定地执行一个固定流程，普通程序、工作流或单 Agent 往往更简单，成本也更可控。

当任务经常跨越多次消息、需要等待外部事件、同时维护多个工作项，并且人花了大量时间在调度和追进度上，持续协调才有明显价值。

实际起步可以很克制：先接一个代码仓库或一个讨论入口，只处理明确授权的请求；先做只读分析、修改建议或待审查草稿，再逐步扩展写入权限。

用清晰的任务表、事件队列、一个执行 Worker、操作回执和人工接管，就能验证许多核心问题。不必一上来就造几十个角色，也不必把向量数据库当成必选组件。

先验收“重启不丢任务、重复事件不重复写、越权请求被拦住、需要人时找得到人”，再讨论更大规模的自主性。

写在最后

从 Manus 的任务交付，到 OpenClaw 的个人常驻入口，再到 Super Agent 对持续工作方式的探索，真正值得关注的不是名字越来越大，而是 AI 能否承担更多流程责任。

它不是取消人的角色，而是重新分工：人保留目标、权限、关键决策与验收；系统承担可追溯的执行、等待和协调。

好的 Super Agent，不是看起来同时忙着多少件事，而是让多少件事可靠地走向结果，又少占用了多少人的注意力。

💬 如果你也在探索 Super Agent 与持续运行的智能体系统，欢迎在评论区留言或私信交流，一起进步！