DeepSeek Harness 团队在内部跑着一个"常驻"的智能体。在他们内部的 DeepSeek Harness 用户群里，有人随口报了个问题，没人 @ 它，它也会在后台自己去复现；确认问题真的存在、而且找到了简单的修法，它才开口，直接在 GitHub 上提一个 Pull Request。要是没复现出来，或者修起来不简单，它就一直不出声，像什么都没发生过。
11 月 1 日，这个团队在 X 上发了一篇很长的文章，讲的就是这类智能体背后的架构，他们管它叫 Super-agent。先交代两句背景：X 上这版是从中文原文机器翻译过来的英文；文章开头就说明，讨论的是架构思路，不是在介绍 DeepSeek Harness 现在已有的功能。文中有一部分设计放进了一个叫 dsh-superagent-prototype 的原型插件，他们也说得很清楚，那只是用来验证技术路线的原型，不是 DeepSeek 的正式产品。下面的内容都来自 X 上这一版。
卡住的是人，不是模型
文章的出发点很朴素。过去一年，编程智能体这类单任务智能体已经很能干了，越来越不需要人盯着、一步步插手。可一旦想同时推进好几件事，问题就变了：今天主流的智能体都以"一个会话"为单位干活，会话之间互不相通。你开五个会话做五件事，就得自己在它们之间来回切，还得记住哪个会话里聊过什么。按他们的经验，一个人同时能跟进的活跃会话，通常也就 3 到 5 个。单个任务的上限是模型能力，多个任务的上限，变成了人的注意力。
给现有的本地智能体接上 CLI、MCP 或者各种连接器，它确实能收到外面的消息了，但老问题还在：遇到耗时的操作就卡住，期间谁的话都接不了；几个任务的上下文搅在一起，结果越来越差；电脑一合盖、一断网，一切都停下。要让它一直跑下去，得靠人不停地照看。
所以他们想要的是另一种东西：一个始终在线的、"同一个"智能体。你在群聊里跟它定了方案 A，后来又在 PR 评论里改成方案 B，它能接上这个变化，你用不着琢磨"这件事它到底知不知道"。它能同时做好几件复杂的事，上一条还没做完就能接下一条；它自己留意环境里发生了什么，该管的管，不该管的不吭声；它长时间在线，出了岔子能自己恢复。文章的判断是，单靠一个 ReAct 循环做不到这些，得靠它外面的一整套系统。
一个负责说话，其余负责干活
最核心的一招，是把智能体拆成两层。
上面一层叫路由层，是一个长期运行的会话。所有入口进来的人类消息都先到它这里，它负责记住全局的事、把任务派出去、协调任务之间的关系，但自己不动手干活，连 Bash 工具都可以不给它。下面一层是执行层，每个任务一个独立的会话，上下文互相隔离，带着全套工具，任务做得好不好、代码写得怎么样，全看它们，所以通常要用最强的模型。执行层从来不直接回复人，只向路由层汇报，由路由层统一对外说话。这样，用户面对的始终是同一个智能体，后台却可以有很多个会话同时在跑。
这和大家熟悉的 Agent Team 看着像，其实分工不同。Agent Team 的组长要把一个复杂任务拆开，还得频繁协调组员，脑子很累；路由层只分派彼此独立的任务、记住它们之间的关系，从不去拆某一个任务。他们的体会是，路由层的活比想象的轻，用一个较小的模型往往又快又好。
一个自然的疑问是：整个系统只有一个路由会话，它会不会成为瓶颈？文章的回答是"自带批处理"。路由层在做一轮推理的时候，新来的事件会先排队，下一轮一起塞进同一次调用。路由层的调用通常输入很长、输出很短，合在一起的事件在预填充阶段是并行算的，所以一次请求的耗时，远不像事件数那样成倍增加。他们专门压测过：需要它拍板的事件从每分钟大约 1 个加到大约 40 个，平均每批的事件数从 1.0 涨到 2.8，单次请求的耗时只从 2.5 秒涨到 3.9 秒，摊到每个决定上的推理时间反而从 6.4 秒降到了 1.6 秒。按他们现在的团队规模，一个路由会话完全够用，没必要为了吞吐量提前把它拆开，牺牲掉全局上下文。
文章里还有一句话很值得做产品的人想一想：让用户手动管理会话，很大程度上只是从底层大模型 API 沿袭下来的习惯。会话应该是系统内部的实现细节，不该成为用户的负担。
让它自己看见该做的事
要让智能体"主动"，驱动它的东西就得换掉：不再是人一条条敲进去的提示词，而是环境里不断发生的事件，比如群消息、邮件、日历提醒、代码评审评论、CI 结果。文章把它们叫做 Trigger。
真接进群聊和代码平台之后，绝大多数消息其实跟智能体没关系。每条都让大模型从头判断一遍，又慢又费钱。他们借了计算机系统里"快路径、慢路径"的思路：先用代码按来源、群组、白名单这些确定的条件筛一遍，比如把某个来源设成"只响应明确的请求"、"当作候选"或者"忽略"，大部分噪音在这一步就挡掉了；剩下的才交给大模型，按照用提示词写好的规则判断要不要处理。这些规则随时可以加、可以关。
事件分出去以后，还有一个问题：每条后续消息如果都要先经过路由层，它迟早会被压垮。他们的做法是把同一个 PR、同一个群聊话题、同一条邮件链上的连续事件看成一个 Thread。路由层为第一条事件派出执行会话之后，这个会话就直接订阅这个 Thread，后面的消息由代码直接送到它手上，不再绕路。几个执行会话订阅同一个 Thread 的时候，会同时收到新消息，也就有机会自己发现彼此的冲突、自己化解。
往上下文里塞多少东西，他们的思路是把上下文窗口当成缓存来用。很快会用到的信息直接放进去，超出预算的留在外面，只放一个引用，需要时再去读。具体做法是从最少的信息开始，先只给当前对象的 ID 和摘要，再按就近原则补上相关的东西，比如内容的前 50 个字符、前后几条群消息、同一条评审讨论里挨着的评论；太长的内容就截断，留个"后面还有"的指针。系统里每个对象都有唯一 ID，彼此引用，模型可以顺着引用一跳一跳往回找。这样一来，有人在别的渠道提起一个很早以前的任务，路由层也能把来龙去脉找回来。
开头那个"没人 @ 也会自己修 bug"的行为，用的是另一招，推测执行：根据环境里的信号先在后台动手，结果用得上就交出来，用不上就扔掉，多花一点算力，换人少等一会儿、少插一次手。
不卡住，也不刷屏
两层架构解决了"跨渠道连贯"，但日常交流还有两个麻烦。
一个是卡住。经典的 ReAct 循环里，模型调用一个工具，就得等它跑完才能干别的。他们把耗时的命令和工具调用改成异步的 start() 和 stop()：调用 start() 马上返回一句"已启动"，工具在后台跑完以后，结果作为一条新事件回到会话里；跑得太久，模型可以自己调用 stop() 叫停。这样前台对话就不会被后台任务拖住。文章提到，DeepSeek Harness 已经实现了这套异步任务机制，只是默认没有打开。
另一个是说话的分寸。终端里一个人看，打印详细的推理过程和工具日志无所谓；同样的东西扔进群聊，就是刷屏。两层架构本身已经挡掉了一部分，执行会话里那些啰嗦的过程从来不直接发出去。在此之外，他们给不同渠道定了不同的规矩：群聊这类即时渠道尽量少打扰人，只在需要人拍板或验收的时候说话，只问直接的问题，只给简短的结论，他们试下来很管用的一条硬规定是每条回复不超过 100 个词；GitHub、邮件、文档这类异步渠道则反过来，要写得完整、信息密集，比如按项目规范把 PR 的背景、改动和验证结果都写清楚。
人的电脑不用搬上云
要让智能体一直在线，又能碰到真实的工作环境，他们做了两层拆分。第一层，把跑智能体循环的计算和需要保存的状态分开：计算放进可以随时扩缩、重启的云容器，会话这类状态存进数据库，本地电脑合盖也不影响它继续干活。
第二层更有意思。真实的工作环境里有还没提交的改动、私有的凭据、只有内网才能访问的服务、特定的硬件，想把这些完整复制到云端，代价很大，还容易漏。他们干脆不搬：每台机器上只装一个很轻的守护进程，不保存任何会话状态，只负责执行命令、把结果交回去。文章管这叫 BYOM，自带机器；云端托管的机器和临时创建的环境也一样能接。这样，智能体可以在需要的那台机器上干活，哪怕那台机器时在时不在：等你的电脑重新上线，云端会自动把该在那台机器上做的任务接着做完。
文章还提到，Anthropic 的《Decoupling the brain from the hands》用的是同样的思路，差别在场景：那篇面向托管服务，而 DeepSeek 这边首先要接的，是大家每天在用的个人电脑。
再加一个看门狗
一个长期运行的系统，光靠自己内部的逻辑很难一直靠谱，需要一个在系统之外盯着它的东西。而且智能体出问题，很多时候不是崩溃，而是进程还活着，模型却在原地打转，或者早就跑偏了。
他们的看门狗是一个独立的会话，按定时消息醒来，手里也有全套工具。它处理 API 报错、状态恢复失败这类基础设施故障，对外部的临时故障会一直复查到恢复为止；它也用模型去判断每个执行会话是不是还在实打实地推进，有没有偏离总目标。维护的人还可以直接用大白话问它某件事为什么失败，或者让它在系统运行的时候调整提示词、改触发规则。
实验怎么说
文章做了两组初步实验，并且自己说明：用的是合成负载和简化环境，有些设置还不够严谨，结果只能当参考。
第一组是端到端对比。四种设计同时跑，每次喂进去大约 300 条群聊和 GitHub CI 消息，其中大约 20 条是真正的工作请求，剩下的是闲聊、追问、取消和 CI 通知。写代码的部分用一个只会消耗时间的工具来模拟，所以比的是调度和协调，不是单个任务干得好不好。每种设计各跑 5 次。
Super-agent 完成任务的时间，中位数是 12.4 分钟，p95 是 15.7 分钟。对照组是"单个会话加一个 Subagent 工具"。用中性提示词的时候，5 次里模型一次都没去调用 Subagent，所有活都在主会话里自己干，不停被新消息打断，p95 拖到了 29.5 分钟。换成"优先委派"的提示词，5 次里有 4 次把活派了出去，时间是短了些，但整体还是比 Super-agent 慢；剩下那一次，模型觉得活儿"不大"，又自己干了，拉出一条长尾。文章的结论是，单会话方案能不能把活派出去，全看提示词和模型当时的判断；两层架构是在系统层面把这件事定下来了。
当然这不是白来的。Super-agent 同时维护好几个独立会话，每次运行读取的缓存 token 比单会话方案多，等于拿 token 换更短、更稳的完成时间。他们还试了把前面说的"订阅直通"关掉：完成时间差不多，但路由层每次运行要多做大约 30% 的决定，缓存读取的 token 从 23.2M 涨到 31.8M，多了大约 37%。也就是说，订阅直通不让任务变快，但能给路由层省下不少开销。
第二组就是前面提到的路由层压测。
还没想明白的事
文章最后很坦白地列了几个没解决的问题。
一是怎么扩展。现在一个路由会话、订阅直通、执行会话之间不直接通信，这套组合足够应付他们日常的大部分任务；可任务更大、彼此纠缠更紧的时候，路由层什么时候拆、拆多细，执行会话之间什么时候该直接对话、按什么方式协作，都还没有答案。系统连续跑上几个月，长期记忆会成为最大的瓶颈。专门为路由层的工作训练模型，也是他们觉得值得试的方向。
二是没有会话以后，人该怎么跟智能体打交道。底层的会话已经不对应界面上的对话了，任务该怎么展示给人看、怎样管理才顺手，还得摸索。他们自己的内部实例直接在 GitHub 的 Issue 和 PR 里干活；任务做到一半，也应该让人能随时插手、接管。
三是上下文的边界。从个人、小团队扩展到更大的组织，决定哪些人共用一个智能体，本质上就是在决定哪些上下文共享、哪些隔离。各自隔离的智能体之间怎么安全、可靠地协作，还没解决。
四是安全和隐私。事件驱动意味着智能体会接触到更多不可信的输入。云端的智能体循环一旦被入侵或者被提示注入，所有连着它的设备都可能被接管；就算云端没出事，凭据只要进了模型的上下文，就有泄露的可能。智能体得学会"用凭据，但看不到凭据"。
能直接拿去用的
这篇文章自己也说，它没提出什么新理论，做的是把计算机系统里那些老办法搬到智能体身上。也正因为这样，里面不少做法不依赖 DeepSeek Harness，做智能体产品的团队现在就能借来试试。下面几条是我们从文中挑出来的。
让负责跟人说话的那个会话别亲自干活，活全交给隔离的会话，它只管统一回话，这样后台再忙，用户看到的也是一个人在跟他交流。后续消息按 Thread 直接送到负责的会话，别让每一条都绕一遍总调度。先用代码做确定的过滤，再让模型做语义判断，能省下大量的调用。耗时的工具拆成 start() 和 stop() 两步，结果当成新事件回来，前台就不会卡住。在群聊里给每条回复设个字数上限，他们用的是 100 个词。最后，单独放一个看门狗，看的不只是进程还活不活着，更要看它有没有在实打实地往前走。