过去两天，DeepSeek 的新 Agent 被传成了一头“AI 牛马”：群里没人 @ 它，它自己复现 Bug、改代码、提 PR。事情是真的，但有一个前提被略过了。10 月 31 日，DeepSeek Harness 团队发了一篇设计文章，并开源了 dsh-superagent 原型。它不是新模型，也不是一个面向普通用户的 App，而是搭在 DeepSeek Harness 上的一个 Agent 原型。文章里确实写了内部群中“无人 @ 也主动定位根因并提交修复 PR”的场景。知乎
先看它具体能做什么。开源原型盯的是一个 GitHub 仓库，也可以接飞书群。有人在群里提需求，它开一张工单，在独立目录里拉分支、改代码、跑测试，最后把 PR 链接发回原帖；后续在 PR 下的评论，会直接送到同一个执行会话，不用再 @ 一次。官方文章里的截图就是一个完整回合：字体设置的需求在 IM 里提出，维护者在 GitHub 上评审、提意见，它改完，最后在 IM 里回一句“Pull Request 已合并”。按文章的说法，内部那个实例已经在日常参与问题复现、代码审查响应，甚至 DeepSeek Harness 自身的迭代。这些事不神奇，难的是它能在没人盯着的情况下，把一条任务从提出跟到合并。
但“不 @ 就干”有前提。它得先听得见：飞书群要设成接收全部消息，GitHub 仓库要打开对应范围的全量接收，否则没 @ 它的消息根本进不来。还得被允许：发消息的人要在白名单里，或者落在一张准入表允许的格子里。团队还要给它写一条明确的规则，比如“群里有人反馈 Bug 时，先在后台复现并尝试修复”。最后，受理模式要从默认的 observe 改成 auto；在 observe 下，它最多记一笔“本来会接”，不会真的动手。 四道门缺一道，“不用 @”就不成立。DeepSeek 的文档写得很直：它只在有人明确要求，或者团队写下了允许它动手的规则时才行动。所以更准确的说法是：你可以授权它在某些条件下不用 @ 就干活，而不是它天生就会自己找活。GitHub
为什么非要把“派活”和“干活”拆开？因为单靠提示词，模型并不可靠。DeepSeek 做了一个调度实验。单会话 Agent 配一个子智能体工具，提示词写得很中性，5 次运行里它一次都没调用子智能体，所有活都自己干。 它的 p95 完成时间是 29.5 分钟；双层架构是 15.7 分钟。把提示词改成“尽量把活派出去”，仍有 1 次它觉得“这活很小”，自己干了。实验用只消耗时间的工具代替真实编码，测的是调度，不是写代码快慢，但它至少说明，派活方式会直接影响完成时间。知乎
差别不在模型更聪明，而在结构。Router 只负责跟人打交道、汇总全局信息、把活派出去，设计上不直接执行具体任务，甚至可以不配 Bash 工具。 Worker 在隔离的上下文里干活，干完只向 Router 汇报，不直接跟人说话。用结构约束行为，比用提示词劝它“要学会委派”稳定得多。知乎
但这也意味着，它的能力边界比宣传语窄。GitHub 仓库的 README 写得很直接：这是一个研究原型，不是 DeepSeek 的官方产品。 开源原型一次只监听一个 GitHub 仓库，飞书是可选项；要装它，得先有 DeepSeek Harness、Node、pnpm、tmux、GitHub CLI 等，还要给它单独注册一个 GitHub 账号。它不是下载下来就能替你处理日常事务的 App，更像是给研发团队看的一个样板间。GitHub
安全边界也像样板间。Worker 以操作系统的用户身份运行命令，默认不需要审批。 文档还明确说，这些包装只是默认值，不是安全边界。文章自己也承认，一旦云端的 Agent 被入侵或提示词注入攻破，连着它的端侧设备都可能被接管。 让 Agent 使用凭证却看不到凭证，仍是没解决的问题。所以更稳妥的起步方式，是把它放进隔离的虚拟机或容器，主动模式先只记录、不执行，观察几天再放开。GitHub知乎
回到那个问题：DeepSeek 的新 Agent 能做哪些事？它能接工单、改代码、提 PR、跟评审、在群里安静地修 Bug，也能在没人 @ 的时候自己判断要不要出手。但它首先要求你把“谁可以让它干活、什么情况下可以不用 @、它能做到哪一步”写成规则。这个答案不如“AI 牛马”带劲，却更接近它现在的样子：不是一个更聪明的聊天窗口，而是一个需要岗位说明书的数字同事。
