DeepSeek又开源了！公布Super agent架构

智东西 作者 | 李水青 编辑 | 心缘 智东西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正式产品。