一文拆解DeepSeek Harness新架构
腾讯云开发者 · 软件开发
原创 陈焕新 2026-11-05 08:45 广东 关注腾讯云开发者，一手技术干货提前解锁👇 开发者公众号专属群聊 扫码加入获取更多一手教程、科技前沿报告 前言 10 月 31 日，DeepSeek 发了一篇《Super-agent 设计探索：迈向更自主的 Agent 系统》，当天就在圈子里传开了。DSH 即 DeepSeek Harness，下文沿用这个简称。 网上的分享不少，但多数停在解读文章本身、复读概念。可如果把里面那些新名词先放下，会发现这条路从"小龙虾"出现之后，大家或多或少都已经试过——DSH 这篇的价值，不在于提出多少新东西，而在于把很多团队脑子里零散的想法，用一套清楚的描述串了起来。所以文章出来之后，很多人的第一反应是："原来我的 idea 和业界顶尖团队是一致的。" 恰巧，文中的很多观点，和我近半年自己做的一些尝试、调研和思考有重合。下面就从我的视角做一次解读。 01 一个被当成产品问题的问题 抛开架构不谈，DSH 要解决的问题其实很简单。官方文章里有一句话很容易被略过： 据我们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。 多数人读到这句，会把它归到产品体验上：窗口切换太麻烦、界面不好用，要是有个统一看板把所有任务收拢起来看就好了。 但再往下一层，用户"管理 Session"这件事，很大程度上是从底层 LLM API 延续下来的设计范式——记忆、调度、审批、恢复，全都困在一个会话里： 并行上 ：多个任务同时跑，你得逐个查进度、逐个回结果、逐个补信息。任务并行了，协调却退回给人。所以很多时候让 AI 干活，其实很累。 单会话上 ：长程任务跑起来，聊天记录回答不了全部问题——记忆会被压缩，摘要有取舍。等任务真需要背景时，又得回去问人。 外部连接上 ：IM、会议、文档、App 里的信息，要么人手动告知，要么人手动触发，调度权还在人手里。 于是"3 到 5 个"这件事有了另一种解释：不是人的注意力只有这么多，而是本该由系统承担的记忆、调度、审批、恢复，被交给了人。 用文章里一句话概括： Session 应当是系统的实现细节，而不应是用户的认知负担。 所以 Super-agent 真正要优化的目标，可以从两个角度看： 产品目标 ：最大化 Agent 产出，最小化人的注意力。靠并行度创造价值，靠弱化 Session 这个产品形态降低认知负担。 技术目标 ：Human out of the loop。没有人干预时，AI 也能自主感知外部信息，完成决策、调度、执行。 要达成这两点，关键不是造一个"更强的 Agent"，而是用系统架构，把现在压在人身上的决策、调度、管理接过去。 02 判断的前提：上下文边界与组织 DSH 对 sessionless 的产品形态并没有给出明确定义：是像 Muse 那样的 personal agent 对话框？还是像 TAPD 那样的任务看板？ 如果要给 Super-Agent 一个产品形态上的幻想，我脑子里 sessionless 的形态只有一个——"贾维斯"。不妨就假设，未来每个人手里都有一个"贾维斯"App。 任何事只需要一个入口。我说一句"帮我做这个"，它去做，在合适的时候答复我；我也可以随时回头问它某件事进展如何。工作、任务、进度追踪，全由它管理、调度、执行。人在这里享受到的，才是 AI 真正带来的便捷。 要实现这个能力，必须引入一个控制层，也就是 DSH 里的 Router。它可以类比主流 Personal Agent 的 Main-Agent，或者干脆就是一个意图识别器：判断一件事值不值得做、该交给谁、做到什么程度算完成。 它不执行，只决策。 官方说 Router 可以很轻量，甚至能用小模型。但通读全文，有一个问题始终没说清： Router 凭什么知道你这句话该派给谁？ 2.1 sessionless的本质 抛开 Super-agent 这个名号，要弱化sessions这个产品形态，更本质的问题其实是上下文管理本身。 现实世界中，事件的上下文来自四面八方：A 项目下面挂着 A、B、C 三个群，B 项目的代码又散在 A、B、C 三个仓库。而真正决定"这次干活和什么有关"的，是与之相关的工作上下文。Session 只是一个临时的执行过程——就像我在 WorkBuddy 里建一个项目，所有 Session 都复用这个工作区的记忆，我在一个会话里面，让他接着干一件事，不需要做很复杂的交代，他便可以知道我在这个空间下，想干什么，改哪些代码，有什么历史信息。 关于上下文的管理，近半年来基本上大家都在研究这个方向，并不稀奇。DSH这套方案的解法，可以理解为Router就是充当一个管理全局上下文的角色，