DeepSeek超级Agent五项实测：能修Bug，也会擅自做主

DeepSeek 新推出的超级 Agent 在三天内收获 16000 颗星，被不少人称为“Claude Code 杀手”。但它的 README 里藏着一句几乎没人注意的话：这个工具的目标不是写出比 Claude 更好的代码，而是让你少被打扰。带着这个判断，一位 B 站 UP 主用一个真实项目和五个 GitHub issue 做了实测，其中两个是陷阱。结果既有惊喜，也有值得警惕的细节。

它到底是什么：一个“住在项目里”的 AI 同事

用大白话说，这是一个绑定在单个项目上的 AI 团队成员。白名单里的人写下“@agent 修一下这个”，它就会开一张工单，在自己的私有会话里干活，最后回复一个 pull request——也就是供人审查后再合并的变更提案。它是免费开源的，背后调用的模型成本只有几美分。

这与“多开几个 AI 聊天窗口”的体验有本质区别。DeepSeek^广告 自己测量过：一个人同时真正能跟住的 AI 会话大约是三到五个。也就是说，AI 不再是慢的那一环，人才是。这个超级 Agent 想解决的正是这个瓶颈——它不需要你盯着，只在有必要时才出声。

五项测试：三次干净通过，两次有“但书”

测试一：真实 bug，52 秒给出 PR

场景是一个餐费分摊应用：4 个人、120 美元晚餐、20% 小费，应用算出每人 31.50 美元，正确结果应是 36 美元，而项目里所有测试仍然通过。

Agent 先做了两道检查：我有没有权限提问？这是不是一个真正的请求？两个都是“是”，于是开票，并附带一份写明工作边界的书面授权。29 秒后它回复“在办了”，52 秒时 PR 已经出现。它找到了真正的错误——小费被除了两次——用两行代码修复，还补了三个测试防止回归。这是干净利落的一次通过。

测试二：模糊反馈，它选择不动

第二个测试是陷阱。UP 主只标记了它并写了一句“分摊页面看起来有点怪”，没有目标、没有具体请求。多数 AI 工具会立刻动手重设计页面，而这个 Agent 读完什么也没做：不回复、不改代码，只给自己留了一条笔记——“模糊的视觉反馈，无目标，方向未定”。

这对应它的两条规则：只在被要求、或团队规则允许时行动；只在需要你行动、或有可用结果时才说话。这一轮，它赢在克制。

测试三：它擅自做了产品决策

第三个测试开始变得微妙。需求是“加货币支持”，听起来简单，但总得有人决定支持哪些货币、一个群组里能不能混用——这是产品决策，不是代码修复。按它自己的规则，它应该停下来问。

它没有。两分钟后，UP 主拿到了一个含 12 种货币的选择器：欧元按欧洲写法显示，日元不带小数，还附上了它自己从页面上截取的前后对比截图。活儿干得不错，但它替人做了决定：只做标签、不做汇率换算。公平地说，它在文字里明确告知了这一点。问题出在设计上——当你直接 @ 它时，它会跳过那道本该拦住设计决策的检查。由此得出一条经验法则：如果你 @ 了它，就意味着你已经做过决定了。

测试四：没 @ 也能跟进评审意见，但留下垃圾

UP 主回到测试一的 PR 下留了一条普通评审意见：“请显示成美元和美分。”完全没有 @ Agent。12 秒后它回复“在办”，两分半后输出 38 美元 33 美分。但看文件列表就会发现，它给项目留下了 7 处残留——截图和用于自查的代码副本。真实评审者会把这些打回去。

不过这轮验证了一个重要理念：一旦工单存在，后续每一条回复都应该再次喂给 AI。这条链路是通的，只是工程细节还糙。

测试五：陌生人请求，被静默忽略

最后一轮，UP 主把自己从白名单里移除，像一个陌生人那样请求加一个新按钮。29 秒后，它无声地忽略了请求，日志里只有一句“非成员”。这个行为是对的，因为这东西对你的电脑有完全访问权限。DeepSeek 官方文档也这么说，并建议给 Agent 单独开一个用户账户，只配置它自己的密码。UP 主把测试限制在一个私有演示项目里，自己写下每一条消息。

白名单（allowlist）机制是这类项目级 Agent 的核心安全边界。它的工作原理是：Agent 只响应预先登记在配置文件中的 GitHub 用户名发出的请求，其他人的 @ 提及会被直接丢弃，连"拒绝"的回复都不会产生。这与传统的权限系统不同——传统系统通常会返回"权限不足"的错误，而白名单选择静默忽略，避免向陌生人泄露"这里有一个 AI 在监听"的信息。文章中提到 Agent 对你的电脑有完全访问权限，这一点并不夸张：它能读写项目文件、执行命令、创建分支和提交 PR。因此 DeepSeek 官方建议为 Agent 单独注册一个 GitHub 用户账户，并且在权限配置上只授予该账户访问特定仓库的权限。这样一来，即使 Agent 被诱导执行了危险操作，影响范围也被限制在隔离账户和单一项目内，而不会波及你个人的主账户和其他私有仓库。

速度对比与一个必须说清的“但书”

DeepSeek 拿它和一个处理约 300 条消息的普通 AI 会话做了对比：超级 Agent 最慢的任务也在约 16 分钟内完成，单会话则花了将近 30 分钟，而且五次任务中零次交接。

但这里有个关键限定：编码过程是用计时器模拟的。所以这组数据只能证明它在任务路由上更快，说明不了代码质量。这也是 UP 主坚持用真实项目做测试的原因。

同样的 bug 交给 Claude，在本机 19 秒内就给出了结果，但 UP 主观察到的更快，更多体现在单次响应而非整条工作流。两者的定位不同：Claude 是更快的工人，DeepSeek 打造的是一个能在你忙别的事时从评论里接活的同事。

**观察模式（observe mode）**是文章结尾建议的安全实践，值得展开。它的思路借鉴自基础设施领域的 dry-run 和 Kubernetes 的审计模式：Agent 照常接收任务、照常推理，但所有会产生副作用的动作——写文件、提交 commit、开 PR、执行命令——都被拦截，只记录到日志里。你可以事后查看"如果放开，它会做什么"，再逐条决定是否放行。这种模式特别适合新手和首次接入真实项目的团队：先用几天时间积累行为样本，评估它的判断是否可靠，再逐步放开权限。与之配套的是最小权限原则：Agent 账户只应拥有目标仓库的读写权限，不应有组织级管理权限，更不应复用你本人的凭据。文章提到的"单独用户账户"正是这一原则的落地方式。

一个没在计划内的发现：@ 消息可能悄悄丢失

实测中出现过两次：UP 主 @ 了它，它却完全没看到，没有报错，什么都没有。原因在代码里——GitHub 通知 mention 大约有 23 秒延迟，而 Agent 只回看 5 秒。这意味着大约三分之一的首条 @ 消息可能直接消失。

这是只有真正跑起来才会发现的问题，也印证了 DeepSeek 自己的定位：判断力令人印象深刻，管道工程仍是原型。

GitHub 通知系统的 mention 延迟值得单独说明。当有人在 issue 或 PR 评论中 @ 某个用户时，GitHub 并不是实时推送这条消息，而是通过通知队列异步分发，官方文档和社区实测都显示延迟通常在数秒到数十秒之间波动，文章给出的约 23 秒是一个观测值。这类 Agent 通常采用轮询方式拉取通知：每隔固定间隔查询一次"有没有人 @ 我"，并且只回看最近若干秒内的通知，以避免重复处理。问题在于轮询窗口与通知延迟之间存在错配——如果一条 mention 在 Agent 查询之后、下一次查询之前才真正进入通知队列，而它又落在回看窗口之外，这条消息就永远不会被看到。解决方案通常是扩大回看窗口、改用 webhook 事件推送，或在评论中同时触发多种信号作为冗余。这也是文章所说"管道工程仍是原型"的具体体现。

实用问答与安全建议

几个高频问题：需要 DeepSeek 的 harness 吗？需要，它是个插件。需要 DeepSeek 自己的服务器吗？不需要，UP 主是通过 OpenRouter 调用 DeepSeek 的 flash 模型跑的。需要那个聊天应用吗？不需要，单独用 GitHub 就能跑。安装难吗？不用照手册，直接让你的编码 Agent 读 setup.md 帮你装，它一次只问一个问题。它唯一替你做不了的一步，是给 Agent 注册第二个 GitHub 账号。

对于是否让新手直接上真实项目，UP 主的建议是：还不行，这仍是研究性质的代码。但它的规则今天就可以借鉴。如果要真用，务必做两件事：给 Agent 单独的用户账户；把任何没人明确要求过的动作先设为观察模式——它只记录自己会做什么，而不真的动手。

整个五项测试的成本是 11 美分。回到开头那个问题：当一个人只能同时盯三到五个 AI 会话时，DeepSeek 真正交付的，是一个知道什么时候该闭嘴的 AI。至于要不要让它在夜里替你开 PR，答案取决于你多信任那套权限设计。