Agent 移走的是「协调」那一步，不是「审查」那一步

DeepSeek 刚刚开源了 Super-Agent，一个免费的编码 agent，设计目标是尽量「少占用人的注意力」（译文）。但看它的设计：它自动化的是协调工作这一步，而每一个结果仍然得由人来审查。瓶颈并没有消失——它挪到了你身上。DeepSeek 在 2026-11-01 放出代码，省下注意力的承诺是真的；问题在于，你在协调工作上省下的注意力，会以审查工作所花的注意力的形式再回来。

这个区分正是本文的全部重点。所谓「编码 agent」，是一个能像初级工程师那样自己编写和改动软件的程序，而不用人去敲每一行代码。当厂商说它的 agent 能「替整个团队」干活时，人们自然会听成：团队的瓶颈——那个限制真正能完成多少工作的环节——被移除了。它没有被移除，而是被挪动了。而它挪到了哪里，决定了这类工具是让你更快，还是只是更忙。

默认读法是：一个自己运转的 agent 移除了人这个瓶颈

大多数人从这类发布里带走的故事是这样的：一个聪明的 agent 现在能自己协调一个团队的编码，于是人被解放出来，团队一下子能同时做多得多的事。跑十个 agent，就得到十个工程师的产出。过去的上限是你能雇佣和管理多少人；现在的上限只是你能开出多少个 agent，而那几乎是无限且近乎免费的。

如果这是真的，那将是软件业最大的生产力跃迁之一，你也会想在预算允许的范围内尽可能多地跑 agent。这个说法值得认真到拿去对照真正的设计来检验——因为那份由 DeepSeek 完整公布的设计，讲的是一个比标题更具体的故事。

下面是这套设计实际在做的事，一步一步看

按 DeepSeek 自己的描述，Super-Agent「监听 GitHub，以及可选的飞书」（译文）——也就是盯着一个团队的代码仓库和聊天。当「有权限的人向 agent 请求工作」时，它「开一个工作项，在它自己的 agent 会话和目录里处理它，并在原来的对话里回复，比如给出一个 pull request」（译文）。pull request 是提议代码改动的标准单位：一捆改动，由人类审查者阅读，然后决定接受还是拒绝，之后才会并入真正的软件。系统内部分成一个负责分派请求的协调器和负责执行的工作器，所以多个任务可以同时跑。

接着是最要紧的那句话。DeepSeek 写道：「一个网页面板显示哪些需要人来处理」（译文）。这个 agent 并不把自己的成果合并进线上代码库。它生成提案，摆出来让人来批准。DeepSeek 明确表示，人仍然「负责设定目标和审查工作」（译文）。

所以，把什么被自动化了、什么没有，理一遍。自动化的是：注意到有活要干、把它接过来、起草改动、并整理成一个可供审查的提案。这是协调和初稿——实打实的劳动，确实被接管了。没有自动化的是：判断这份提案是否正确、是否安全、是否值得保留。这是审查，而它按设计又交还给了你。agent 移走了组织和书写这一步，却保留了判断那一步。

这并不是工具的缺陷，而是工具诚实的形状。一个你敢让它不经人看就自行合并代码的 agent，会是一个非常不同、也危险得多的产品。DeepSeek 做的是更安全的那个版本，而更安全的版本，把人留在了那个决定其余一切上限的位子上。

审查并不免费，而上限就坐落在那里

默认读法悄悄假设审查很便宜——批准一个 agent 写的改动不花什么真正的时间。并非如此。要负责任地接受一个 pull request，人必须读懂这个改动、明白它动了什么、再判断它对不对。这要花几分钟到几小时，视改动而定，而且跳不过去——跳过去就把「agent 干活」变成了「agent 发布没人审过的代码」，而那恰恰是没人真正想要的。

一旦你承认审查要花时间，这笔账就反过来了。真正落地的总产出——被合并、被使用的代码——并不由有多少个 agent 在起草来决定。它由人能多快接受或拒绝 agent 起草的东西来决定。多开一个 agent，起草量翻倍，送到面板上的提案也翻倍。它对审查者清掉这些提案的速度毫无帮助。上限是审查能力，而更多 agent 并不抬高它；只是把它填得更快。

有一项独立证据值得小心地点出来，因为它很容易被夸大。一个叫 CooperBench 的通用研究，发表于 2026 年 1 月，发现编码 agent 组队工作时，成功率平均比各自单干时低 30%。那项研究并没有测试 DeepSeek 的 Super-Agent——它是一项独立、无关的研究。所以它不是关于这款产品的证明。但它是一个指向同一方向的信号：协调多个 agent 是有代价的，一群里塞更多 agent，并不自动等于产出更多好活。把它当作一个去测量的理由，而不是一个定论。

一个主动出击的 agent，填队列的速度比清队列更快

设计里还有第二处转折，它让审查这个上限卡得更紧，而不是更松。Super-Agent 是主动的。它不只在被召唤时才回应；它「只在被请求、或团队写好的某条规则允许时才行动」（译文）。这句话是双刃的。它是一道合理的安全栏——agent 不会乱跑，它遵守你设的规则。但这也意味着 agent 能自行开工，横跨整个团队的对话，只要某条常设规则被触发。一个主动的 agent，按其构造就是一台审查项的发生器。它监听团队活动越多，它不用任何人开口就能生成的提案越多。

DeepSeek 看得很清楚，也说了出来。它自己的文档警告：「一个能替整个团队行动的 agent，也能浪费整个团队的注意力」（译文）。一个厂商把这句话印在自家发布旁边，是很了不起的；而它恰恰就是这里描述的机制。agent 靠协调和起草省下的注意力，可能被原样花回去——甚至更多——如果它递交的提案多过团队能审查的量。队列不会缩短，只会填得更快。

同一套设计里还有一个更安静的代价也值得点名：为了能在团队范围内主动出击，agent 读取团队的聊天和代码仓库。那是一片隐私与信任的暴露面，不是一个要最大化的功能。一个 agent 为了能不被请求就行动而监听的团队私下对话越多，团队就越依赖那份监听本身表现良好。把这份监听当作一个要权衡的代价，而不是一个要拧到底的旋钮。

这里还有一条诚实的提醒要放进来。DeepSeek 把 Super-Agent 标注为「仅供参考的研究原型，不是 DeepSeek 的正式产品」（译文），并告诉你「把它当研究代码看，不是生产级软件」（译文）。所以上面说的一切，描述的是一次能力演示，而不是一个可靠性承诺。它表明一个 agent 能协调一个团队的编码。它并没有表明审查那一步变便宜了，而那一步才决定这一切是否真让一个团队更快。

反方最强的版本

公平的反方不是说瓶颈消失了——而是说，每单位工作所花的审查时间可以真正下降，而不只是挪位置。对一个有纪律的团队来说，论证是这样的：agent 只按你写好的规则行动，它起草的改动本来就得你自己写，而读一份写好的 diff，比从零去写需求、编写、再自查要快。如果草稿好到审查只是快速浏览而非返工，而且自动开出的提案的流量保持在审查者能清掉的范围内，那么这个 agent 就是实打实的净收益——你白得了起草，每个交付的改动所花的总人力时间反而更少。

那个版本可能成立。不过注意它的条件：草稿质量高到可以浏览，以及主动性被节制到队列始终清得完。两者都是经验问题，也正是你在信任它们之前该去测量的东西。反方并不推翻本文的判断；它告诉你哪个数字能证实或证伪它。

如果你正心动想跑一队 agent，这意味着什么

如果你是一个单打独斗的创造者，或一个小团队，正在掂量要不要把好几个自主编码 agent 对准你的工作，有用的做法是别再数 agent，而去数审查这一步的吞吐量。具体说：这一周，量一量你自己的「每审查者每小时合并的 pull request 数」——一个人一小时里真正能读完、批准并落地多少个提议的改动。那个数字才是你真正的产能。只在它稳得住时才加 agent。如果你加了第二个、第三个 agent，等待中的未处理提案在涨，而每小时的合并数却持平，那你并没有扩大产出。你只是把瓶颈从「做这份活」挪到了「清这个队列」，还把队列拉长了。

这个总原则比这一个原型活得更久，这也是它值得记住的原因。每当一个工具承诺「尽量少占用你的注意力」，去找它交还给你的那一步，并测量你在那一步上的速度。是那个被保留的环节，而不是那个光鲜的自动化环节，给整个系统封了顶。

什么会让我改判

这是一个判断，而且它可被证伪。如果有一项独立评测——或者一个团队自己记录的数据——显示采用像 Super-Agent 这样的 agent 之后，每审查者每小时被接受、被合并的产出上升了，也就是每个被接受的 pull request 所花的时间真的下降了，而不只是等待人处理的未处理提案数变多了，那我就会改判。该去看的地方是独立的、针对该 agent 的基准测试（CooperBench 式的团队评测，或 SWE-bench-Multi 式的测试），以及公开的、采用前后对比的团队「每审查者每小时合并改动数」。一个合理的复核日期是 2027-03-31。在这样一个数字出现之前，稳妥的读法是：这些 agent 把瓶颈挪到了审查，而还没有让审查变得更便宜。

看清系统，建立杠杆。这里的杠杆不是你能开出多少个 agent，而是你能多快地对它们产出的东西说「行」或「不行」。