§8.1如何扩展双层架构
Router 何时水平切分、粒度如何，同层 Worker 何时需要直接通信、用什么拓扑，都无定论。与模型协同设计（针对事件判别、批量分派、上下文召回做专项训练）是可能方向；跨月以上的长程记忆是主要瓶颈。
以 Coding Agent 为代表的单任务 Agent 已经证明：模型能够使用工具解决复杂问题，且越来越少需要人类持续监控和逐步干预。随着人在底层执行中的参与减少，人的角色正逐步上移到更高层的决策与验收。
Agent 仍以单个 Session 为基本单位，不同 Session 彼此独立。并行推进多项工作时，人必须手动切换并记住各会话的上下文——据观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。
把「维护全局连续性」与「高并发执行」从人的注意力里接管过来：Agent 成为跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。这种形态与系统架构称为 Super-agent。
单个 ReAct Loop 无法同时支撑这四个特征，底层需要一套相应架构。
直接在 IM、GitHub 评论等熟悉界面交互，感觉始终只存在一个 Agent。先在 IM 上定方案 A、随后在 PR 评论里改成方案 B，它能理解并调整执行方向。
交互响应迅速，同时能并行、高质量地完成多个复杂任务。不必等上一条命令或任务完成，就能接收下一条指令。
不等用户逐条下达指令，持续观察环境事件并推进值得处理的事项；不需要介入时保持安静。例如在无人 @ 的公共群聊里主动定位根因并提交修复 PR。
始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。
每条事件都进同一 Session，上下文最连续，但受单个 ReAct Loop 串行限制、细节混杂；每条事件都新开会话，吞吐最高，但缺少全局上下文、结果割裂。解法是分层：Router 管全局连续性，Worker 管并发执行。
常驻、轻量，是所有跨任务信息与决策的汇总点——全局序点、协调点与记忆。不执行具体任务，甚至不配 Bash 工具。
上下文隔离、挂载完整执行工具、专注单一任务，通常配能力最强的模型；不直接对人，由 Router 统一回复。
上一轮推理期间积压的 Trigger 合并进下一次调用，Prefill 阶段并行计算，单次耗时增长远慢于 batch 大小。
Session 应当是系统的实现细节，而不应是用户的认知负担。— 原文 §2 双层架构
让 Agent 主动起来，先要换驱动方式：群聊消息、邮件与日程、评审评论、CI 结果这类半结构化环境事件称为 Trigger。真实事件流「高噪音、低触发率」，逐条调模型承担不起——先过滤，再判断。
针对事件来源、群组范围、用户或机器人白名单等确定性条件，直接由代码做快速准入：对不同来源分别设置「仅响应明确请求」「作为候选事件」或「直接忽略」，在调用模型前滤除大部分无关消息。
通过准入的候选事件交给 LLM，由它依据提示词策略与上下文判断是否需要行动。这一层同时是面向人类的自然语言扩展点——随时可用提示词开关或新增策略，不必改代码。
过滤的目标是在调用大模型之前，先用确定性策略筛除噪音，只把需要语义理解的候选事件交给模型。
同一个 PR、同一个 IM 话题或同一封往来邮件串下的连续事件构成一条 Thread。初始事件经 Router 建 Worker 并订阅后，后续事件由程序直接发往该 Worker；Router 仍观测全部事件，但只判断尚未被订阅的新事件。
订阅是多对多的：一个 Worker 可订阅多个 Thread，同一 Thread 也可被多个 Worker 订阅——新事件同时直通给所有订阅者，让它们无需点对点通信也能发现彼此的操作。
把上下文窗口当 Cache：近期很可能用到的信息直接内联，超出预算或低频的完整信息外置、只留引用与摘要。
Trigger、Thread、Worker 各有唯一 ID，注入时内联下一跳关联对象的 ID，底层因此构成一张引用图：从一条消息找到所在 Thread，再找到相关 Worker 与它关联的另一个评审 Thread，逐跳按需展开。
结果还不确定时，先按环境信号在后台尝试：群里有反馈就先复现、找修复，确认问题且方案简单才交付，否则全程保持安静。结果有价值就交付，没有价值就丢弃。
模型也可调用 stop() 主动终止过长的后台命令。该机制已在 DeepSeek Harness 实现，尚未默认开启。
像人类同事一样，只在需要决策或验收时发通知；只问直接问题、给简短结论。一条验证有效的硬性规定：单次回复不超过 100 词。
结构化、高信息密度的异步交付：创建或更新 PR 时按项目规范写清问题背景、改动说明与验证结果；个人助手场景直接起草结构化邮件与摘要。
任务中冗长的推理与密集的工具调用都被隔离在 Worker Session 内部，不直接输出到外部信道；对外只由 Router 层统一说话。
本地 Agent 把计算、会话状态与执行环境绑在同一台设备上：设备休眠或离线，Agent 就停摆。按存算分离的思路分两步解耦。
真实环境常含未提交的本地修改、私有凭据、内网服务依赖与特定工具链；在云端重建成本高且易遗漏，要求用户整体迁移也不现实。
Bring Your Own Machine：日常开发机、个人电脑、托管机器与按需环境都能接入；某台设备重新上线后，云端 Agent 可自动触发并完成需在该设备执行的任务。
思路与 Anthropic 提出的「脑手分离」一致：harness 保持无状态，会话日志存放在 harness 之外，通过统一接口按需接入执行环境；区别在场景——先接的是日常使用、可能间歇在线的个人机器。
长期在线的分布式系统很难只靠主系统内部逻辑保证可靠，需要在主系统之外引入独立的外部控制回路（Control Loop）。
在主系统外部配置独立的 Watchdog Session，由定时消息驱动，构成外部 Control Loop；处理接口报错、状态恢复失败等基础设施故障。
许多异常不是进程崩溃，而是模型陷入无效循环或偏离目标。Watchdog 还要由模型判断各 Worker 是否有实质进展、方向是否偏离整体目标；遇到外部偶发故障则持续复查直至恢复。
它本身也是具备完整工具能力的 Agent Session：维护者可以用自然语言询问故障原因，也可以让它在线修正主系统行为，例如增删提示词、调整触发规则。
它监控的不只是基础设施是否存活，还包括任务本身有没有在推进——这是传统的进程探活与监控脚本给不出的判断。
单次实验约 300 条消息，其中约 20 条为工作请求；编码工作用一个只消耗时间的工具代替，因此衡量的是调度与协作能力，而非单任务执行能力。每种方案重复运行 5 次。
Super-agent 以更多 token 换取更短且更稳定的完成时间。
直通机制不提高完成质量与速度，但为 Router 省下可观的 token 与推理开销。实验基于合成负载与简化环境，仅作初步参考。
这套系统能以较低复杂度运作，很大程度源于当前阶段的一系列工程与场景简化。超出简化范围后，四个方向仍待解决。
Router 何时水平切分、粒度如何，同层 Worker 何时需要直接通信、用什么拓扑，都无定论。与模型协同设计（针对事件判别、批量分派、上下文召回做专项训练）是可能方向；跨月以上的长程记忆是主要瓶颈。
底层会话不再对应界面会话后，任务呈现与项目管理成了新的产品问题。以聊天窗口为中心有路径依赖，交互可能更多发生在领域特化界面；过渡期内如何兼顾中途干预与后台自主推进，同样待探索。
配备 Super-agent 实际上是在划分上下文共享与隔离的边界：需共享的共用实例，需隔离的各自配备。多个彼此隔离的实例之间，跨边界协同就是 Agent 间通信（A2A），安全可靠的实现仍需探索。
云端 Loop 一旦被入侵或提示词注入攻破，连接的全部端侧设备都面临被控制的风险；即使未被攻破，凭据进入模型上下文也会泄露——需要让 Agent 在不接触凭据本身的前提下使用凭据。
Agent 不再只是一个被动等待指令的对话窗口，而是数字环境中持续在线的自主协作者。
这套设计没有提出全新的理论，而是把计算机系统中经典的工程思想——批处理、快慢路径、缓存局部性、投机执行、存算分离、外部控制回路——应用到了 Agent 系统的构建上。人的角色则从具体执行细节上移，退回决定与验收。
原文《Super-agent 设计探索：迈向更自主的 Agent 系统》· DeepSeek Harness 团队 · 2026-10-31
本页为原文的精炼可视化，保留论证结构与实验数字，非逐字转载；原型 dsh-superagent-prototype 仅验证技术路线，并非正式产品。