多开Agent不等于多产出：真正决定效率的是验证环节

同时打开五个Agent窗口，看着它们各自滚动输出，很容易产生一种“今天能多做五样东西”的错觉。B站这条视频提了一个反直觉的判断：Agent开得再多，放大的只是改动量，真正让结果变好的是验证。

改动多从来不等于功能多

视频里说得很直白：网上流传“大厂每天几万个Agent在干活”，但几万个Agent不等于几万个新功能。

人写代码的年代就是这个规律。一个新功能背后拖着一长串修补、测试、改旧代码的尾巴，一天下来改动成百上千，真正能让别人用上的可能只有一样。Agent把这套流程加速了，改动变得更便宜、更密集，但“改动→可用功能”的转化率并没有自动跟着涨。

增加Agent的数量，本质是增加候选方案的数量。而候选本身是没有价值判断的——它只是“可能对”的东西。

五个窗口各出一版，你会怎么挑？

一个自然的想法是：让五个窗口各出一版，挑最好的那个。

问题出在“挑”这个动作上。视频指出，实际挑选时评的多半是“哪一版读着顺”，而哪个版本真能用，全看你怎么查它。这就把问题从“生成能力”转移到了“验证能力”——你有没有一套可靠的筛子，决定了这五版里能不能筛出真正有价值的那一版。

没有筛子，五版候选就只是五份不知道对不对的东西，挑选退化成凭感觉。

AlphaCode的启示：候选再多，也要靠测试一轮轮筛

视频举了DeepMind AlphaCode这个公开案例：先生成大量候选方案，再用测试一轮轮筛，绝大部分过不了测试，剩下的少数才有资格交上去。

这个流程的关键不在“生成大量候选”，而在“用测试一轮轮筛”。生成环节的规模优势，只有配上足够严格的筛选机制，才能转化成可交付的产出。反过来说，如果筛子太松，生成得越多，混进来的坏东西也越多。

这也解释了为什么单纯堆Agent数量收效有限：你放大的是供给端，需求端的验收标准并没有同步变强。

AlphaCode 是 DeepMind 于 2022 年公开发表的编程竞赛模型，其核心思路是先在给定题目下大规模采样生成成千上万个候选程序，再借助题目自带的公开测试用例做第一轮过滤，对通过者进一步用人工构造的额外输入做聚类与筛选，最终只提交极少量进入正式评测。论文报告其在 Codeforces 竞赛中达到约前 54% 的人类选手水平。这个流程常被引用为“大规模采样 + 严格筛选”范式的代表：模型单次生成的正确率并不高，但通过扩大候选规模并配合高效过滤，整体成功率被显著抬升。值得注意的是，该范式的收益高度依赖筛选环节的可靠性与成本，筛选越严格、越廉价，采样规模的优势才越能兑现。

筛子本身也会漏

视频里有一个更进一步的观察：筛子本身也会漏。测试写得松，坏的东西也能大摇大摆通过。

这句话值得反复琢磨——测试全过了，只说明它过了你写的那些测试，不代表它真的对。验证的质量上限，取决于验证标准的质量。用一套宽松的测试去筛Agent产出，得到的只是“看起来通过”的错觉。

所以真正的改进方向不是“开更多窗口”，而是“让每一次验证都更准”。视频给的例子很小但很实用：AI汇总的周报，先跟上周的总数对一对——这就是一张小筛子，成本低，却能拦住明显错误。

测试的完备性是软件测试领域的经典难题。Dijkstra 有句名言：测试只能证明缺陷的存在，不能证明缺陷的不存在。也就是说，任何一组测试用例都只是对输入空间的一次有限采样，未被覆盖的分支、边界条件和异常路径仍然是盲区。对 Agent 产出而言这一问题尤其突出，因为生成的代码或文本往往“看起来合理”，语法正确、风格一致，却在语义或业务规则上出错。提高筛子质量的常见手段包括：基于需求逐条构造验收用例、引入变异测试来评估测试集本身的检出能力、以及用独立于生成方的标准做交叉核验。

把筛子做小、做准、做进流程

从这条视频的逻辑往下推，实践上可以落在这几个点上：

• 给每类Agent产出配一张明确的验收表。不是“看着还行”，而是具体到可核对的数字、字段、边界条件。
• 用小筛子做前置拦截。像周报对总数这类低成本校验，适合放在流程最前面，先挡掉低级错误。
• 警惕“全部通过”的假安全感。测试通过率是筛子质量的函数，不是产出质量的函数。筛子松，通过率再高也不说明问题。
• 数量扩张之前先问筛子够不够用。如果现有验证手段撑不住五路并发，多开的窗口只会把评审负担成倍放大。

视频结尾抛出的问题很适合当成日常自检：改动越来越便宜，值钱的是那张筛子。你今天收下的那几样东西，过的是哪一张筛子？

这个问题没有标准答案，但它把注意力从“我用了多少Agent”拉回到“我用什么标准验收”。在Agent产出越来越廉价的环境里，后者才是稀缺能力。