常驻 AI 如何持续工作：DeepSeek SuperAgent 深度解读

最近，Personal Agent 很火。Meta 的 Muse、OpenAI 的 dots、Anthropic 的 Claude Duet，还有 Grok Bot，几家大厂接连推出自己的个人智能体。

其中，Muse 已经登上多国应用商店的免费榜首。

Personal Agent，也就是个人智能体，可以理解为围绕一个用户长期工作的 AI 助手。它保留用户的偏好和任务上下文，连接实际工具，在授权范围内持续执行。比如，把“跟踪这几个项目的更新”交代给它，后续继续收集变化、按计划整理结果，需要决定时再回来找人。不同产品的记忆、触发方式和执行权限各有差异。

持续工作也带来了新的系统问题。单个 Agent 的能力越来越强，工作却常常断在对话边界。任务交出去之后，进度、异常和下一步如果仍要人盯着，人的注意力并没有省下来。

DeepSeek SuperAgent 提供了一个研发协作样本。它把 GitHub 和可选的飞书消息接到 DeepSeek Harness 上，让协调者分派任务，用工单保存授权和进度，再把后续评审、CI 反馈送给对应的执行者。通过这个面向单仓库的原型，可以进一步看清持续接活、等待反馈和中断恢复需要怎样组织。

先说明范围。官方仓库将其标为研究原型，非 DeepSeek 正式产品，也未达到生产就绪状态。公开原型与内部版本、设计文章并不完全相同，部分设计方向尚未实现。下面主要解读已经公开的原型机制。

减少人的注意力成本：解决 Agent 越多，人反而越忙

Agent 把资料搜集齐了、代码修改好了，后续仍可能等人筛选、转交和推进。人一忙，任务就停在交接处。每个 Agent 都完成了分内工作，整项任务却未必能继续。

这些协调动作会消耗人的注意力。Agent 能并行执行多少任务，和人能同时管理多少任务，是两件需要分别处理的事。

SuperAgent 在产品理念中把目标写得很直接。

Take as little human attention as possible, and give as much value as possible.

它要求每条消息、每次提问，甚至设置项和面板元素，都要值得人花时间看。普通进度尽量留在系统内部；结果准备好、需要决策或无法完成时，再回到发起请求的讨论里沟通。

用一项接口修改请求接起来看，这个目标更容易理解。获准用户在 GitHub Issue 中提出“为创建接口增加参数校验，并补充测试”。系统接单后，为它安排独立工作目录和执行会话。Worker 读取代码、修改并测试，提交 PR 后进入待审阅。后续评审和 CI 消息继续送给负责这项工作的 Worker，必要问题再交还给人。

人仍然负责需求和关键判断。请求分发、后续消息归属、等待期间的状态维护，则由系统接过来。

协调者与执行者：把任务分派也交给 Agent

前一步的结果能够交给下一位执行者，工作才有机会持续往前走。SuperAgent 由主 Session 和多个 Worker Session 分工，负责这些交接。

主 Session 负责评估与路由。它接收候选请求，判断是否创建新工单、关联已有工作，或忽略无须处理的内容。Worker 上报重要结果、人工提出后续问题时，也由它协调。主会话主要保留跨任务摘要，避免被每项工作的代码和测试日志占满。

Worker 负责具体技术工作。每张工单有自己的执行会话和目录，Worker 在其中调查问题、选择方案、修改文件、运行测试，并处理授权范围内的后续反馈。超出范围的要求会退回，等待重新路由。

两类会话都复用 Harness 的模型与工具执行循环。SuperAgent 在上面增加了接单、授权、派工和协作状态管理；Engine 以程序逻辑维护这些业务事实，模型通过受校验的工具提交判断和操作。主 Session 提出接单决定，也要经过 Engine 检查才能落成工单。

这也适合与 Grok Bot 放在一起看。两者都希望让用户交代工作后，由系统组织后续执行，但组织工作的中心有所不同。

Grok Bot 的产品重点是长期角色、工具使用与工作习惯。官方还提供示范工作流程、保存为例行任务的交互。SuperAgent 则更明确地表达了一项工作为何被接受、由谁执行、后续消息应该交给谁。这里比较的是公开可见的设计重点，不能据此给两者的整体安全能力排高低。

默认静默：有结果或需要决策时再找人

协调工作交出去之后，如果 Agent 仍把每一步进度发出来，人还是得不断检查通知。

SuperAgent 区分内部报告和对外回复。Worker 可以汇报进度，但没有可供人使用的回答时，普通进度不会继续转发给主会话。准备好的结果、具体问题和重要阻塞才按规则向外传递。接单时可以确认一次，后续沟通回到原讨论，减少人切换系统和重新找背景的负担。

需要人作决定时，系统使用 Attention 保存一个结构化问题。问题关联到工单及相关消息，主 Session 据此向人提问。这样，“需要人回答”成为可以识别的业务事实，面板也能优先展示这些待处理事项，无须从一长段执行日志里猜测。

遇到接口行为需要需求方选择的情况，Worker 可以把这项选择交还给人，保留工单和已经完成的工作。人的回复到达后，再继续推进。

等待新事件、等待评审和需要人回答，也要分开记录。Worker 回合结束时可能只是暂时无事可做；出现 Attention 才表示有明确问题等人决定。

受控的主动性：看见需求，不等于获得授权

主动执行需要把条件说清楚。什么时候检查，遇到什么情况介入，可以处理到哪一步，哪些地方需要回来找人确认。条件不清楚，Agent 可能增加人的协调负担。

能读到一个群或一个仓库里的消息，并不能让 Agent 自行把每条建议变成任务。SuperAgent 为此区分两条接单路径。

明确请求有可识别的发起方式，例如获准的人直接向 Agent 提出要求。团队也可以通过来源准入规则，开放特定讨论范围内的请求。另一条是主动候选，系统从接收到的事件里识别潜在工作，再判断是否符合团队事先写好的规则。

主动模式提供关闭、观察和自动接单三档，默认处于观察模式。此时会记录“本来会做什么”，供操作者检查；切换为自动接单后，符合条件的候选才会进入执行。默认主动规则的范围较窄，主要针对文案修正和有明确标准的局部视觉修正。

这条路径里，Source 表示外部事件来源，Trigger 表示一次归一化事件，Thread 把相关事件组织成持续讨论。Eval 对候选作出判断，接受后创建 Ticket，也就是工单，并保存 Mandate 这份授权快照。

Mandate 记录发起者、授权依据、策略版本和工作范围。它随工单保存，后续模型会话的变化不会悄悄改写这份授权。更大的工作范围需要重新接单。同一个 Trigger 被重复接受，也只应创建一张工单。

已有工单收到新消息时，授权边界仍然有效。订阅讨论中的人、机器人和 CI 消息可以作为上下文送来，但这些信息本身不授予新的权限。修复接口的 Worker 可以继续处理相关测试反馈，不能因为讨论里顺便提到重做整个业务模块，就直接扩大任务。

程序约束和模型判断在这里共同存在。宿主校验模式、规则、策略版本和操作资格；某段话究竟表达了什么意图，仍需要模型判断。记录了匹配理由，并不能证明语义判断一定正确。因此，从观察模式开始检查接单质量，是这套机制的重要使用前提。

工单独立于会话：对话结束，工作仍在继续

接口修改的 PR 已经提交，Worker 暂时空闲。过一段时间，评审者留下修改意见，CI 也返回新的结果。此时需要接续同一项工作，保留原先的范围、代码目录和讨论背景。

SuperAgent 把三种对象分开保存。Thread 记录外部讨论和事件；Ticket 记录一项获准工作的业务事实；Session 保存模型看过的内容、工具调用和对话历史。它们各自有自己的生命周期。

这使系统可以表达几种常见情况。一次模型回合已经结束，工单仍在等待评审；执行出现问题，需要重新派工，但继续使用原来的目录、分支和 PR；正常结束的任务收到后续人工消息，可以在重新验证授权后恢复。人主动停止的任务则撤回授权，不能靠普通后续消息自动唤醒。

Subscription，也就是订阅关系，负责把讨论中的新事件送到关联工单。Worker 跟随自己的 PR 后，后续评审和 CI 信息可以继续送来，人不必每次重新提到 Agent、复制意见和解释背景。若只是为读取上下文而关注另一段讨论，则不会因此得到新授权，也不会按同样方式恢复已经结束的工单。

等待期间的推进由事件和队列管理，不要求模型持续发问检查进度。这里仍要区分两层“轮询”。GitHub 来源当前通过程序轮询获取事件，飞书采用事件消费并结合历史恢复、话题轮询；模型无需为了等待这些结果而一直运行。

中断之后，系统靠什么接着做

任务状态独立保存之后，还需要处理进程重启、模型错误和消息发送失败。原型将状态分成三部分保存。

SQLite 保存业务事实，例如事件、决策、授权、工单和待执行操作；Harness Session 保存模型上下文与工具历史；文件和 Git 保存代码、分支及实际工作成果。重启时，系统根据这些记录恢复派工和待处理输入，要求执行器先检查目录、Git 历史与 GitHub，再决定下一步动作。

Effects 是持久化的待执行操作队列。接单之后要启动执行器，或把报告交给主 Session，系统先记录这件待办，再执行。失败后可以根据记录重试，避免工作只存在于某次模型输出或内存回调里。

回答生成了、进入发送队列、实际送达，是三个需要分别确认的状态。SuperAgent 的对外回复经过 Outbox。业务层先判断消息是否有资格发送、应发给谁，Outbox 再保存待发状态和发送回执。GitHub 评论使用消息标记辅助去重，降低中断重试时重复发送的概率。

这些机制仍有明确边界。SQLite 提交、Harness 会话持久化和 GitHub 写入之间，没有一个覆盖全部操作的全局事务。恢复依赖稳定标识、投递去重和外部事实检查，不能保证任意工具操作都严格只发生一次。队列保持顺序，也可能让前面的失败阻塞后续同类操作。

执行隔离同样需要单独看待。每个 Worker 有独立目录，但仍使用宿主操作系统用户的权限；目录分离不构成容器或系统级安全边界。语义授权有模型误判的可能，GitHub 必需审批等规则应在分支保护层执行。

当前部署仍以单机、单状态目录和单仓库为中心。内部超时和恢复机制可以处理部分故障，外部小时巡检则需要另外配置；它们无法抵御整机断电、休眠或网络中断。要扩展为多租户平台、远程执行集群，还需要补齐隔离、凭据管理和分布式执行协议。

状态检查：接单以后，任务仍然会发生变化

前面的流程把接单、执行和回复串在了一起。但这些动作之间都有等待，模型作出判断时看到的情况，可能已经与真正开始执行时不同。

仍以接口修改为例。系统已经接受请求，执行器正在准备工作目录，这时需求方要求停止。如果系统只记得“这项工作获准执行”，等目录准备好后就启动 Worker，人的停止指令就会被旧派工覆盖。任务还在原来的队列里，执行它的条件却已经改变。

SuperAgent 因此在准备目录、创建会话和投递消息前后，反复检查工单是否仍有效、当前派工是否仍然匹配，以及系统是否暂停或正在关闭。这些检查处理的是等待期间的变化。接单时判断正确，只能说明那一刻有执行依据。

主动评估也有相同的问题。一轮模型判断可能依据旧规则展开，等结果返回时，操作者已经缩小了允许自动处理的范围。原型把规则、主动模式和来源准入配置一起计入策略版本。评估期间版本变化，旧判断会被废弃，相关事件重新排队，按新规则处理。

已经执行中的工作采用另一种处理。系统把受影响的策略变化交给对应 Worker，让它知道哪些条件变了，并保留当前工作现场。结束后的工单需要恢复时，再按当前策略重新校验授权。立即停止、通知执行者和恢复前重验，分别适用于不同阶段，不能用一个全局开关代替。

Engine 在这里负责把判断落实成一致的业务事实。接受请求时，决策、授权、工单和后续派工需要一起保存；只有“模型说可以做”，系统还无法可靠地接着执行。把业务修改放进事务、把后续动作记入持久化队列，能避免留下“工单已经建了，却没有任何派工记录”这样的中间状态。

模型和网络调用都可能等待较长时间，因此不放在这一同步事务里。业务状态先提交，耗时动作随后推进，再根据结果写回。这也解释了为什么流程里需要多次检查状态。每跨过一次异步等待，执行条件都有可能发生变化。

消息归属：同一条回复由谁继续处理

工单可以独立于对话存在，同一段讨论也可能对应几项工作。有人在 PR 下追加意见，系统要先弄清这条消息已经由谁接手，再决定是否创建新任务。

如果每收到一条评论都交给主 Session 重新判断，就可能把现有 Worker 正在处理的修改意见再派一次。两个执行者看到的是同一个需求，却各自维护一份任务状态，后续报告和授权也会分叉。

SuperAgent 用订阅关系把新事件送到相关工单，并记录人工后续消息的处理归属。消息仍由某个 Worker 负责时，主 Session 不能同时把它当作新的独立请求接单。Worker 先在自己的授权范围内判断，可以继续就处理，超出范围则退回并说明原因。

这里还要考虑多个 Worker 同时订阅同一讨论的情况。一个 Worker 退回消息，不代表其他 Worker 都放弃了处理。只要还有工单负责这条消息，就不能据此启动一轮重复评估。等到没有工单继续拥有它，才重新判断是否需要接单或交给别的任务。

讨论中的关联也有不同含义。Worker 可能关注另一个 Issue，只为读取背景；这种关注能带来上下文，但不意味着它接管了那个 Issue。相关消息不会因此扩大授权，也不会按同样方式恢复已经结束的工单。允许读取哪些信息、由谁负责处理请求，需要分别表达。

批次控制则处理消息接连到达的情况。同一个 Thread 同时最多只有一个活动评估，评估期间的新事件先留到下一轮。已经用于创建工单的事件不能再次提供重复接单依据，过期评估返回的决定也不能拿来接受新的工作。

这些约束并没有消除模型对意图的判断。它们约束的是判断发生的时机，以及一个判断可以影响哪些任务。模型仍然需要理解评审意见，但不必每次从聊天历史里重新猜测“是否已经有人在做”。

并发调度：等待期间怎样让出执行机会

多个 Worker 独立运行之后，系统需要决定何时占用资源、何时等待，以及新到的人类消息能否及时插入。只限制 Worker 的数量，还不足以回答这些问题。

一个 Worker 的模型回合结束时，测试命令可能仍在后台运行，子 Agent 也可能还没交回结果。如果立即把它视为空闲并释放执行位置，系统会继续启动更多工作，实际资源消耗就会超过表面上的并发限制。

原型把这些后台工作纳入工单的运行判断。回合结束但后台仍有工作时，继续保留执行槽位，完成事件回来后再唤醒执行器。只有后台工作也已收尾，才按等待处理。

等待人审阅则不同。代码和结果已经准备好，什么时候继续取决于人的回复。这时继续占用执行槽位，并不会让任务更快完成。原型允许交还给人时释放槽位，保留工单、会话和工作目录；用于展示结果的服务还可能继续运行，但不再按同样方式占用执行位置。

长命令也需要尽早把控制权交回来。Router 和 Worker 的专用预设会把较长的前台命令转入后台，让 Agent 在后续步骤有机会接收新消息。测试继续跑，需求方的补充说明仍然可以进入执行过程。命令完成后，再由事件推动下一轮工作。

调度还给人工消息和状态请求保留优先机会，避免所有执行位置都被新任务占满。这样做需要在任务吞吐量和交互响应之间取舍。持续启动新工作容易保持系统繁忙，但用户发来的停止、修正和追问也需要及时处理。

Worker 内部还可以拆出子 Agent，因此 Worker 数量并不等于整个系统的模型并发数。主 Session 与 Worker 可以选择不同模型，也不能直接推导出系统已经具备全局费用预算或自动算力伸缩。执行槽位管理的是任务推进机会，费用控制还要覆盖子任务和模型调用。

可靠投递：送进会话之后，还要知道模型读过什么

接收了消息、把消息送进会话、模型实际读到消息，以及根据消息完成工作，是几个不同的进度。中断恢复尤其依赖这些区别。

设想评审意见已经进入 Worker 的待处理消息队列，进程却在模型读取之前退出。恢复时如果把“已经投递”当成“已经处理”，这条意见就会漏掉。反过来，如果模型已经读过并完成修改，恢复后又把全部输入重新塞一遍，也可能重复执行。

原型会分别记录输入投递和进入会话历史的事实，并结合报告、回合结束等事件判断处理进度。消息标识在持久化历史、当前记录和待处理队列之间保持稳定，用来识别重试带来的重复投递。

尚未进入会话历史的输入，可以重新安排投递；已经读取的内容则要结合执行报告和工作成果判断。模型读过一条消息，也不能单独证明相应修改已经完成，所以恢复提示还要求执行器检查目录、Git 历史和外部 PR 状态。

第一次派工会带上标题、简报、来源事件和必要背景。重试时，如果初始消息已经存在，就主要补充新的派工安排与恢复说明。这样既能告诉模型发生了什么，也减少了重复背景挤占上下文。

不同消息还需要不同的进入方式。有些应该排进后续回合，有些需要在后续执行步骤中加入，还有些只补充背景，不必马上唤醒模型。把它们区分开，才有可能同时做到及时响应和默认静默。

这些投递动作通过同一宿主进程中的 Harness 会话能力完成。SuperAgent 负责记录业务上需要什么、当前送到了哪一步，Harness 负责会话历史与模型执行。跨越这两层时，系统需要确认持久化进度，不能只凭一次内存调用返回成功就认为恢复依据已经齐全。

重试与顺序：失败之后怎样继续，才不会扩大问题

持久化队列保住了待办，接下来的难题是判断哪些动作可以重做，以及重做会不会影响后来到达的工作。

对外发送结果时，存在一个难处理的时间窗口。GitHub 已经接受评论，本地进程却在保存成功回执前中断。恢复后，数据库看到的仍然是一条待发消息。直接重发可能产生重复评论，直接忽略又可能漏掉实际没有发送成功的结果。

Outbox 先把发送意图和回复回执一起保存，再尝试发送。恢复时，根据稳定的消息标记检查目标端是否已经出现对应评论。已有外部事实可以帮助判断下一步，但这个办法依赖具体渠道提供可查询的标识。换成另一个工具，不能自动沿用相同的保证。

创建 PR、推送代码也有类似边界。一次本地执行中断，不能直接证明外部动作失败。先读外部状态再决定是否重试，会增加查询和等待，但能减少重复创建或覆盖已有成果的风险。

同一项待办被改写时，旧执行结果怎样处理

队列中的一项操作在执行期间，也可能收到新的内容。例如，一批输入正在投递，后续消息又到达了同一工单。如果执行完成后直接删除这个键下的待办，新到的内容也可能被一起删掉。

Effects 为待执行项保存顺序和内容版本。同类型、同键的操作可以合并更新，但旧版本执行结束时，只能按自己的版本确认完成，不能替后来写入的内容作决定。

合并能减少重复唤醒与重复排队，前提是系统知道合并后保留了什么。它适合具有明确身份和状态的操作，不能把所有工具调用都当作可覆盖的同一条消息。

顺序保证也会带来阻塞

同一项工作的报告如果乱序到达，人可能先看到“已经完成”，随后又收到更早的“仍在修改”。因此，部分报告和上下文通知需要保持处理次序。

顺序约束带来的代价是前面的失败会拖住后面。原型中的部分队列采用有序处理，队头失败时，后续同类输入也会等待。运维时需要检查最老待处理项和失败原因；仅看队列总长度，很难发现一项反复失败的操作正在阻碍多少工作。

对外回复还要区分目标暂时不可用和永久失效。来源暂时关闭时可以等待，讨论已删除或不再被监听时，则应记录丢弃原因。同一讨论中的后续回复优先等待前一条，但也需要避免一次发送故障让后续沟通无限停滞。

自动恢复需要知道什么时候停止重试

临时网络错误可以退避后再试，账号权限错误通常需要人修复配置，缺少环境信息则要先补齐。对这些失败采用相同的重启策略，只会反复撞上同一个问题。

原型把评估超时、准备目录失败、投递失败和执行受阻分别记录。评估重排有次数限制，消息发送保留回执，受阻工单暂停自动输入唤醒，同时保留人的直接干预。这样，恢复失败本身也能成为可见状态。

人工停止尤其需要与故障区分。停止代表人撤回了继续执行的意愿，不能因为巡检发现任务没有运行，就把它当作异常重新拉起。外部巡检会检查人工停止标记，再决定是否恢复服务。

可观测性：让人看清一项工作为何走到这里

默认静默减少了通知，却也意味着人不会一直看着执行过程。等人需要介入时，系统要能说明这项工作从哪里来、依据什么被接受，以及当前具体卡在哪里。

只展示模型输出不够。聊天记录里可能写着“开始修改”，但实际派工还在排队；也可能已经生成回答，回复却一直没有送达。业务状态、执行状态和投递结果需要各有证据，面板才能把问题放在正确的位置。

SuperAgent 保存事件的处理去向、接单决定、订阅关系和派工记录。操作者可以沿这些关系回看，一条消息是被过滤了、交给某个 Worker 了，还是因为超出范围被退回。来源健康和执行器负载则帮助区分任务问题与运行环境问题。

面板上的阶段依据工单事实计算。有具体问题就显示等待回答，交付物就绪则等待审阅，输入发送失败则显示投递问题。另行维护一份独立的界面状态，反而容易在异常路径中与实际工作脱节。

任务结束也需要读这些事实。PR 关闭之后，如果还有恢复中的工作或已经接手的后续请求，工单不能跳过它们直接结束。评审结果和模型回合只是判断依据的一部分，任务是否完成还取决于它已经承担了哪些责任。

启动过程同样存在这种差别。管理页面可以先开放，让人补充配置，但只有账号、仓库等检查通过后，运行时才开始正常处理任务。面板可访问、执行器可运行和某一项工作已完成，分别对应不同的状态。

这里的可观测性服务于具体干预。人需要决定是补配置、重新评估、重试执行，还是停止任务。能追溯这些事实，默认静默才不会变成出错之后也没人知道发生了什么。

扩展到其他任务，先定义什么算同一件工作

这些机制要复用到巡检、告警或其他业务，首先需要确定事件和讨论怎样组织。外部系统不断产生信号，如果每条信号都建立新工单，持久化和重试只会让重复工作保存得更完整。

以测试环境健康检查为例，可以按环境与故障特征，把重复出现的告警归到同一段讨论。已有任务仍在诊断时，新结果继续提供上下文；故障范围发生变化，再判断是否需要新的授权。这里的事件标识和讨论划分，直接影响后续去重、消息归属与任务恢复。

来源接入还需要提供按需读取背景的能力。初始候选保留足以判断是否介入的信息，日志、指标和配置由执行器进一步获取。把全部历史都塞进模型上下文，会增加接单成本，也更难分辨哪些内容与当前工作有关。

接着才能定义允许自动处理的范围。只读诊断、可逆修改和需要人工批准的操作，可以使用不同规则。工单负责保存这次工作获得了什么授权，结果渠道负责把诊断或交付物送回提出问题的地方。

公开原型的部署检查和执行环境仍围绕单个 GitHub 仓库，这些依赖需要随场景调整。若再把执行器迁到远程机器，还会遇到连接断开后的所有权问题。旧执行器是否仍在工作，取消指令是否收到，新执行器能否接手，都需要明确协议。

任务租约、取消确认、输入序号和成果回传因此成为新的设计内容。扩展接入渠道可以复用现有工单结构；扩展执行位置，还要处理网络分区下同一项工作由谁继续执行。