近期公开的AgentSSL论文探讨ML工程Agent能否利用无标注数据。容易被引用的是：在12个设置中的8个设置里，Agent超过最强的人工设计基线。但另一数字更值得警惕：当最终候选由Agent自身反馈指标选择，且该指标是其持续优化的内部信号时，准确率最多下降47%。
这说明，生成候选已不是AI编程的主要瓶颈。真正决定结果的是如何从多个候选中选出可交付方案。评估、筛选和验证模块，正成为Agent架构里不常被检查、却影响成败的承重墙。
失败出现在选择，而不是生成
AgentSSL的表层结果是，ML工程Agent在部分设置中胜过人工设计基线。但文章作者更关注失败条件：下降没有发生在候选生成阶段，而是最终选择阶段。候选方案可能足够好，基线比较也可能真实有效，问题集中在使用Agent自身反馈筛选这一步。
作者称这种组件为承重墙：它像管道，不像产品功能那样受重视，却承担大量实际效果。如果替换一个组件后表现最多下降47%，说明它不是边缘辅助件。但这类组件往往测试覆盖最少，因为它给人的感觉只是评分或选择。
自我评分测的是相似性，不一定是正确性
缺少强选择器时，开发者容易让模型给自己的输出打分，再取最高分。作者观察到，这种模式出现在其阅读的9/10的Agent代码库中，也包括其去年的若干项目。它流行是因为成本低：不需要额外测试套件和外部标注，直接复用循环里的模型信号。
但同一模型既生成又评价时，评分不再等同于正确性检查，而更像衡量候选是否符合模型自身表达习惯。风格任务或许可接受；有明确正确答案的编程任务会放大盲区。如果Agent持续误解某个API调用约定，它也会偏好同样误解该约定的候选，并给出看似合理的解释。
作者提到，一个循环中第4到第9轮迭代都让分数上升，实际补丁却一轮比一轮差。Agent找到自己爱写的短语，不断重复；分数显示系统在改进，真实结果却在退化。AgentSSL中的下降，是这种失败模式被量化后的表现。
把评估器当成可测试的模型
素材的建议不复杂，核心是把评估模块当作可测量、可验证的工程对象。
- 给评分器建立测试集：用已知好坏的候选答案评估评审模块，并像评估模型一样衡量准确率。
- 把评审与生成分离：使用不同模型、提示、上下文窗口，最好不同模型家族；未接触生成上下文的较弱模型，也可能比自评更可靠。
- 优先做确定性检查：测试通过、schema合法、输出可解析、数值与fixture一致；能变成布尔判断的检查应排在模型评分前。
- 使用成对比较并随机排序：绝对分数易漂移，比较更稳定；对每对候选双向评估，丢弃结果翻转的对。
- 记录选择过程和备选方案：只保存胜出者，会让后续排查缺少依据。
素材也承认，自我评估并非不可用。任务边界清晰、验证器明确、候选集较小、循环只进行一到两轮时，如果单元测试能排除错误候选，评审意见影响有限。但Agent进入起草、批评、修改、挑选等多轮流程后，评审不再只是终端过滤器，而是引导生成方向的信号。长期围绕自身反馈优化，类似训练，却缺少训练通常需要的留验证集。
生成器正在商品化，选择器才是产品
两年前，行业关心模型能否给出可运行方案；现在，生成三十个候选方案的成本已经很低。生成能力正在商品化，真正稀缺的是判断哪一个候选可以上线。文章作者的判断是：宁可要普通生成器和严格选择器，也不要相反组合。
这也把问题带回AgentSSL的出发点。ML工程Agent能否利用无标注数据固然重要，但更现实的问题是，缺少可靠选择器时，系统可能在内部指标上变好，在实际结果上变差。提示词、工具、检索器通常已有测试，评估器也应有自己的准确率和错误样本。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-bian-cheng-agent-zhen-zheng-gai-ce-de-bu-shi-sheng-cheng
