智东西（公众号：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-chung
Edition.
On the evening of 31 October, according to Jiji, the DeepSeek Harness team 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 has 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 results this time are not a new product, but rather a new approach — bringing the classic ideas of dispatch, cache, storage separation, Watchdog, etc., into the Agent structure.
As model execution line fewer manual interventions, bottlenecks turn to human attention. DeepSeek Harness tried to improve the Agent application experience by synchronizing with context on the ground floor by using five main modules — double-layer structure, event-driven, walk-through multi-channel interaction, memory separation — with the outside Watchdog taking over session management.
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 (session) with the Subagent tool; the number of Router's decisions increased by about 30 per cent when subscriptions were removed, and the reading of cachetoken increased from 23.23 million to 317.7 million; and Router's batch processing reduced the reasoning for individual decisions from 6.4 to 1.6 seconds.
This group of data means that Super-agent demonstrated the feasibility of a “system-level take-over session” in a preliminary experiment.
On the one hand, multiple missions are faster and more stable, and Router spends more money on bulk and batch processing; on the other hand, it takes more token in exchange for time and stability, and the experiment is based on synthetic loads and simplified environments, which are only preliminary references, not formal product conclusions.
i. Super-att: Agent to advance multiple tasks in parallel 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 becoming involved in the bottom line of implementation and moving roles upwards to decision-making and acceptance check. New, event-driven patterns, such as personal assistants, are beginning to emerge.
However, the existing Agent is based on a single Ssession, the multi-task cap is limited by human attention, and simple expansion is still constrained by synchronous blockages, context chaos, and equipment offline stoppages.
As a result, DeepSeek Harness presented Super-agent: a continuous entity with cross-conferences that maintain context, advance multiple tasks in parallel and do not interfere with each other, and there are internal examples of successive missions between IM and GitHub.
The same mission advanced between the IM community and GitHub Pull Review
▲ continued to focus on public conversations and proactively identify deficiencies in the absence of @ and submit them for restoration of the Pull Request
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 need to think about “Was there any Y in the context of Sesion X”. For example, the user first proposed the introduction of option A in IM and later changed it to option B in GitHub PR comments, which understand and reorient implementation.
– Efficiency: a rapid and interactive response that simultaneously enables multiple complex tasks to be accomplished in parallel and of high quality. The next order is accepted without waiting for the last order or mission to be completed.
– Proactive: there is no need to wait for a user-by-user directive, to be able to observe environmental events on an ongoing basis and to take the initiative to advance matters worth dealing with, 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 run.
Individual Rect Loop cannot support the four characteristics at the same time, and the bottom level requires a corresponding structure. According to the article, similar design constraints would export similar structural choices. Agent, either a personal assistant or a commercial scenario 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 classic design ideas in computer systems apply equally.
While there are variations in the physical location, the articles consider that the five modules constitute the basic framework underpinning the four above-mentioned characteristics: continuous interaction and efficient co-production through a two-tiered structure, proactive response through event-driven interaction, continuous and efficient interaction through person-oriented interaction at the same time, and sustained inter-equipment online and abnormal self-healing through computation, state and environment separation and Watchdog.
Two-tier structure: one for successive and one for distribution and one for work.
Cross-channel interaction and multi-tasking efficiency and fundamental trade-offs exist: it is all handed over to a board, with context being the most continuous, but only rect Loop swathing, low swallowing, mixed in detail; and a full independent session with the highest amount of throughput, without a global context, fragmented and fragmented results.
The DeepSeek Harness team's solution was to break “maintenance of global continuity” and “high parallel implementation” down to 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 perception burden.
Two-tier structure: Router level, integrated router and external interaction, multiple worker sessions isolated and tasked
1 Router level: assignment of no work and amortization of costs through batch processing
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 sequencing, coordination and memory. In order to avoid this global node becoming a performance bottleneck, the Router layer is designed not to perform specific tasks directly, but to be responsible for human interaction and task assignment, even without Bash tools.
This structure, which assigns multiple implementation nodes to a central node, appears to be similar to the usual Agent Team, with a different focus. The common Agent Team, which is used primarily to dismantle steps within a single complex mission and collaborates with roles, is usually 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 and does not need to intervene in the break-up of a single task. On the contrary, such a two-tiered structure could also be considered if the main session of an Agent Team, through prompt, did not carry out a specific task in person and was only responsible for interacting with the outside world and assigning different tasks to members for independent advancement. Team practice shows that the Router layer is often not as complex as expected, and the use of lighter models tends to balance speed with effect.
In terms of internal realization, the Router layer also does not need to be confined to a single session, and even part of the logic does not need to call for 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 dealt with together in the next round and form 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 crowding out 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 interaction and assignment, usually with long input and short output. The consolidation of the backlog of Triggers into one LLM API call will be calculated in parallel during the Prefilt phase, with single requests growing much slower than batch size. As a result, within a given range, the more backlog there is, the lower the reasoning time for individual decisions to apportion; 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 batch processing 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 insufficient to carry, the Router layer can 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 the particles are sliced, the more the Router layer is adsorbed, 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, with a full implementation tool mounted and a single mission focused on in a stand-alone context. As the task results and code quality are directly determined by the Worker Session, the most capable model is usually required.
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, thereby avoiding confusion caused by multiple responses, while safeguarding the quality of simultaneous 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 practice often occur in a shared working environment, such as the same Pull Request; as long as they all subscribe to the Thread, they receive notification of the same events, thereby providing an opportunity to identify and resolve conflicts on their own, while a small number of cross-mission synergies pass through the Router layer.
Similar to the Router layer, it is not necessary to limit each Worker Summit to a single session: when performing a complex single task, Worker can create a new Subagent, or it can itself be an Agent Team, which is transparent to the upper Router layer. This structure applies both to the coding scenario, while promoting the recurrence of multiple stand-alone issues, the evaluation of the PR and the development of identity without blocking each other; and to the personal assistant scenario: While only one single session chat page is usually available on the personal assistant interface, when users discuss multiple different topics simultaneously in the same dialogue box, the front-end single chat page is responsible for maintaining interactive continuity, and the bottom-end is used to assign workker to each topic in parallel to advance tasks and draft responses.
III. Event drivers: not according to instructions, environmental events entered and 4 steps allowed Agent to take the initiative
To be proactive, Super-agent needs to change the system-driven approach. The main input driving Agent is no longer a prompt typed by humans, 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 instructions to do so once more.
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-tier strategy that integrates the program with the model; how to route events to Walker through subscription and direct access mechanisms; how to use Inline & Spill and the chain to call back high-density injection into the model and to recall context as required; and how to use speculation to carry out forward action on the basis of 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, the delay and the cost of calculation would be unbearable. Drawing on the Fast Path/Slow Path ideas of computer systems, LLM reasoning can be seen as a flexible but high-cost Slow Path, while the solidization of well-defined and stable high-frequency judgements into certainty codes constitutes a low-delayed, low-cost Fast Path.
As a result, the first step after an event enters the system is filtering, with the goal of sifting noise with a certainty strategy before calling LLM, 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 strategy, as Fast Path: For certain conditions such as source, cluster range, user or robotic white list of events, rapid access checks are conducted directly by code, such as setting up separate “selections only” or “direct neglect” for different sources, so that most irrelevant messages are filtered before a model is called.
– Semantic Strategy, as Slow Path: A candidate for program level access, is given to LLM to determine whether action is required on the basis of a strategy prepared with prompt and context. Semantic layers also serve as natural language extension points for humans, facilitating easy access to prompt switches or new strategies.
Two-tier filter: first the program-level strategy filters most irrelevant messages, and then the semantic strategy.
2. Course of events: Follow-up events no longer revolve around Router, and then directly send Walker
The global Router layer introduced in section 2 is responsible for maintaining continuity across the channel, but if each subsequent incident assigned to the task is still to be forwarded through the Router layer, this global node will continue to bear a large load and the response of the push system will be delayed. Therefore, Fast / Slow Path also applies to filtered event paths. The global Router level is responsible only for the cold start-up and cross-mission coordination of new missions, and the follow-up 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 Router.
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
When the Router layer created the Worker Session based on an initial event in Thread, the Worker directly subscribes to 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, Solow 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.
Subscriptions and direct connections: the initial event created and subscribed through the Router Layer, and the same Thread follow-up events sent directly to the Worker
In addition, the subscription between Thread and Walker 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 incident under Thread goes 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 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, long run 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 more important as the system input shifted from a limited human prompt to a semi-structured event that continued to occur in the environment. Excessive infusion crowds out windows, dilutes the attention of the model, and infrequent infusions force the model to repeat the tools 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. Using the concept of compilation optimization and computer systems, the context injection design can be grouped into two basic operations. 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 refers to the retention of complete information beyond the window budget or low-frequency use outside of context window and the retention of references or summary only in the window for model reading on demand.
Combining the classic local thinking in the design of computer systems, the Inline & Spill can be used to inject events and gradually optimize tool call:
– Start with minimum information: initially only current object ID and content summary were provided.
– Locally, step by step information on Inline: Inline, which is likely to be used in the near future, is attached to context, with a closely related object ID, followed by a time- and space-based adjacent content, such as 50 words in front of the content, information on the proximity of the IM message and the response received, or a comment on the adjacent side of the review under the code review.
– Beyond the ceiling, Spill: set a smaller length limit for 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 out the excess and keep the re-reading portal, and the model needs to be called on to read the tool when it is complete.
In addition, after a large number of follow-up events go through Worker and the system has been operating for a long period of time to accumulate many historical tasks, the Router layer is neither able to put the full history of all tasks into its own context window, nor is it necessary to recover context when the user crosses the channel to initiate an old task. 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 previous information from the Router layer over a long distance.
Recall in the chain: each caller connects the ID of the next jumper, supporting the rollover of context along the reference lines
Specifically, the system assigns unique IDs to objects such as Trigger, Thread and Worker Session, and is closely linked to objects IDs when injected so that they form a reference map at the bottom. Since each caller follows the Inline & Spill itself and returns the summary and ID of the next jumper, the model can start from the current event and gradually return context as required by reference. For example, from a current message read in Thread, then from the inter-ID in Thread to the relevant Worker Summit, find another code associated with the Worker to evaluate Thread.
4. Early action: early backstage testing, valuable delivery
Drawing on speculative executive thinking in computer systems, Agent can attempt to reduce human waiting and intervention costs by consuming additional back-office calculations in advance of environmental signals when 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 a meeting or to-do message is received, Agent can check the scheduling conflicts in the back desk, gather relevant background information and prepare a draft response, which will be confirmed directly by the user after reading. The same is true in the development collaboration scenario. For example, the team has set up a silent recovery and repair strategy within the user base of DeepSeek Harness: When feedback was received from the group or changes were discussed, Agent first tried to reproduce and look for a rehabilitation programme in the background, and only after the problem had been identified and a simple rehabilitation programme had been found would the results be delivered to the user, otherwise the whole process remained quiet.
Example of speculative implementation: 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 continuity across the channel context, but there are two more things to be addressed by the actual interactive experience: to use a different rect Loop to keep backstages open for time, and to receive new instructions at any time in the session; and to match the bandwidth of different faiths with the usage habits of people.
1. Full-time interaction: backstage work, no front desk cards, new instructions 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-double-work model to a full-work model.
The classic rect Loop versus rect Loop
To this end, the team changed the time-consuming command from subtasktool call to a start() and stop() walk, constituting a rect Loop. Once the model has been called start() the "started" return is received and the loop no longer awaits the tool; after the back-office tool has been implemented, the system will post the final result as a new event message into the session; and the model can also voluntarily terminate the long back-office command based on the context call to stop() the execution.
As a result, the dialogue response from the front desk and the execution of the backstage mission were decoupled, and Agent was able to operate the time-consuming mission backstage while also responding to human input. New input is processed after the current reasoning step, without waiting for the backstage tool to be completed. The article revealed that this walk-through mechanism had been achieved in DeepSeek Harness but had not yet been implicitly activated.
Multi-channel interaction: small group chats with low interruption responses, high-intensity completion of PR mail
Different working channels have different information density and interactive habits, and system output needs to be matched. The lengthy reasoning process and 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, a 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 World Council, not directly exported to external channels, but under the unified responsibility of Router. On this basis, the system also requires access to the types of 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 send notifications when there is a need for decision-making or acceptance check, asking only direct questions and giving brief conclusions. The team validated a simple and valid mandatory provision: a single response does not exceed 100 words.
– GitHub, e-mails and documents, etc., are walk-throughs that focus on structured, high-infodensity, e.g. creating or updating a full background of questions by project specifications, changes and validation, or directly drafting structured mail and document summary in a personal assistant setting.
Category Anthropic's “brain separation”, computation, state and environmental decomposition
The existing local Agent defaults will advance the calculation of Agent Loop, the status of the session that needs to be permanently preserved, 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.
For Super-agent to be permanently online and to have flexible access to all types of real work environment, two steps of decomposition can be used to draw on 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 mono-cycle limit and to achieve a permanent cloud online; the second step would be to decorate the cloud-end Agent Loop from the heavy state, to keep the real work environment in place and to support cross-equipment access.
The article states that 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 scenes: the Anthropic article describes the hosting service and focuses on the creation of sandboxes on demand and the customer ' s VPC in-house resources; the first access here is to personal machines that users use on a daily basis, possibly intermittently online, with no amendments submitted and no local documentation. Thus, this design supports both the BYOM, which connects developers or personal computers used by users on a day-to-day basis to 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, choosing the environment for the execution of the order and acquiring 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 triggered by cloud-end Agent and performing tasks that need to be performed on the device.
Separability of storage and enforcement of the environment
VI. RESPONSIBILITY OF THE INTERNAL WATCHDOG: LOOKING AT INSTITUTIONS AND 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 loop 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 and forming an external Controll Loop. In addition to addressing infrastructure failures such as faulty interfaces and failed state recovery, Wachdog will be able to determine whether 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, while occasional external malfunctions continue until normality is restored.
Since 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 modify the behaviour of the main system online, for example by adding or deleting prompt and adjusting the trigger rule.
VII. Preliminary experiments: two-layer structures are faster and more stable, 30% token straight through province, and Router's decision is cheaper by blockage.
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 batch separately. Since the experiment was based on synthetic loads and simplified environments, some of the settings could be made more rigorous, and the results below are for preliminary reference only.
1. Absorption experiments: faster and more stable, straight without 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, and the coding was replaced by a time-consuming tool, five times each.
The cumulative arrival curve for work requests and the cumulative completion curve for four scenarios
Five times for each project to be duplicated, while task completion refers to the time taken from the request to the result message
Super-agent's p50 and p95 are 12.4 and 15.7 minutes, respectively, significantly superior to the single-session with the Subagent tool. The latter were affected by prompt: the neutral hints ran without calling Subagent at the next five times, all in the main Session and repeatedly interrupted by new news, p. 95 for 29.5 minutes; the first five assignments were given on a priority basis, with four assignments, which were still slower than Super-agent, 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 was largely the same, but Router's decision was increased by about 30 per cent, cache Ztoken was increased from 23.23 million to 317.7 million, an increase of about 37 per cent, and did not go up at the rate, but cost Router considerable token and reasoning.
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 adjusted the real model, Walker used the Mock model, and Trigger arrived at a rate of about 1 to 40 per minute.
The result was a rise in the average number of bats from 1.0 to 2.8, an increase from 2.5 to 3.9 seconds for single requests, slower than the size of the bats, and a reduction in the reasoning time for individual decisions to share from 6.4 to 1.6 seconds.
This shows that Router automatically combines the backlog to increase the amount of consumption 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 taken for a single request and the time allocated for a single decision are different from the rate of Trigger's arrival.
VIII. The four tracks remain unresolved: architecture expansion, human collaboration, A2A, security privacy
The five modules described in sections 2 to 6 constitute the basic structure that underpins Super-Agent ' s operation, and the experiment in section 7 also validates the multitasking effect of the core dispatch and routeing mechanism.
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 scopes, there are still issues 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 extended, when the single Router load was overstretched, when the particle size was, when the direct communication between Worker was inconclusive, and how the long-term memory of the inter-monthly journey was also a bottleneck; and, second, how the chat window was not necessarily the final form, with interaction taking place more in such areas as GitHub, where there was also a need to support mid-way intervention, take-over and real-time synergy.
Third is how the context boundary is divided by the enlargement of the organization, with A2A communications and collaboration to be explored between multiple isolated cases; fourth is security and privacy, with cloud-based Agent access-side evidence at risk of invasion and prompt injection, and also the need for Agent not to access the evidence itself.
Concluding remarks: Five main modules to free the Agent people ' s attention bottlenecks
The article does not introduce entirely new theories, but uses the classic engineering idea of computer systems for the construction of the Agent system to achieve evolution, but design thinking has long-term reference value. The internal Super-agent example based on DeepSeek Harness has been running on a continuous basis, with participatory issues resuscitation, code review and Harness iterative.
As model execution line fewer manual interventions, bottlenecks turn to human attention. Two layers of structure, event-driven, walk-through interaction, memory separation, and external Wackdog take over session management at the bottom, synchronized with context, allowing people to move up to decision-making and acceptance check.
Agent moved from a passive dialogue window to an on-line, autonomous collaborators: Personally, it works as a cross-equipment assistant, team integration and development of workflow. The team believes that a more autonomous way of working is expected to become normal. Part of the design has been implemented in 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 Atlas. All rights belong to the original author.