--- title: "Agent 移走的是「协调」那一步，不是「审查」那一步" url: https://wakenex.com/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/ language: zh-CN type: article section: "系统研究" published: 2026-11-02 author: "WAKENEX" id: "article:the-agent-removed-the-coordinating-step-not-the-reviewing" alternate_language: https://wakenex.com/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/index.md license: "© WAKENEX。可引用与摘要，请注明出处并附原文链接。" cite_as: "WAKENEX. \"The agent removed the coordinating step, not the reviewing one.\" wakenex.com, 2026-11-02. https://wakenex.com/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/" --- # Agent 移走的是「协调」那一步，不是「审查」那一步 > DeepSeek 开源了一个号称尽量少占用你注意力的编码 agent。读一读它自己的设计，那个它无法移除的上限就冒出来了。 **一句话判断：** 把 agent 的协调自动化，只是把瓶颈挪到了审查，而不是移走它。 **WAKENEX 概念：** [知识调用与任务执行](https://wakenex.com/concepts/how-tasks-get-done/) ![一条传送带把一大堆空白白纸倒进一个金属漏斗；漏斗收窄成一个小口，一只人手拿着小台灯在出口处一张一张地检查、盖章，而积压的纸越堆越高。身后一道蓝色光门发光。](https://wakenex.com/assets/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/cover-1600.jpg?v=c3078bdc9c) *图片：WAKENEX* 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 做的是更安全的那个版本，而更安全的版本，把人留在了那个决定其余一切上限的位子上。 ![一个一分为二的场景。左边，一群小小的自动化机械臂高速地分拣、分派一叠叠工作文件夹。右边，一个人坐在一张被灯照亮的书桌前，在灯下读一页文件。自动化那一侧一片忙乱的动态；人这一侧安静而审慎。](https://wakenex.com/assets/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/fig1-1600.jpg?v=daf39177f2) *图片：WAKENEX* ## 审查并不免费，而上限就坐落在那里 默认读法悄悄假设审查很便宜——批准一个 agent 写的改动不花什么真正的时间。并非如此。要负责任地接受一个 pull request，人必须读懂这个改动、明白它动了什么、再判断它对不对。这要花几分钟到几小时，视改动而定，而且跳不过去——跳过去就把「agent 干活」变成了「agent 发布没人审过的代码」，而那恰恰是没人真正想要的。 一旦你承认审查要花时间，这笔账就反过来了。真正落地的总产出——被合并、被使用的代码——并不由有多少个 agent 在起草来决定。它由人能多快接受或拒绝 agent 起草的东西来决定。多开一个 agent，起草量翻倍，送到面板上的提案也翻倍。它对审查者清掉这些提案的速度毫无帮助。上限是审查能力，而更多 agent 并不抬高它；只是把它填得更快。 有一项独立证据值得小心地点出来，因为它很容易被夸大。一个叫 CooperBench 的通用研究，发表于 2026 年 1 月，发现编码 agent 组队工作时，成功率平均比各自单干时低 30%。那项研究并没有测试 DeepSeek 的 Super-Agent——它是一项独立、无关的研究。所以它不是关于这款产品的证明。但它是一个指向同一方向的信号：协调多个 agent 是有代价的，一群里塞更多 agent，并不自动等于产出更多好活。把它当作一个去测量的理由，而不是一个定论。 ![数据卡。一个数字：编码 agent 组队工作时成功率比各自单干低 30%（CooperBench，2026 年 1 月——一项并未测试本文所讨论的 Super-Agent 的通用研究）。](https://wakenex.com/assets/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/fig2-1600.jpg?v=1d24dba46e) *Chart: WAKENEX · Source: The Next Web / CooperBench · as of 2026-01* ## 一个主动出击的 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，等待中的未处理提案在涨，而每小时的合并数却持平，那你并没有扩大产出。你只是把瓶颈从「做这份活」挪到了「清这个队列」，还把队列拉长了。 这个总原则比这一个原型活得更久，这也是它值得记住的原因。每当一个工具承诺「尽量少占用你的注意力」，去找它交还给你的那一步，并测量你在那一步上的速度。是那个被保留的环节，而不是那个光鲜的自动化环节，给整个系统封了顶。 ![一个人坐在书桌前，面对一摞高高的、还在变高的文件夹，标注为未处理的提案，桌上一个小仪表读数「每小时合并数」稳稳不动。那摞文件越堆越高；仪表纹丝不动。仪表是亮的；那摞文件在阴影里。](https://wakenex.com/assets/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/fig3-1600.jpg?v=e1a17a46ff) *图片：WAKENEX* ## 什么会让我改判 这是一个判断，而且它可被证伪。如果有一项独立评测——或者一个团队自己记录的数据——显示采用像 Super-Agent 这样的 agent 之后，每审查者每小时被接受、被合并的产出上升了，也就是每个被接受的 pull request 所花的时间真的下降了，而不只是等待人处理的未处理提案数变多了，那我就会改判。该去看的地方是独立的、针对该 agent 的基准测试（CooperBench 式的团队评测，或 SWE-bench-Multi 式的测试），以及公开的、采用前后对比的团队「每审查者每小时合并改动数」。一个合理的复核日期是 2027-03-31。在这样一个数字出现之前，稳妥的读法是：这些 agent 把瓶颈挪到了审查，而还没有让审查变得更便宜。 看清系统，建立杠杆。这里的杠杆不是你能开出多少个 agent，而是你能多快地对它们产出的东西说「行」或「不行」。 ## 来源与说明 - [DeepSeek，「dsh-superagent-prototype」（GitHub 仓库，MIT 许可），2026-11-02 打开。关于设计、监听行为（「监听 GitHub，以及可选的飞书」）、按任务独立会话、以 pull request 回复、网页面板（「一个网页面板显示哪些需要人来处理」）、所述目标（「尽量少占用人的注意力，并给出尽量多的价值」）、主动性规则，以及自我警告（「一个能替整个团队行动的 agent，也能浪费整个团队的注意力」）和研究原型声明（「不是 DeepSeek 的正式产品」「把它当研究代码看，不是生产级软件」）的一手来源](https://github.com/deepseek-ai/dsh-superagent-prototype) - [The Next Web，「DeepSeek open-sources a coding agent」，2026-11-02 打开。关于 2026-11-01 发布、把该 agent 定位为对标 Anthropic 的 Claude Code，以及 CooperBench 数字的报道。CooperBench 研究（2026 年 1 月）发现编码 agent 组队时成功率平均比各自单干时低 30%；The Next Web 明确表示「该研究并未测试 DeepSeek 的 agent」。因此这个约 30% 的数字是「多 agent 协调有代价」的通用证据，而不是对这款产品的评测](https://thenextweb.com/news/deepseek-super-agent-open-source-coding-agent) - [南华早报，「DeepSeek unveils AI super-agent in coding race」，用于报道与背景，仅标题/摘要](https://www.scmp.com/tech/article/3372884/deepseek-unveils-ai-super-agent-coding-race-openai-anthropic) 关于中立的说明：报道把 Super-Agent 定位为 Anthropic 的 Claude Code 的对手。本文不对孰优孰劣表态；它分析的是任何自我协调的编码 agent 共有的机制，不作任何性能对比的断言。 --- 引用格式：WAKENEX. "The agent removed the coordinating step, not the reviewing one." wakenex.com, 2026-11-02. https://wakenex.com/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/ 网页版：https://wakenex.com/articles/the-agent-removed-the-coordinating-step-not-the-reviewing/