optimize_anything：一个 API 统治所有优化——当 Berkeley 把万物皆文本推到极致

如果代码、提示词、Agent 架构、调度策略、CUDA 内核、甚至 SVG 独角兽都能被同一个 API 优化，那"领域专用优化器"这个概念本身是否正在消亡？

一、一个 API 的野心

Berkeley 和 MIT 的一群研究者发布了一个看似狂妄的系统：optimize_anything。它的接口简单到近乎冒犯——你只需要提供一个"文本工件"和一个"打分函数"，它就能帮你把这个工件优化到 SOTA。

但它真正疯狂的地方是跨领域的广度：

七个完全不同的领域。同一个 API。没有领域专用代码。

作者名单也是重量级的：Matei Zaharia (Spark 创始人)、Ion Stoica (Berkeley 分布式系统泰斗)、Joseph Gonzalez (MLsys 核心人物)、Omar Khattab (DSPy 作者)、Dan Klein (NLP veteran)、Alexandros Dimakis (生成模型专家)……这不是一个普通的学术论文，这是一个来自 systems + ML + NLP 交叉地带的宣言。

二、核心洞察：万物皆文本，文本皆可优化

optimize_anything 的设计哲学只有一句话：如果你的工件能被序列化成字符串，且它的质量可以被测量，那 LLM 就能优化它。

听起来像口号？但看具体例子：

• 代码优化：一个 Python 函数是文本，pytest 跑测试 + 计时器打分
• 提示词优化：系统提示是文本，LLM-as-judge 给推理答案打分
• Agent 架构：Agent 的完整描述（工具调用逻辑、思考链格式、重试策略）是文本，在 ARC-AGI 数据集上跑通率打分
• 调度策略：调度算法的伪代码是文本，在模拟云负载上测成本打分
• CUDA 内核：内核源码是文本，nvcc 编译 + nsight 测速打分
• SVG 图形：SVG 的 XML 文本是文本，渲染后 VLM 给视觉质量打分

所有这些都是同一个模式：text_artifact → evaluator(score + diagnostics) → LLM_proposer → improved_artifact。领域的差异被压缩进了"打分函数怎么写"这个局部问题里。

这就是"万物皆文本"的暴力美学。不是因为它优雅，而是因为它有效到让人不安。

三、三种优化模式：单任务、多任务、泛化

prior work（AlphaEvolve、OpenEvolve、ShinkaEvolve）只支持单任务搜索。optimize_anything 在一个 API 下统一了三种范式：

3.1 单任务搜索（Single-Task Search）

"解决一个难题"。给一个初始工件，让系统迭代改进。这是最直接的模式，也是 AlphaEvolve 们做的事情。

result = oa.optimize_anything(
    seed_candidate="你的初始代码/提示词",
    evaluator=evaluate,
)

3.2 多任务搜索（Multi-Task Search）

"解决一批相关问题，经验共享"。这是 optimize_anything 相比 prior work 的核心增量之一。

举个 CUDA 内核生成的例子：你有 20 个不同的 PyTorch 算子要加速。传统做法是每个算子单独优化。但多任务模式把这 20 个算子放进一个 dataset，系统在优化算子 A 时学到的"如何写高效共享内存访问"可以迁移到算子 B。

论文证明：同等预算下，多任务模式优于独立单任务优化。而且好处随相关任务数量增加而放大。这是因为在帕累托前沿上，不同任务的最优解共享底层优化模式。

3.3 泛化模式（Generalization）

"构建一个能处理没见过的问题的技能"。训练集 + 验证集的结构，和经典机器学习一模一样——只是"模型"现在是一个文本工件（提示词、Agent 架构、策略代码）。

ARC-AGI 的实验就是这个模式：训练集上优化 Agent 架构，验证集上挑最好的，最终在测试集上跑出 89.5%。

这个模式的关键在于：它把传统 ML 的泛化概念迁移到了文本优化。你不是在调网络权重，你是在"调"一段描述 Agent 如何工作的文字。但"训练/验证/测试"的统计学逻辑完全一样。

四、ASI：把诊断信息变成"梯度"

optimize_anything 最被低估的创新，是 Actionable Side Information（ASI，可执行的侧信息）。

传统优化（贝叶斯优化、进化算法、强化学习）的核心问题：它们只看到一个标量分数。它们知道"这个候选得了 0.7 分"，但不知道"为什么只得了 0.7"。

就像训练神经网络时只给你损失值，但不给你梯度。你能慢慢摸索出方向，但效率极低。

ASI 的洞察是：打分函数应该同时返回诊断信息。错误栈、编译器输出、性能 profiler 数据、渲染后的图像、多维度分数——任何能帮助"工程师理解问题并修复"的信息，都应该被喂给优化器。

def evaluate(candidate: str) -> tuple[float, dict]:
    result = execute_code(candidate)
    return result.score, {
        "Error": result.stderr,     # 编译错误
        "Output": result.stdout,    # 输出
        "Runtime": f"{result.time_ms:.1f}ms",  # 耗时
    }

论文的消融实验显示：带 ASI 的优化比只有分数反馈的优化，收敛速度快 4-6 倍，最终性能也大幅提升。

这不是"多给点信息更好"这种泛泛的结论。这是把梯度下降里的"梯度"概念，迁移到了文本优化里。ASI 就是文本优化世界的梯度——它告诉 LLM "往这个方向改"。

而且 ASI 支持多模态：可以是文本、结构化数据、甚至图像（通过 gepa.Image）。在 SVG 优化的 demo 里，评估器把渲染后的图片传回给 VLM proposer，让它"亲眼看到"自己生成的图形哪里不对劲。

五、帕累托搜索：为什么"平均分数"是陷阱

optimize_anything 的另一个核心机制是 Pareto-efficient search。

传统做法是：每个候选给一个平均分，每次只改进当前最高分候选。这有两个问题：

1. 平均掩盖互补性：候选 A 在速度上极好但内存占用高，候选 B 内存占用低但速度慢。平均后两者可能都不突出，但它们的组合可能更优。
2. 改进目标模糊：如果你告诉 proposer"把什么都改好一点"，它反而不知道重点改什么。

optimize_anything 的做法：

• 维护帕累托前沿：只要一个候选在某个维度上是最好的（哪怕是"在这个任务上最好"或"在这个指标上最好"），它就存活下来
• minibatch 反射：每次只给 proposer 看 2-3 个例子/指标，让它做 targeted 改进
• 前沿积累互补优势：迭代过程中，前沿汇集不同候选的专长，最终组合出综合最优解

在多任务搜索中，这个机制尤其重要：候选 A 在任务 1 上最优，候选 B 在任务 2 上最优，它们的策略差异被保留下来，proposer 可以从两者学习。

六、零种子模式：不需要初始方案

最让用户友好的设计：你可以不提供初始工件，只给一个自然语言描述，系统自己生成第一个候选。

result = oa.optimize_anything(
    evaluator=evaluate,
    objective="写一个 Python 函数 reverse() 反转字符串",
)

这意味着什么？领域小白也能用这个系统。你不需要先写一个"能跑但不够好"的初始版本——你只需要说清楚你要什么，LLM 会从零生成第一个候选，然后迭代优化。

这对 prompt 优化、Agent 架构发现尤其重要。很多人不知道"一个好的系统提示长什么样"，零种子模式让他们跳过这个门槛。

七、结果解读：为什么这些数字令人不安

让我挑几个最有冲击力的结果，分析它们为什么"不对劲"。

7.1 ARC-AGI：89.5%（从 32.5%）

ARC-AGI 是 François Chollet 设计的"AGI 评测"，核心思想是：测试人类般的抽象推理能力，而非记忆训练数据。2024 年的 ARC Prize 竞赛中，最好的系统也只达到约 50-60%。

optimize_anything 让 Gemini Flash（一个中等规模模型）达到 89.5%。这几乎不是一个"优化"的结果，而是一个"发现全新架构"的结果。

关键原因：ARC-AGI 的 puzzle 可以用程序合成的方式解决——如果你能发现正确的"元策略"（比如"先检测对称性""再尝试颜色映射"），一个相对弱的模型也能做对。optimize_anything 的泛化模式正是在搜索这种元策略。

7.2 CUDA 内核：87% 超越 PyTorch

PyTorch 的内核是 NVIDIA 工程师多年优化的结果。optimize_anything 生成的内核有 87% 达到或超越这个基线。

这不是"LLM 写代码超过了人类"，而是"LLM 写的专用内核超过了人类写的通用内核"。PyTorch 的内核要处理各种输入形状和数据类型，而 optimize_anything 为特定 workload 生成的内核可以极度特化。但即便如此，87% 的比例依然惊人。

7.3 超越 AlphaEvolve

AlphaEvolve 是 Google DeepMind 的 LLM 进化系统，专门用于数学发现。optimize_anything 在圆堆积问题（n=26）上超越了它的发表结果。

这意味着什么？一个通用 API 在专用数学优化任务上，打败了一个由顶级数学 AI 团队开发的专用系统。如果这能复现到更多数学问题上，"领域专用优化器"的商业逻辑会被严重挑战。

八、限制与边界

这篇论文的 demo 令人印象深刻，但我们需要清醒地看到边界：

8.1 评估成本

每次迭代都需要运行评估器。对于 CUDA 内核，这意味着编译+跑测；对于 Agent 架构，这意味着跑完整套 ARC-AGI puzzle。优化 100 轮可能花费数百美元 API 调用 + 计算资源。

论文没有报告总成本，但这是实际使用时的关键考量。

8.2 评估器质量的天花板

系统的效果上限取决于评估器。如果评估函数本身有噪声或偏差，优化会收敛到错误的地方。在提示词优化中，"LLM-as-judge"的评估偏差是已知问题。

8.3 复杂工程的组合爆炸

对于需要多个文件、复杂依赖、跨服务协调的系统，单个"文本工件"的抽象可能不够用。你很难把整个微服务架构序列化成一段字符串来优化。

8.4 可解释性与维护性

优化出来的工件可能极度特化、难以维护。一个为特定 workload 生成的 CUDA 内核，在硬件换代后可能需要重新优化。这与人类工程师写的通用、可维护代码是不同维度的价值。

九、更大的图景："文本优化"作为一种通用计算范式

optimize_anything 的深层意义，不在于它解决了多少具体问题，而在于它提出了一个新的问题框架：

如果把所有"可序列化、可评估"的对象都视为文本，LLM 是否正在成为一种通用的"优化编译器"？

这有点像早期编译器的发展：最初每种机器都有专用的汇编器，后来高级语言和通用编译器统一了这个领域。optimize_anything 在做类似的事情——它试图证明：在"优化"这个计算原语上，领域特异性是不必要的。

如果这是真的，那么：

• AutoML 不再是训练网络权重，而是优化描述模型的文本
• 系统优化 不再是手写启发式，而是进化调度策略的代码
• 提示工程 不再是人类试出来的，而是算法搜索出来的最优解

当然，这还停留在"玩具到中等复杂度问题"的制度。但当底层模型变得更强、评估基础设施变得更便宜，这个制度的边界会不断外扩。

十、结语：优化的公众化

optimize_anything 的 API 设计有一个很 Berkeley 的特点：极度声明式。你声明"我要优化什么"和"怎么衡量好坏"，系统处理"怎么优化"。这和 DSPy 的"programming not prompting"、Spark 的"描述计算而非实现计算"是一脉相承的。

它的终极愿景可能是：让优化能力像数据库查询一样——用户写声明式的"what"，系统处理复杂的"how"。在数据库领域，这个愿景花了 50 年才基本实现。文本优化可能不需要那么久，因为 LLM 已经承担了最困难的部分（理解语义、提出改进）。

但一个更哲学的问题留给了读者：当"优化"本身被自动化，人类工程师的价值会迁移到哪里？也许是定义正确的评估器——也就是回答"什么算好"这个更难的问题。毕竟，系统可以告诉你怎么到达山顶，但选择哪座山，仍然需要人类的判断。

参考与延伸

• Agrawal et al., "optimize_anything: A Universal API for Optimizing any Text Parameter", arXiv:2605.19633, CAIS 2026
• GEPA 项目: https://gepa-ai.github.io/
• AlphaEvolve (DeepMind), 2025
• FunSearch (DeepMind), 2023
• DSPy (Khattab et al.): declarative programming for LLM pipelines
• ARC-AGI: https://arcprize.org/

#深度研究 #优化算法 #LLM #Berkeley #Agent架构 #CUDA #ARC-AGI #通用人工智能