深度研究 · Agent系统架构
10月31日晚，DeepSeek Harness团队发布技术长文《Super-agent设计探索：迈向更自主的Agent系统》。
这不是一次模型发布，也没有新的benchmark榜单。它更像一份来自工程一线的系统论文，讨论的是一个正在变得尖锐的问题。当单任务Agent已经不需要人盯着，多任务协作的瓶颈，为什么还是人？ 团队给出的答案是Super-agent，一个能跨会话保持上下文、同时推进多项复杂任务且互不干扰的连续实体。基于这套架构的内部实例已在DeepSeek研发团队持续运行，日常参与问题复现与修复、代码审查响应，以及DeepSeek Harness自身的迭代。 目前公开披露的应用集中于代码协作场景，官方尚未透露是否向其他业务线推广。 过去一年，Coding Agent证明了模型可以用工具解决复杂问题，人类在底层执行中的参与不断减少。但随着个人助手类产品开始集中涌现，一个结构性矛盾浮出水面。 现有主流Agent以单一Session为基本单位，不同Session彼此独立。用户并行推进多项工作时，只能手动切换、逐个记住上下文。 团队给出一个观察数据， 一个人通常只能同时跟进3到5个活跃Session 。这意味着单任务的上限取决于模型能力，多任务的上限取决于人的注意力。 如果只在本地单会话Agent上借助CLI、MCP或外部连接器做简单扩展，问题依旧。单会话同步阻塞、多任务上下文混乱、设备离线即停止运行，且需要大量人工维护。 要突破这些限制，必须打破Agent与「单次手动会话」的绑定。 Super-agent被归纳为四个基础特征。 连续，在IM、GitHub评论等熟悉界面中交互，始终感觉只有一个Agent。 高效，无需等上一条指令完成即可接受下一条，并行推进多个复杂任务。 主动，持续观察环境事件，值得处理时行动，不需要时保持安静。 持久，始终在线，异常时自动恢复。 四个特征背后是五个支撑模块。文中几乎没有提出全新理论，而是大量借用计算机系统的经典设计。文章开宗明义，相似的设计约束，会导出相似的架构选择。 系统在底层会话组织上面临一个根本权衡（Trade-off）。连续性要求事件汇入同一会话，吞吐量要求事件拆分到多个会话。DeepSeek的解法是把两件事拆到两个层级。 Router层，常驻全局路由层，承接所有人类交互，充当全局的序点（Sequence Point）、协调点与记忆。它不直接执行任务，甚至可不配备Bash工具，因此不会成为瓶颈。团队还发现一个反直觉现象，Router的负载常以批处理（Batching）方式被自然吸收。上一轮推理期间积压的事件会在下一轮合并处理，而长输入、短输出的Router恰好适合Prefill阶段的并行计算。 Worker层，由上下文隔离的执行会话组成，挂载完整工具，专注单一任务，通常配置能力最强的模型。Worker不直接与人交互，推理过程与工具调用全部隔离在内部，只向Router汇报状态。 从工程实践看，这套分层还有一层成本含义。 Router层用较轻量的模型即可胜任路由、过滤与协调，昂贵的强模型算力集中在真正的任务执行环节 。不是所有环节都需要最强模型，这是多任务Agent规模化落地时绕不开的账本。 让用户手动管理Session，很大程度是从底层LLM API延续下来的设计惯性。Session应当是系统的实现细节，而不应是用户的认知负担。 驱动Agent的输入，从人类逐条键入的提示词，变为群聊消息、邮件、代码审查评论、CI结果等半结构化事件，统称为Trigger。 围绕Trigger的生命周期，团队设计了四层递进机制。 两级过滤（Fast Path/Slow Path）。真实环境事件流呈「高噪音、低触发率」特征。确定性代码构成低延迟的Fast Path，先行筛除无关消息。通过准入的候选事件再交给LLM做语义判断。闲聊在程序层被拦截，连模型都不必调用。 订阅与直通。同一Pull Request、同一IM话题构成一条Thread。Router依据初始事件创建Worker后，该Worker直接订阅对应Thread，后续事件由程序直通，无需Router中转。Router只负责新任务的冷启动与跨任务协调。 Inline & Spill与链式召回（Chain of Recall）。上下文窗口被当作Cache来管理，高频信息直接内联进窗口，低频完整信息留在窗外、只保留引用。配合为Trigger、Thread、Worker赋予唯一ID构成的引用图，模型可以从当前事件出发逐跳按需召回上下文，缓解Router层的长程失忆。 投机执行（Speculative Execution）。借鉴处理器设计思想，不确定结果是否被采用，也先在后台尝试。内部用户群配置了「静默复现并修复」策略，有人反馈问题时，Agent后台复现、找修复方案， 确认能修好才交付，修不好就全程安静 。多余算力被用来换人的等待时间。 经典ReAct Loop中，模型调用run()后同步阻塞，期间无法响应任何新输入。团队将其改造为异步ReAct Loop，耗时工具改为start()和stop()，调用后立即返回「已启动」，执行结果作为新事件投递回会话。前台对话与后台执行解耦。 这一机制已在DeepSeek Harness中实现，只是尚未默认开启 。 输出侧，系统按信道定制交互规范。IM信道遵循「单次回复不超过100词」的硬性规定，只在需要决策时打扰人。GitHub、邮件等异步信道则交付结构化的完整说明。 本地Agent默认把计算、状态、环境绑在同一台设备上，设备休眠即停摆。团队分两步解耦。 第一步，推进Agent Loop的无状态计算放入云端弹性容器，会话状态存入数据库，实现云端持久在线。 第二步，让Agent Loop常驻云端，而代码仓库、本地工具链等重状态环境留在原地。端侧只部署一个不保存会话状态的轻量daemon，负责执行命令、返回结果。这一思路与Anthropic此前提出的「脑手分离」一致，但场景不同。DeepSeek首先要接入的是用户日常使用的、可能间歇在线的个人设备，支持BYOM（Bring Your Own Machine），也支持云端托管环境。 在约300条消息、其中约20条工作请求的合成负载下，四种方案跑了5轮对比（需注明基于合成负载与简化环境，官方自述结果仅作初步参考）。 12.4/15.7分钟 Super-agent的任务完成时间P50/P95 20.4/29.5分钟 单Session+Subagent（中性提示）的P50/P95 中性提示下， 模型在5次运行中一次都没有调用Subagent，所有工作挤在主会话里被新消息不断打断 ，p95被拖至29.5分钟。这印证了文章的底层判断，与其依赖提示词工程和模型临场决定分不分工，不如在系统层面把分工固化下来。 另一个对照来自消融实验。关闭订阅直通机制后，任务完成时间基本不变，但Router决策次数增加约30%，单次实验读缓存token从2323万升至3177万，增幅约37%。事件直通的价值由此变得具体，它不只为降低延迟，更直接削减了调度层的算力开销。 Super-agent单次实验读缓存token整体高于单Session方案的605万，用更多推理开销，换更短且更稳定的完成时间。Router层压力测试还显示，Trigger到达速率升至每分钟约40条时，单个决定分摊的推理时间从6.4秒降至1.6秒，拥堵反而摊薄了单位成本。 在当下的技术叙事里，一篇文章愿意用整整一节列出自己尚未解决的问题，并不多见，而DeepSeek就是给出这样的答案—— 长程记忆，引用图与链式召回解决的是近期检索，跨月乃至更长周期的记忆仍是可扩展性的主要瓶颈。 交互形态，聊天窗口为中心的交互是路径依赖的结果，未来的项目管理形态可能是高度定制化的。 A2A协作，多个彼此隔离的Super-agent实例之间，如何在不共享底层上下文的前提下安全通信。 安全与隐私，云端Agent Loop持续接入外部环境、端侧又存有凭据与私有代码，提示词注入与服务端入侵的风险被直接点明。团队甚至提出，需要让Agent在「完全不接触凭据本身」的情况下使用凭据。 如果没有办法很好地解决安全与隐私问题，Super-agent只有在一个很小且可信的范围才能工作。 这也划出了当前架构的现实边界，它更适合内部可信环境。 若面向外部开放、对接敏感业务系统，还需叠加权限沙箱、全链路审计、高危动作人工审批等机制。这与官方将其开源实现定位为 「验证技术路线的原型、并非正式产品」 的姿态，是一致的。 行业坐标 当前各家的Agent路线，侧重点并不相同。 OpenAI的GPT-6.1 Terra聚焦桌面软件操作，解决「怎么操作界面」。 腾讯WorkBuddy一类企业级Agent聚焦业务系统连接与办公协同，解决「接入什么」。 DeepSeek的Super-agent则聚焦多任务调度与持久化运行，解决「怎么并行、怎么持续跑」。 三分法只是观察的简化框架，边界正在互相渗透 。 WorkBuddy近期已推出云端托管服务，同样主打7×24小时不间断运行。执行、连接、调度三层能力，大概率不会长期分属三家。「云端持久调度+本地环境执行+业务系统打通」的完整Agent栈，才是各家的终局形态。 回到那组数字。 3到5个，是人能同时跟进的Session上限。 12.4分钟对29.5分钟，是系统固化分工对提示词分工的效率差。 这篇技术长文的真正分量不在于Super-agent这个命名，而在于它传递的判断。 Agent竞争的下一阶段，主战场正从模型能力转向系统工程 。调度、持久化、容错、成本控制、多任务管理，这些传统计算机领域的老问题，正在新物种身上重新变得关键。单模型跑分的边际收益正在下降，模型决定单任务的上限，系统决定协作的规模，而规模，才是Agent真正走进产业的前提。 内部实例已在运行，参考架构的原型代码已在GitHub开源，官方明确其为验证技术路线的最小可运行实现，并非生产级正式产品。我们可以知道Agent不再只是被动等待指令的对话窗口，而是演进为数字环境中持续在线的自主协作者。这句话能否兑现，取决于接下来几个开放问题被解决的速度。
本文来源于DOIT传媒，文章内容仅供参考，不构成投资建议。
评论列表