今天一起读 DeepSeek 的 Super-agent 设计文章，看看一个能持续接活的 Agent，需要怎样的系统架构。 我们先从日常体验说起，再沿着一条任务看它如何运行，最后讨论实验的边界和我们自己的取舍。 这篇文章讨论架构思路。公开代码是研究原型，不能把文章里所有设计当成已经交付的产品功能。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

先顺着动画讲：上面是一件事，人等 Agent 推进；下面是五个 Agent 并行，进展、问题和待确认事项都汇到一个人。图中的五个只是示例，重点是人的跟进负担。 先问大家：同时开几个 Agent 窗口，你会开始忘记谁在做什么？作者说自己通常只能跟住 3 到 5 个活跃会话，这是经验值，不是实验测出来的人类上限。 这里有两个不同的问题。多个会话本来就能并行，难的是人要来回跟进。把所有事情放到同一个会话，又会碰到上下文混杂和传统同步工具阻塞的问题。 所以不能说“多会话无法并发”。他们要同时保留任务之间的并行，以及对人的连续交互。现代 Agent 已经有异步工具和 subagent，后面会看这些能力为什么还需要系统组织起来。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 右下角可打开“会话越开越多”互动演示。参数为假设，只演示等待如何累积，不作为真实收益证据。

这一页先讲四个目标，不急着介绍实现模块。 第一，连续性。即使底层使用不同会话，用户的任务关系和相关上下文仍能延续。比如在 IM 改需求，到了 GitHub 评审仍接得上。连续的是交互和任务语义，不要求同一个 Session 永远运行。 第二，多任务执行能力。几件事可以并行推进，长任务执行期间仍能及时接新请求。原文还强调任务结果的质量；并行只是其中一部分，不应把能接收多个请求等同于真正有产出。 第三，主动性。系统持续接收环境事件，在既定授权和策略下判断是否值得行动。并非每条消息都要处理，更不意味着事件能自动授予权限。 第四，持续运行。系统保存持久状态，并在长期运行出现故障时尝试恢复。它强调的是持续服务和恢复能力，不保证永不宕机，也不保证任意中间状态都能无损恢复。本地设备离线时，依赖它的操作仍需等待。 Continuous 关心任务和交互能否接续；Persistent 关心系统能否长期运行、保留状态并恢复。下面看 DeepSeek 怎样用系统架构把这些目标组织起来。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

一个会话保留完整历史，但多个任务的过程会混在一起。每件事独立开会话，能并行、能隔离，但任务之间的联系和对人的回复需要额外协调。 两层架构的选择是：用一个长期存在的入口掌握任务之间的关系，让独立 Worker 执行完整任务。 这里比较的是组织方式的取舍。并非前两种方式在所有场景都不能用，简单任务未必需要两层。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

比如你同时要求修一个 PR、复现一个 bug、回一封邮件。Router 负责理解请求、关联已有任务、派活，以及把需要你知道的结果带回来。每个 Worker 有隔离的上下文和执行工具，负责把一件事情做完。 为什么 Router 不自己深入执行？因为一个复杂调试可能占很久，还会带入大量细节，影响它接其他消息。 它与常见 Agent Team 的侧重点不同：Team Lead 往往要把一件大事拆成紧密关联的步骤；这里 Router 主要派发完整任务，任务内部仍然可以由 Worker 再组织 subagent。 限制的是执行职责。原文说轻模型通常够用，并没有要求 Router 缺乏判断能力。后续消息也并非每次都由 Router 的模型转发，接下来会讲直送。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 职责轻量不等于模型必须更弱。选型要结合路由准确性、延迟和成本，不在这页给出统一配置。

Worker 接手 PR #42 时，系统记录它对这个话题的订阅。新的评论到达后，代码查订阅表，直接送到这个 Worker，省掉 Router 再判断和转发的一轮。 Router 仍然能看到事件，但主要评估没有订阅者的新事件。Worker 发现消息不属于自己当前的任务，可以退订或交还 Router。 如果评论说“先停这个任务，优先做另一个项目”，仍然可以先直送。Worker 在授权范围内处理自己的暂停要求，把跨项目优先级交给 Router 协调。收到消息和有权决策是两回事，评论本身不能授予权限。 多个 Worker 可以订阅同一话题。这样有机会发现冲突，但不能保证状态一致或自动达成协调。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

这一页讲系统如何组织提供给模型的信息。左边是可以同时使用的构建规则，不是模型依次执行的三个步骤，也不代表要发起三轮模型调用。 举例：PR #42 收到一条 Safari 白屏的反馈。系统可以在准备输入时，同时给出当前对象的 ID、摘要、关联 PR 和 Worker，附带被回复的消息、邻近讨论，再为放不下的完整内容留下引用。右侧展示的是这些规则共同作用后的一份上下文示意，不是标准 API 或规定的数据结构。 Inline 是把预计马上有用的内容直接放入窗口，减少后续工具往返。Spill 是把超出预算或暂时不常用的完整内容保留在外部，在窗口里留下摘要或读取引用。 模型拿到这些输入后，信息够用就处理；信息不足再调用工具按引用读取。工具返回内容也可以遵循同样的规则，因此上下文组织既发生在事件注入时，也发生在后续工具返回时。 原文按“最小信息、利用局部性补充、超长内容外置”讲策略如何逐步完善，没有规定每条事件必须分三轮推理。原文举过前 50 个字符的例子，但不是统一的固定参数，所以图中只写消息预览。 这些原则适用于 Router 和 Worker。它权衡窗口占用、信息相关性与检索开销，不保证在所有任务里都更省。下一页再讲，Router 如何沿着对象之间的关系找回跨话题、跨会话的历史。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

用户在 IM 私聊里问“上次那个登录问题怎么样了”，Router 不必一直把每个任务的完整过程塞在窗口里。 系统给消息、话题和 Worker 会话分配 ID，并保存关联关系。读取一个对象时，同时返回相关对象的摘要和 ID，模型便可以沿着关系继续查：当前话题、相关 Worker、另一个代码评审话题。 这就是 Chain of Recall。Inline 与 Spill 决定信息怎么放，这里的引用关系决定外部信息怎么找。原文重点讨论 Router 的历史召回问题。 它也可以和 Markdown 项目记忆一起使用，并不意味着文件记忆应被替代。文章自己说，运行数月之后的长期记忆仍是开放问题。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 这个示例的前提是 Router 能定位到 #T-812，且后续对象间已有引用。第一段不是凭空得到 ID：可以来自明确链接、当前上下文或检索，无法确定就要澄清。Chain of Recall 解决沿关系读取历史，不保证任意跨渠道消息都能自动识别为同一个任务。

前面讲事件怎么进入系统、怎么找到 Worker、怎么组织上下文。这一页是建立在这些机制之上的一种主动行动策略，原文把它类比为投机执行（Speculative Execution）。它不代表事件驱动架构的全部。 例如群里有人报 bug，团队事先允许 Agent 静默尝试复现和找修复。它可以先在后台做准备，确认问题并找到简单修复后，再交付有用结果；没有可交付成果时，尽量不主动打扰用户。个人场景可以先查会议冲突、收集背景和起草回复。 要区分对外通知和内部记录。原文对一般投机执行说，结果有用就交付，其余丢弃；但这不能解释为系统会删除所有失败日志或执行记录。这页只表达“不主动通知”的策略，不声称公开原型已经有某种统一的记录保留机制。实际实现应另行明确如何保留和检查必要的执行证据。 主动工作要在既定授权内。后台准备和对外提交有不同影响，不能仅因事件到达就获得执行或发布权限。没有成果时保持安静也不应被推广成所有失败、阻塞和授权问题都不报告；那些仍需遵循任务的汇报和升级规则。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

任务派给 Worker，并没有自动解决 Worker 内部的阻塞。如果它同步等一个十分钟测试，发给它的新消息仍可能排队。 异步 ReAct 把耗时工具改成 start 和 stop。start 先返回已启动，工具继续在后台跑；结束时，结果作为新事件送回同一个会话。模型在当前推理步结束后，就可以处理新输入。 所以要区分：多个 Worker 是任务之间的并行，异步工具是同一会话内不必一直等工具。后台工具在跑，不等于模型在同一会话同时进行两次推理。 及时收到新指令，也不等于运行中的工具已经安全取消或修改了。取消与版本仍需要运行时处理。 原文发布时，Harness 已实现该机制，但尚未默认开启。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

同一件事，在不同渠道需要不同的信息量。群聊里给简短结论，指出需要对方决定什么；PR 里则写完整背景、改动和验证。 Worker 的推理和工具日志留在内部，Router 负责对外表达，避免几个 Worker 同时向人倾倒过程。 作者实践过 IM 每条回复不超过 100 词。这个数字是一种交互规则，不是适用于所有语言和场景的最优长度。更重要的是让接收者知道是否需要行动，并能找到详细证据。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

进程在线、API 正常，并不能说明任务在向目标靠近。一个 Worker 可能一直重复修改同一个 bug，也可能只是正在进行很难的调试。 原文让独立的 Watchdog 定时醒来，既看基础设施故障，也用模型读任务内容、判断进展，并处理异常。 我们讨论中补充的是职责分离：持续巡检独立出来，Router 可以专注交互和全局协调，用户问进度时再读取状态。 图里的逐级处理是我们的建议，不是原文给出的一套固定算法。可以先询问进展、检查证据，再按授权采取恢复措施。运行时间、重复失败、反复修改都只是信号。模型监督也可能误判，需要比较新增调用成本和实际收益。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

这里我们只看一个开关：后续事件有没有经过代码直送。两边都是 Router / Worker 两层架构，关闭直送后，后续消息需要 Router 再判断和转发。 结果很直观：每次运行所有会话的缓存读取量从 23.2M 增至 31.8M，约增加 37%；Router 的决策次数约增加 30%。但完成时间的中位数和 p95 基本相当。这说明在这组负载里，直送的主要收益是减少额外读取和路由开销。 为什么多花了 token，时间却没明显增加？原文第 7.2 节解释，Router 会把一轮推理期间积累的事件合并到下一轮，关闭直送后负载上升仍未达到吞吐上限。我们可以进一步推测，额外路由没有成为整体完成时间的主要瓶颈，但实验没有逐项拆分各因素的贡献。 如果有人追问批处理：作者单独压测 Router，事件到达率从每分钟约 1 条到 40 条，平均批大小从 1.0 到 2.8，单次请求耗时从 2.5 秒到 3.9 秒，每决策摊销推理时间从 6.4 秒到 1.6 秒。一个决策可能包含多次模型请求。 实验边界用一句话交代即可：这是合成消息流，每次约 300 条消息、约 20 个工作请求，每种设计跑 5 次，编码只用耗时工具模拟。它测的是调度表现，没有验证真实代码质量。缓存读取也不能直接换算为总账单，不能说“费用增加了 37%”。p95 是第 95 百分位完成时间，不是最慢 5% 的平均值。 延伸讨论可以问：在我们的任务里，哪些消息有明确归属，可以省掉一次模型判断？最终还要用真实任务看人工介入、返工和总成本。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 主画面只保留这一个开关实验，完整消融与批处理压测在原文第 7 节，不能把局部结果扩展为所有任务上的收益。

文章之外，DeepSeek 公开了 dsh-superagent-prototype，作为 Harness 的一个 bundle，主要盯一个 GitHub 仓库，可选接飞书。 值得读的是它怎么定义工单、执行者、授权和面板：谁可以提出请求、什么时候允许主动行动、什么事情需要人处理。文档强调消息只是输入，不能通过聊天改变权限。 同时，README 明确说是研究代码，文章中的一些设计还没有在原型里实现。部署文档说明预设以操作者的系统用户运行，建议专用账号隔离。因此不要把架构目标当成原型已经充分保证的行为。 推荐从 docs/000-philosophy.md 开始读。 资料：https://github.com/deepseek-ai/dsh-superagent-prototype

这是我读完后最关心的使用问题。Router 把入口统一起来，确实不用记哪个窗口在干什么。但理解五个项目、处理五个决策的成本仍然存在。 假设 A 问 PR 要不要合，B 问协议怎么改，C 问版本发不发。你还在回答 A，其他项目又插进来，回头处理 C 还得往上翻。跨窗口切换，可能变成同一条聊天流里找任务。 这不是两层架构必然造成的。原文第 8.2 节已经把任务呈现、领域界面、中途接管列为开放问题。我们往前推进的判断是：除了统一入口，还要给每件事独立的上下文和决策位置，并减少真正需要人参与的决定。 卡片、独立线程、引用回复都可能缓解，具体哪种适合，要看工作场景。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

多个 Worker 收到同一条消息，只说明信息可见，不能保证它们看到相同版本，更不能保证行动已经协调好。 我最初担心：如果三个 PR 有架构冲突，Router 过于简单，谁能理解并拍板？这里要把能力与职责分开。原文没有主张 Router 越笨越好，而是让它不被具体执行占住。 一种可尝试的分工是：简单问题由 Worker 或 Router 处理，需要长时间分析的交给专门协调 Worker，重大取舍交给有权决策的人。这样 Router 保留识别和协调职责，不必自己读完每个 PR 的所有细节。 这与原文的委派思路兼容，是我们对复杂协调场景的延伸。强模型、专项 Worker 都会增加延迟和成本，不能在没有证据时无限叠加协调层。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

开一个 Worker 并非没有代价：要写派单、读背景、执行、汇报，前台再理解结果。任务越小，这些固定开销越可能占主要部分。 但直接在主会话做也有代价：如果会不断被外部消息打断，或者一做就带入大量过程，可能影响其他任务。所以要同时看执行耗时、交接成本和被打断的风险。 我们更倾向按完整任务划分，相关后续回到原来的 Worker，减少反复交接。对于很小的工作，是否允许入口直接处理，是对严格两层设计的另一种取舍，需要验证，不是原文的结论。 图只是示意，并没有测出“两分钟”是一个实际阈值。任务较大时需要 Worker 自己规划，也需要可观察的进度和适当监督。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236

这张表比较解决问题的方式，而不是功能排名。DeepSeek 列对应设计文，不能认为公开原型已经完整实现；Hive 列来自公开 README，默认分支可能含未发布内容；bot 列沿用旧稿中的小规模实践，也不代表所有 bot 系统。 Hive 的 Orchestrator 规划和派单，Worker 是实际 CLI 进程，通过任务图、消息和报告协作。README 明确不从进程活动猜测任务是否完成；Worker 通过 report 更新状态，人可以停止或重启。不能由此推导 Hive 永远没有监控或恢复能力。Hive 采用 BUSL-1.1，准确叫法是源码可用，不在此称 OSI 开源。 旧稿对 bot 的观察频率和路由方式只是当时配置，不应描述成固定上限。已有的角色约定和交接记录，也不能直接等同于持续运行的事件系统。 接下来应挑同一个实际流程，比较是否减少转述、等待和返工，而不是根据架构图宣布优劣。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 https://github.com/tt-a1i/hive/blob/main/README.md Hive README blob: 8820fc2daa0e9d11dc6e359b2ed99af809cdc0be

这里不提出“十倍 Agent 只能带来几倍收益”的数字，因为我们没有做过这种测量。先把并行执行能力与有效生产力分开：更多 Agent 能同时尝试更多工作，但下游还要处理任务依赖、上下文交接、修改冲突、结果验证以及人的决策。 按右键先看中间：任务能否拆成独立单元，往往比能启动多少进程更重要。互相依赖的任务会等待；多个修改碰到同一接口要协调；看起来完成的结果还要验收。 再看右边：有效结果是可接受、可使用的产出，不是消息量、运行时长或 PR 数。增加 Agent 也可能降低某些等待，所以不能预先断言一定出现负收益。 最后回到人的注意力：如果每个 Worker 都找你确认，系统的执行并发上去了，人的决策吞吐却没变。这与前面的统一入口、任务粒度和交接成本是同一个问题的不同层面。 建议用同类任务比较完成质量、返工次数、人工介入、等待与总成本。这是后续验证方向，不是 DeepSeek 已验证的规模化定律。

这篇文章给出了一组值得参考的系统设计：把会话管理、事件路由和持续运行更多地交给系统。模拟实验提供了调度方面的初步证据。 我们的判断是，下一步要把“省注意力”落实到真实工作里：到底少了哪些跟进和决策？出了冲突能否正确处理？增加的成本换回多少有效产出？ 如果继续试，可以先挑一个真实流程，记录人工介入和结果质量，再比较是否加入话题直送或独立巡检。一次只改变少量机制，才容易知道收益来自哪里。 组织里的上下文边界、A2A、安全和长期记忆，原文也承认尚待解决，可以在讨论环节继续展开。 资料：https://x.com/DeepSeekHarness/status/2116857257245987236 前一页进一步提出：智能能力与并发增加，不自动等于有效产出增加。我们的结论是优先验证有效生产力，在可控的协调与运行成本下，让人更容易把事情推进。

今天的分享就到这里。文章和原型都在下面两个链接里，推荐读原文，再读原型的 philosophy 与授权文档。 欢迎结合自己的任务讨论：统一入口以后真的更轻松了吗？遇到跨任务冲突时，最需要补的是模型能力、上下文，还是决策边界？ 资料：https://x.com/DeepSeekHarness/status/2116857257245987236