DeepSeek Harness 把 AFK AI 的 Comma 率先实现的「超级智能体」模式正式化
Router-Worker 架构让任务耗时缩短 39%;跨越数月的记忆问题依然没有解决

一篇研究论文和一款已上线的产品,从不同方向走到了同一个设计上。2026 年 10 月 31 日,DeepSeek Harness 发布了它的「超级智能体」架构规范,描述了一个两层系统:一个常驻的 Router 负责管理与用户的关系和跨任务的上下文,而多个并行、无状态的 Worker 在相互隔离的环境中执行各自的任务。五个月前,AFK AI 已经把一模一样的结构定为其个人智能体平台 Comma 的基础。两支团队似乎都不知道对方的工作。这种殊途同归——两套独立实现得出了结构上完全一致的结论——表明 Router-Worker 拆分正在成为实用型个人 AI 智能体的共识设计模式,而不是某个产品的独特选择。
这次不谋而合的时间点,意义不止于巧合本身。2026 年,个人智能体领域已经变得很拥挤:Meta Muse、OpenAI Dots、Claude Tag、Instinct 和 Town 今年都推出了产品。它们中的大多数都没有公布过任何内部架构信息。DeepSeek Harness 的论文为这种设计方法提供了第一套正式词汇,而 AFK AI 的 Comma 则提供了第一份开源实现。两者合在一起,给了开发者和研究者一样东西——这是单靠一款封闭的商业产品或一篇理论论文都给不了的:一套有基准数据、有文档、可部署的架构,可以研究、可以 fork、可以在其上继续构建。
单会话智能体为什么会失效:人类注意力的瓶颈
Router-Worker 架构不是为了优雅而发明的。它是为了解决一个特定的限制而发明的——只有当你尝试让一个个人 AI 智能体连续运行几周而不是几小时时,这个限制才会显现出来。
单会话智能体在一个对话上下文中运行。用户打开一个会话,描述一项任务,然后等待。对于简单任务,这样还算够用。但对于需要跨越数小时、包含多个步骤的复杂任务——一边订机票、一边起草报告、一边盯着一个代码仓库——单会话会迫使用户始终保持投入:手动跟踪进度,在上下文退化时重新给智能体定向,还要通过一个个独立的对话来管理每一个并行目标。
关于工作记忆的认知研究表明,人类大约只能同时对三到五条活跃的任务流保持有意义的关注。超过这个阈值,监督开销就会吞噬掉智能体本应带来的效率提升。人成了瓶颈,智能体本身的任务完成能力反而得不到充分利用。
DeepSeek Harness 的论文明确地这样界定问题:目标是构建一个系统,让智能体能处理的并行任务数超过用户可以直接监督的数量,同时不要求用户逐一跟踪每项任务的执行状态。AFK AI 的 Comma 也是围绕同一限制设计的,在其设计文档中被表述为「一个团队,一段对话」——用户只与一个常驻的主导智能体交互,由它在表面之下负责协调。
Router-Worker 架构详解
两套实现共享四个结构要素,只是用词不同。
Router(AFK 称之为主导智能体,DeepSeek 称之为 Router)是一个常驻进程,负责维系与用户的关系。它知道用户是谁,记得跨任务的上下文,保留跨会话的对话历史,并且是用户唯一会接触到的界面。Router 不直接执行任务。它的工作是倾听用户,把请求拆解成离散的工作项,把这些工作项分派给 Worker,再把完成报告汇总成给用户的概要更新。Router 持续运行——它可以接收外部事件(一封新邮件、一条 GitHub 通知、一个日历提醒),并自主采取行动,无需等待用户发起对话。
Worker(AFK 称之为子智能体,DeepSeek 称之为 Worker)是无状态的执行容器。每个 Worker 从 Router 那里接收一项任务,以及一整套工具——文件访问、API 调用、代码执行、网页浏览,任务需要什么就给什么。Worker 运行在相互隔离的执行上下文中:它们看不到彼此的状态,也不直接通信。这种隔离是刻意的设计选择,它简化了错误处理,并让 Worker 可以在没有协调开销的情况下并行运行。Worker 完成任务后,把结果报告给 Router。接下来由 Router 决定下一步——再派出更多 Worker、向用户更新进展,或者结束任务。
并行异步执行是这套架构高效的关键。当用户和 Router 正在讨论一个话题时,之前某个请求派出的 Worker 可能还在运行——写文件、调 API,或者等待外部系统。一个复杂多步任务的实际耗时,等于最长的串行依赖链所需的时间,而不是所有任务耗时的总和——当任务确实可以并行时,这是一个可观的缩减。
四项必备属性,按DeepSeek Harness的正式定义是:持续性(Router 跨会话保留上下文,用户不必每次都重新解释自己的情况)、高效性(异步并行的 Worker 缩短完成时间)、主动性(系统可以响应外部事件主动采取行动,无需等待用户输入),以及持久性(状态存放在独立于执行环境的持久化存储中,因此系统崩溃后能恢复,而不会丢失任务进度)。
两支团队各自如何实现:Chain of Recall 与 Salix
两套实现在基础设施层出现了分歧——在这一层,两支团队各自打造了专有的机制,让这套共同的架构能够在规模化场景下实际运转。
DeepSeek Harness 描述了一种名为Chain of Recall的机制,用于在长时间运行的任务中管理上下文检索。每个 Trigger(触发事件)、Thread(一组相关任务)和 Worker(单个执行者)在创建时都会获得一个唯一标识符。当某个 Worker 需要检索更早的上下文时——比如弄清 Router 几个小时前说了什么,或者回想另一个 Worker 昨天完成的任务结果——它会沿着 ID 链逐跳查找,而不是把整个对话历史都加载进自己的上下文窗口。这种惰性的上下文加载,让跨越数百条消息、数十项任务的会话,每 token 的推理成本依然可控。它在概念上类似于数据库中的索引分页:按需要的顺序,只取需要的内容,而不扫描整张表。
AFK AI 对应的基础设施是Salix,一个专有的分布式智能体运行时,支撑着 Comma 的 Agent Loop。Salix 把存算分离作为首要设计原则:所有状态都存在数据库里,Agent Loop 在无状态的云容器中运行,请求与请求之间不保留任何会话信息。在已集成的平台——Telegram、Signal、微信、iMessage、飞书和 Slack——上,本地端点守护进程负责接收外部事件并转发给 Salix,自身不保存状态。看门狗进程监控系统并重启出故障的组件,使任务可以在不丢数据的情况下恢复。实际效果是,一个 Comma 会话可以挺过容器崩溃、网络中断和平台重启,而不会损坏正在进行的任务。
Comma 的平台集成范围,比 DeepSeek Harness 为其系统所描述的更广。AFK AI报告称,Comma 可以把 Codex 和 Claude Code 作为下属 Worker 来编排——实际上是把其他商业 AI 智能体当作 Router-Worker 层级中的专门工具,而不是竞争系统。公司还支持自带密钥(BYOK)和自托管部署,让需要数据主权的用户可以提供自己的 API 密钥,并在自己的基础设施上运行整套系统。
AFK AI 实现的第三种机制——在 DeepSeek 的论文中没有直接对应物——是一个持续学习循环。Comma 会从每项任务中记录三类信号:完成结果(Worker 是否成功?)、用户的显式修正(对 Worker 输出所做的编辑),以及隐式接受信号(未经修改就被认可的输出)。这些信号构成了一份训练数据集。公司报告称,只有当新版 Comma 模型在一个由真实任务场景构成的内部留出基准上明显胜过前一版时,才会发布。这种做法把生产环境中的任务完成情况作为监督信号,而不是使用人工整理的偏好标注——这是一个有意义的方法论差异,尽管尚未经过独立审计。
基准数据实际说明了什么
DeepSeek Harness在合成测试条件下,把它的超级智能体与单会话基线做了对比:每次运行约三百条消息,每个会话约二十个离散的工作请求。超级智能体架构完成任务的中位耗时为 12.4 分钟,单会话基线为 20.4 分钟——缩短了 39%。在第 95 百分位上,差距进一步拉大:超级智能体为 15.7 分钟,单会话为 29.5 分钟,缩短了 47%。
论文作者称这些结果是初步的,这个定性值得认真对待。合成测试条件无法反映真实个人智能体使用中的全部变数:依赖结构各异的多种任务类型、外部 API 的延迟和故障、用户的中途打断和任务修改,以及跨越数天而非单个会话的长时任务。尤其是第 95 百分位上的提升——单会话基线在这里本来就表现不佳——表明并行 Worker 更多是压缩了最坏情况下的长尾延迟,而不是提升了典型表现。这是一个有意义的结果,但比「超级智能体好 39%」这个说法要窄。
截至发稿时,还没有独立团队复现 DeepSeek Harness 的基准结果。AFK AI 的 Comma 也没有公开发表过同类基准。
一个拥挤的领域,一份开放的蓝图
2026 年,个人智能体领域已经积累了至少六款不同的产品。Meta Muse 在 Meta 生态内运行,没有公布过任何内部架构信息。OpenAI Dots 与 OpenAI 现有的模型基础设施集成;架构细节未公开。Claude Tag 在 Slack 及类似的工作空间工具中运行,是一个常驻但轻量的助手,而不是自主的多任务编排器。Instinct 和 Town 推出了独立产品,公开的技术文档很少。
AFK AI Comma 的独特之处,主要不在于功能集——而在于其设计的开放性。Comma 的架构于 2026 年 9 月在GitHub上开源,使它成为唯一一款 Router-Worker 实现可以被开发者检查、部署和修改的已上线个人智能体。BYOK 支持又进了一步:无法接受由第三方 API 处理数据的用户,可以用自己的模型密钥在自己的基础设施上部署 Comma——这是该领域其他产品目前都无法以类似形式提供的。
DeepSeek Harness 的论文带来的是另一种开放性:正式的架构词汇。在这篇论文之前,评估个人智能体框架的开发者没有一套共同的语言来描述其中涉及的结构性设计选择。论文对 Router、Worker、Chain of Recall 以及超级智能体四项属性的定义,为这个领域提供了一个参照点,让比较产品、找出缺口、评判架构取舍都变得更容易。这正是一篇研究论文能做出、而一款已上线产品做不到的贡献——哪怕是像 Comma 这样文档完善的产品。
AFK AI 的 BYOK 支持在数据管辖权上的意义,值得比产品公告给予的更多关注。Comma 的平台集成包括微信和飞书——这些服务分别在腾讯和字节跳动运营的基础设施中、依据中国法律处理用户数据。对于希望利用这些沟通渠道的跨国企业团队或中国境外用户来说,智能体的任务数据存放在哪里,就成了一个合规问题,而不仅仅是偏好问题。BYOK 自部署把数据处理转移到用户自己掌控的云环境中,绕开了平台的数据处理前提。在当前这个领域里,似乎没有其他已上线的个人智能体,能在同等的架构文档水平上提供类似的自托管路径。话虽如此,AFK AI 的部署模式默认用户有能力管理自己的基础设施——这一要求在短期内会限制它在开发者群体之外的实际普及。
两支团队都没有解决的问题
两支独立团队殊途同归地走向 Router-Worker 架构,这是一个有意义的信号。但它并不意味着个人智能体的问题已经解决。
Router-Worker 设计擅长处理的是:在一组会话中并行执行任务、在这组会话内积累上下文、崩溃恢复,以及由事件驱动的主动行动。它处理不了的是:那种让 AI 助手在几个月而不是几天的时间尺度上真正有用的记忆。这个区别很重要,因为个人智能体的市场定位——Comma 的「一个团队」说法、OpenAI Dots 的常驻助手概念、Claude Tag 的随时在线——都在暗中承诺着更接近后者的东西。架构能力与营销承诺之间的落差,正是用户未被满足的期望不断累积的地方。
一个与某人共事了六个月的人类助理,会记住对方决策中那些从未明说的模式。他们会想起三个月前的一个项目突然又变得相关了。他们知道这个人认为哪些事紧急、哪些可以等。他们会跟踪对方从未正式表达、却一贯表现出来的不断变化的偏好。这些都不是 Router 的跨会话上下文积累所能捕捉的——它保留的是对话历史,却没有构建出那种压缩的、结构化的、长时程的记忆,而正是这种记忆,才能让智能体表现得像是真正了解这个人。
Chain of Recall 机制能高效地处理会话内和跨会话的上下文检索,但它检索的是历史,而不是把历史综合成持久的知识。AFK AI 的持续学习循环会根据任务结果更新模型,但更新的是模型权重——而不是这位特定用户这段特定历史的情景记忆。「能访问以往的对话记录」与「对一个人数月来的工作、偏好和承诺有真正累积起来的理解」之间的差距依然很大,而两支团队都没有发表针对它的系统性解决方案。
这个差距,正是个人智能体领域下一场有意义的竞争将要发生的地方。架构决定智能体能否可靠地处理并行任务。记忆决定智能体能否随着时间推移成为真正有用的协作者。Router-Worker 的问题似乎正在趋于共识。记忆问题还没有得到同样专注的正式研究——这意味着,谁能率先发表一套可信、有基准、可部署的解决方案,谁就将定义这个领域的下一代架构。