10 月 31 日晚，DeepSeek Harness 团队在官方公众号发布《Super-agent 设计探索：迈向更自主的 Agent 系统》，同时开源了一个 MIT 许可的研究原型 dsh-superagent-prototype。文章开篇就把话说死：“本文是一篇面向工程实践的架构思路探讨，并非对 DeepSeek Harness 现有产品功能的介绍”，README 也写明这只是研究原型、不是正式产品。所以"主动干活会不会越界打扰"的第一层答案是：它还不是一件正在打扰你的事——目前没有任何 DeepSeek 产品默认开启了这种自主行为，连原型里最接近产品化的异步执行，也是"已实现、但未默认开启"。微博知乎
但更值得看的是第二层：这套设计的全部出发点，恰恰是"怎样不打扰人"。原型哲学文档把第一性原理写成一句话——Take as little human attention as possible, and give as much value as possible（占用尽可能少的人类注意力，提供尽可能多的价值）。而一位开发者搭回放测试台复现这套架构后发现，真正的风险换了个方向：它不会吵到你，但可能安静地犯错，而且错误会连锁。知乎知乎
把"派活"从人手里拿走，但不给 Agent 动手的权力
这套架构要解决的矛盾很具体：现在用 Coding Agent，一个窗口干一件事，开到第四个窗口就记不清哪个改到哪一步。DeepSeek 团队的观察是一个人通常只能同时跟进 3 到 5 个活跃会话，原文那句判断因此被广泛引用——“单任务的上限取决于模型能力，多任务的上限取决于人的注意力”。他们的解法是把调度从人手里接走：用户面前只留一个 Agent 入口，底下几个会话在跑，不用人操心。36氪
架构切成两层：常驻的 Router 只接消息、维护全局上下文、分发任务，死规矩是自己不动手，源码解读把它概括为"路由者不做技术决策"，原文甚至说它可以"不配备 Bash 工具"。下面一堆隔离的 Worker 会话挂着完整工具链并发干活，不直接跟人对话，干完统一经 Router 汇报。为什么非要这样拆，原文的消融实验给得很直接：一个会话配 subagent 工具、用中性提示词跑 5 次，模型一次都没有主动分工，全堆在主会话里干一半就被新消息打断；改成"优先委派"，也只派下去 4 次。双层架构等于用系统结构定死了"必须分工"，不再赌模型的临场判断——这正是"Router 不动手"这条硬规矩存在的意义。知乎知乎
为了"主动得不打扰"，它在代码里划了几道硬边界
细读原型的文档和源码，"主动"在这个系统里是被层层约束的，而且大多由代码保证、不靠提示词自觉。外部事件进来先过程序规则——来源、群组、白名单写死快筛，过了关的才交给模型判断要不要接，避免每条群消息都去调一次大模型。
动手要有边界：接受一个请求时生成一份不可变的授权书 Mandate，“执行以它为界”，工单结束不自动撤回，只有人显式停止或规则变更才失效，恢复工单前还要重新校验。主动性放在团队环境里首先是个授权问题，原型的做法是：只有明确请求或团队白纸黑字的规则，它才动手。知乎
提前干活，没结果就闭嘴。这套设计借用了 CPU 的投机执行：收到会议邀约不等开口，后台先查日程冲突、拟好草稿。DeepSeek 的内部用户群真配了一条规则——有人提 bug，Agent 先在后台试着复现和找修法，确认存在且有简单修法才在群里开口，复现不出或改动太复杂就全程沉默。知乎
输出端同样有节制：IM 里验证过一条硬限制，单次回复不超过 100 词，只在需要人拍板或验收时才出现。知乎
还有两个写在源码里的保险栓。其一，接受模式分 off、observe、auto 三档，默认 observe——第一次跑起来它不会真动任何东西，只在旁边记录"如果让我干、我准备怎么干"，人翻完记录觉得靠谱，才手动切自动。其二，人随时可以插队：Worker 并发槽限 1 到 16，但人的消息可以多占一个额外槽位，且唤醒优先级高于新任务启动——哪怕 16 个 Worker 全满，人说话它就得腾地方先接。知乎
复现实验：错误不是"吵"，是"安静"
边界画得严，不代表执行得住。一位开发者把模拟团队群聊的消息流灌进原型真实代码搭了回放评测台（语料是合成的，不是真实团队长期运行，结论要按这个口径看）。好消息是，叫停、指代不明、"先别动手"这类难例上，Router 判对 77/78。坏消息是前面说的那类错误：它判断了，判断错了，而且没人知道。知乎
典型的是误叫停。"你不用管了"这类没指明是哪件事的话，Router 常按发送人去猜他手上唯一在办的工单，然后直接停掉——叫停是破坏性的，进行中的工作丢了。原版提示词下它错误叫停了 9 次、连带波及 18 条消息；加一条"必须明确指向某张工单，没说就反问"后降到 0 次，但回复从 42 条涨到 56 条——安全是拿更多打扰换来的，这恰好就是标题那个问题的两难。知乎
另一头是"太安静"的问题：人补充需求时如果没 @ 智能体，会被准入策略直接静默丢弃，全不 @ 的场景丢 100%，一半 @ 的场景丢 45%。所谓跨渠道连续，目前还得靠人主动 @；工单完成瞬间恰好到达的补充消息，26 条里 Router 只挽回了 20 条；再让 15% 的 Worker 随机卡死，默认只有 3 个槽位，3 个一起卡住整个系统就停摆，卡住期间没有任何人被告知。显式触发漏了，人会再 @ 一次，错误看得见；Router 判错了，错误会顺着后面的判断悄悄传下去。知乎
团队自己留在台面上的两道坎
比"打扰"更重的越界问题是安全，文章写局限性时自己摆了出来：一旦云端 Agent Loop 被服务端入侵或提示词注入攻破，它连接的全部端侧设备都面临被控制的风险；就算云端没被黑，端侧凭据一旦进入模型上下文，正常干活调用也可能漏出去。原文的结论毫不含糊：“如果没有办法很好地解决安全与隐私问题，那么 Super-agent 只有在一个很小且可信的范围才能工作”。知乎
验收则是注意力没有消失、只是上移。Super-agent 省下的是派活和来回搬背景的注意力，"主动"并不意味着刷存在感，但人退到决策与验收之后，验收本身成了新瓶颈——上面那位复现者援引的行业数据里，AI 用得多的团队合并 PR 多了 98%、review 时间多了 91%，Anthropic 团队代码库每天落地的改动从 5 月约 2500 个涨到 9 月 3 万多个，而原型里还没有验收这一层。知乎
需要说清的现状是：文章讲了五个模块，这份开源原型只落地了双层架构、事件驱动和面向人交互的三块，存算分离和 Watchdog 还没实现；全部实验基于合成消息流，没有真实代码交付的长期对比。接下来值得盯的信号很具体：产品化版本会不会把默认模式从 observe 切向 auto，误判能不能做到"可见"——出错时主动报警，而不是等人发现，以及同一批真实任务上 Super-agent 对照显式触发的实测结果。一个主动干活的 Agent 到底越不越界，答案不在架构文章里，在这三件事上。知乎
