本文是对 @DeepSeekHarness（账号显示名 DeepSeek Harness，简介 Everything is a plugin.）一篇 X Article 的摘要与评论。发帖时间约 2026-11-01 19:37（Asia/Shanghai）（UTC 2026-11-01T11:37:54.000Z）。起草时互动约：浏览 275 万+（精确约 2,754,839）、赞 1.3 万+（约 13,235）、书签 1.7 万+（约 17,607），另约转发 1,648、引用 829、回复 456；账号粉丝约 7.1 万——互动与粉丝数会变，请以 X 页面现值为准。

Article 英文机翻页标题：《Exploring Super-agent Design: Towards a More Autonomous Agent System》（探讨超级代理设计：迈向更自主的代理系统）。文首写得很清楚：原文为中文；本文讨论的是架构思想；不是 DeepSeek Harness 现有功能的说明书。文末写明：文中部分设计落在开源原型插件 deepseek-ai/dsh-superagent-prototype（Towards a More Autonomous Agent System；起草时 GitHub API 约 ★14,903）——只是验证技术路线的原型，不是 DeepSeek 官方正式产品。主项目为 deepseek-ai/deepseek-harness（Everything is a Plugin；起草时约 ★270,266、主语言 TypeScript、许可证 MIT；主页 deepseek.com/harness）。

钩子核对：标题、文首声明与文末边界一致。 这不是「又一个会写代码的 Agent 教程」，也不是「装好 DeepSeek Harness 就能开箱使用 Super-agent」的产品手册。它要回答的是：当模型已经能少靠人盯着完成单任务时，多任务并行、跨 IM / GitHub 连续协作、环境事件驱动、长期在线这些需求，为什么会被单会话 Agent 卡住，以及一套偏计算机系统风格的架构如何拆开这些约束。站内已有 Anthropic / LangGraph 编排线、Karpathy「怎么用 LLM」实用片，以及已发的 OpenMausBot「通讯录式多 bot 壳」 等讨论，多落在会话、编排或本地小队形态；本稿主线是 Super-agent 作为持续实体的系统架构，与上述「会话 / 编排」线可对照定位，勿当成同一篇的复读。

本稿依据官方 X Article 英文机翻全文整理，不是全文转载。完整论证、配图与实验图请读原帖 Article；实现细节以原型仓库与主仓 README 为准。

这篇在说什么

先讲场景。过去一年，编码 Agent（能调工具改代码、跑命令的代理）和各类单任务代理已经证明：模型可以在较少的人工逐步干预下解决复杂问题；人也开始把多 Agent 协作、跨会话调度当成可讨论的工程问题，而不是科幻。与此同时，个人代理开始直接挂上即时通讯、日历、邮箱、工作平台，监控信息流并帮忙办事——这种「一直在线、由环境事件推动」的工作方式，并不只属于个人助理，对团队软件研发同样有价值。

但主流设计仍把单次会话当成工作单元，会话彼此隔离。人要并行盯几件事，就得手动切换会话、自己记「哪条线程里有什么」。作者团队的经验是：一个人通常只能同时跟住大约 3～5 个活跃会话。于是出现一句很扎人的分工：单任务的上限在模型能力，多任务的上限在人的注意力。 给本地单会话 Agent 加上 CLI、MCP（Model Context Protocol，一种让外部工具接到模型侧的协议）或各类连接器，可以接收外部消息，但根上的限制还在：同步会话会被长操作堵住；不同任务的上下文容易搅在一起；本机一休眠或离线，整条链路就停。

他们把突破口说成：让代理不再绑定某一次由人手动驱动的会话，而变成一个跨会话保持上下文、能同时推进多项复杂任务且任务间尽量不互相污染的连续实体。这种代理及其系统架构，文中称为 Super-agent（超级代理）。内部实例跑在 DeepSeek Harness 上：同一条研发任务可以在 IM（即时通讯）与 GitHub 之间接续；也能在公开群聊里监听反馈，即便没人 @ 它，也可能自行定位根因并开出 Pull Request（合并请求）去修。

支撑四特征的，不是「再写一个更聪明的单环 ReAct」（Reason + Act：模型交替推理与调用工具的经典循环），而是外围系统架构。作者归纳出五块基本模块：两层架构（Router / Worker）、事件驱动 Triggers、全双工多通道交互、算力 / 状态 / 环境分离，以及外部 Watchdog（看门狗）。全文主线可以压成一句：人往上挪到决策与签核，系统把「管会话、同步上下文、并发执行」接过去；代理从「等你打字的聊天窗」变成「待在真实数字环境里的长期协作者」。

适合谁：已经用过编码 Agent / 个人助理，却被「开太多会话、人肉当调度」拖住的人；以及想读清「架构探讨」与「现成产品」边界的工程读者。不适合谁：指望本稿当安装手册、功能对照表，或把原型星标误读成官方正式上线承诺的人。

1. Super-agent 的四特征：Continuous / Productive / Proactive / Persistent

文中给出四个基本特征（首次出现时用白话钉一下）：

1. Continuous（连续）：人在已有工作面里直接交互——IM、GitHub 评论等——体感上始终是同一个代理，而不必猜「会话 X 里有没有信息 Y」。例如先在 IM 里定 Plan A，后来在 PR 评论里改成 Plan B，代理应理解变更并调整正在做的事。
2. Productive（高产）：响应快，且能并行高质量完成多项复杂任务；前一条命令或任务还没跑完，也能接下一条指令。
3. Proactive（主动）：不等人逐步下指令；监控环境事件，值得处理就行动，不值得就保持安静。
4. Persistent（持久在线）：尽量始终在线，直接连到用户真实工作环境，并在长时间运行中对异常自动恢复。

作者强调：没有哪一个孤立的 ReAct 环能同时给出这四点，它们必须来自环外的系统结构。约束相似时，个人代理与商业研发代理往往会收敛到相近形态；而这些问题又大量像经典计算机系统问题，所以存算分离、快慢路径、投机执行、看门狗一类旧思想会反复出现——不是为了炫术语，而是因为「并发、可靠性、上下文预算」本来就长这样。

解读： 四特征是验收清单，不是口号。读后文时可以用它自测：某一设计到底是在补「连续」、补「并发吞吐」，还是在补「别等人喊才动」与「机器睡了别全挂」。

2. 两层架构：长寿命 Router + 上下文隔离的 Worker

连续交互与多任务吞吐之间，存在硬权衡。

• 所有事件都进同一个会话：全局上下文最完整，但单环逐步执行会卡住吞吐；不同任务的中间细节还会在同一条上下文里交错，反而伤质量。
• 每个事件都新开会话：并发吞吐上去了，但缺共享全局上下文时结果容易「各说各话」；多个会话分别回用户，交互也会乱。

折中是逻辑上的两层：Router 层（路由层） 长寿命地承接所有人对交互与全局协调；Worker 层（工人层） 为每个任务准备隔离上下文与完整执行工具，高并发干活。于是「会话」更像系统实现细节，而不是用户必须亲手管理的项目单位——作者认为，让用户管会话，很大程度上是从底层 LLM API 习惯里带上来的产品债务。

2.1 Router：全局序点，但不自己干重活

Router 接收各入口的人对交互，把跨任务信息与决策收拢成系统的全局序列点、协调点与记忆。为避免单点成为性能瓶颈，它被设计成不执行任务本身：只与人交互、派发任务，甚至可以完全不带 Bash（命令行执行）一类重工具。

它看起来像 Agent Team（代理团队：把复杂任务拆给多个角色），但重心不同：Team Lead 往往要深挖单任务、频繁协调紧耦合子步骤；Super-agent 的 Router 更偏任务级派发与关系跟踪，不为单个任务做细拆。实践上，Router 侧工作常比想象中轻，较轻量的模型也可能兼顾速度与质量。实现上也不必死守「一个 LLM 会话」：作者选了最直接的「单个长寿命 LLM 会话」，并发现它未必那么容易成为吞吐瓶颈——原因是环境事件（后文 Triggers）会在一轮推理期间排队，在下一轮被合并注入同一调用，形成批处理；Router 步骤通常「输入长、输出短」，合并后的 Prefill（预填充：模型先消化输入）阶段可并行计算，单请求时延随批量增长得较慢，摊到每次决策的均摊推理时间反而可能下降（上限仍受上下文长度与单轮可准确处理的 Trigger 数量约束）。若将来单会话真撑不住，可做多级过滤或水平分片，但分片越细，吞吐越高、共享记忆越少——在「全局记忆」问题解决前，这道权衡会一直在。

2.2 Worker：隔离执行，不直接对用户七嘴八舌

Worker 直接决定任务结果与代码质量，通常要用最强模型。它们不直接对人交互：推理过程与工具调用留在内部，状态上报给 Router，由 Router 统一对外回复——这样既保并发，又避免多会话抢着回用户。

并行时，Worker 彼此通常不必点对点通讯；冲突更多发生在共享工作环境（例如同一 PR）。只要相关 Worker 都订阅该环境的 Thread（事件线程，见下节），就能收到同一批通知并自行发现冲突；少数跨任务协调仍经 Router。单个 Worker 内部也可以再起子代理或本身就是一个 Agent Team，对上层 Router 透明。同一结构既适合「复现问题 / 审 PR / 开功能」并行推进的研发协作，也适合个人代理：前端仍是一个聊天页保持对话连续，后端按话题各派 Worker 并行起草。

解读： 两层架构的产品含义是——用户感觉只有一个 Super-agent；底下有多少会话，是调度问题。这和「再教用户怎么开对线程」是相反方向。

3. 事件驱动 Triggers：从「等人打字」到「环境半结构化事件」

要主动，先改驱动源。Super-agent 的主输入不再是人在会话里一条条敲的 prompt，而是环境里的半结构化事件——群聊消息、邮件、日历提醒、代码评审评论、CI（持续集成）结果等——文中统称 Triggers（触发器）。代理监听并响应 Triggers，就不必像单会话 Agent 那样每次都等人下令才跑。

处理链路按四步叠起来：过滤噪声 → 路由到 Worker → 组织上下文 → 必要时抢先行动。

3.1 两级过滤：代码 Fast Path + 模型 Slow Path

接到真实群聊与代码平台后，事件流噪声大、真正需要动手的比例低。若每个事件都从零丢给大模型判定，延迟与算力都会炸。作者借用系统里的 Fast Path / Slow Path（快路径 / 慢路径）：把大模型推理当成灵活但贵的慢路径；把高频、规则清晰、稳定的判定写成确定性代码当快路径。

• 程序化策略（Fast Path）： 按来源、群组、用户/机器人白名单等做准入；例如某来源可设为「只响应显式请求」「当作候选」「直接忽略」。多数无关消息在此被丢掉。
• 语义策略（Slow Path）： 过了程序化关卡的候选，再交给 LLM，结合上下文与写成提示词的策略决定是否行动；同时也是自然语言扩展点——人随时可用提示词开关或增补策略。

3.2 订阅与直通：冷启动走 Router，跟进事件尽量绕开

若每个任务的后续事件仍全部挤过 Router，单点负载与延迟都会变差。于是过滤后的路由也分快慢：Router 主要负责新任务冷启动与跨任务协调；代码则把同一 Thread 上的后续事件直通给已订阅的 Worker。

所谓 Thread，是同一 GitHub PR、同一 IM 话题或同一邮件链上连续事件形成的流。Router 为 Thread 的首个事件创建 Worker 后，该 Worker 直接订阅该 Thread：

• 已订阅（Fast Path）： 代码把后续事件直通给订阅者，不必再让 Router 做一次工具转发；若新事件超出当前任务，Worker 可退订或交回 Router 重派。
• 未订阅（Slow Path）： Router 仍能看见全局事件以跟踪状态，但只评估与派发尚无订阅者的新事件。

订阅是多对多的：一个 Worker 可订多个相关 Thread，一个 Thread 也可被多个 Worker 订阅。共享环境上的新事件会同时打到所有订阅者，让他们有机会了解彼此并自行解冲突，而不必点对点通讯；对外仍由 Worker 把关键结论报给 Router，保持全局记忆一致。

3.3 Inline & Spill 与 Chain of Recall：把上下文窗口当缓存

事件过滤并路由到位之后，问题变成：往模型窗口里塞多少。输入不再是有限几条人工提示，而是环境持续产生的半结构化事件——塞太多稀释注意力，塞太少又逼模型反复调工具读上下文。作者把有限窗口当成缓存，借用编译优化与系统里的说法：

• Inline（内联）： 把近期很可能要用的信息直接放进当前窗口，省掉额外工具往返。
• Spill（外溢）： 超预算或很少用的完整信息放在窗外，窗内只留引用或摘要，需要时再按需读取。

再叠上局部性：先给对象 ID 与摘要 → 按时空邻近逐步 Inline 相关片段（例如内容前 50 字、消息前后文与被回复对象、同一次评审里的邻近评论）→ 超长内容设小上限并 Spill，截断处留指针。

Router 自己也有上下文问题：许多后续事件直通 Worker，历史任务又不断堆积，它不可能把每个任务的完整历史都留在窗里；但用户换个通道提起旧任务时，又必须能恢复。把 Inline & Spill 一致地用在 Trigger、Thread、Worker Session 等对象上，就得到按需、多跳的 Chain of Recall（回忆链）：对象有唯一 ID，注入时内联密切相关对象的 ID，形成引用图；工具召回的结果同样带下一跳摘要与 ID，模型可从当前事件一跳跳地往回找，需要多深找多深。

3.4 抢先行动：投机执行换「人少等、少插手」

再借系统里的投机执行：根据环境信号，在尚不确定结果是否会被采用时，先在后台开工；有用的交付，无用的丢弃。个人场景里，会议邀请或待办到达后，可后台查日历冲突、搜集背景、起草回复，人只审草稿再发送。研发协作里，他们举例在内部 DeepSeek Harness 用户群配置「默默复现并修复」策略：有人报问题或讨论改动时，代理先在后台尝试复现与找修复；确认问题且修复足够简单才交付，否则全程安静。

解读： Triggers 一节的工程灵魂，不是「多接几个 webhook」，而是噪声过滤、冷热路由、上下文当缓存、以及何时允许静默开工——全是用系统套路驯服「永远在线」的代价。

4. 全双工多通道：后台别堵前台，通道别用同一套话术

两层架构在上下文层面保证了跨通道连续；日常交互还要再解决两件事：交互如何发生，以及发生在哪里。

4.1 全双工与异步 ReAct

经典 ReAct 里，模型发起同步的 run() 一类工具调用时，环会阻塞到工具返回；在此之前会话无法响应用户新输入。要把对话从半双工、轮次制改成全双工，作者把耗时命令换成异步的 start() / stop()：start() 立刻返回「已启动」，环不等工具；工具在后台结束后，系统把最终结果作为新事件消息送回会话；模型也可按上下文 stop() 掉跑太久的后台命令。前台对话与后台任务解耦后，耗时任务跑着时仍可回人；新输入在当前推理步结束后就能处理，而不必等后台工具全部结束。

文中明确：DeepSeek Harness 已实现这套异步任务机制，但默认尚未开启。 读产品时不要默认「装上 Harness = 已开全双工」。

4.2 多通道：IM 短、GitHub / 邮件密

群聊、邮件、GitHub 讨论的沟通习惯不同。终端里详列推理与工具日志或许合适，原样贴进群聊会淹没参与者。两层架构已经把啰嗦过程留在 Worker 内；此外还要用提示词为各通道设定规范。文中给出经验向硬规则示例：IM 侧尽量轻、少打断，像同事一样只在需要决策或签核时通知，问题直接、结论短——他们验证过的一条简单有效规则是每条回复不超过约 100 词。GitHub、邮件、文档等异步通道则交付结构化、信息密度高的输出：按项目惯例写清问题背景、变更说明与验证结果；个人代理场景则可直接起草结构化邮件与文档摘要。

解读： 「同一个代理」不等于「同一段口吻贴所有地方」。Router 统一对外，正是为了按通道裁剪详略，而不是把 Worker 的调试日志泄漏到群里。

5. 算力、状态与环境三分离：云上脑、库里记、环境留在原处

默认的本地 Agent 常把三件事绑在同一台设备上：跑 Agent Loop（代理主循环）的算力、必须持久的会话状态，以及代码仓库与本地工具链等执行环境。设备一睡或离线，代理就停；也够不着别的设备上的环境。作者分两步解耦。

第一步：算力与状态分离。 跑 Loop 的算力可以无状态，会话等持久状态进数据库；算力跑在可弹性伸缩、可重启替换的无状态云容器里。本机休眠不再等于代理下线。

第二步：云上 Loop 与「状态很重的执行环境」再分离。 模型大量上下文其实来自对仓库、本地文件、内网依赖服务等环境的工具调用——广义上，环境本身就是上下文的一部分。常见两条路都不理想：在云里起沙箱、拉代码、试图重建并同步环境——真实环境常含未提交改动、私有凭据、内网依赖、特定硬件或工具链，同步贵且易漏；或要求用户放弃本地环境、整迁上云——对许多人迁移成本过高。

因此：Loop 在云，环境留在原处；每个端点只需轻量 daemon（守护进程），不持会话状态，只执行命令并回传结果。文中对照 Anthropic「Decoupling the brain from the hands」（大脑与双手解耦）的相近思路：harness 无状态、会话日志外置、执行环境按需经统一接口接入。差异在目标场景——Anthropic 文更多谈托管服务、按需沙箱与客户 VPC 内资源；他们首先要接的是人们日常用的个人机器（含未提交改动与本地凭据，且可能间歇在线），因此支持 BYOM（Bring Your Own Machine，自带机器），也支持云主机与按需创建的计算环境。结果是：代理不再绑死一台机器，可按任务需要在执行设备间切换；间歇上线的设备重连后，云代理可自动启动并完成必须在该设备上跑的任务。

解读： 这是「持久在线」的物理底座。读到 BYOM 时务必同步记住后文安全开放问题：云与端互信一旦被打破，风险面会铺开。

6. Watchdog：主系统外的独立 Control Loop

仅有存算分离不够；长时间在线的分布式系统若只靠内部逻辑，很少能长期可靠。需要主系统外的独立 Control Loop（控制回路）。Agent 系统也不能只靠进程存活探针：很多异常不是崩溃，而是进程还在、模型却卡在无产出循环或偏离目标。因此既要盯基础设施存活，也要盯任务是否在实质性推进。

他们的外部回路是独立的 Watchdog Session：由定时消息驱动，处理 API 错误、状态恢复失败等基础设施问题，也用模型判断各 Worker 是否在推进或是否偏离总目标；及时修复，并对短暂外部故障反复复核直到解决。因为 Watchdog 本身也是带完整工具的代理会话，维护者可以用自然语言问它「为什么挂了」，甚至在系统运行中让它修正主系统行为（例如增删提示词、调整触发规则）。

解读： Watchdog 把「长期自主」从愿望变成可运维对象——承认主环会漂、会卡，所以把纠偏做成环外职责。

7. 实验要点（synthetic / indicative）

第七节是初步实验，测的是调度与路由，不是单个任务的编码能力。作者写明：工作负载与环境是合成 / 简化的，部分设定严谨性不足，结果仅供示意（indicative），不要当成生产基准。

7.1 端到端消融：两层架构 vs 单会话 + Subagent

四套设计同时跑，由群聊与 GitHub CI 消息流驱动；每轮约 300 条消息，其中约 20 条是工作请求，其余为闲聊、跟进、取消与 CI。编码工作用「只耗时」的假工具模拟。每套设计跑 5 次。对比组包括：完整 Super-agent、去掉 Pass-through（直通）的 Super-agent，以及两种不同提示词的「单会话 + Subagent 工具」。

文中表格（机翻页）可概括为：

设计	任务完成时间 p50 / p95（分钟）	每轮全会话 cache-read tokens
Super-agent	12.4 / 15.7	23.2M
Super-agent without Pass-through	12.6 / 15.5	31.8M
Single Session + Subagent，中性提示	20.4 / 29.5	6.1M
Single Session + Subagent，优先委派提示	13.8 / 29.0	10.8M

说明：完成时间从工作请求到结果消息；p50 / p95 分别是中位数与第 95 百分位；cache-read tokens 指各会话合计的缓存读 token 量。数字来自作者合成实验，请当示意，勿外推为真实研发吞吐。

文字结论侧重点是：Super-agent 完成时间明显更短、更稳；单会话设计高度依赖提示词——中性提示下五次都没调用子代理，工作全挤在主会话，新消息不断打断，p95 到 29.5 分钟；优先委派提示下五次中有四次委派，时间有所下降但仍整体慢于 Super-agent，另一次模型觉得「活小」自己干，拖出长尾。两层架构把「Router 不自己干活、Worker 只收订阅 Thread 的消息」做成系统约束，而不是押在临场判断上。去掉 Pass-through 后完成时间差不多，但 Router 每轮决策约多 30%，cache-read tokens 从 23.2M 升到 31.8M（约多 37%）——直通未必让任务更快更好，却能实质降低 Router 的 token 与推理开销。Super-agent 因多会话并行，cache-read 用量高于单会话，是在用 token 换更短更稳的完成时间。

7.2 Router 批处理压力测试

单独压 Router：真实模型跑 Router，Worker 用 mock。把需要决策的 Trigger 到达率从约 1 提到约 40 次/分钟。平均批量从 1.0 升到 2.8；单请求时延仅从约 2.5s 到 3.9s，慢于批量增长；摊到每次决策的均摊推理时间从约 6.4s 降到 1.6s。突发堆积时，自动合并排队事件会抬高有效吞吐。这也解释了消融里「去掉直通加重 Router 峰值负载，但单 Router 仍未顶满」——以他们当前团队规模，不必过早为了吞吐去分片而牺牲全局上下文连续性。

解读： 实验想证明的是调度故事，不是「Super-agent 写代码更强」。读表时盯 p50/p95 稳定性与 Pass-through 的 token 账，比盯绝对分钟数更有用。

8. 开放问题：规模、无会话产品面、A2A 与安全

作者承认现阶段能保持相对简单，是因为工程与场景都做了简化。开放问题收成四块：

1. 两层如何继续放大： 单 Router + 订阅直通、Worker 间无直连，已覆盖他们日常大部分任务；任务更大、耦合更紧时，Router 何时分片、分多细，Worker 何时直连、用什么协作拓扑，仍待更多场景验证。系统与模型共设计（专门训 Router 侧判事件、批派发、召回）也是方向。长期记忆则是再下一层瓶颈：Chain of Recall 主要解决近况按需找回，跑到数月以上后长期记忆会成为主瓶颈。
2. 没有「会话」之后怎么协作： 执行会话不再一一对应界面上的对话后，任务如何呈现、何种交互与项目管理自然，变成产品问题。聊天窗成为中心有路径依赖；更多交互可能迁入领域界面（例如直接在 GitHub Issue / PR 里干活）。会话也可以留在界面上迁就习惯，但用户看见的一条对话不必等于底层一个会话。过渡期模型仍常需人中途介入，如何在不毁掉后台自主效率的前提下逐步插手，也值得探索。最终形态高度依赖领域与个人风格；DeepSeek Harness 的开放架构被写成便于定制的理由。
3. 上下文边界与 A2A： 单实例内默认信息收拢进一个全局上下文；组织变大后，给哪些部分共享实例、哪些隔离，本质上是在划上下文边界。跨边界协作就是广义的 A2A（agent-to-agent，代理间通讯）——不是特指某一协议。如何在无共享底层上下文、各代表不同权限边界的代理之间安全可靠地协作，仍未写完。
4. 安全与隐私： 事件驱动扩大了不可信输入面；第五节云上 Loop + 端上 daemon 隐含云与端互信。云侧不断吃外部事件，端上却有私有代码、敏感数据与本地凭据——一旦服务端入侵或 prompt injection（提示词注入）拿下 Loop，所有已连接端点都可能被接管。即便云未被攻破，只要端上凭据能进入模型上下文，正常执行也可能泄露。代理需要一种使用凭据却永不看见凭据的路径。不能解决安全隐私，Super-agent 就只能缩在很小的可信范围里。

解读： 开放问题一节其实是全文最诚实的产品说明书——告诉你「哪些故事还没资格当承诺」。尤其是安全段，应和 BYOM 一起读，而不是只抄架构图。

9. 读法与边界

可以带走的读法： 把这篇当成「用计算机系统经典招式重组 Agent 运行时」的架构随笔。五块模块分别回答连续与吞吐、主动性、交互体验、持久在线、异常自愈；实验只示意调度，不证明编码神力。对人的启示是：下一步生产力瓶颈，越来越不像「模型会不会干单活」，而像「人还要不要亲手当会话调度员」。

必须守住的边界：

• 架构探讨 ≠ DeepSeek Harness 现成功能说明书。 文首已写死；不要按文中模块清单去对照「设置页里有没有同名开关」。
• 原型插件 ≠ 官方正式产品。 dsh-superagent-prototype 用于验证路线；主仓 deepseek-harness 是 Everything is a Plugin 的开源主项目，二者不要混成「已经上线的官方 Super-agent 产品」。
• 异步 ReAct： 文称 Harness 已实现，但默认未开。
• 禁止把本稿当原文替代。 完整论述、图示与实验曲线以官方 X Article为准。

原文链接：https://x.com/DeepSeekHarness/status/2116857257245987236。本稿为摘要与评论，非全文转载。