持续在线

单任务智能体已经能用工具把一件复杂事做完，人不必逐步盯着。一直在线、同时推进多件事，是另一套系统。下面按 DeepSeek Harness 团队的架构笔记压缩：Super-agent 设计探索：迈向更自主的 Agent 系统。原文声明这不是产品功能介绍。文末的 dsh-superagent-prototype 只用来验证路线。

他们把这种形态叫 Super-agent：一个跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。个人助手只是其中一种应用，研发协作是同一种约束。

四个特征为什么单循环撑不住？

• 连续：人在即时通讯、GitHub 评论这些本来就在用的界面里说话，感觉始终只有一个智能体。先在聊天里定方案 A，再在拉取请求评论里改成方案 B，它要能改方向。不用去想「那句话在哪个会话」。
• 高效：响应要快，多个复杂任务还要并行。上一条还没做完，下一条指令就得能接。
• 主动：驱动它的是环境事件，不是人逐条键入的提示。群聊、邮件、日程、审查评论、CI 结果都是触发。该处理就推进，不该插手就安静。没人点名，也可以自己定位问题并提交修复。
• 持久：直接接入真实工作环境，长期运行，异常能自己恢复。机器休眠不能等于它停机。

一个同步的 ReAct 循环四件一起做不到。笔记把支撑它们的框架收成五块：双层架构兼顾连续和并发，事件驱动负责主动，面向人的信道负责交互，计算、状态与环境分开，再加上主系统外面的 Watchdog，负责跨设备在线和异常自愈。具体实现会有变体。计算机系统里的经典办法在这里反复出现：快路径和慢路径、批处理、缓存式的上下文、投机执行、存算分离、外部控制回路。

会话不该是人的认知负担。让人自己管理会话，多半是底层模型接口把会话暴露成产品之后留下的惯性。会话在现有产品里同时充当上下文容器和项目管理；两者解开之后，给人看什么任务、在哪个界面里协作，是单独的产品问题。

路由层和执行层怎么分？

连续性要和吞吐量拆开，不能两头都押在同一种会话上。

每条事件都进同一个会话，上下文最连续，但单个循环串行，吞吐低，多件事的中间细节还会搅在一起。每条事件都新开一个会话，并发最高，任务之间一旦有关联，结果就割裂，还会有好几个会话同时对人说话。

拆法是逻辑职责，不是「每层只能有一个会话」：

• 路由层常驻，承接所有入口的人话。跨任务的信息和决定在这里汇总。它是全局的序点、协调点和记忆。它不执行具体任务，甚至可以不配 Bash 一类执行工具，免得自己变成瓶颈。实践里这一层往往没有想象中重，较轻的模型就能兼顾速度和效果。部分逻辑也可以不调用模型。
• 执行层的各个会话上下文隔离，挂完整工具，各自做一件事，通常用最强的模型。它们不直接对人说话，推理和工具调用留在内部，只向路由汇报。路由统一回复。同层执行会话一般也不互相通信。冲突常出现在同一个拉取请求这类共享环境里：都订阅了对应话题，就会收到同一条事件，有机会自己发现冲突。少数跨任务协同才由路由中转。复杂的单任务在执行会话内部还可以再开子代理或一个小团队，对路由透明。

这和常见的智能体团队侧重点不同。团队用来拆一个耦合很紧的任务，主管要懂细节并高频协调。路由只处理任务之间的高层关联。如果用提示词约束主会话不自己执行，只对外并把不同任务派出去，那个团队也可以看成同一种双层。不给路由执行工具，是把这道约束放进结构里，而不是放进临场判断。

路由不必是吞吐瓶颈的那个样子。上一轮推理期间到达的事件会积压，下一轮合并处理。事件平稳时逐条进，延迟低。事件密集时，多条触发合成一次调用：这一步通常是长输入、短输出，预填充并行算，耗时涨得比批大小慢，所以单个决定摊到的推理时间会下降。上限是窗口长度，以及模型一轮能看准多少条触发。订阅直通和按引用召回进一步减轻路由的负载。笔记里的团队规模，一个常驻路由会话已经够用。

再大就要在路由内部做多层过滤，或水平切成多份会话。切得越细，吞吐越高，分片之间的记忆越断。全局记忆没解决之前，这道权衡一直在。

事件怎么过滤，又怎么不每次都过路由？

接入真实群聊和代码平台之后，事件是高噪音、低触发率。每条都叫大模型从头判断，延迟和算力都扛不住。

先走快路径：用来源、群组、人或机器人白名单这类已经稳定的条件做准入。不同来源可以规定成「只响应明确请求」「先当候选」或「直接忽略」。慢路径才把候选交给模型，用提示词里的策略和上下文决定要不要行动。提示词是给人改策略的扩展点。

过滤之后还有第二道快慢路径。新任务的冷启动和跨任务协调仍走路由。归属已经清楚的后续事件，由程序直接发给对应的执行会话。

同一条拉取请求、同一个即时通讯话题、同一封邮件往来，是一条 Thread。路由根据初始事件创建执行会话后，该会话订阅这条 Thread。

• 已订阅：后续事件直通，不再让路由调用工具转发。事件超出当前任务，执行会话可以退订，或交回路由重派。
• 未订阅：路由仍能看见事件、掌握全局，但只判断和分派还没人认领的新事件。

订阅是多对多。一个执行会话可以订多个相关话题，一个话题也可以被多个执行会话订。交集出现时，新事件同时直通给所有订阅者，它们不用点对点通信。输出侧，关键结论仍回到路由，由路由对人说，并同步全局记忆。

窗口里放多少，是下一件事。近期会用到的邻近信息内联进去，低频全文只留引用，再沿触发、话题、执行会话的 ID 按需跳。做法记在窗口预算和上下文组装里。主动还有一种更进一步的用法：结果还不确定会不会被采纳，就先在后台做，有价值再交付，没有就丢，人不等的时候它保持安静。

不同信道为什么不能用同一张嘴？

双层已经保证跨信道的上下文还在同一个人设上。交互还要再解决两件事。一件是后台的耗时操作不能堵住前台：耗时工具改成异步的启动和停止，当前这一步结束后就能接新指令。另一件是输出要匹配信道的带宽。

执行会话里的长推理和密集工具调用不能原样进群聊，否则多人协作会过载。对外只有路由。在此之上按信道写交互规范：

• 即时通讯：低打扰。像同事一样，只在要决策或要验收时出声，只问直接问题，给短结论。他们验证过的一条硬规定是单次回复不超过 100 词。
• GitHub、邮件、文档：结构化、信息密度高。创建或更新拉取请求时按项目规范写清背景、改动和验证；个人助手场景则是起草邮件和文档摘要。

以聊天窗口为中心，有一部分是路径依赖。交互可以发生在领域自己的界面里，例如直接在 Issue 和拉取请求上工作。界面上也可以为了习惯保留「一个会话」，但人看到的一个会话，底下不必是一个 Session。

模型还没强到全程不用人的阶段，很多任务中途仍要人插手。怎么同时保留对关键细节的逐步干预，和后台自己往前推进，笔记留作开放问题。人需要的项目管理方式跟领域和个人习惯绑在一起，最终多半是高度定制的。

机器休眠之后，循环还在哪？

本地智能体默认把三样绑在同一台设备上：推进循环的计算、要持久保存的会话状态、代码仓库和本地工具链。设备休眠或离线，它就停，也碰不到别的机器上的环境。

第一刀，计算和状态分开。循环放进云上无状态的弹性容器，会话等状态放进数据库。容器可以扩、可以换，连续性靠存储。这样才脱离单台电脑的生命周期。

第二刀，循环和执行环境分开。模型要的上下文很大一部分来自仓库、本地文件和依赖服务，广义的上下文包含环境本身。把环境克隆上云，会漏掉未提交的修改、私有凭据、内网依赖和特定工具链，成本高还容易漏。要求人放弃本地、整套迁到云上，迁移成本又过高。

所以环境留在原地。端侧只放一个不保存会话的轻量 daemon，负责执行命令并返回结果。云上的循环按需来读。这同时容得下人自己的开发机或个人电脑、云上托管的机器、以及按需创建的环境。一个智能体可以按任务换执行设备。设备间歇在线也行：那台机器重新上线后，再把必须在上面做的事补完。

这和「脑在云上、手在环境里」是同一刀。差别是手首先是会休眠的个人机器，上面有未提交的修改和本地凭据，不只是托管服务里按需创建的沙箱或客户网络里的资源。

这套连接默认云端和端侧互相信任。循环一边吃外部环境事件，端侧一边放着私有代码、敏感数据和凭据。云端被入侵或被提示词注入带偏之后，连着的端侧设备都有被控制的风险。即便云端没被攻破，凭据只要进了模型上下文，正常执行也可能泄出去。所以还要有一种用法：智能体能使用凭据，但全程碰不到凭据本身。这件事没解决，它就只适合很小、且可信的范围。

持久在线还有一条在主系统外面的检查回路。进程还活着，不等于任务没在空转。那一层看进展和偏离，记在「做完再检查」。

这套简化盖不住的是什么？

当前能以较低复杂度跑起来，是因为做了简化：单个常驻路由、订阅直通、执行会话之间不直接通信。盖不住的时候，笔记自己列出这些缺口：

• 路由何时水平切分、切多细，执行会话何时要直接通信、用什么拓扑，都还没有定论。路由上的事件判别、批量分派和上下文召回，可以之后再跟模型一起设计，甚至专项训练。
• 引用图解决的是近期任务还能按需找回。跨月以后，长程记忆才是扩展瓶颈。
• 会话从界面上消失之后，任务怎么呈现、人怎么在中途接手，还是产品问题。
• 组织变大时，先划上下文边界：要共享的范围共用一个实例，必须隔开的范围各自一份。隔开之后，个人助手和团队实例之间才是跨边界协作。双方不共享底层上下文，也代表不同的权限边界。
• 安全和隐私若没有对应机制，触发面一宽，这套架构就不能离开小的可信范围。