智东西（公众号：zhidxcom）
作者 | 李水青
编辑 | 心缘
智东西11月1日报道，10月31日晚间，DeepSeek Harness团队公布了其关于自主Agent探索——Super-agent（超级智能体）的底层架构。
▲Super-agent开源项目地址
GitHub地址：
https://github.com/deepseek-ai/dsh-superagent-prototype
DeepSeek想做的“Super-agent”，可以通俗理解为一个一直在线、能同时干多件事、会主动找活干、出问题能自己恢复的Agent。该团队本次推出的成果并非一款新产品，而是更接近一种新思路——把计算机系统里的调度、缓存、存算分离、看门狗（Watchdog）等经典思想搬进Agent架构。
随着模型执行单任务减少人工干预，瓶颈转向人的注意力。DeepSeek Harness试图通过五大模块——双层架构、事件驱动、异步多信道交互、存算分离与外部Watchdog在底层接管会话管理与上下文同步，使人上移到决策与验收，提升Agent应用体验。
▲Super-agent整体系统架构
实验上，基于该思路的Super-agent任务有一半任务12.4分钟内完成，95%的任务15.7分钟内完成，显著优于带Subagent工具的单Session（会话）；去掉订阅直通后，Router决定数增加约30%，读缓存token从2323万增到3177万；Router批处理能把单个决定分摊的推理时间从6.4秒降到1.6秒。
这组数据意味着Super-agent在初步实验中证明了“系统层接管会话调度”的可行性。
一方面，多任务完成更快更稳，Router靠直通省开销、靠批处理扛突发；但另一方面，它是拿更多token来换取时间和稳定性，而且实验基于合成负载与简化环境，只是初步参考，不是正式产品结论。
一、Super-agent：不用切会话，一个Agent并行推进多任务
过去一年，Coding Agent等单任务Agent已证明模型能用工具解决复杂问题，人越来越少介入底层执行，角色上移到决策与验收。个人助手等持续在线、事件驱动的新形态开始涌现。
但现有Agent以单一Session为单位，多任务上限受人的注意力限制，简单扩展仍受同步阻塞、上下文混乱、设备离线即停等制约。
因此，DeepSeek Harness团队提出Super-agent：跨会话保持上下文、并行推进多任务且互不干扰的连续实体，并且已有内部实例在IM与GitHub间连续推进任务。
▲同一个任务在 IM 群聊与 GitHub Pull Request 评审之间连续推进
▲持续关注公共群聊，在无人@的情况下主动识别缺陷并提交修复Pull Request
团队认为，Super-agent具备四个基础特征：
– 连续：用户可以直接在IM聊天、GitHub评论等熟悉界面与它交互，感觉始终只存在一个Agent，不需要去想“Session X的上下文中是否有Y信息”。例如用户先在IM提出采用方案A，随后在GitHub PR评论里改为方案B，它能理解并调整执行方向。
– 高效：交互响应迅速，同时能并行、高质量完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。
– 主动：无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时保持安静。
– 持久：始终在线、直接接入用户真实工作环境，并在长期运行中遇到异常时自动恢复。
单个ReAct Loop无法同时支持上述四个特征，底层需要一套相应架构。文章认为，相似设计约束会导出相似架构选择。无论是个人助手，还是软件开发等商业场景的Agent，如果目标是构建持续在线、并发响应环境事件的系统，底层可能采用相近架构。这一过程中面临的许多问题与传统计算机系统长期探讨的问题高度相似，因此计算机系统中的经典设计思想同样适用。
具体落地会有不同变体，但文章认为五个模块构成支撑上述四个特征的基本框架：通过双层架构兼顾连续交互与高效并发，通过事件驱动实现主动响应，通过面向人的交互在交互过程中同时做到连续与高效，并通过计算、状态与环境分离及Watchdog实现跨设备持久在线与异常自愈。
二、双层架构：连续与吞吐不必二选一，一层分派、一层干活
跨信道连续交互与多任务高效并发存在根本权衡：全交给一个Session，上下文最连续，但单ReAct Loop串行、吞吐低、细节混杂；全开独立Session，吞吐最高，但缺全局上下文、结果割裂、交互混乱。
DeepSeek Harness团队的解法是把“维护全局连续性”与“高并发执行”拆成两层：常驻Router层承接人类交互与全局协调，上下文隔离的Worker层并发执行具体任务。Session应成为系统实现细节，而非用户认知负担。
▲双层架构：Router层统一负责路由与对外交互，多个Worker Session隔离并发执行任务
1、Router层：只分派不干活，靠批处理摊薄成本
Router层是常驻的全局路由层，负责承接所有入口的人类交互。所有跨任务的信息与决策都在Router层汇总，由它充当全局序点、协调点和记忆。为避免这一全局节点成为性能瓶颈，Router层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备Bash工具。
这种由一个中心节点分派多个执行节点的结构，表面上与常见Agent Team相似，但侧重点不同。常见Agent Team主要用于单个复杂任务内部的步骤拆解与角色协作，子步骤通常耦合较紧，Team Lead往往需要深入理解任务细节、规划子任务并高频协调成员，自身承担很重推理负载。而在Super-agent中，Router层只处理任务之间的高层关联与分派，无需介入单任务内部拆解。相反，如果通过提示词约束一个Agent Team的主会话不亲自执行具体任务，仅负责对外交互并将不同任务分派给各成员独立推进，也可以视为这种双层架构。团队实践显示，Router层任务常常没有想象中复杂，使用较轻量模型往往就能兼顾速度与效果。
内部实现上，Router层同样不必局限于单个Session，甚至部分逻辑未必需要调用LLM。团队选择最直接的单个常驻LLM Session作为Router层核心实现，并发现它并没有表面看起来那么容易成为吞吐瓶颈，因为上一轮推理期间到达的环境事件会积压下来、在下一轮一并处理，形成批处理，而合并处理的额外开销很小：
– 外部事件流平稳时，Trigger逐条进入Router Session，单次响应延迟较低；
– 事件密集涌入、Router Session出现排队拥堵时，上一轮推理期间积压的多条Trigger会自动合并，在下一次LLM调用中一并注入。Router Session只做轻量交互与分派，每步通常是长输入、短输出。把积压多条Trigger合并进一次LLM API调用，会在Prefill阶段并行计算，单次请求耗时增长远慢于批处理大小。因此在一定范围内，积压越多，单个决定分摊的推理时间越低；上限取决于上下文长度，以及模型在一轮中能准确处理多少条Trigger。
文章在后文通过实验定量展示批处理机制效果。加上订阅与直通机制以及链式召回，单个常驻Router Session在保持上下文连续的同时，在目前团队规模下已经够用。
当规模进一步扩大、单个会话确实不足以承载时，Router层内部也可设计为多层过滤结构，或水平切分为多个会话。此时Router层内部设计本质上是连续性与吞吐量的权衡。切分粒度越细，Router层并发吞吐量越高，但分片之间的记忆与上下文连续性越低。在全局记忆问题被解决前，这一权衡始终存在。
2、Worker层：只干活不抢话，冲突靠订阅同一Thread自己发现
Worker层由负责具体执行的会话组成，各Worker彼此上下文隔离，挂载完整执行工具，在独立上下文中专注完成单一任务。由于Worker Session直接决定任务结果与代码质量，通常需要配置能力最强的模型。
Worker不会直接与人类交互，其推理过程和工具调用不会直接输出到外部信道，而是向Router层汇报状态，由Router层统一向用户回复，从而在保障并发度与交付质量的同时避免多个会话各自回复带来混乱。
多任务并发执行时，各Worker独立推进任务，同层Worker之间通常不需要直接通信。多个Worker在具体执行中的冲突往往出现在同一个Pull Request等共享工作环境中；只要它们都订阅了对应Thread，就会收到相同事件通知，从而有机会自行发现和解决冲突，少数跨任务协同则由Router层中转。
与Router层类似，每个Worker Session内部也不必局限于单个会话：执行复杂单任务时，Worker内部可再创建Subagent，也可本身就是一个Agent Team，这些对上层的Router层保持透明。这一结构既适用于代码协作场景，同时推进多个独立问题复现、PR评审与特性开发而互不阻塞；也适用于个人助手场景：虽然个人助手界面上通常只提供一个单会话聊天页面，但当用户在同一对话框同时讨论多个不同话题时，前端单一聊天页负责维持交互连续性，底层可为每个话题分别分派Worker，并行推进任务、起草回复。
三、事件驱动：不等指令，环境事件当输入，四步让Agent主动干活
要让Super-agent具备主动性，首先需要改变系统驱动方式。驱动Agent的主要输入不再是人类在Session中逐条键入的提示词，而是环境中的半结构化事件。在Super-agent中，群聊消息、邮件与日程提醒、代码审查评论、CI运行结果等环境事件被称为Trigger。通过监听并响应Trigger，Agent不必再像单Session模式下那样，等人类下达指令才被动执行一次。
围绕一条环境事件从进入到处理的生命周期，文章依次讨论四个递进问题：如何通过程序与模型结合的两级策略过滤大量噪音；如何通过订阅与直通机制将事件路由给Worker；如何利用Inline & Spill与链式召回向模型高密度注入与按需召回上下文；如何利用投机执行根据环境信号在后台提前行动。
1、 事件过滤：程序先快筛，模型再慢判
接入真实群聊与代码平台后，环境事件流呈现显著“高噪音、低触发率”特征，绝大多数日常消息并不需要Agent介入。如果对每个事件都调用大模型从头判断，延迟和算力成本都难以承受。借鉴计算机系统中的Fast Path / Slow Path思想，大模型推理可看作灵活但高成本的Slow Path，而将已经明确且稳定的高频判断固化为确定性代码，则构成低延迟、低成本的Fast Path。
因此，事件进入系统后的第一步是过滤，目标是在调用大模型之前先用确定性策略筛除噪音，只将需要语义理解的候选事件交给模型判断。团队采用程序策略与大模型相结合的两级过滤机制：
– 程序层策略，作为Fast Path：针对事件来源、群组范围、用户或机器人白名单等确定性条件，直接通过代码进行快速准入检查，例如对不同来源分别设置“仅响应明确请求”“作为候选事件”或“直接忽略”，在调用模型前滤除大部分无关消息。
– 语义层策略，作为Slow Path：通过程序层准入的候选事件交给LLM，由它根据用提示词编写的策略和上下文判断是否需要行动。语义层同时作为面向人类的自然语言扩展点，方便随时通过提示词开关或新增策略。
▲两级过滤：先由程序层策略筛除大部分无关消息，再交由语义层策略判断
2、事件路由：后续事件不再绕Router，订阅了就直接发Worker
第2节引入的全局Router层负责维持跨信道连续性，但如果已分配任务的每个后续事件仍需经由Router层转发，这一全局节点依然会承受大量负载，推高系统响应延迟。因此，Fast / Slow Path同样适用于过滤后的事件路由。全局Router层仅负责新任务冷启动与跨任务协调，已确定归属关系的后续事件由程序直接发往对应Worker会话，无需经由Router层转发。
实际工作流中，同一个GitHub PR、同一个IM话题或同一封往来邮件串下的连续事件构成一条事件流，即Thread。
▲Thread示例：同一个IM话题或同一个GitHub Pull Request下的连续Trigger构成一条Thread
Router层根据某个Thread的初始事件创建Worker Session后，该Worker会直接订阅对应Thread，从而将事件路由分为两条路径：
– 已订阅，Fast Path：同一Thread下后续事件由程序直通已订阅Worker，无需Router层再次调用工具转发。若新事件超出当前任务范围，Worker也可取消订阅或交回Router层重新分派。
– 未订阅，Slow Path：Router层仍可观测所有事件以掌握全局状态，但仅负责判断和分派尚未被订阅的新事件。
▲订阅与直通：初始事件经由 Router 层创建 Worker 并建立订阅，同一 Thread 的后续事件直接发往该 Worker
此外，Thread与Worker之间的订阅是多对多关系。一个Worker可同时订阅多个相关Thread，同一个Thread也可被多个Worker订阅。当多个Worker在同一个工作环境或讨论中发生交集时，该Thread下新事件会同时直通给所有订阅它的Worker，使它们无需点对点通信，也有机会获知彼此操作并自行解决冲突。在输出侧，Worker仍将关键结论汇报给Router层，由Router层统一向用户回复并同步全局记忆。
3、上下文组织：常用直接放，长文先摘要，旧任务顺ID找
事件经过过滤与路由、进入目标Session后，下一个问题是应向模型上下文窗口注入多少信息。由于系统输入从有限人类提示词转向环境持续产生的半结构化事件，工具调用与事件注入的结构设计变得更加重要。注入过多会挤占窗口、稀释模型注意力，注入过少又会迫使模型反复调用工具读取，增加执行步数。文章直言：浪费上下文窗口，就是浪费模型的智能。
为此，可将有限上下文窗口当作Cache管理。借用编译优化与计算机系统概念，上下文注入设计可归纳为两个基本操作。Inline是指将近期很可能用到的信息直接内联进当前上下文窗口，以省去额外工具调用往返。Spill则是指将超出窗口预算或低频使用的完整信息留在上下文窗口之外，仅在窗口内保留引用或摘要，供模型按需读取。
结合计算机系统设计中经典的局部性思想，可用Inline & Spill对事件注入和工具调用逐步优化：
– 从最少信息开始：最初只提供当前对象ID和内容摘要。
– 利用局部性逐步Inline关联信息：将近期很可能用到的信息Inline到上下文中，先附上紧密关联对象ID，再附带时空相邻内容，例如内容前50字、IM消息前后相邻消息与所回复消息，或代码评论所在评审讨论中的相邻评论。
– 超出上限则Spill：对无法全部Inline的长内容设定较小长度上限，将超出部分Spill到窗口之外。一种简单直接做法是截断超出部分并保留续读入口，模型需要完整内容时再调用工具读取。
此外，在大量后续事件直通Worker、系统长期运行累积许多历史任务后，Router层既不能把所有任务全量历史都放入自己的上下文窗口，又需要在用户跨信道提起某个旧任务时找回上下文。将Inline & Spill一致应用到系统中各类对象后，就得到一种按需展开的多跳检索机制，即链式召回。这种链式召回缓解了Router层在长程中丢失先前信息的问题。
▲链式召回：每次召回的对象均内联下一跳关联对象的ID，支持沿引用关系逐跳展开上下文
具体来说，系统为Trigger、Thread和Worker Session等对象赋予唯一ID，并在注入时内联紧密关联对象ID，使这些对象在底层构成一张引用图。由于每一次调用工具召回的对象本身同样遵循Inline & Spill，其返回结果中又会内联下一跳关联对象的摘要与ID，模型便可以从当前事件出发，顺着引用关系逐步按需召回上下文。例如从一条当前消息读取所在Thread，再从Thread内联ID追踪到相关Worker Session，进而找到该Worker关联的另一个代码评审Thread。
4、提前行动：后台提前试，有价值才交付
借鉴计算机系统中的投机执行思想，Agent可以在还不确定结果是否会被采用时，根据环境信号在后台提前尝试，通过消耗额外后台算力减少人类等待与介入成本。结果有价值就交付，没有价值就丢弃。
在个人助手场景下，收到一封会议邀约邮件或待办消息时，Agent可先在后台核对日程冲突、搜集相关背景资料并备好回复草稿，待用户过目后直接确认发出。在研发协作场景下同样如此。例如团队在DeepSeek Harness内部用户群中配置了一条“静默复现并修复”策略：当群里有人反馈问题或讨论改动方案时，Agent先在后台尝试复现并寻找修复方案，只有在确认问题并找到简单修复方案后，才把结果交付给用户，否则全程保持安静。
▲投机执行示例：群内还在讨论解决方案时，Super-agent已在后台提交了修复Pull Request
四、 面向人的交互：全双工随时接新指令，多信道按人的习惯说话
双层架构保证了跨信道上下文连续，但实际交互体验还需解决两点：用异步ReAct Loop让后台耗时操作不阻塞前台，会话随时接受新指令；让输出方式匹配不同信道的带宽与人的使用习惯。
1、全双工交互：后台干活，前台不卡，新指令随时进
经典ReAct Loop中，模型发起一次同步的run()工具调用后，循环会阻塞，直到工具执行完毕并返回最终结果，在此期间会话无法响应任何新的用户输入。要消除这一阻塞，需要将对话从一问一答的半双工模式转变为全双工模式。
▲经典ReAct Loop与异步ReAct Loop对比
为此，团队将耗时命令与子任务工具调用改为异步的start()和stop()，构成异步ReAct Loop。模型调用start()后立即收到“已启动”返回，循环不再等待该工具；后台工具执行完成后，系统再将最终结果作为一条新事件消息投递进会话；同时，模型也可根据上下文调用stop()主动终止执行时间过长的后台命令。
由此，前台对话响应与后台任务执行得以解耦，Agent在后台运行耗时任务的同时也能响应人类输入。新输入在当前推理步结束后即被处理，不必等待后台工具完成。文章透露，这一异步任务机制已在DeepSeek Harness中实现，但尚未默认开启。
2、多信道交互：群聊低打扰短回复，PR邮件高密度写完整
不同工作信道具有不同信息密度与交互习惯，系统输出需要与之匹配。如果将面向单人终端的交互方式直接搬入群聊，把冗长推理过程与密集工具调用原样输出，在多人协作中极易造成信息过载。
在Super-agent中，双层架构已解决其中一部分问题：具体任务中冗长推理过程和密集工具调用都被隔离在Worker Session内部，不会直接输出到外部信道，而由Router层统一负责对外交互。在此基础上，系统还需接入用户日常使用的各类工作环境，并通过提示词针对不同信道定制交互规范：
– IM等即时通讯信道：侧重低打扰的轻量沟通，像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。团队验证过一条简单有效的硬性规定：单次回复不超过100词。
– GitHub、邮件与文档等异步信道：侧重结构化、高信息密度的异步交付，例如创建或更新Pull Request时按项目规范撰写完整问题背景、改动说明与验证结果，或在个人助手场景下直接起草结构化邮件与文档摘要。
五、类Anthropic式“脑手分离”，计算、状态与环境解耦
现有本地Agent默认将推进Agent Loop的计算、需要持久保存的会话状态，以及代码仓库与本地工具链等执行环境绑定在同一台设备上。一旦设备休眠或离线，Agent就会停止运行，且无法访问其他设备上的环境。
要让Super-agent做到持久在线并灵活接入各类真实工作环境，可借鉴计算机系统中存算分离思想，分两步解耦三者绑定：第一步先将推进Agent Loop的计算与持久化会话状态分离，使Agent摆脱单机生命周期限制、实现云端持久在线；第二步再将云端Agent Loop与重状态执行环境解耦，让真实工作环境留在原地并支持跨设备访问。
文章指出，这一思路与Anthropic提出的“脑手分离”一致，同样让harness保持无状态，把会话日志存放在harness之外，并通过统一接口按需接入执行环境。
但两者区别在于场景：Anthropic那篇文章描述的是托管服务，主要讨论按需创建的沙箱和客户VPC内资源；这里首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交修改和本地凭据。因此，这种设计既支持BYOM，即把用户日常使用的开发机或个人电脑接入云端Agent，也支持接入云端托管机器或按需创建的计算环境。
由此，一个Agent不再受限于单台机器，而是可以在不同执行设备之间切换，根据任务需要选择环境来执行命令并获取环境中上下文。它甚至能支持间歇在线设备，例如用户某台个人设备重新上线后，再由云端Agent自动触发并完成需要在该设备上执行的任务。
▲存算分离与执行环境解耦
六、持久在线靠外部Watchdog：既盯基础设施，也盯任务进展
要实现持久在线，除了第5节存算分离，还需要让系统在长期运行中能从异常中自动恢复。持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠运行，需要在主系统之外引入独立外部控制回路，即Control Loop。
同时，在Agent系统中，仅靠传统进程存活探测或监控脚本是不够的，因为许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标。因此，长期运行Agent系统不仅需要监控基础设施存活，还需要监控任务本身进展。
团队在主系统外部配置了一个独立Watchdog Session，用定时消息驱动它，构成外部Control Loop。Watchdog除了处理接口报错、状态恢复失败等基础设施故障，还会由模型判断各Worker是否有实质进展、方向是否偏离整体目标。发现异常时及时介入修复，遇到外部偶发故障则持续复查直至恢复正常。
由于Watchdog本身也是一个具备完整工具能力的Agent Session，维护者可以用自然语言向它询问故障原因，也可以让它在线修正主系统行为，例如增删提示词、调整触发规则。
七、初步实验：双层架构更快更稳，直通省三成token，Router越堵单决定越便宜
为评估前文核心调度与路由设计，团队从两个层面进行初步实验：首先通过端到端实验对比双层架构、订阅直通与单Session方案；随后单独测试Router层批处理。由于实验基于合成负载与简化环境，部分设置还可更加严谨，以下结果仅作初步参考。
1、消融实验：更快更稳，直通不提速但省Router约37% token
实验用群聊和GitHub CI消息流驱动四种方案，单次约300条消息、其中约20条工作请求，编码工作用只耗时工具代替，每种跑5次。
▲工作请求的累计到达曲线与四种方案的累计完成曲线
▲每种方案重复运行 5 次，任务完成时间指从工作请求到结果消息的耗时
Super-agent的p50与p95分别为12.4分钟和15.7分钟，显著优于带Subagent工具的单Session。后者受提示词影响大：中性提示下5次运行一次都没调用Subagent，全在主Session里干、不断被新消息打断，p95达29.5分钟；改为优先委派后5次有4次委派，仍慢于Super-agent，剩下1次模型判断工作“很小”自己执行，形成长尾。
开销上，Super-agent维护多会话，读缓存token高于单Session，用更多token换更短更稳的完成时间。去掉直通后完成时间基本一致，但Router决定数增加约30%，读缓存token从2323万增至3177万，增幅约37%，直通不提升速度，但为Router省下可观的token与推理开销。
2、Router层的批处理：积压合并后，单决定分摊时间从6.4秒降到1.6秒
团队单独压测了Router层：Router调真实模型、Worker用Mock模型，Trigger到达速率从每分钟约1条升至约40条。
结果平均batch从1.0升至2.8，单次请求耗时仅从2.5秒增至3.9秒，增长慢于batch大小，单个决定分摊的推理时间从6.4秒降至1.6秒。
这说明突发拥堵时Router能自动合并积压事件提高吞吐，也解释了去掉直通后峰值负载增加仍未触及瓶颈。因此目前团队规模下无需过早水平切分、牺牲全局上下文连续性。
▲不同Trigger到达速率下Router Session的batch大小、单次请求耗时与单个决定的分摊推理时间
八、四道坎仍待解：架构扩展、人机协作、A2A、安全隐私
第2至第6节介绍的五个模块构成支撑Super-agent运转的基本架构，第7节实验也验证了其中核心调度与路由机制在多任务并发下的效果。
这套系统之所以能以较低复杂度运作，很大程度上是因为当前阶段做了一系列工程和场景简化。超出这些简化适用范围后，在双层架构扩展、脱离Session后的人机协作、上下文边界与A2A，以及安全与隐私上，仍有一些问题需要解决。
文章列出四个开放问题：一是双层架构如何扩展，单Router承载超限后何时切分、粒度如何、Worker间何时直接通信均无定论，跨月长程记忆也是瓶颈；二是脱离Session后如何协作，聊天窗口未必是最终形态，交互可更多发生在GitHub等领域界面，还需支持用户中途介入、接管与实时协同。
三是组织扩大后如何划分上下文边界，多个隔离实例间的A2A通信与协作待探索；四是安全与隐私，云端Agent接入端侧凭据存在被入侵和提示词注入风险，还需让Agent不接触凭据本身也能使用凭据。
结语：五大模块，解放Agent时代人的注意力瓶颈
文章并非提出全新理论，而是把计算机系统经典工程思想用于Agent系统构建，具体实现会演进，但设计思路有长期参考价值。基于DeepSeek Harness的内部Super-agent实例已持续运行，参与问题复现修复、代码审查和Harness迭代。
随着模型执行单任务减少人工干预，瓶颈转向人的注意力。双层架构、事件驱动、异步多信道交互、存算分离与外部Watchdog在底层接管会话管理与上下文同步，使人上移到决策与验收。
Agent从被动对话窗口变为持续在线的自主协作者：面向个人是跨设备助手，面向团队融入研发工作流。团队相信更自主的工作方式有望成为常态。部分设计已在dsh-superagent-prototype实现，但该插件仅为验证技术路线的原型，并非DeepSeek正式产品。
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Intellectual (WeChat Official Account:zhidxcom)
The author, Li Shui-young
Edition.
On the evening of 31 October, Ji-Jin reported that the DeepSeek Harness team had released its bottom-up structure for the autonomous Agent Explore — Super Z42Z.
Address of the Super-agent Open Source Project
GitHub address:
https://github.com/deepseek-ai/dsh-superagent-prototype
DeepSeek's "Super-agent" can be understood as an Agent who's been on line, capable of doing many things at the same time, looking for work on his own initiative, and having problems recovering himself. The team's result this time is not a new product, but rather a new approach — bringing the classic ideas of dispatch, cache, storage separation, Watchdog, etc. in the computer system into the Agent structure.
As model execution of single tasks reduces manual intervention, bottlenecks turn to human attention. DeepSeek Harness tried to upgrade the Agent application experience through five major modules — double-layered, event-driven, multi-touching, memory separation — and external Watchdog taking over session management at the bottom with context, moving people up to decision-making with acceptance check.
Super-agent corporate system architecture
On an experimental basis, half of the Super-Agent task based on this approach was completed within 12.4 minutes, 95 per cent of the task was completed within 15.7 minutes, significantly better than the single Ssession (meeting) with the Subagent tool; the number of Router decisions increased by about 30 per cent after the off-subscription and the reading of cachetoken increased from 23.23 million to 317.7 million; and Router batch processing reduced the reasoning time for individual decisions from 6.4 to 1.6 seconds.
This group of data means that Super-agent demonstrated in a preliminary experiment the feasibility of “system-level take-over session scheduling”.
On the one hand, multi-missions are faster and more stable, with Router spending directly, and batch processing, but on the other hand, more token is used for time and stability, and the experiment is based on synthetic loads and a simplified environment, a preliminary reference, not a formal product conclusion.
i. Super-att: One Agent parallels multi-task without talking
Over the past year, Coding Agent, a single task such as Agent, has proven that models can be used as tools to solve complex problems, with fewer and fewer people involved in bottom-level implementation, moving roles upwards to decision-making and acceptance check. New and event-driven patterns, such as personal assistants, are beginning to emerge.
However, the existing Agent is organized in a single Ssession, the multi-task cap is limited by human attention, and simple expansion is still constrained by synchronous blockages, context chaos, and the stoppage of equipment offline.
As a result, DeepSeek Harness presented Super-agent: a continuous entity with cross-conferences context, multi-task parallel and non-disturbed, and there are internal examples of successive missions between IM and GitHub.
The same mission advanced between the IM community and GitHub Pull Review
▲ Keep an eye on the public conversation, identify the defects in the absence of a @ and submit them for restoration
According to the team, Super-agent has four basic features:
– Continuity: Users can interact with me directly at familiar interfaces such as IM chats, GitHub comments, and feel that there is always only one Agent, and do not have to think about whether there is a Y in the “SESSION X context”. For example, the user first proposed the introduction of option A in IM and then changed it to option B in GitHub PR comments, which understood and reoriented implementation.
– Efficient: a rapid, interactive response, with parallel, high-quality and complex tasks. The next directive is accepted without the need to wait until the last order or mission is completed.
– Proactive: there is no need to wait for the user to give an article-by-article order, to be able to observe environmental events on an ongoing basis and to take the initiative to advance matters that are worth addressing, and to be quiet when involved.
– Persistence: always online, direct access to the user's real working environment and automatic recovery in the event of an anomaly during long-term operations.
Individual Rect Loop cannot support the above four characteristics at the same time, and the bottom level requires a corresponding set of structures. According to the article, similar design constraints would export similar structural options. Agent, either as a personal assistant or as a commercial scene, such as software development, may have a similar structure at the bottom if the goal is to build a system that is continuous online and responds to environmental events. Many of the problems faced in this process are highly similar to those that have long been explored in traditional computer systems, so that the classic design thinking in computer systems applies equally.
While specific landings may vary, the articles consider that the five modules constitute the basic framework that underpins the four above-mentioned features: a two-tiered structure that combines continuous interaction and efficient co-generation, a proactive response driven by events, continuous and efficient interaction through human-oriented interactions at the same time, and sustained inter-equipment online and abnormal self-healing through computation, state and environment separation and Watchdog.
Two-tiered structure: one, one, one, one, and one.
Cross-channel continuous interaction and multitasking are highly efficient and have fundamental trade-offs: it is all handed over to a Ssession, context, which is the most continuous, but only React Loop is in swath, low-in, mixed in detail; and it is all opened independently, with the highest level of throughput, but without a global context, the results are broken and the results are confused.
The DeepSeek Harness team's solution is to break the “maintenance of global continuity” and the “high co-execution” into two layers: the permanent Router layer, which is responsible for human interaction and global coordination, and the context isolated Walker layer, which carries out specific tasks. The session should be the details of the system, not the user-awareness burden.
Two-tiered structure: Router level, integrated router and external interaction, multiple worker sessions isolated and tasked
1 Router level: assignment of no work, bulk-processing at a low cost
The Router layer, a permanent global router, is responsible for all human interactions at all entry points. All cross-mission information and decision-making is aggregated at the Router level, which serves as global sequence, coordination and memory. To avoid this global node becoming a performance bottleneck, the Router layer is designed not to perform specific tasks directly, but rather to be responsible for human interaction and tasking, even without Bash tools.
This structure, which assigns multiple implementation nodes to one central node, appears to be similar to the common Agent Team, with a different focus. The common Agent Team, which is mainly used to dismantle steps and engage in role collaboration within a single complex mission, is often more closely aligned, and Team Lead often requires in-depth understanding of mission details, planning of subtask and HF coordination members, with its own heavy burden of reasoning. In Super-agent, the Router layer deals only with high-level linkages and assignments between tasks, without having to intervene in the break-up of a single task. On the contrary, this can also be considered a two-tiered structure if the main session of Agent Team, through prompt, does not carry out specific tasks in person and is responsible only for interacting with the outside and assigning different tasks to members for their own advancement. Team practice shows that Router missions are often not as complex as they would have been imagined, and the use of lightweight models tends to balance speed with effect.
In-house realization, the Router layer also does not have to be confined to a single session, and even part of the logic does not necessarily require a call to LLM. The team selects the most direct individual resident LLM Session as the centre of the Router layer and finds that it is not seemingly as easy as a bottleneck, as environmental events that arrived during the previous period of reasoning will accumulate, be processed together in the next round, into batches, with minimal additional costs for consolidation:
– When the flow of external events is smooth, Trigger enters Router Session by article, with a lower delay in a single response;
– When there is an influx of events, and there is a queuing of Router Session, the backlog of Triggers during the previous round of reasoning is automatically merged and injected into the next LLM call. Router Session is only a light interactive and distributed process, usually with long input and short output. The consolidation of the backlog of Triggers into one LLM API call will be calculated in parallel at the Prefill stage, with single requests growing much slower than batch size. Thus, within a given range, the more backlog there is, the lower the reasoning time for individual decisions on allocation; the upper limit depends on the length of context and the number of Triggers that the model can accurately handle in the round.
The post is followed by an experimental quantitative presentation of the effects of the batching mechanism. Together with subscription and direct access mechanisms and chain recall, individual resident Router Session, while maintaining the continuity of context, is sufficient at the current team level.
When the scale is further expanded and a single session is indeed not sufficient to carry, the Router layer may also be designed as a multilayered filter structure or horizontally divided into multiple sessions. At this point, the internal design of the Router layer is essentially a trade-off between continuity and throughput. The more we cut the grain, the higher the Router layer, the higher the amount of co-ingestion, but the lower the memory between the fractions and context continuity. This trade-off persists until the global memory problem is resolved.
2 Worker level: Work without talking, conflict by subscription to the same Thread itself
The Worker layer consists of a session for specific execution, each of which is isolated from each other by context, mounts a complete implementation tool and focuses on a single mission in a separate context. The most capable model is usually required because of the direct determination of mission results and code quality by the World Council.
Worker does not interact directly with humans, and its reasoning and tool call do not directly export to external channels, but rather report to Router level, where they respond to users in a uniform way, thus avoiding confusion caused by multiple responses, while safeguarding the quality of both distribution and delivery.
When multitasks are carried out, individual Workers carry them out independently, and direct communication between the same layer of Worker is usually not required. Multiple Worker conflicts in implementation often occur in a shared working environment, such as the same Pull Request; as long as they subscribe to the Thread, they receive notification of the same event, which gives them the opportunity to identify and resolve the conflict on their own, while a few cross-mission synergies are passed through the Router layer.
Similarly to the Router layer, each Worker Summit need not be limited to a single session: when performing a complex single task, Worker can create a new Subagent within itself, or it can itself be an Agent Team, which is transparent to the upper Router layer. This structure applies both to the coding scene, while promoting the re-emergence of multiple independent issues, the evaluation of the PPR and the development of identity without blocking each other; and to the personal assistant scenario: While the personal assistant interface usually provides only a single session chat page, when the user discusses multiple different topics in the same dialogue box, the front-end single chat page is responsible for maintaining interactive continuity, and the bottom-end can assign a Worker to each topic in parallel with a task and a response.
III. Event-driven: Not according to instructions, environmental event input, 4 steps to get Agent to work
A change in the system-driven approach is needed first for Super-agent to be proactive. The main input driving Agent is no longer a prompt typed by humans in the Summit, but a semi-structured event in the environment. In Super-agent, environmental events such as group chats, emails and agenda alerts, code review reviews and CI run results are known as Trigger. By listening and responding to Trigger, Agent does not have to wait for humans to give orders once more, as was the case under the single-session model.
Four progressive issues were discussed in turn around the life cycle of an environmental event: How to filter out a large amount of noise through a two-tiered strategy that integrates the program with the model; how to route events to Walker through subscription and direct access mechanisms; how to use the Inline & Spill and chain-based recall for high-density injection into the model and recall context as required; and how to use speculation to implement early action backstage based on environmental signals.
1. Event filtering: program quick sift, model slow
With access to the real group chat and code platform, environmental events flow is characterized by significant “high noise and low triggers”, and the vast majority of daily messages do not require the intervention of Agent. If LLM were to be used from scratch for each event, it would be difficult to bear the delay and the calculation costs. Drawing on the Fast Path/Slow Path ideas in computer systems, LLM reasoning can be seen as a flexible but high-cost Slow Path, while the solidization of a well-defined and stable high-frequency judgement into a certainty code constitutes a low-delayed, low-cost Fast Path.
Therefore, the first step after an event enters the system is filtering, with the goal of sifting noise with a certainty strategy before calling LLM, and leaving only candidate events that require semantic understanding to model judgement. The team uses a two-tiered filter that combines the program strategy with LLM:
– Program level policy, as Fast Path: For certain conditions such as source of event, cluster range, user or robotic white list, rapid access checks are conducted directly by code, for example by placing “only as a candidate” or “direct neglect” for different sources, respectively, “only responding to an explicit request” and filtering out most irrelevant messages before calling on the model.
– Semantic-level strategy, as Slow Path: candidate events for access through the program level are referred to LLM, which determines whether action is required on the basis of the strategy prepared with prompt and context. The semantic layer also serves as a natural language extension point for humans, allowing for easy access to prompt switches or new strategies.
Two-tier filter: first program-level strategy filters most irrelevant messages before semantic strategy
2. Course of events: Follow-up events no longer revolve around Router and send Worker directly after subscription
The global Router layer, introduced in section 2, is responsible for maintaining continuity across the channel, but if each subsequent incident assigned to it is still to be forwarded through the Router layer, this global node will continue to bear a large load and delay the response of the push system. Therefore, Fast / Slow Path is also applicable to filtered event routing. The Router level is responsible only for the cold start-up and cross-mission coordination of new missions, and subsequent events for which attribution has been determined are sent directly from the process to the corresponding Worker session and do not need to be forwarded through the Router level.
In the actual workflow, the same GitHub PR, the same IM topic or a continuous incident under the same line of correspondence constituted an event stream, namely, Thread.
Example of ▲Thread: A continuous Trigger under the same IM topic or the same GitHub Pull Request constitutes a Thread
After the Router layer created the Worker Session based on an initial event in Thread, the Worker directly subscribes to the Thread, thus dividing the event path into two paths:
– Subscriptions, Fast Path: Follow-up events under the same Thread are done by direct subscription to Worker without the Router layer calling again. Worker can also cancel the subscription or return the Router layer for reassignment if the new event exceeds the current task.
– Unsubscribed, Slow Path: The Router layer can still observe all events for global status, but is only responsible for judging and assigning new events that have not yet been subscribed to.
订阅subscription and direct connection: the initial event created and subscribed through the Router Layer to worker and sent the same Thread follow-up event directly to that worker
In addition, the subscription between Thread and Worker is multi-to-relationship. One Worker can subscribe to more than one relevant Thread at the same time, and the same Thread can be subscribed to by more than one Worker. When multiple Workers intersect in the same work environment or discussion, the new events under Thread go directly to all those who subscribe to it, so that they do not need point-to-point communication and have the opportunity to learn about each other ' s operations and to resolve their own conflicts. On the output side, Worker will still report key findings to the Router layer, which will provide a unified response to users and synchronize global memory.
3 context: Usual Direct, Longman First summary, Old Mission Following ID
The next question is how much information should be injected into the model context window after the event has been filtered and routed into the target Session. The structural design of tool call and the event injection became even more important as the system input moved from a limited human prompt to a semi-structured event that continued to occur in the environment. Excessive infusion crowds in windows, dilutes the attention of models, and infrequent infusions force the models to repeatedly call on tools to read and increase the number of implementation steps. The article was forthright: waste of context window is waste of the intelligence of the model.
To that end, limited context window could be managed as Cache. The context injection design can be grouped into two basic operations, using the concept of compilation optimization and computer systems. Inline refers to the direct in-linking of information that is likely to be used in the near future into the current context window to save the extra tool call round trip. Spill, in turn, means that complete information beyond the window budget or low-frequency use is left outside context window and only quoted or summary is kept in the window for the model to read on demand.
Combining the classic local thinking in computer system design, inline & Spill can be used to inject events and gradually optimize tool call:
– Starting with the minimum information: the first to provide only the current object ID and content summary.
– The use of a local step-by-step Inline connection information: Inline, which is likely to be used in the near future, is attached to context, with a closely related object ID and a time- and space-based adjacent content, such as the first 50 words of the content, the information that is adjacent to the IM message and the information that has been received, or the comments that are related to the review of the code.
– Beyond the ceiling, Spill: set a smaller length cap on long content that cannot be fully inline, which will exceed some of the Spills outside the window. A simple and direct approach is to cut the excess and keep the re-reading portal, and the model needs to be called on to read when it is complete.
In addition, after a large number of follow-up events went through Worker and the system was operating over a long period of time to accumulate many historical tasks, the Router layer was neither able to put the full history of all tasks into its own context window, nor needed to recover context when an old task was raised by the user across the channel. The consistent application of Inline & Spill to various objects in the system provides a needs-based multi-jump search mechanism, or chain recall. This chain recall mitigates the loss of prior information from the Router layer over long distances.
Recall in a chain: each caller connects the ID of the next jumper, supporting the roll-out of context along the reference lines
Specifically, the system assigns unique IDs to objects such as Trigger, Thread and Worker Summit, and is closely linked to objects IDs when injected so that they form a reference map at the bottom. Since each caller follows the same line of Inline & Spill itself, the return result of summary and ID, which are linked to the next jumper, allows the model to start from the current event and to gradually recall context as required in line with the reference. For example, the location of Thread, which is read from a current message, is traced from the inter-ID in Thread to the relevant Worker Summit, and then found another code associated with the Worker to evaluate Thread.
4. Early action: early backstage testing, valuable delivery
Drawing on speculative implementation ideas in computer systems, Agent can try in advance in the backstage, on the basis of environmental signals, to reduce human waiting and intervention costs by consuming additional back-office calculations, if it is uncertain whether the results will be used. The results are delivered and abandoned without value.
In the personal assistant scenario, when an invitation to attend a meeting or to-do message is received, Agent can check the conflicting calendars, gather relevant background information and prepare a draft response in the back desk, and confirm it directly after the user has read it out. The same is true of the collaborative development scene. For example, the team has set up a silent recovery and repair strategy in the DeepSeek Harness internal user group: When feedback was received from the group or changes were discussed, Agent first tried to reproduce and look for a rehabilitation programme in the back and only delivered the results to the user after the problem had been identified and a simple repair programme had been found, otherwise the whole process would remain quiet.
Example of speculative execution: While solutions were still being discussed within the group, Super-agent presented the restoration of the Pull Request backstage
IV. People-oriented interaction: full-time access to new instructions, multi-faith rhetoric
The two-tiered structure ensures a continuum of context, which crosses the channel, but the actual interactive experience needs to address two things: to use a different rect Loop to keep backstages open for hours, to receive new instructions at any time, and to allow the output to match the bandwidth of different faiths with the usage habits of people.
1. Full-time interaction: backstage work, no front desk cards, new commands coming in.
In classic rect Loop, after the model initiates a synchronized run() tool call, the loop is blocked until the tool is finished and the final result is returned, during which the session cannot respond to any new user input. To eliminate this obstacle, it is necessary to move from a semi-bi-working model to a full-labour model.
React Loop versus rect Loop
To this end, the team changed the time-consuming command from subtasktool call to a start() and stop() to a walk-in, constituting a rect Loop. The model immediately receives a “started” return, and the loop no longer awaits the tool; the system sends the final result as a new event message after the implementation of the back-office tool; and the model can also proactively terminate the lengthy back-office command on the basis of context call stop() call.
As a result, the dialogue response from the front desk and the execution of the backstage task were decoupled, and Agent was able to run the time-consuming mission backstage while also responding to human input. New input is processed at the end of the current reasoning step, without waiting for the back-office tool to be completed. The article revealed that the mechanism of this different mission had been implemented in DeepSeek Harness but had not yet been introduced by default.
Multi-channel interaction: small group chats, short replies, high-intensity PRS
Different working channels have different information density and interactive habits, and system output needs to match them. The lengthy reasoning process and the intensive tool call output would easily result in overloading of information in multi-person collaboration if one-person terminal-oriented interactions were to be moved directly into the community.
In Super-Agent, the two-tiered structure has solved some of these problems: the lengthy reasoning process and the intensive tool call in the specific task are isolated within the Worker Summit and do not directly export to external channels, but are under the unified responsibility of Router. On this basis, the system will also need to access the various work environments that users use on a daily basis and customize interactive specifications for different channels through prompt:
– IM and other instant communication channels: Focus on low-intensity light communication, like human colleagues, only sends a notice when there is a need for decision-making or acceptance check, asking only direct questions and giving short conclusions. The team validated a simple and effective mandatory provision: a single response does not exceed 100 words.
– GitHub, e-mail and documents, etc., walk-throughs that focus on structured, high-infodensity, e.g. creating or updating a full background of questions in accordance with project specifications, changes and validations, or directly drafting structured mail and document summary in a personal assistant setting.
Category Anthropic “brain-brain separation”, computation, state and environmental decomposition
The existing local Agent default will advance the calculation of Agent Loop, the status of the session that needs to be preserved for a long time, and the implementation environment, such as the code warehouse and the local tool chain, bound to the same device. Once the equipment is dormant or offline, Agent ceases to operate and cannot access the environment on other equipment.
To enable Super-agent to maintain a permanent online and flexible access to all types of real work environment, two-step decoupling can be achieved using the idea of separation in computer systems: The first step would be to separate the calculation of Agent Loop from the permanent conversational state, to remove Agent from the single life-cycle limit and to achieve a permanent cloud-on-line; the second step would be to decorate the cloud-end Agent Loop with the heavy state to keep the real work environment in place and support cross-equipment access.
According to the article, this line of thinking is consistent with the “brain separation” proposed by Anthropic, which also leaves harness in a state of disarray, keeps the session logs outside of harness and access the implementation environment on demand through a unified interface.
But the difference is between the scenes: the Anthropic article describes the hosting service and focuses on the creation of a sandbox on demand and the customer ' s VPC in-house resources; the first thing to access here is the personal machine that the user uses on a day-to-day basis, possibly intermittently online, with no changes submitted and local evidence. Thus, this design supports both the BYOM, which connects developers or personal computers used by users on a day-to-day basis to the cloud-end Agent, and the cloud-based hosting machine or the needs-based computing environment.
As a result, an Agent is no longer limited to a single machine, but can switch between the different implementing equipment, select the environment to execute the order and acquire context in the environment according to mission requirements. It can even support intermittent online devices, such as a user's personal device that is re-connected and automatically activated by cloud-end Agent and performing tasks that need to be performed on the device.
Separating and decomposing the environment
VI. RESPONSIBILITY OF AN OUTSIDE WATCHDOG: A focus on infrastructure and mission progress
To achieve sustainability online, in addition to the savings separation of section 5, there is a need to enable the system to automatically recover from anomalies in long run operations. It is difficult for a sustainable, online distributed system to ensure long-term reliability on the internal logic of the main system alone and requires the introduction of an independent external control circuit outside the main system, that is, Controll Loop.
At the same time, in the Agent system, survival detection or monitoring of scripts by traditional processes alone is not sufficient, as many anomalies are not process collapses, but models are being implemented in an ineffective cycle or de-targeting. Therefore, the long-term operation of the Agent system requires monitoring not only the viability of the infrastructure but also the progress of the mission itself.
The team deployed an independent Watchdog Summit outside the main system, driven by time-messaging messages, to form an external Controll Loop. In addition to addressing infrastructure failures, such as faulty interfaces and failed state recovery, WATCHDOG will be able to determine whether or not Worker is making substantial progress and moving away from overall objectives. When anomalies are detected, intervention is made in a timely manner to repair them, and in the event of an occasional external malfunction, the review continues until normality is restored.
As Watchdog itself is also an Agent Session with the capability of a complete tool, the maintainer can ask it in its natural language about the cause of the failure, or it can amend the behaviour of the main system online, for example by adding or deleting prompt and adjusting the trigger rule.
VII. Preliminary experiments: double-layer structure is faster and more stable, 30% token straight to province, and Router gets cheaper by blocking the singles.
In order to assess the preface core movement and route design, the team conducted preliminary experiments at two levels: first, comparing the two-layer structure through end-to-end experiments, subscription to direct and single-session programmes; and then testing the Router layer batches separately. Since the experiment is based on a synthetic load and a simplified environment, part of the set-up could be made more rigorous, and the following results can be used only as a preliminary reference.
1. Absorption experiments: faster and more stable, straight to speed but about 37% token in Router
The experiment was driven by group chats and GitHub CI newsstreams, with about 300 single messages, of which about 20 job requests were replaced by a time-consuming tool, five times each.
The cumulative arrival curve of the work request and the cumulative completion curve of the four scenarios
Five times for each option to be duplicated, task completion time is the time between the request and the result message
Super-agent's p50 and p95 are 12.4 and 15.7 minutes, respectively, and significantly superior to the single-session with the Subagent tool. The latter were affected by prompt: the neutral hints ran without calling Subagent at five times, all in the main Session and repeatedly interrupted by new news, p. 95 to 29.5 minutes; the first five assignments were given on a priority basis, with four assignments, which were still slower than Super-atent, and the remaining one model judgement was “small” self-executed and formed a long tail.
At cost, Super-agent maintains multiple sessions, reads cache Ztoken more than singleSESSION, and uses more token for shorter and more steady completion times. The time of completion after elimination is largely the same, but Router's decision increased by about 30 per cent, from cachetoken from 23.23 million to 317.7 million, an increase of about 37 per cent, or no increase in the speed of direct access, but token and reasoning, which is significant in Router's province.
2. Batch processing on Router level: reduced from 6.4 seconds to 1.6 seconds after consolidation of backlogs
The team had independently pressed the Router layer: Router had adjusted the real model, Worker had used the Mock model, and Trigger's arrival rate had risen from about 1 to 40 per minute.
The result was an average rise from 1.0 to 2.8, a single request taking only 2.5 to 3.9 seconds, a slower increase than the size of the bat, and a reduction in the reasoning time for individual decisions from 6.4 to 1.6 seconds.
This is an indication that Router automatically combines the backlog to increase throughput in the event of congestion, and explains that the bottlenecks remain untouched by the removal of post-peak load increases. Therefore, the current team size does not require a premature horizontal split at the expense of global context continuity.
The size of the watch, the time of a single request and the time of an individual decision to share the reasoning at a different rate of Trigger's arrival at Router Session
VIII. THE THREE BALANCES STILL TO BE FREEDOMED: STRUCTURE EXTENSION, HIP COORDINATION, A2A, SAFE HOUSING
The five modules described in sections 2 to 6 constitute the basic structure that underpins the operation of Super-Agent, and the experiment in section 7 also validates the multitasking of the core movement and routeing mechanisms.
The system is operating at a lower level of complexity, largely as a result of a series of engineering and scenario simplifications at the current stage. Beyond these simplified areas of application, there are still issues that need to be addressed with regard to the expansion of the two-tiered structure, human collaboration after separation from the Summit, the context border with A2A, and security and privacy.
The article listed four open questions: first, how the two-tiered structure was expanded, when to cut after the single Router load was overstretched, how the particle size was, when the direct communication between Worker was undecided, and how the long-term memory of the inter-monthly journey was also a bottleneck; and second, how to collaborate after the breakout of the Ssession, the chat window was not necessarily the final form, with more interaction taking place in such areas as GitHub, and there was a need to support the user ' s intermediate intervention, take-over and real-time synergy.
The third is how the context boundary is divided by the expansion of the organization, with A2A communications and collaboration to be explored between multiple isolated cases; the fourth is security and privacy, with cloud-based Agent access-side evidence of the risk of invasion and prompt injection, and the need for Agent not to have access to the evidence itself.
Conclusion: Five main modules, a bottleneck to free the Agent generation
The article does not introduce a whole new theory, but rather uses the classic engineering idea of a computer system for the construction of the Agent system, which will actually evolve, but design ideas have long-term reference value. The internal Super-agnet case based on DeepSeek Harness has been running continuously, with participatory problems resuscitation, code review and Harness iterative.
As model execution of single tasks reduces manual intervention, bottlenecks turn to human attention. Double-layered structures, event-driven, walk-in multiple interactions, memory separation, and external Watchdog taking over session management at the bottom, synchronized with context, moving people up to decision-making and acceptance check.
Agent moved from a passive dialogue window to an on-line, autonomous collaborators: Personally, it is a cross-equipment assistant, and workflow for team integration. The team believes that a more autonomous way of working is expected to become normal. Part of the design has been implemented at dsh-suberagent-prototype, but the plugin is only a prototype of the certification technology route and is not a formal DeepSeek product.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.