Autoresearch、Claude 与约束优化（13 分钟阅读）

# 自动研究、Claude 与约束优化 来源：https://www.elliotcsmith.com/autoresearch-claude-and-constrained-optimization/ ## 引言 你不需要费多大力气就能找到一些人声称他们用 AI 完成了数十人的工作。对于任何没有证据的改进声明，我通常都持怀疑态度。我决定把这种怀疑付诸实践。这跟 X 上关于“循环”的讨论有一点交集，但纯属巧合。 过去几周里，我按照 Kaparthay 的“自动研究”主题搭建了一个项目。我想选择一个既不是传统机器学习也不是数值优化问题，但仍然有一些客观成功衡量标准的问题。 我选择这类问题，是因为我参与过的很多项目或产品都是这种结构：你有一个想要改变（提高或降低）的指标，理想情况下还有一个衡量它的方法。你也可能有一些约束条件，比如“这个功能的页面加载时间不能超过 500ms”。 我还没遇到过这样一种问题：从未知到成功的路径像机器学习那样是清晰的梯度优化。更多时候，你完成一些工作，在“现实世界”中测试它，观察它的表现，然后决定下一步怎么做。并非所有改变都能带来积极结果，而且很容易深入一条导致局部最优结果的道路。 我想要一个实验，让我直观地了解如何以基本无监督的方式将更大的工作块分配给 AI 代理。已经有一些其他机制试图实现这种结果，比如 Ralph Loops 和 Claude Code 中现有的 `/goal` 命令。这个设置的不同之处在于，我会选择一个可量化的数字作为成功的主要衡量标准，并用一些通过/失败约束来限定问题。 为了不过度复杂化，我选择了文件压缩问题。我选它是因为目标和约束都很简单：如果最终文件大小更小，压缩算法就更好。我加了两个约束：解压后的文件必须完全匹配原始文件；压缩或解压过程都不能超过 300 秒。我故意没有优化速度，只是想限制时间，并确保过程可以在基本无监督的情况下运行，知道超时会捕获并阻止无限循环。 文件压缩的另一个好处是，有很多现有工具可以用作最终基准测试。鉴于这只是一个小型概念验证，我不期望能创造出顶尖的新算法。 尽管如此，了解这个自制版本与现有工具相比表现如何，也能为我们提供一些数据点，了解我们可能在多大程度上脱离库和现成解决方案。如果一个代理能快速可靠地解决一个以前由外部依赖解决的问题，那么必然存在某个临界点，自制解决方案的价值会超过供应链攻击等风险。这不是单个实验能回答的，但有助于判断这是否值得进一步研究。 ## 方法 ## 问题设定 首先，提醒一下，这里的目标是看这种方法是否可行，而不是对某个特定模型进行基准测试。 其次，在深入之前，这个项目的所有代码都在这里：https://github.com/smitec/agent-compression?ref=elliotcsmith.com 这项工作我使用了 Claude Code，默认设置，使用 Sonnet 4.6。我确定不同模型会采取不同做法，那是另一天的练习。 在代理介入之前，我搭建了一个基本的项目脚手架。我选了 Rust，因为一些隐式约束（如“不要修改函数签名”）可以通过类型系统轻松实施。我编写了压缩和解压函数的存根，它们都只是直接复制字节。这“能用”，但没有对任何数据提供压缩。 然后我放了一些基本的单元测试，测试一个字符串和一个简单文件的压缩-解压往返。这些测试并不详尽，但确实验证了 `compress` 和 `decompress` 函数实现了位完美的往返目标。 接着我编写了一个基准测试脚本。这个脚本获取了一些公共领域的文件样本，包括视频、音频和文本，同时也创建了一些填充随机数据的各种大小的文件。其中许多文件已经是某种压缩格式，所以我添加了一步，将它们转换为较少压缩的格式。这为整体压缩基准测试以及按文件类型的基准测试提供了良好基础。 拥有这个样本集意味着混合了高熵和低熵的文件格式。一个好的压缩算法会缩小低熵格式，让高熵格式基本不变。由于格式特定的字节，文件大小可能会有微小变化，但总体上你不希望文件大小显著增加。 样本集中最大的文件大约 150MB。虽然压缩在更大文件上可能更有意义，但这会导致非常慢的测试循环，尤其是在后面的步骤中。 基准测试脚本循环遍历每个文件，单独压缩，然后解压。脚本检查解压后的文件是否与原始文件逐位匹配，并记录大小变化以及压缩和解压步骤所花时间。每个文件的步骤都有 300 秒超时，主要是为了检查意外的无限循环。 脚本生成一个 `debug.csv` 文件，列出每个文件的变化，如果有所改进，则将关键指标写入 `results.csv` 文件。需要注意的一点是，综合压缩指标是 `(total compressed bytes) / (total original bytes)`。我也考虑过取样本集上平均压缩百分比。稍后会介绍这种选择的影响和差异。 所有这些设置完成后，我为存根实现运行了基准测试，并认为实验已准备好运行。 ## 迭代 为了保持相对良好的控制，我在每次迭代前清除了 Claude 上下文，并提示模型“审查当前代码库并尝试另一次改进迭代”。我将 Claude Code 默认设置为计划模式，所以等待计划生成，快速审查后接受计划，让代理自主运行。 在这个实验中，我有意不修改任何计划，想让它完全自主选择。有几次我认为干预会有用，但这是学到的一课。 我运行了十次迭代，然后对一些常见压缩工具和一个新数据集进行一次最终扩展基准测试，以控制任何特定数据的优化。这些迭代在大约两周内运行，通常是我在做其他事情时启动并让它运行。这种延长的时间段并非试验的设计特征，主要是为了避免在用 Claude Code 处理其他工作时耗尽限制。 ## 结果 ## 迭代 在第一次迭代中，代理生成了一个自定义的 LZSS 实现，这是一种相当标准且广为人知的压缩方法。接下来的九次迭代是对这种方法的扩展，添加了新的熵检查和编码技术，试图去除熵。 每次循环在耗时和 token 使用上差异很大。根据 Claude Code 中的 `/usage` 命令，每次迭代平均花费约 4 美元。再次强调，这是在默认设置下，所以我不太在意价格，因为不同模型差异很大。 有趣的是，模型在每次迭代中从未做过多于一组更改。它会形成假设，添加代码，运行基准测试，然后称自己“完成”。这可能是由于提示设置中没有使用 `/goal` 命令。 下面的结果显示模型能够持续改进压缩率。特别是“可压缩”比率，在我看来，考虑到任务的宽松程度，结果相当令人印象深刻。 ## 基准测试 为了评估最终结果，我对同一数据集运行了几种压缩工具。选择这些工具是因为它们恰好已经安装。这不是最稳健的选择基准的方法，但它确实反映了与常见工具的比较。 整体来看，自定义算法表现相当不错，它在音频和视频压缩方面表现出色，在其他类别中稍微差一些或持平。音频和视频分数较低并不奇怪，因为优化所用的指标是综合压缩率。这些文件类型占据了大部分压缩字节，因此综合得分主要受这些文件类型的改进影响。 回到这个项目的目标，这不是为了寻找突破性的压缩算法，而是为了开发关于将代理任务用于优化软件的直觉。 ## 学习 总结一下，如果这篇文章太长，给读者一些可以跳过的地方，以下是这个项目的一些高层收获。总的来说，我认为如果能找到一个稳健、可测量且良好约束的指标来优化，那么这种自动研究/循环式的工作模式是有意义的。但找到这样的指标往往很棘手。 ### 模型急于“完成” 在观察/审查设置时，我整体感觉是它想尽快“完成”。基于此，我认为在现实世界的版本中设置某种显式循环机制会很重要。 ### 目标函数的选择至关重要 另一个观察是，300 秒的时间参数可能太宽松了。它对于限制更改的负面影响很有用，但模型只优化压缩率。Mitchell Hashimoto 最近在 X 线程中捕捉到了这种现象： > 我让一个代理在循环中优化一个渲染器，目标是尽量减少帧时间（并用测试来测量）。它将时间从 88ms 降到了 2ms，分配次数从约 150K 降到了 500。听起来不错，对吧？错了。这正是代理精神病是一个大问题的地方。正如... —— Mitchell Hashimoto (@mitchellh) 2026年5月28日 (https://x.com/mitchellh/status/2060088112257372610?ref_src=twsrc%5Etfw&ref=elliotcsmith.com) 这个方法的实际应用要么需要一个更复杂的“分数”来优化，要么稍后切换到速度优化。对于代码长度、内存使用等其他次要指标也是如此。 这绝非新问题，也不是基于代理编码独有的。衡量“成功”和“完成”一直是工程组织中的长期挑战。实际上，任何指标或指标组合都会带来权衡。你可能只需要接受这个事实，并愿意随着需求变化而调整关注点。 我最近看到 PostHog 在他们的新产品 PostHog Code 中做了一些这方面的工作。允许用户将产品分析数据带入他们的编码代理上下文中，以更好地指导决策。我还没有测试过，但感觉方向是对的。 ### 现实世界的目标很少如此容易衡量 在讨论指标时，值得考虑一下这种方法在“现实世界”中可能会有何不同。压缩工具有非常快的反馈循环。你可以拿一个文件，压缩它，解压它，比较结果。如果这个改变更广泛，比如“提高结账转化率”，你需要更多时间来收集样本，并且更容易受到数据噪声的影响。 一种解决方案是优化一个代理指标，寄希望于它能提高转化率。这可能类似于“提高页面加载速度”或“减少结账所需的点击次数”。这当然可以更容易迭代，但你会冒过度优化代理指标的风险，而这个代理指标与最终目标只存在松散的相关性。找到一个与复杂指标完美线性相关的代理指标是很难的。 ## 局限性 这里简要承认一些局限性： - 模型选择——这些结果在多大程度上有效？模型一直在变化（Sonnet 5 今天发布了），实际上今天运行相同试验的结果很可能大不相同。 - 成本——这合理吗？根据 Claude 的估计，每个循环在 token 上花费约 4 美元。在“真实”产品中这样做需要有投资回报率。40 美元（10 个循环）的门槛不高，但如果为代码库中的每次更改都运行这种循环，成本可能会很高。 - 单机、单线程结果。压缩基准测试在不同 CPU 上差异很大，这些都在 M2 Macbook Pro 上完成，但我确信在其他场景下结果会不同。 - 优化函数的选择——这是最大的问题，上面已经多次提到。如果我选择了像 `average(compressed / raw)` 甚至 `median` 这样的指标，通往更好的路径会非常不同。我过去写了很多关于选择指标的 (https://www.elliotcsmith.com/how-to-avoid-picking-terrible-metrics/) 文章，这同样适用于代理和人类。