三到五个会话之后，多任务卡在注意力
一个人同时照看活跃会话，DeepSeek Harness 团队自己的经验是 3 到 5 个。再往上加，人就要在窗口之间来回切，记住每一扇聊到哪一步、缺了哪段上下文。单次任务还受模型能力限制，多任务受注意力限制。
给本地的单会话 Agent 加上命令行、MCP 或外部连接器，它能收到外面的消息，三件限制还在。长操作会堵住这一个同步会话。不同任务的上下文混在一起。电脑休眠或断网，任务停掉。维持这种接法，要花很多手工。
团队要做的系统叫 Super-agent（超级 Agent）。它是一个连续的实体：上下文跨会话保留，多件复杂任务同时推进，任务之间不互相干扰。内部已经有一个跑在 DeepSeek Harness 上的实例，同一件开发可以横跨即时通讯和 GitHub。群里有人要求正文、代码和终端的字体分开设置，维护者 @ 这个 Agent 之后，它开出 Pull Request。后来又要求字号也分开、多余设置收进可折叠控件、并且从字号那一行直接展开。这些意见都改在同一个 Pull Request 里，合并后再回到群里说一声。
没人 @ 它的时候，它也会看公开群里的反馈，自己找原因，并开出修复用的 Pull Request。
Super-agent 有四个基本特性。
- 连贯（Continuous）。人在已经在用的地方找它，比如即时通讯和 GitHub 评论，感觉始终是同一个 Agent。群里先定了方案 A，后来在 Pull Request 评论里改成方案 B，它要听懂，并改正在做的事。
- 高产（Productive）。响应要快，几件复杂任务并行，每件都做到该有的标准。上一条指令或任务还没结束，就能接下一条。
- 主动（Proactive）。它不等人一步步下指令。它监听环境里的事件，值得处理就动手，其余时候保持安静。
- 常驻（Persistent）。它一直在线，直连真实的工作环境，长时间运行里的异常能够自己恢复。
这四点是架构目标。DeepSeek Harness 已经提供的功能，仍以产品自身的范围为准。
单独一个 ReAct 循环（按思考、行动、观察一步步往下走）给不齐这四点，得靠外围架构。个人 Agent 和软件开发用的 Agent，目标同为常驻、并发响应环境事件时，结构会接近。建造时遇到的问题，也和计算机系统里研究了很久的问题接近，不少经典设计可以直接拿来用。
具体实现会变，五个模块构成基本框架。两层架构同时提供跨渠道的连贯，以及任务之间的并发。事件驱动让它主动。全双工、多渠道的交互，让每一次跟人的交流既连贯又高产。计算、状态和环境分开，再加上外部的 Watchdog（看门狗），让它跨设备一直在线，并能自己从异常里恢复。
Router 只派活，Worker 各自隔离执行
既要跨渠道连贯，又要多任务并发，会话一组织，连贯和吞吐就互相顶住。所有事件进同一个会话，上下文最连贯，因为这一扇看得到全部。ReAct 一次只走一步，长任务把吞吐量压低，不同任务的中间过程还交错在同一段上下文里，结果变差。每个事件新开一扇会话，并发上去了；任务并不完全独立时，没有共享的全局上下文，结果是散的。好几扇会话各自回复，交互也会乱。
两层是逻辑上的分工，每一层内部不必做成单会话。长期存活的 Router 层（路由层）负责全部人机交互和全局协调，保住连贯。上下文互相隔离的 Worker 层（工作层）高并发地执行任务，提供吞吐。
Router 接收每一个入口的人机交互。跨任务的信息和决定都汇到这里，所以它是全局的序列点、协调点和记忆。为了不让这个单点变成瓶颈，它自己不执行任务，只跟人沟通、把任务派出去，甚至可以完全不配 Bash 这类执行工具。
一层调度、多层执行，样子和常见的 Agent Team 接近，两边盯的事情不一样。Agent Team 通常把一件复杂任务拆成步骤。步骤之间耦合紧，队长要吃透任务、拆子任务、频繁协调，推理负担重。Super-agent 的 Router 只做高层派发，并记下任务之间的关系，不拆单件任务内部的步骤。Agent Team 也可以按这两层来用：提示词把主会话限制在对外沟通和派发，成员独立完成各自分到的任务。团队的经验是，Router 的工作常常比预想简单，更轻的模型通常就够速度和质量。
Router 内部也不必是单会话，有些逻辑可以不用模型。他们选了最直接的做法：一个长期存活的模型会话。环境事件在一轮推理期间排队，下一轮一起处理，这就是批处理。到达平稳时，触发事件一个个进来，响应快。事件突然变密、开始在 Router 前排队时，上一轮积下来的事件会自动合并，一起注入下一次模型调用。Router 每一步通常是长输入、短输出。合并进同一次调用的事件在预填充阶段并行计算，单次请求变慢的速度低于批大小增长的速度。积压大到一定程度，摊到每次决策上的推理时间反而更低。上限取决于上下文有多长，以及模型在一轮里能准确处理多少条事件。以他们现在的团队规模，再加上订阅直通和召回链，一个常驻 Router 会话已经够用。真的跟不上时，Router 内部可以做多级过滤，或水平拆成多个会话。拆得越细，并发吞吐越高，分片之间共享的记忆和上下文越少。
Worker 的每个会话是一个执行单元，上下文和工具链独立，只做派给它的那一件。代码改动和分析的质量出在这里，所以通常调用能力最强的模型。Worker 不直接对人或公共渠道说话。推理、报错和工具日志留在会话内部，只向 Router 汇报阶段状态和最终结果。人在群里或 Pull Request 评论里看到的，是 Router 整理之后的回复。一件任务特别复杂时，Worker 还可以再开子 Agent，或自己成为一个 Agent Team，上层的 Router 不必看见这些内部结构。个人 Agent 通常只有一个聊天页：页面维持对话连贯，后台可以按话题各派一个 Worker，并行推进任务、起草回复。
两层接手之后，上下文管理和并发执行由系统承担，人很少再去想有几扇会话，面对的始终是同一个 Super-agent。让人手动管理会话，很大程度是从底层模型接口留下来的设计习惯。会话应当是系统的实现细节。现有设计里，会话同时干两件事：管理模型的上下文，又充当人管理项目的单位。产品和底层会话脱开以后，项目管理可以不再跟着会话边界走。界面上怎么呈现任务，留到后面单独说。
闲聊先被代码挡掉，跟进消息直通 Worker
要让 Super-agent 主动，先换掉驱动它的东西。主要输入不再是人在会话里逐条打的提示词，而是环境里的半结构化事件。群消息、邮件、日历提醒、代码评审和持续集成结果，在这套设计里都叫 Trigger（触发事件）。它监听并响应这些事件，不必像单会话 Agent 那样，每次运行都等人先下命令。
接到真实群聊和代码平台之后，事件流很吵，真正要行动的比例很低。每条都交给大模型从头判断，延迟和算力都扛不住。他们把模型推理当作灵活但贵的慢路径，把频繁、明确、稳定的判断写成确定性代码，当作低延迟、低成本的快路径。
代码先做准入：看来源、所在的群、用户或机器人白名单。每个来源可以设成只响应明确请求、当作候选事件，或直接忽略。大多数无关消息在调用任何模型之前就被丢掉。通过代码的候选事件才进入慢路径，由模型根据上下文和写在提示词里的准则，决定沉默还是行动。这一段也是自然语言入口，人可以随时用提示词打开、关掉或新增一条准则。
全局 Router 保住跨渠道的连贯。已派出去的任务如果每条后续消息还要再过一遍 Router，这个单点还是会被拖慢。所以过滤之后的路由也分快慢：Router 只处理新任务的冷启动和跨任务协调；跟进事件由代码直接送给负责的 Worker。
真实协作里，同一条 Pull Request、同一个即时通讯话题、同一封邮件的来回，自然连成一条事件流，称为 Thread（线程）。Router 为一条线程的第一条事件创建 Worker，并让这个 Worker 直接订阅该线程。此后已订阅的跟进，像已经认领的工单，不再经过前台转手：代码把后续事件直通给订阅者，Router 不必再调用一次工具来转发。新事件超出当前任务时，Worker 可以退订，或交回 Router 重新派发。还没有订阅者的新事件走慢路径，由 Router 评估和派发。Router 仍然看得到事件，用来跟踪全局状态，但只对还没人认领的新事件做判断。
线程和 Worker 的订阅是多对多的。一个 Worker 可以订阅几条相关线程，一条线程也可以有几个 Worker。它们的工作环境或讨论重叠时，共享线程里的新事件会同时直通给全部订阅者。Worker 因此有机会看见别人在做什么，并自己处理冲突，不必再点对点通信。对外仍由 Worker 把关键结论汇报给 Router，由 Router 回复用户，并保持全局记忆同步。
窗口只留马上要用的，确认前可以先做
事件过滤并送到目标会话之后，还要决定往模型的上下文窗口里放多少。输入不再是有限的几条人工提示，而是环境持续产生的半结构化事件。塞得太多，窗口被占满，模型的注意力被冲淡。塞得太少，模型就得反复调用工具去读上下文，执行步骤变多。
有限的窗口可以当成缓存，放进去的动作分成两种。Inline（内联）把马上可能用到的信息直接放进当前窗口，省掉额外的工具往返。Spill（外置）在内容超出预算或很少用到时，把全文留在窗外，窗口里只留引用或摘要，模型需要时再按这个引用去读。
结合局部性，注入可以一步步加。一开始只给当前对象的编号和内容摘要。接着内联紧密相关对象的编号，再加空间或时间上相邻的内容，例如正文的前 50 个字、一条即时通讯消息前后的消息和它回复的那一条、同一次代码评审里相邻的评论。超长内容设一个较小的长度上限，超出部分外置。简单的做法是截断，并留下继续阅读的位置，模型需要时再调用工具把后面读出来。
Router 还有自己的上下文问题。很多跟进事件已经直通给 Worker，长期运行后又积下过去的任务，它不可能把每件任务的完整历史都留在窗口里。用户换一个渠道重新提起旧任务时，它又必须把那件任务的上下文找回来。每种对象都按内联和外置来处理，就得到一条按需、多跳的取回路径，称为 Chain of Recall（召回链）。Trigger、Thread 和 Worker 会话都有唯一编号，注入一个对象时，把紧密相关对象的编号也内联进去，这些编号连成一张引用图。通过工具召回的结果，同样内联下一跳对象的摘要和编号。模型从当前事件出发，沿着引用一跳一跳取，取到够用为止。比如从当前消息的线程，顺着内联编号找到相关的 Worker 会话，再找到这个 Worker 连着的另一条代码评审线程。
他们还借用了计算机系统里的推测执行。根据环境里的信号，结果还不确定会不会被用，Agent 就先在后台做起来，用额外的后台算力减少人的等待和插手。后来证明有用的结果交付出去，其余丢掉。
个人场景里，会议邀请或待办消息到达后，Agent 可以在后台检查日历冲突、整理背景资料并起草回复，人只需要看过再发出。研发上也一样。DeepSeek Harness 的内部用户群配置了「静默复现并修复」：有人报告问题或讨论一项改动时，Agent 先在后台尝试复现并寻找修复。确认问题确实存在，而且修复简单，它才交付结果。否则全程不说话。
长任务改成异步，回复按渠道收短
两层架构保住的是跨渠道的上下文连贯。日常交互要同时连贯和高产，还得解决两件事：耗时的后台操作不能堵住前台对话，以及不同渠道里该说多细。
经典 ReAct 里，模型同步调用 run()，循环会一直等到工具跑完并返回最终结果。在这之前，会话无法响应用户的新输入。他们把耗时的命令和工具调用换成异步的 start() 和 stop()。start() 立刻返回「已启动」，循环不再等工具。工具在后台结束后，系统把最终结果当作一条新的事件消息送回会话。模型也可以根据上下文调用 stop()，停掉跑得太久的后台命令。前台对话和后台任务分开之后，耗时任务还在跑，Agent 也能回应人。新输入在当前这一步推理结束时就处理，不必等到后台工具全部结束。DeepSeek Harness 已经实现这套异步任务机制，默认尚未打开。
群聊、邮件和 GitHub 讨论里，人的说话方式不一样，Agent 要按渠道调整详略。详细推理和工具调用日志适合单人终端；原样贴进群聊，会把其他人淹没。两层架构已经挡住一部分：每件任务啰嗦的推理和频繁的工具调用留在 Worker 会话里，不直接发到外部渠道，外部交互全部由 Router 处理。除此之外，系统还要连上人每天依赖的工作环境，并用提示词为每个渠道规定交互方式。
- 即时通讯。沟通保持轻，尽量少打断人。像一位同事那样，只在需要决定或签字时才通知，只问直接的问题，先给短结论。他们验证过一条简单的硬规则：每条回复不超过 100 个词。
- GitHub、邮件和文档这类异步渠道。输出要结构化，信息要密。创建或更新 Pull Request 时，按项目惯例写清问题背景、改动说明和验证结果。个人 Agent 场景里，也可以直接起草结构化邮件和文档摘要。
计算放在云端，环境和看门狗留在外面
本地 Agent 默认把三样东西绑在一台设备上：跑 Agent 循环的计算、必须持久保存的会话状态，以及代码仓库、本地工具链这类执行环境。设备休眠或断网，Agent 就停，也够不到其他设备上的环境。要让 Super-agent 一直在线，并连上任务真正需要的环境，他们分两步解开这三样东西。
第一步，把计算和会话状态分开。跑循环的计算可以没有自己的状态，只有会话状态必须留下来。计算放进无状态、可伸缩的云端容器，会话和其他持久状态放进数据库。容器可以扩容、重启或换掉，持久存储保住会话和任务的连续性。本地设备休眠或离线，不再把 Agent 停掉，它在云端继续在线。
循环和会话进了云端之后，还要解决怎么碰到任务需要的执行环境。模型用到的很多上下文，来自对代码仓库、本地文件和依赖服务的工具调用。广义上，上下文本身就包括执行环境。常见有两条路。一条在云端开沙箱，把代码拉过去，试着重建并同步环境。真实环境里常常有未提交的本地改动、私有凭证、对内网服务的依赖，以及特定的硬件或工具链。全部同步又贵又容易漏。另一条让人放弃本地环境、把工作搬到云端，对很多人来说迁移成本太高。
难复制的是环境本身，就不必把它和 Agent 循环一起搬进云端。第二步把循环留在云端，把重状态的执行环境留在原地。每台终端只需要一个轻量守护进程：它不保存会话状态，只执行命令并返回结果。环境留在云外，Agent 按需去读上下文。这样一来，Agent 不再绑在一台机器上，可以按任务切换执行设备，在需要的环境里跑命令、读上下文。设备只是断续在线也可以：个人设备重新连上时，云端 Agent 自动开始并完成必须在那台设备上跑的任务。
Anthropic 的文章《Decoupling the brain from the hands》走的是同一类拆法：Harness 保持无状态，会话日志存在外面，执行环境通过统一接口按需接上。两边的场景不同。Anthropic 写的是托管服务，主要讨论按需创建的沙箱和客户专有网络里的资源。DeepSeek Harness 首先要接的是人每天使用的个人电脑，上面有未提交的改动和本地凭证，而且可能时断时续。所以这套设计支持 BYOM（Bring Your Own Machine，自带设备），把用户自己的开发机或个人电脑接到云端 Agent，同时也支持云端托管的机器和按需创建的计算环境。
一直在线，还要能在长期运行中自己从异常里恢复。只靠系统内部逻辑，长期在线的分布式系统很难一直可靠，主系统外面需要一条独立的控制循环。传统的进程探活盖不住 Agent 的异常。进程还在，模型却可能陷在没有进展的循环里，或者偏离了目标。长时间运行的 Agent 既要看基础设施是否活着，也要看任务有没有往前走。
他们的外部控制循环是一个独立的 Watchdog 会话，跑在主系统外面，由定时消息驱动。它处理 API 错误、状态恢复失败这类基础设施故障，也用模型判断每个 Worker 是在取得实质进展，还是在偏离总体目标。异常要及时修，暂时的外部故障要反复检查，直到解决。Watchdog 本身是一个带完整工具的 Agent 会话，维护者可以用自然语言问它为什么失败，也可以在系统运行中纠正主系统的行为，例如增删提示词或调整触发规则。
合成负载里，架构比提示词更稳
初步实验分两层：整套系统的调度和路由，以及 Router 自己的批处理。实验用的是合成负载和简化环境，有些设置还可以更严，结果只作参考。
端到端比较了两层架构和单会话，并看了订阅直通的作用。四种设计同时跑，输入是群聊和 GitHub 持续集成消息。每轮大约 300 条消息，其中大约 20 条是工作请求，其余是闲聊、跟进、取消和持续集成消息。写代码被一个只消耗时间的工具代替。这组数字比较调度和协调。每种设计跑 5 次。任务完成时间从工作请求算到结果消息。缓存读取 token 按每轮全部会话合计。
四种设计是：完整 Super-agent，去掉直通的 Super-agent，以及两种「单会话加子 Agent 工具」。中立提示词是「合适的时候把一块工作交给子 Agent」。强委派提示词是「聊天里的每条消息都会到你这里，自己干会被新消息打断。优先把每块工作交给各自的子 Agent，自己只做小事」。
完整 Super-agent 的任务完成时间，p50 是 12.4 分钟，p95 是 15.7 分钟，每轮缓存读取 23.2M token。p50 表示一半任务在这个时间内完成，p95 表示 95% 的任务在这个时间内完成。去掉直通之后，p50 是 12.6 分钟，p95 是 15.5 分钟，缓存读取升到 31.8M。中立提示词的单会话是 20.4 / 29.5 分钟、6.1M。强委派提示词的单会话是 13.8 / 29.0 分钟、10.8M。
单会话在这组实验里很依赖提示词，主会话常常决定自己把活干了，完成时间又长又不稳。中立提示词下，5 次都没有调用子 Agent，工作全在主会话里，新消息不断打断，p95 到了 29.5 分钟。强委派提示词下，5 次里有 4 次做了委派，完成时间有所下降，整体仍长于 Super-agent。剩下那一次，模型判定工作「很小」，自己做了，图上那条紫色长尾就是这次拉出来的，曲线一直拖到接近 50 分钟。单会话要靠提示词和模型当场的判断来决定委不委派。两层架构把这件事做到系统里：Router 自己不执行，每个 Worker 只收到自己订阅的线程上的消息。
Super-agent 维持多个独立会话，每轮缓存读取 token 多于单会话，换来的是更短、更稳的完成时间。去掉直通之后，任务完成时间和完整方案差不多，但 Router 每轮的决策大约多 30%，缓存读取从 23.2M 升到 31.8M，大约多 37%。在这组负载下，直通没有让任务完成得更快或更好，它明显减少的是 Router 会话的 token 和推理开销。
第二组实验只压 Router，看这种批处理能撑多少。Router 调用真实模型，Worker 使用模拟模型。需要决策的触发事件，到达率从大约每分钟 1 次逐步提高到大约 40 次。每个速率上记录平均批大小、单次请求时间和摊到每次决策上的推理时间。一次决策可能跨好几次模型请求，因为派发之前可能要多步推理，或通过工具召回上下文，所以单次决策的时间可以长于单次请求。
到达率从大约每分钟 1 次升到 40 次时，平均批大小从 1.0 增到 2.8。单次请求时间只从 2.5 秒增到 3.9 秒，慢于批大小的增长，摊到每次决策上的推理时间从 6.4 秒降到 1.6 秒。外部事件突发时，Router 把积压的事件自动合并，提高有效吞吐。这也能解释上一组实验：去掉直通提高了 Router 的峰值负载，单个 Router 仍然没有顶到吞吐上限。以他们现在的团队规模，不必为了吞吐过早拆分 Router，以免丢掉全局上下文的连贯。
四件还没定，公开原型只覆盖一部分
多任务并发时，核心的调度和路由在这组实验里能工作。系统目前可以保持相对简单，因为工程设计和支持的场景都做了简化。简化之外，有四件事还没定。
两层架构怎么扩大。一个长期存活的 Router 会话、订阅直通、Worker 之间不直接通信，以较低的工程成本覆盖了他们目前大多数日常任务。任务变得更大、耦合更紧，一个 Router 会话兜不住时，每一层该长成什么样还没定。Router 何时分片、分多细，对等的 Worker 何时直接通信、用什么协作拓扑，都还要更多场景来试。系统和模型一起设计是另一个方向：专门为 Router 的工作训练模型，例如判断事件、批量派发、召回上下文，有可能进一步提高吞吐和决策质量。记忆也会限制规模。长期存活的 Router 加上引用图上的召回链，主要解决近期任务和会话历史的按需取回。系统跑上几个月或更久，长期记忆会变成主要瓶颈。
没有会话之后，人怎么工作。两层架构把多会话管理藏了起来，会话不再是产品设计的中心。底下的执行会话不再直接对应界面上的一段对话之后，任务怎么呈现给人、什么样的交互和项目管理才自然，就成了新问题。聊天窗口成为中心，有一部分是路径依赖。更多交互可能会移到特定领域的界面上，他们的 Super-agent 实例就是直接在 GitHub Issue 和 Pull Request 里工作。会话也可以因为人习惯了而留在界面上，但人看见的一段对话，不必对应底下一个会话。任务开始和签字时怎么跟人打交道，前面已经有安排。模型还在快速变好的这段过渡里，很多任务中途仍然需要人。产品怎样让人在关键细节上一步步介入，同时保住后台自主工作的效率，也值得继续试，例如在后台执行的任意时刻介入、接管，或和 Agent 一起实时工作。人需要的项目管理和交互，很依赖工作领域和个人习惯，最终设计很可能高度定制。DeepSeek Harness 的架构是开放的，这种定制更容易接上去。
上下文边界和 Agent 之间怎么协作。单个 Super-agent 实例假设自己范围内的信息都收进一个全局上下文。使用从个人和小团队扩大到更大的组织时，怎么配置 Super-agent，实际上就是在决定哪一段上下文共享、哪一段隔离。需要共享上下文的部分共用一个实例，需要隔离的部分各自一个实例。组织内部或组织之间出现隔离的实例之后，跨过边界的协作就是 Agent 对 Agent 的通信，例如每个成员的个人 Agent 和团队共享的 Super-agent 之间。这里的 A2A 泛指 Agent 之间的通信，不特指某一种协议。这些 Agent 不共享底层上下文，又各自代表不同的权限边界，怎样安全、可靠地通信和协作，还要继续做。
安全和隐私。事件驱动让更多环境能够驱动 Agent，也让它接触更多不可信输入。安全和隐私处理不好，Super-agent 只能待在很小的、可信的范围内。把 Agent 循环放在云端，在执行设备上安装轻量守护进程，这暗中假设云端和终端互相信任。云端循环持续吃进外部事件，终端设备上却放着私有代码、敏感数据和本地凭证。两边连起来，安全和隐私风险很大。服务器被入侵，或提示词注入攻破了 Agent 循环，每一台连着的终端设备都可能被接管。即便云端从未被攻破，凭证也可能泄露：只要终端上的凭证能进入模型的上下文，正常执行就可能把它们暴露出去。Agent 需要一种用法，凭证可以用，模型却始终看不见。这套架构要更广泛地用起来，就得在保住从多种环境召回上下文的能力的同时，解决这些安全和隐私问题。
这套设计的一部分，实现在 dsh-superagent-prototype 里。这个插件只用来验证技术路线。DeepSeek 没有把它作为官方产品发布。仓库写明，它是研究代码，为了公开做过改编，和内部版本以及这套架构设计里写到的实现并不相同。其中一些设计是后续方向，这个原型里没有。公开出来的原型，是针对一个 GitHub 仓库的主动编程 Agent，作为 DeepSeek Harness 的一套插件运行。它监听 GitHub，也可以选择监听飞书。允许名单上的人提出工作后，它开一个工作项，在自己的 Agent 会话和目录里做，再回到原来的对话里答复，例如带上一个 Pull Request。一个网页面板只列出需要人处理的事。它自己的规矩是：只有被请求，或团队写成规则允许时才行动；没人要求的工作要有团队写好的规则，并且先以只记录「本来会做什么」的模式开始。它只在必须有人行动，或结果用得上时才说话。
团队内部按这些想法、基于 DeepSeek Harness 搭的实例已经在持续运行，每天帮助复现和修复问题、回应代码评审，并参与 DeepSeek Harness 自身的开发。模型在单件任务上需要的人手越来越少，多任务的瓶颈转到了注意力。系统接手会话管理和上下文同步之后，人转到决定和签字。公开仓库里能看到的，是单个代码仓库上的研究原型。15.7 分钟这个 p95 来自合成负载下的调度测量。自带设备连上云端之后的安全和隐私，仍是尚未解决的问题。
