DeepSeek团队提出Super-agent 设计，迈向更自主的Agent系统

原创

网络安全透视镜
网络安全透视镜

网络安全透视镜

2026年11月1日 11:59
新加坡

去阅读

QUOTE

单会话 Agent 只能跑单条探测链，决定渗透效率上限的是 调度架构、上下文回收和空转纠偏 。

昨天 DeepSeek Harness 团队发了一篇讲 Super-agent 架构 的文章，同时放出了一个验证原型 dsh-superagent-prototype 。这次不是发新模型，也没有推正式产品，整篇都在聊一件事：如果要把 Agent 从“问一句动一下的工具”改成 长期在线、自己盯事件的系统 ，底层到底该怎么搭。

通篇看下来，基本没怎么谈模型推理能力，全在 算系统工程账 ——路由怎么分层、上下文怎么当缓存使、慢任务怎么异步化、状态怎么和机器解耦、模型卡死了谁来拉一把。

我把原文顺了一遍，发现里头拆出来的双层架构、Inline & Spill、异步工具、Watchdog 这几块，正好撞上了平时折腾 渗透测试 Agent 最头疼的几个坑。下面先把 DeepSeek 这套设计按模块捋清楚，最后聊一聊如果把这套东西搬到挖洞或渗透 Agent 上，能解决哪些实际问题。

本文看点

01

Router 管全局、Worker 干脏活的双层隔离

02

把上下文窗口当缓存使与链式召回

03

搬到渗透测试 Agent 上能治哪五个硬伤

01

BOTTLENECK

为什么单 Session 架构跑不动了

过去一年 Coding Agent 已经把 单任务闭环 跑通了，模型自己调工具改代码、跑测试，人只需要在最后拍板和验收。顺着这个趋势往下走，自然就会想做接入 IM、邮件、日程和代码平台的个人助手或团队 Agent，让它 一直挂着、有事自己动 。

但现在主流的 Agent 还是绑死在 单个 Session 上，窗口和窗口之间互不相通。这在实际干活时有四个绕不开的麻烦：

1

同时干几件事就得手动切窗口。

2

哪个窗口聊到了哪一步，全靠人脑自己记。

3

一个人盯着三五个活跃会话基本就到极限了。

4

单个任务能做多深看模型，但同时能推多少摊事，卡死在人的精力上。

现在很多做法是在本地单会话 Agent 外面套一层 CLI、MCP 或者消息连接器，把群聊、告警接进来。跑起来就会发现， 单会话同步阻塞、多任务上下文串台 、电脑一合盖 Agent 就失联，最后还是得人天天去伺候它。

DeepSeek 把他们想做的形态叫 Super-agent ：拆掉 Agent 和“单次手动会话”的绑定，跨会话留住上下文，多条任务并行推且互不污染，能长期挂着跑。原文给了一个内部在跑的例子——同一个实例横跨 IM 和 GitHub 推进开发任务，平时自己盯着公共群里的反馈，没人提及它也能 自己去翻代码定位根因 ，顺手提个修复 PR。

为了撑起这种形态，系统得同时做到四点：

连续

刚才在 IM 里敲定用方案 A，转头在 GitHub PR 评论里改主意要用方案 B，Agent 得知道这是一件事，自己改方向，不用人去操心“那段背景到底在不在当前窗口里”。

高效

秒回，能同时跑多个重任务，不用等上一条命令跑完才能说下一句话。

主动

不用人发一条指令动一下，自己盯环境事件，该出手时出手，没事时闭嘴。

持久

全天候在线，直接嵌在真实工作流里，挂了能自己拉起来。

一个 ReAct Loop 肯定撑不起这四个要求。原文直接搬了 传统计算机系统里的老手艺 ，搭了五个模块出来：用双层架构保连续和并发，用事件驱动做主动响应，用异步和多信道改造交互体验，把计算、状态和执行环境拆开保持久在线，最后在系统外挂一个 Watchdog 做异常自愈。

02

ARCHITECTURE

双层架构：Router 管全局，Worker 干脏活

既要上下文连续，又要并发吞吐量， 这两件事天生矛盾 。

如果把所有事件全塞进同一个 Session，上下文最全，但受限于单 ReAct Loop 的串行执行， 一个慢任务直接堵死后面所有事 ，而且几个任务的中间过程混在一个窗口里，模型很容易越跑越懵。反过来，如果每来一条事件就新开一个独立 Session，并发是拉满了，但 会话之间是瞎的 ，干完活还会好几个实例同时跑出来回消息，人直接看晕。

DeepSeek 的做法是拆成 Router 和 Worker 两层。

Router 层 是常驻的全局总管，所有外部交互都由它接，负责把控跨任务信息和全局决策，相当于整个系统的序点、协调点和全局记忆。它只干三件事： 跟人说话、派活、跨任务通气 ，自己绝不下场干具体脏活——原文甚至说 Router 可以连 Bash 工具都不挂。实现上就是一个常驻的单 LLM Session，而且不少路由逻辑直接用代码就能判，未必每次都要过模型。

Worker 层 就是干脏活的独立会话。每个 Worker 上下文隔离，挂全套执行工具 ，配能力最强的模型，专心啃完手头那一个任务。Worker 不直接跟人说话，里头大段的推理和调工具过程也不往外吐，干完活或者卡住了只向 Router 汇报，由 Router 统一对外回话。

这里顺带区分一下它和常见 Agent Team 的差别：一般的 Agent Team 是为了啃单个大任务，在内部做步骤拆解和角色分工；而 Super-agent 的 Router 只管任务和任务之间的关联与分发，不插手单个任务内部怎么干。反过来说，如果一个 Agent Team 的主会话自己不动手、只对外说话、把不同差事甩给底下成员各自跑完，那它其实就是这种双层结构。

Router 的批处理

Router 干的活天然是“长输入、短输出”。上一轮模型还在推理的时候，外头新来的事件可以先攒着，等下一轮调用时 把攒下的多个 Trigger 一次性全喂进去 ，这就是批处理（Batching）。

平时消息少，来一条处理一条，延迟低；赶上消息扎堆涌进来，多个 Trigger 合并进一次请求，Prefill 阶段并行算掉，总耗时的涨幅远小于攒下的事件数。在模型窗口和单轮判别能力撑得住的前提下， 积压越多，均摊到每个决定上的耗时反而越短 。

真到了单个 Router Session 扛不住的时候，再往多层过滤或水平切分（Sharding）上走。但 切得越碎，跨分片的记忆就越散 ；切得越粗，吞吐就越容易见顶。在全局长程记忆没彻底解决之前，这笔账只能根据业务规模去平衡。

Worker 怎么协同

多个任务同时跑的时候，Worker 各自推各自的，平级之间一般不用直接通气。真要撞车，通常也是 撞在共享环境上 （比如两个 Worker 同时去改一个 PR）。只要让它们订阅同一个 Thread，两边都能收到事件，自己就能发觉冲突并协商处理，少部分跨任务的协调再由 Router 传个话。

Worker 内部也不一定就只有一个会话，它自己也能拉 Subagent 或者组个小 Team，对上头的 Router 来说完全透明。像在一个聊天框里同时聊好几个不搭界的话题，前端看着是一个窗口，后端其实已经 按话题拆给好几个 Worker 在跑了。

「Session 应该藏在系统底下当实现细节，别甩给用户当管理负担。」

以前是拿技术上的上下文窗口直接当面向用户的项目文件夹使，现在双层架构把这两件事拆开了，怎么向人展示进度、让人怎么插手，完全可以按习惯重做。

03

EVENT-DRIVEN

事件驱动：过滤、直通与上下文当缓存使

Super-agent 平时吃的不是人敲进去的 Prompt，而是环境里源源不断冒出来的 半结构化事件 （ Trigger ）：群消息、邮件、日程提醒、Code Review 评论、CI 报错。一条事件从进来到处理完，要过四道关。

先过筛子：Fast Path 与 Slow Path

真实工作环境里的事件流，绝大部分是跟 Agent 无关的噪音。要是每条群消息、每次构建通知都拉起大模型判一遍， 账单和延迟都得炸 。

所以前面挡了一层两级过滤。第一级 Fast Path 纯用 代码写死规则 ：看事件来源、看在哪个群、看发信人在不在白名单、看有没有明确触发词，先把明显无关的直接拦掉，剩下的标成候选。第二级 Slow Path 才把候选事件喂给大模型，结合上下文判断到底要不要接这活、怎么接。语义层用 Prompt 控制，想加个新规矩或者关掉某类响应，改几句提示词就行，不用动代码。

订阅与直通：别事事都找 Router

一个任务派给某个 Worker 之后，后续围绕这件事的讨论如果还得条条经过 Router 转手，Router 迟早变成 传话筒瓶颈 。

解法是引入 Thread （围绕同一个对象串起来的事件流，比如同一个 PR、同一个邮件串、同一个群话题）。Router 根据初始事件拉起 Worker 后，Worker 直接订阅这个 Thread。后面这个 Thread 里再有新动静，程序 直接走 Fast Path 塞给对应的 Worker ，绕开 Router；只有当新消息超出了原本的任务边界，Worker 才退订并甩回给 Router 重新派发。还没人认领的新事件则继续走 Slow Path 归 Router 管。

Thread 和 Worker 是 多对多的 。一个 Worker 能盯好几个关联 Thread，一个 Thread 也能被多个 Worker 同时盯。输出口还是收紧在 Router 手里，Worker 报结果，Router 同步记忆并对外说话。

Inline & Spill：把上下文窗口当缓存管

「浪费上下文窗口，就是浪费模型的智能。」

原文这句话说得很实在。他们管上下文的路子，基本就是操作系统的缓存管理——分为 Inline 和 Spill 两个动作。

近期大概率要用到的高价值信息， 直接塞进当前上下文（Inline） ，省得模型再调一次工具去读，减少来回折腾的轮数；超长或者低频的信息 留在窗口外头（Spill） ，上下文里只留个引用 ID 或短摘要，模型真用得着的时候再自己调工具拉全文。

实际跑起来是渐进式的三步：

1

一上来只给最少的必要信息：当前对象 ID 加一段摘要。

2

顺着局部性往里 Inline 相邻信息：先带上强关联对象的 ID，再把时间和空间上挨着的内容塞进来——比如前 50 个字、群聊里紧挨着的前后几句、被回复的原消息、PR 评审里同一串讨论的上下文。

3

超出长度预算的直接 Spill：截断超长部分，留个续读入口，按需再读。

链式召回（Chain of Recall）

既然大量后续事件都直通 Worker 了，Router 脑子里肯定记不全所有任务的历史细节。那用户隔了半个月在另一个群里突然提一嘴旧任务，Router 怎么找回场子？

靠的是给每个 Trigger、Thread、Worker Session 都发一个 唯一 ID ，每次往上下文里塞信息时，顺手把强关联对象的 ID 也 Inline 进去，底下自然就结成了一张 引用图 。等需要捞历史的时候，从当前消息出发，顺着内联 ID 一跳一跳往回摸：

CHAIN OF RECALL

当前消息 → 所在 Thread → 干这活的 Worker Session → 该 Worker 当时关联的另一条代码评审 Thread。每跳一步都把下一跳的摘要和关联 ID 带出来，历史上下文就能按需展开了。

投机执行：先在后台把活干了

借用了处理器里的 Speculative Execution 思路——还不确定用户最后要不要，看到环境信号就 先在后台偷跑起来 ，拿富裕的后台算力去省人的等待时间。算出来的东西有用就直接端上来，没用就悄悄扔掉。

比如收到会议邀请邮件，后台先把日程冲突查了、背景资料搜好、回信草稿写好，人看一眼点个确认就能发。他们内部研发群还挂了个 “静默复现并修复”策略 ：群里有人提嘴 bug，Agent 在后台自己去尝试复现和修代码，真复现出来并且改法简单，才把结果甩出来；没搞定就全程装不存在，不出来添乱。

04

INTERACTION

交互改造：异步工具与按信道说人话

传统的 ReAct Loop 一调 run() 就卡死，工具没跑完之前，你跟它说什么都没反应。

DeepSeek 把耗时工具改成了异步的 start() 和 stop() 。模型调 start() 启动后台任务，工具立刻回一个 Started ，ReAct Loop 继续往下走，不傻等；等后台任务跑完了，结果 作为一条新事件塞回会话 ；跑太久或者方向不对，模型还能调 stop() 把它掐掉。这样后台在跑长任务的时候，前台照样能跟人正常搭话。原文提了一嘴，这个机制在 DeepSeek Harness 里已经写好了，只是还没默认开。

对外说话也得看场合。既然 Worker 已经把啰嗦的推理和工具调用全闷在自己肚子里了，Router 对外输出就可以按信道定死规矩：在 IM 里要像正常同事一样少废话，只在要拍板或交活时出声，原文直接定了条死规矩—— IM 单次回复不超过 100 词 ；到了 GitHub PR、邮件和文档这种异步场景，再把问题背景、改了哪、怎么验证的写全乎。

05

INFRASTRUCTURE

存算与环境分离：云端跑脑子，本地挂 daemon

本地 Agent 最大的毛病就是 计算、状态和环境全绑在一台电脑上 。电脑一休眠就断片，也没法跨机器干活。

拆法分两步。第一步把计算和状态拆开：Agent Loop 放到 云端无状态容器 里跑，随时能扩缩容、能重启；Session 状态落数据库，保证不丢记忆，先把全天候在线解了。

第二步把云端计算和执行环境拆开。模型干活总得碰代码库、本地文件、内网服务和特定工具链。如果全在云端起沙箱重建环境， 本地没提交的改动、私有凭据、内网依赖 根本同步不过去，成本还高；如果逼着用户把所有家当全搬上云，又没人愿意干。

他们的方案是在机器上只装一个极轻的 daemon ，不存任何会话状态，只管接命令、跑命令、回结果。 脑子（Agent Loop）在云端跑，手（重状态环境）留在原地 ，云端按需通过统一接口去调端侧环境。

这跟 Anthropic 提过的“脑手分离”是一个路子，区别主要在落地的场景：Anthropic 盯着的是云上托管服务、按需拉起沙箱和客户 VPC 资源；DeepSeek 这篇更关心人每天在用的 个人电脑、开发机这种时断时续的设备（BYOM） ，怎么在机器重新上线时自动接着跑任务，顺手用上本地没提交的代码和凭据。

06

WATCHDOG

Watchdog：专盯“假装在干活”的外部回路

一个长期挂着的系统，不能指望它自己发现自己疯了。传统用脚本查进程活没活着也没用，因为 Agent 出问题很少是进程崩掉，绝大多数时候是进程活得好好的，但模型在里头 原地打转、推理跑偏、或者死磕一个报错半天没进展 。

所以在主系统外头单独挂了一个 Watchdog Session ，用定时消息推着走。它既盯基础设施报错和状态恢复失败，也盯着 各个 Worker 到底有没有干出正经进展 、方向有没有歪。一旦发现不对劲就下场修，遇到外部偶发故障就一直复查到好为止。

因为 Watchdog 自己也是一个 带全套工具的 Agent Session ，维护的人可以直接用大白话问它“刚才怎么挂的”，或者直接吩咐它去改主系统的提示词和触发规则。

07

EXPERIMENTS

实验数据：靠 Prompt 让模型自觉派活，基本不靠谱

原文声明了实验是在 合成负载和简化环境 上跑的，主要看个趋势。

消融实验模拟了群聊加 GitHub CI 消息流，单轮大约 300 条消息，里头混着 20 个正经干活请求，剩下全是闲聊、追问、叫停和 CI 通知。对比了四组方案（每组跑 5 次）：完整 Super-agent、砍掉直通的 Super-agent、单 Session 挂 Subagent 工具配中性提示词、单 Session 挂 Subagent 工具配“催着它派活”的提示词。

里头有两个很说明问题的细节：

中性提示词：一次都没调过 Subagent

提示词写“合适的时候可以用 subagent”时，5 次实验里模型全自己硬扛，结果在主会话里不停被新消息打断，耗时直接翻倍。

明确催着派活：还是会手痒自己干

改成“每条消息都会打断你，优先把活派给独立 subagent，自己只干小事”之后，5 次里有 4 次派了活，但还是有 1 次模型自己觉得“这活挺小的”，决定亲自动手，当场拉出一条长尾。

结论很直接：靠写提示词指望模型自己临场判断要不要拆任务，是兜不住底的。双层架构能稳住，是因为在系统层定死了规矩——Router 根本不许干具体活，Worker 根本收不到无关 Thread 的闲聊。

代价当然是花更多 token。多维护几个独立会话， 读缓存 token 肯定比单 Session 高 ，本质上是拿 token 换更短、更稳的交付时间。另外，把“订阅直通”砍掉之后，完成时间没怎么变，但 Router 的决策次数多了约 30%，总读缓存 token 从 2323 万涨到了 3177 万（多了约 37%）——说明 直通机制主要是帮 Router 省钱省推理开销 。

另一组批处理压测，把 Trigger 速率从 1 条/分钟拉到 40 条/分钟：

消息越密，自动合批越多，单次耗时只从 2.5 秒涨到 3.9 秒， 均摊到每个决定上的时间反而从 6.4 秒掉到了 1.6 秒 。所以作者判断在他们目前的团队规模下，单 Router 靠自动合批完全扛得住，犯不着太早去做水平切分把全局记忆切碎。

08

PENTEST AGENT

放到渗透测试 Agent 上，这套架构能解什么痛点

把前头这七节看完，平时自己写自动化挖洞脚本或者折腾渗透 Agent 的同行应该都能对上号。

现在咱们见到的绝大多数渗透测试 Agent，底子还是 “单会话 Coding Agent + 一堆安全工具 MCP” ——给个域名或资产列表，模型在同一个 ReAct Loop 里调 subfinder、跑 ffuf、拉前端 JS、拼 curl 发包。拿去打个靶场或者单站小目标看着挺热闹，一放到真实的 SRC 挖掘或大范围授权测试里，马上全露怯：

1

一个端口扫描或者目录爆破跑慢了，整个会话直接卡死在那等。

2

多开几个窗口扫不同子域，A 站抠出来的通用 SSO 票据、AK/SK 或者签名盐值，B 站的窗口根本不知道。

3

抓回来几兆的 webpack 前端包和满屏的 403 拦截页，三五轮下来上下文窗口直接塞爆，模型开始失忆，连最开始定的测试范围都忘了。

4

最要命的是“空转装忙”——对着一个所有接口都回同一句“请重新登录”的网关，或者对着一个静态同构壳站点，挨个路径喷单引号，工具调得飞起，半小时出不来一个有效差分。

如果把 DeepSeek 这套设计搬过来，刚好能把这几个工程硬伤挨个按住。

1. 用 Router / Worker 双层隔离，解决“主会话被探测噪声淹没”

渗透测试天生就是 “全局资产调度 + 单点深度突破” 的双层活。如果像实验里那样只靠单 Session 加 Subagent 提示词去跑，模型极容易在看到某个登录框或某个接口时觉得“这顺手打一枪就行”，结果在主会话里连发几十个测试包，几千行 HTTP 响应一塞进来，主控立马变成单点死磕，原本排在队列后面的几百个子域再也没人管了。

照着双层架构改：Router 层干脆不配发包、扫描和浏览器工具，它手里只攥着三样东西—— 全局资产与种子队列 、 已覆盖站点与接口状态 、 跨站共享钥匙表 （在边缘站拿到的测试账号、硬编码密钥、通用 Token、加签逻辑）。每清洗出一个存活的业务站点，Router 就派一个隔离的 Worker Session 下去，把全套浏览器、抓包、发包工具挂给 Worker，让它按单站测试矩阵把这个站啃透。

单站测试里产生的大段 404/403 噪声、前端源码分析过程， 全烂在那个 Worker 自己的上下文里 ，干完了只把“本站接口清单、已测完类型、新发现的同集团业务域名、确认打穿的漏洞报告”报回给 Router。Router 拿到新域名或新凭据，更新全局队列，再拉新的 Worker 接着滚。

2. 用 Inline & Spill 和链式召回，治好大包与扫描结果撑爆窗口

做渗透 Agent 最吃上下文的从来不是推理，而是 原始报文和前端代码 ——一个前端 chunk 动辄两三兆，一次目录扫描几千行，全往窗口里塞，几轮下来既烧钱又把模型注意力带偏。

按 Inline & Spill 的路子管上下文：所有原始 HTTP 响应包、下载下来的 .js 源文件、扫描原始输出一律落盘（Spill），每次往模型上下文里塞的只是一行摘要（Inline）：请求路径、状态码、响应包长度、提取出的新接口列表、或者报错信息的前 50 个字符。模型只有看到某条请求的长度或状态码 跟基线有明显差分 ，才按 ID 调工具去读那一段完整的响应体或对应的 JS 函数。

而链式召回放在多资产渗透里尤其好用。比如打到 C 站时碰到一个带前端加密签名的接口，当前站点混淆太重没找到盐值，但每个测过的资产、JS 文件、提取出的配置项都挂了唯一 ID 和关联引用，模型完全可以顺着 “当前接口参数特征 → 同集团共享前端框架名 → 早期测过的边缘站 A 的 Worker 记录 → 当时抽出来的未混淆 env.js” 一跳一跳把签名密钥捞回来，不需要在 Router 脑子里时刻背着所有站点的 JS 原文。

3. 用异步 start() 和事件直通，把慢扫描、外带回显和业务深挖并行起来

渗透测试里到处都是耗时没准谱的活：全端口扫描、大字典目录 fuzz、时间盲注确认、还有异步 SSRF 或盲 XSS 等待外带平台（DNSLog / HTTP 回调）回显。同步阻塞模式下，发完 payload 等回显的那几分钟里，Agent 只能干瞪眼。

改成异步工具加事件驱动之后，跑 nmap、跑大字典、或者挂起一个外带监听，直接调 start() 丢进后台立刻返回。在等扫描结果或者等 DNSLog 回调的空档，同一个 Worker 完全可以 先去抽前端 JS 里的接口清单、测逻辑越权和未授权访问 。等后台扫出了新的高危端口，或者外带平台收到了目标打过来的请求，系统把它包装成一条 Trigger 事件直通推回给订阅了该目标的 Worker，模型当场就能顺着这条回显把漏洞链往下坐实。

要是再往外扩一步，把证书透明度（ crt.sh ）新增、GitHub 敏感信息监控、测绘引擎定时增量接成外部事件源：先用 Fast Path 确定性规则做去重、去 CDN、去非存活和股权范围过滤，筛出真正在授权范围内的新上线业务，再走 Slow Path 唤醒 Worker 进站测一轮，这就直接是一套 7×24 小时自己盯资产变动的持续渗透系统 。

4. 用端侧轻量 daemon，打通本地浏览器态与内网跳板机

安全测试对执行环境的要求比写代码刁钻得多：有的接口过了人机验证，必须复用测试人员 本地浏览器里已经登进去的真实会话 ；有的目标在客户授权的内网里，必须走内网跳板机或者挂特定 VPN 才能通；有的公网探测又希望分散在不同地域的云节点上跑。

把云端 Agent Loop 和端侧执行环境拆开，在本地电脑、内网跳板机、云端发包节点上各自挂一个不存状态的轻量 daemon，这个问题就顺了。云端大脑统一管测试进度和漏洞线索，碰到需要过复杂登录态的站点，指令下发到本地电脑的 daemon 借用真实浏览器上下文；拿到内网凭据需要横向移动时， 无缝切到内网跳板机的 daemon 执行命令 ，不用费劲在云端沙箱里去复刻复杂的内网网络拓扑和本地证书环境。

5. 外挂 Watchdog，专门掐断“死磕 WAF 和空壳站”的空转

写过挖洞 Agent 的人应该都深有体会：模型在实战里最烧钱、最耽误事的不是工具报错，而是 死脑筋空转 。比如碰到一个统一回 200 但正文全是拦截页的 WAF，模型在那里换着花样做 URL 编码、双写、插注释连打上百发；或者碰到一个只有登录页、背后连业务 API 都抽不出来的死壳站点，还在那一遍遍试默认口令和目录字典；又或者同一套 CMS 建的二十个同构镜像站，它在每个站上都老老实实跑一遍全量测试矩阵。

靠在主会话 Prompt 里写“遇到空转请及时跳过”，效果就跟 DeepSeek 实验里写“请优先使用 subagent”一样，模型打嗨了照样忘。

在主系统外头挂一个独立的 Watchdog Session ，每隔 10 到 15 分钟巡检一次各 Worker 的硬指标：这段时间里有没有抽出新的业务接口？有没有打出除统一登录拦截图之外的响应差分？是不是一直在重复触发同一个错误码？当前站点跟之前已经测完的站点是不是同构皮肤？一旦判定某个 Worker 是在瘦壳或死胡同里空耗，Watchdog 直接 从外部调 stop() 掐掉这个线程 ，把该站点标成 cold，督促 Router 切到队列里的下一个未覆盖目标。

∞

THE END

结语

回看整篇文章，DeepSeek 团队其实没发明什么新概念，就是把路由分层、缓存局部性、异步 IO、存算分离、外部看门狗这套在分布式系统里验证过无数遍的老手艺，严丝合缝地搬进了 Agent 架构里。原文也特地说明了，相关的 dsh-superagent-prototype 只是验证技术路线的原型，还不是正式产品。

「别再指望靠写一份几千字的超级 Prompt，让单个会话自己学会合理派活、自己扛住几兆的扫描噪声、自己发觉在死胡同里空转了。」

对正在折腾安全 Agent、自动化渗透或者漏洞挖掘系统的人来说，把全局调度和单站深挖从架构上劈开，把原始报文挡在上下文窗口外头按需拉取，在主回路外头加一个不讲情面的 Watchdog，这些 系统工程上的硬框框 ，比在单会话提示词里雕花管用得多。

END

我是 网络安全透视镜，专注 AI 安全与漏洞挖掘。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。