别让优化器空想:AlphaEvolve 把 Agent 关进评分循环1×0:007:220:08开场0:53事件播报2:22技术拆解4:19工程意义5:42落地建议6:49收尾0:08主持过去二十四小时里,Agent Loop Engineering 没有出现比一手资料更扎实的新主线,所以这一期把窗口放宽到近一周。主事件是 Google Cloud 在七月九日宣布,AlphaEvolve 已经在 Gemini Enterprise Agent Platform 上正式可用。它不是让模型替你写一段代码,而是把算法优化做成一条可运行、可评分、可反复进化的闭环。0:33主持这件事值得单独讲,是因为它把一个老问题摆到了台面上:Agent 如果只会提建议,工程价值很容易停在幻觉和灵感之间;Agent 如果每一次建议都必须被编译、测试、打分,再把失败样本反馈回下一轮,它才开始像一个能进生产系统的优化器。0:53主持先把事实说清。Google Cloud 官方博客写到,AlphaEvolve 现在 GA,也就是 generally available。它是一个基于 Gemini 的代码优化和发现 Agent,面向物流、半导体、基因组学、高性能计算、金融服务这类优化问题。Google 的发布稿把使用流程拆成四步:先给一个种子算法和问题定义,再写评分函数,然后让 AlphaEvolve 生成优化候选,最后把验证过的算法放回生产负载。1:23主持Gemini Enterprise 的发布说明也在七月九日同步更新,确认 AlphaEvolve optimization service 已经 GA。Google 的文档进一步限制了它的边界:它不适合拿自然语言从零写业务代码,也不是 lint 工具。它要的输入,是已经能工作的程序,以及一组明确的指标。也就是说,它优化的是可测量的性能目标,不是泛泛的代码风格。1:52主持Google 同时放出了一个客户端示例仓库。仓库里的说明更工程化:云端负责生成候选程序,本地或者客户自己的云环境负责 evaluator,也就是评分器。你给它 seed program,标出允许改写的代码块,再用控制循环去获取候选、运行评分、提交结果。候选会失败,分数可能长时间不涨,这都不是异常;这些失败和停滞会变成下一代候选的反馈。2:22主持把它放进 Loop Engineering 里看,AlphaEvolve 的核心不是一句 prompt,而是四个闭环部件。第一是可变区域,工程师明确告诉系统哪些代码能改,哪些代码不能碰。第二是候选生成,模型提出新实现。第三是执行环境,候选必须真的跑起来。第四是评分函数,候选要按正确性、速度、成本、约束这些指标拿到分数。没有第四步,前面三步都只是自动补全。2:53主持这里最容易被低估的是 evaluator。Google 的博客说,开始使用只需要两个核心输入:种子程序和确定性的客户端评估脚本。这个设计把责任切得很清楚。模型负责探索搜索空间,客户负责定义什么叫好,运行环境负责把答案落到实测结果上。Agent 不再自己宣布胜利,而是把自己交给分数。3:16主持这也解释了为什么 AlphaEvolve 不是普通编码助手。普通助手经常停在一次性回答:我建议你把函数改成这样。AlphaEvolve 的工作方式更像实验平台:一轮生成很多候选,候选有的编译不过,有的违反约束,有的指标倒退;这些结果被记录下来,下一轮继续搜索。对 NP-hard、组合优化、GPU kernel、训练管线这类问题,手工穷举不现实,模型的价值就变成替人探索那些没人愿意一个个试的路径。3:49主持Google 给出的客户案例很密集,但不要把它们听成统一保证。比如 Coolblue 说二十八天需求预测的 WMAPE 降低超过百分之五,FM Logistic 说仓库 routing 在已有基线之上又提升百分之十点四,Klarna 说三周探索近六千个候选程序并提升训练吞吐。它们共同说明一件事:这类 Agent 真正的使用场景,是有稳定评分口径、有运行预算、能承受多轮试错的优化问题。4:19主持这和最近一篇 arXiv 论文里的 progressive crystallization 很像。那篇论文讨论的是,把 Agent 在生产里的探索轨迹逐渐固化成更便宜、更可复现的确定性工作流。它报告,在一个云网络运维系统里,八个月后大约百分之四十五的执行已经变成 deterministic workflow,每个 incident 的 Agent 成本下降超过百分之七十。这个数字不应被直接外推,但思路很重要:Agent 的探索不该永远按原价重复。4:49主持AlphaEvolve 走的是另一条类似路线。它没有说把整个业务流程固化成工作流,而是把算法设计空间交给 Agent 搜索,再让 evaluator 筛掉不合格候选。最后留下来的不是一句模型回答,而是一段可以审查、复跑、上线的程序。对工程团队来说,这比一句高分答案更接近可交付资产。5:14主持同时,它也暴露了门槛。第一,你得有可运行的种子程序。没有 baseline,系统不知道从哪里开始。第二,你得有靠谱的评分函数。评分函数写偏了,Agent 会认真地优化一个错误目标。第三,你要有隔离的执行环境。候选代码会失败,会跑慢,甚至可能做出不该做的副作用;没有沙箱和预算上限,这条循环会把风险直接带进生产。5:42主持如果你在团队里评估类似系统,不要先问模型是不是聪明。先问四个更土的问题:我们的优化目标能不能量化,候选程序能不能自动测试,失败候选会不会破坏真实数据,最好的候选最后由谁审查上线。答不上来,就先别把它叫自动优化,最多叫代码建议。6:03主持第二个建议,是把 evaluator 当成一等公民。很多团队愿意花时间调 prompt,却不愿意写评分脚本。可在 AlphaEvolve 这类循环里,评分脚本才是工程边界。它决定了 Agent 到底在追求低延迟、低成本、高准确率、低风险,还是在钻指标空子。写 evaluator 的人,实际上是在写系统的价值函数。6:25主持第三个建议,是把探索和生产分开。Google 的仓库说明里,生成在托管服务侧,评估可以跑在本地、Cloud Run、GKE 加 Ray 这样的环境里。这个分离很关键。你可以给探索阶段更宽的预算和沙箱,给上线阶段更严格的审查、回滚和可观测性。Agent 可以大胆试,生产系统不能跟着它一起冒险。6:49主持今天可以带走的判断是:Agent 的下一步,不是更会空想优化方案,而是更会被评分函数约束。AlphaEvolve 的价值不在于它声称自己能发现更好的算法,而在于它把发现、执行、评分和复盘放在同一个循环里。团队要先写清楚什么叫更好,Agent 才有机会把更好真的跑出来。