让 AI 代理反复优化 Rust 代码，性能可超越当前最先进水平

2025年1月，我有一个有趣的假设一篇博客文章： 如果你不断要求LLMs“写更好的代码”，它们能写出更好的代码吗？那是在稳健智能体编码出现之前，但Claude Sonnet 3.5仍然能够迭代改进算法蟒蛇代码。

“更好”的指令被证明是规定不足的：Sonnet利用这种模糊性，添加了大量无用的功能，但代码确实更快。即使代理型大型语言模型（LLM）特别兴起RLHFED处理常见的通过/失败编码问题，优化通常不属于该领域。

在那篇博客文章的结尾，我对一个假设的未来发表了看法，这样大型语言模型（LLM）可以通过写作来编写超高速的Python代码半场休息代码与使用PyO3以桥接语言，使Python的人体工学与Rust的速度结合起来。

那篇文章的早期草稿声称，同样的“写代码更好”指令也可以应用到基础Rust代码上，从而大幅提升速度，从而传播到Python代码中;然而，当时我对Rust了解不够，提出这样的说法也太过分了辣没有证据。

自Opus 4.5发布以来，经过数月的测试和实验，使智能编码变得更可行，我可以自信地确认，现代智能大型语言模型确实能够编写出远快于当前最先进方法的Rust代码如果给予适当的保护栏和约束.此外，自Opus 4.5以来，随着LLM在每次前沿模型发布中对编码的巨大改进，优化效果也变得更加出色，累计提升幅度在不同领域内可提升2倍至20倍不等。

更重要的是，这篇博客文章并不含糊，我包含了我使用的提示和基准测试结果。你已经被提醒了。

迭代“台面极限优化”

起初，让软件更快是我测试和比较这些新代理模型的好方法。我主要用Rust作为目标语言，是因为Python集成和速度，但如果发现了快速实现，Rust语言还有其他方面使其特别有用，比如内存安全和编译能力WebAssembly/WASM，这样它就能在网页浏览器中轻松运行。

不过，我会遵循一个重要的限制，虽然技术上可能不会带来最快的代码，那就是禁止不安全代码只要有机会。

我的第一个测试案例是在Rust中重新实现机器学习算法，如果我拥有更快且可扩展的工具，这将为我作为数据科学家带来显著的生产力提升。

当时，我傲慢地认为自己能击败那些经过十多年迭代、已经用C语言编写的经过实战考验的算法，Rust的底层优势不那么明显。我最想优化的算法是UMAP，这是一个有价值的算法，适用于降维我在工作中用过，但对大数据的扩展性差且速度很慢，有替代方案如cuML设置起来非常耗时。

UMAP Rust 箱子，例如乌玛普-RS已经存在了，我可以直接分叉它们，然后提示 Claude Opus 4.5 添加 Python/PyO3 支持，但作为实验和学习体验，我想让代理从零开始编写算法，尽量减少对 Rust 的依赖，以便尽可能低层次地进行优化。

Rust 有一个全面的基准测试工具，包括标准所有特工都知道如何利用的箱子。criterion运行基准测试，跟踪迭代结果，判断性能是提升还是倒退，并能计算这些变化是统计显著还是仅仅是噪声。

首先，在创建 UMAP Rust crate 的初始提示中，我要求 Opus 4.5 创建不同输入数据大小的基准测试，因为小数据集优化可能对大数据集无效，反之亦然。

Afterwards, create and run a benchmark suite which stores the results as a Markdown file. The benchmark suite MUST include inputs up to 100000x768 and be tested in both CPU and GPU modes.

这种方法创建了基准测试，使用criterion在提示性能改进后，我手动重新运行了基准测试套件，比如使用市长为了更快的线性代数，并且使用Simsimd为了更快SIMD运营.这很快变得麻烦，因为每次更改后我都得手动重跑每个基准测试，确认没有速度回归。

关于提示风格的旁注

我提示代理型LLM的方式很特别：我通常会在Markdown文档中提供非常长的提示，并额外使用全大写字母和**加粗**为了强调。这是为了确保我能捕捉到内容全部通过提示工程以及其他一些技巧，详见本博客文章。

虽然有人可能会认为提示工程已经死去，因为最新模型已经足够智能，能够正确处理歧义，但我强烈不同意，因为大型语言模型在跟踪这些细微差别方面也变得更好。

在有足够的信心后，代理人不会无意中rm -rf关于仓库，我尝试让代理自主运行，允许他们迭代，直到达到速度提升，希望如此。

**YOU MUST KEEP ITERATING OPTIMIZATIONS AND SOLVING ISSUES UNTIL THE BENCHMARK RESULTS STOP IMPROVING AND THE CRATE IS AS FAST AS IT CAN BE**. You have permission to keep iterating until you run out of ideas.

事实证明，“尽可能快”太模糊了，而Opus 4.5也懒散，只调整了一些超参数，但实际上速度提升不大，就算了。我需要一个明确的目标，可以通过或失败，所以我完善了提示：

First, **without making any futher changes**, run the CPU Rust benchmarks to establish a True Performance Baseline.

Then, optimize the crate code to make it such that ALL CPU benchmarks run **atleast 1.2x faster** than the True Performance Baseline; ideally as fast as possible. NEVER hack the benchmarks to accomplish this runtime reduction, only iterate on the library code.

You may use ANY techniques to do so (e.g. import new crates) other than adding `unsafe` code. **REPEAT THIS PROCESS UNTIL BENCHMARK PERFORMANCE CONVERGES AND YOU ARE OUT OF OPTIMIZATION IDEAS.** You have permission to keep iterating. After each benchmark iteration, report the relative results to the True Performance Baseline to console.

Prioritize making quick/high-impact wins iteratively and making changes accordingly. Do not overthink the necessary changes.

效果非常好，不仅基准测试速度提升了1.2倍，而且代理在达到度量约束后继续运行，只有在度量约束不可行时才停止;这次，代理成功了1.5x-2.0x加速。

低层Rust优化围绕多种技术展开，包括但不限于：更积极地利用SIMD操作、融合函数、展开循环、创建中间缓存、使用故事弧与其尽可能借用，不如根据输入数据创建性能配置文件（例如，如果数据较小，就不要使用人造丝随着开销消除收益，数据并行化）。

我选择“快1.2倍”作为理智测试：如果目标过高，代理可能会通过冒险或冗长的重写作弊来实现目标。更小的改动更好，因为代理能更容易识别加速/回归的原因，这也是关于迭代的说明。

在发布了新的前沿大型语言模型（如GPT-5.3 Codex和Opus 4.6）后，我对每个新LLM都重复了这个提示，且每个都能实现累计1.5倍到2.0倍比上一遍加速。

一直到GPT-6 Astra，历时数月，差不多就是这样7.5x-32x比初始实施基线还要快。

这种方法针对给定的基准进行高度优化，因此可以考虑benchmaxxing：这是一个贬义词，指那些只针对基准测试高分的前沿大型语言模型，而这些基准测试在实际应用中推广效果不佳。

然而，如果基准足够异质且真正代表现实应用场景，那么这个问题就不那么重要了。对于这类项目，解决benchmaxxing问题有两种方式：1）让代理设计多样化/异常/对抗性的输入数据集，而不是通用的“输入最高可达100000x768”;2）通过将输出与已知正确实现进行比较，强制对输出设置质量门。

在机器学习算法中，速度和质量之间总是存在权衡，但在这种情况下，快速完成模型比让它正确化要容易得多。这不是科学工程的做法通常虽然可行，但除非新实现完全正确，否则很难在多个基准测试中匹配一个已知好的实现。

幸运的是，UMAP 有一个标准的 Python 实现umap-learnRust crate 的 Python 绑定已经被简单地添加了，因此新的目标是同时实现约束：在限制速度损失的同时提升代码质量。

Create a Python Jupyter Notebook comparing the performance of the Python bindings with `umap-learn`, including a check to confirm where the outputs and UMAP losses are as similar. Use diverse datasets with different matrix sizes than the benchmarks.

If the outputs are not sufficiently similar, investigate methods to fix it **without causing more than a 5% speed regression**.

确实，Agentic的Rust实现质量更差，但后续提示成功，所有质量指标都接近均衡，速度损失极小。而这个新箱子依然4x-15xx比umap-learn及其 Python 绑定，2x-4x比类似的Rust更快umap-rs实施。

当智能体迭代仅带来3~5%的小幅速度提升时，就存在收敛，而智能体增加了大量代码，这可能在统计上不显著;这种权衡不值得。

我最终测试了其他具有相同提示进程的机器学习算法：梯度增强决策树（GBDT）、多层感知器（MLP）、图网络，以及许多典型的算法Scikit-Learn…而且效果还在继续全部.我不想过度专注于优化机器学习，尽管那本身价值极高，所以我在更多日常软件库中采用了类似的流程来优化它们：模板引擎、HTML解析，甚至网页服务器......而且效果不错全部又一次。

这些优化并不是一个简单的过程，你不能仅仅因为这种模糊的说法，就直接提示“来做个突破”来获得更好的代码。我不满足于仅仅写出最快的软件：我希望软件能越快越好该死。

所以，像我的特工一样，我继续迭代，寻找更多技巧，促使特工们取得真正的突破。

提示约束而非结果

进行中的作品

本博客中演示的所有项目都在积极开发中，结果可能无法代表最终版本......不过我猜它们会更好。😇

必须重申，代理可以且会作弊。举个例子，我测试了代理迭代流水线巴林——我在终端中的二维球物理模拟——以替换其Rapier2D物理引擎的性能上限已接近。

作品4.5确实能够加快每个物理步骤......有点过头了。

在headless_step34,500倍的加速和在球数上的稳定表现都非常非常可疑：手动检查后发现，Claude实现了加速，通过完全禁用物理引擎.这很合理，但不是最理想的;后续提示确实修复了问题，整体性能提升（还加了回归测试以防万一）。

在上述实验中，我使用了自定义的Rust导向AGENTS.md;最新版本为点击此处.令人惊讶的是，自从二月的代理实验以来，我几乎没有需要更新核心规则，因为大型语言模型的编码能力持续提升，我也没有遇到需要添加的重大问题。

不过，基于基准测试的经验，我又增加了一个章节AGENTS.md并附有一些规则以减少观察到的作弊来源：

## Benchmarking and Optimization

- **NEVER** run benchmarks in parallel, as the benchmarks will compete for resources and the results will be invalid
- **NEVER** game the benchmarks. Do not manipulate the benchmarks themselves to satisfy any required performance constraints
- **NEVER** run benchmarks with `target-cpu=native` or any other `RUSTFLAGS`
- Ensure benchmark tests are independent. If the tests are dependent due to a feature (e.g. caching), ensure the feature is disabled
- **ALWAYS** use `criterion` directly for running benchmarks if available

让我们逐一解释：

• 没有平行基准测试：我看到Opus 4.5同时启动两个基准以提高效率，值得称赞的是它立刻意识到了内在问题并顺序重启了基准测试，但主动添加规则来阻止它们能节省时间。
• 不玩基准测试：虽然这应该在“不要犯错”的层面上要有常识，这句话是在我看到Opus 4.5减少训练纪元数以实现基准测试并声称加速后添加的。
• target-cpu=native:此设定 雌鸟通常会加速，但对于通用使用来说并不公平，多个大型语言模型在遇到瓶颈后还在尝试。
• 基准是独立的：这应该是常识，但在上述作弊之后，主动告诉大型语言模型别再做了也无妨。
• 用途criterion如果未加说明，有时LLM会自行创建基准工具，这可能给它们提供更难审计的作弊机会。

在当今的代理型大型语言模型中，这些约束已经成功运行，尽管我可能仍会出于习惯性在提示中加入它们。如果你看到基准测试文件，很容易判断算法是否篡改了基准测试git diff——特工们不可能轻易逃避这一点。

随着时间推移，我发现了许多额外的提示工程技巧和约束，这些也在提升性能方面取得了惊人的成功。

创新鼓励

为了找到必要的优化，使速度比当前最先进的技术快10倍，代理们需要跳出固有思维，避免被当前最佳算法实践束缚。因此，我给了他们明确的警告和鼓励命令：

Due to the current highly-optimized state of this repository, this is a very difficult problem and traditional engineering approaches **WILL BE GUARANTEED TO FAIL** to hit the specified metric constraint. Therefore, you have permission and encouragement to investigate more radical fundamental low-level changes to hit the desired metrics. You have permission and encouragement to invent completely new/bespoke algorithms and engineering approaches that have never been before been utilized for this problem in order to hit the specified metric constraint.

这个方法奏效了，结果是1.2-1.5倍累计加速跨基准测试和不同软件领域。

次级代理

我发现的另一个鼓励代理跳出框架思考的技巧是调用子代理。我假设强制这些子代理用不同的提示词研究，可以a） 给母代理植入独特的想法，从而激发代理的灵感，b） 通过审查代码的不同区域来监督代理是否正确实现。

说到这里，我对软件开发者社区有点意见：每个人都在谈论他们的分代理员工军团他们很了不起，但没人谈论过怎么会这样你可以在标准束缚中调用子代理人，比如Codex。

对于复杂且高度并行的问题，束会自动调用子代理工具来完成工作。然而，一个大问题是，在某些束缚器中，子代理工具会使用当前的大型语言模型大小调用子代理，这在使用 Opus/Sol 类模型时成本可能较高。

我想用一个更便宜、更小的模型，比如 GPT-5.6 Luna 来做子代理，因为他们不需要写代码，所以我设计了一个无论使用哪种父框架都能运行的 Galaxy Brain 解决方案：告诉模型运行独立的CLI命令这些行为本身调用了该代理人：

codex exec --sandbox read-only -m gpt-5.6-luna \
  -c 'model_reasoning_effort="high"' \
  PROMPT

因此，我提出了提示工程：

To best accomplish innovative implementations, you **MUST** spin up 7-12 independent distinct "subagents" by running a long-duration CLI command (do not use the subagent tool) which can explore and evaluate different feasible hypotheses for improving the performance, usability, and security of this crate. Only have the agents return their response; do not save their full transcript to a file. Instruct them to be **very** picky. These subagents MUST use `gpt-5.6-luna` in Codex, e.g.

<<>>

You must instruct these subagents to NOT run tests/benchmarks, as they will compete for resources and not be valid. After you are done making changes, before handing off to the user, spin up the subagents again to confirm your implementation matches their hypotheses and ask for potential further areas of improvement. Keep iterating until ALL subagents are satisfied with your implementation.

这确实很稳定;“长时间”、“CLI 命令”、“不使用子代理工具”和“不要将完整转录保存到文件”这些限制是在代理做了浪费代币的低效操作后添加的。

7-12 是一个任意的数字区间;由于 Luna 使用成本低，我选择了一个比必要更高的数字。并非所有子代理都有显著的想法，但母代理能处理并忽略错误的想法。

总体来说，通过分代理的审核，我勉强拿到了另一个1.2-1.5倍累计加速.此外，从 GPT-5.6 Sol 起，提示中的“安全”部分开始提供解决方案，帮助在对未知输入的脆弱性下增强代理生成代码的防护，同时还能获得速度提升。

重构并减少代码行数

在我AGENTS.md每次优化时添加的代码大约在每次提交10000行代码（LoC）之间是合理的。然而，代理通常会把代码添加到单个文件中，并且不会主动重构。

只要最终修复，臃肿的文件在开发中是可以接受的，所以我写了一个提示来执行该重构：

The Rust code in `/src` has become particularly bloated, with several source files >1k SLoC. Refactor and reduce the Rust source codebase by **atleast 20% SLoC** through deduplication, pruning redundant code, and following idiomatic DRY Rust principles. Simultanously, refactor and split the code such that no single source file has >1k SLoC, splitting larger files into multiple subfiles in accordance to Rust standards for popular open-source repositories. Ensure **all current tests pass and there are no severe regressions**.

我故意用SLoC（代码源行）作为目标指标，而不是LoC，因为我不希望代理为了作弊而删除注释，从而作弊了20%的删除。

有趣的是，这种重构计算成本高于实际编码，且通常耗时更长。但它最终还是成功了，在验证没有严重回归的基准测试中，数据出乎意料地奇怪：

有些基准测试有两位数百分比速度提升/运行时间缩短，尽管我没有明确要求代理优化运行时速度。这对Rust来说并不直观，因为它是编译语言，且有遵守所有现有测试/功能的约束，它应该编译成性能相似的代码，而不是有意义地加快的代码。

我当然不是抱怨不过，我增加了一个额外的约束，至少避免回归：

Additionally, ensure there are **zero `criterion` benchmark speed regressions**: if a speed regression occurs on a given benchmark as a result of the refactor, you **MUST** keep iterating afterwards to improve those benchmarks to atleast zero regression. NEVER hack the benchmarks to accomplish this speed increase, only iterate on the library code.

这方法按描述工作。

竞争

另一种有用的方法是创建竞争对手基准——这也是开源软件创建基准测试的一半原因。让我们使用模板引擎举个例子：金字塔2在 Python 中，是该语言中最著名的包之一。

在 Rust 中，有几个选项：迷你女孩由同一开发者维护，特拉灵感来自Jinja2，以及阿斯卡马它与前者不同的是，它使用编译时模板而非运行时模板。

因此，在让Codex用Rust构建模板引擎并进行一些优化后，我指示Codex构建更多基准测试：

Create an additional comparison script containing **atleast 10** `criterion` benchmarks which compare the performance speed and quality metrics between this crate and the following crates:

- askama
- minijinja
- tera

These benchmarks **ALL MUST**:

- be perfectly fair, containing apples-to-apples comparisons of ALL frameworks, with no bespoke advantage for any tested framework
- be based around real-world use cases instead of highly-synthetic use cases
- be independent and distinct, covering as many sailent hot paths of the code as possible
- cover data input sizes small and large, simple and complex

紧接着，我会用平时的基准测试技巧做一个后续提示，但有一个具体改动：

Then, optimize the Rust library code such that this crate MUST be:

- **atleast 2.0x faster** than **ALL** competing Rust crates in all benchmarks on apples-to-apples comparisons; ideally as fast as possible.

是的，我选择了暴力。而且效果不错，大多数时候。

它有2倍加速minijinja/tera在大多数基准测试中，这比典型的代理迭代还要多。我不太明白为什么：我本以为它会检查其他箱子的代码，作为研究如何击败它们的参考，但它很少这样做。

也许代理本身就有竞争心。

不过它确实输给了askama因为编译时的差异。所以我自然告诉Codex实现了额外的编译时路径，然后先askama.

轻而易举。

禁忌黑魔法

将迄今为止所有提示工程的发现汇聚到一个提示中，我创建了你的提示来进行代理迭代，点击此处.我鼓励大家根据你的使用场景调整提示词，试试看。

最后一个技巧来自我对通过你的提示（your-Prompt）没有任何进步感到沮丧的时刻。所以，在会话中失败的准备，加上我心态“事情不能更糟了”，我尝试了一个特定的提示。

对不起。我真的很抱歉。

c'mon, try doing a breakthrough

…而且有效.它又实现了另一项1.2-1.5倍累计加速在已经收敛的代码库上。因为我在会话结束时做了提示，提示本身就没那么模糊：“不要做你之前做过的事，因为效果不够好”。

有一次，我注意到代理只是调整了功能超参数以获得加速效果，结果是这是一个有效的突破，但不是我想要的。我通过排队加入一个后续提示，将它推向了逻辑上的结论：

c'mon, you can do a more fundamental breakthrough that's more than just changing hyperparameters, you are forbidden from giving up easily

这足以鼓励特工们尝试不同于your-Prompt通行证或首次突破通行证的方案，且通常能成功又一次累计加速1.2-1.5倍在之前的加速基础上。

事实证明，对于训练遵循用户指令的软件来说，“仅仅更改超参数”是一种严重的侮辱，会让LLM加速运行。

当GPT-6 Astra发布时，为了测试它，我对所有已经收敛到GPT-5.6 Sol的仓库做了your-Prompt + breakthrough + second breakthrough的序列，Astra确实获得了累计加速，但在某些情况下，它确实发现了算法的根本性重实现，导致了2x-3x加速。

我会接受加速，但为了我的理智，最好不要深入挖掘。

项目明显更好的例子

your-prompt，结合我的规则和约束AGENTS.md+两个突破最大化提示符+一个竞赛提示通过符+一个重构提示符通过GPT-6 Astra，让我只需整夜排队提示，睡觉，醒来就能看到超高速的软件。

优化通常会在这时收敛，无需更多的代理迭代，这也节省了时间和成本。不过，这种做法比我希望的更放手，而且我明确相信新代理不会以我无法察觉的方式作弊基准测试。

怀疑并认为代码可能因强烈的氛围编码而出错是合理的，所以这里有一些我更注重视觉化的项目收据，这些项目很容易验证输出良好且非复杂作弊。

ASCII

我脑海里有一个项目是将图像以超高速且高质量转换成ASCII艺术，以便可能将视频转换为ASCII——一个网络摄像头转ASCII的项目可能会很有趣。

今年早些时候，Alex Harri写道精彩的博客文章关于一种新颖的高质量ASCII渲染方法，但也指出即使用GPU编程，也很难达到实时渲染速度。

为了科学，我用Codex中的各种GPT模型指向博客正文，告诉它“用Rust实现”，果然做到了......结果得到了2-3毫秒开箱即用的CPU输出时间。

然而，Codex的实现中ASCII的主观质量并不理想（例如负空间使用不当），令人惊讶的是，即使向Codex指出缺陷后也无法修复，所以我搁置了......直到我注意到GPT-6 Astra在处理图像设计方面如果有功能需求，我重新开始，将基础实现通过代理迭代流水线处理，重点是视觉确认输出图像。

除了质量提升，速度还更快：文本输出仅为亚毫秒，图像光栅化即使使用2倍超采样也能达到1-2毫秒。有了这个速度，我可以在不到一秒的时间内将视频和GIF转换为高分辨率ASCII动画。

词云

一个滑稽快速的词云生成器是我最早参与的项目之一，也是我多年来一直想做的项目之一。今年二月，词云生成器在WASM默认设置下生成图像需要~100毫秒，而其他生成器渲染同样质量只需几秒钟，这足以让我决定追求速度优化。

重新审视项目并经过完整的代理迭代流程后，生成速度降到了10-20毫秒.

世界需要超高速的词云生成器吗？不需要。我需要一个超高速的词云生成器吗？不需要。我需要想要超高速词云生成器？是的。如果我有词云生成器，速度会尽可能快，见鬼。

而且因为箱子是开源的，所有未来的世代都能基于这个超快的词云实现来改进。说到这个......

我计划将所有内容开源

像往常一样，我开发了这里展示的所有软件，目的是最终将其开源，所有内容都会开源并允许麻省理工学院许可除非出现任何意外问题。

如果是一年前，我早就把所有东西开源了，默认代码还在进行中，可能存在粗糙之处。然而，开源软件开发的文化与一年前有很大不同。

开源软件一直在遭受氛围编码流行病.坦率承认LLM被用于任何开发辅助（无论大大小）现在已经成为最终代码库“杂质”的信号。我仍会出于礼貌披露我的LLM使用情况，但当完全vibecode软件带来了人类此前未曾察觉的真正有意义的软件性能提升时，会发生什么？

对vibecoding的怀疑将导致没人相信这些说法，因此这些新的开源项目需要有充分证据证明其速度确实符合营销预期。因此，我会比平时花更多时间发布，以a）建立真实世界的示例来演示工具，特别是文档，b）扩展测试套件，涵盖更多真实测试用例;c）撰写配套博客，详细介绍技术和基准测试的成就。

还有一点是我正在创作又一个工具在已经流行的软件工具生态系统中。我那批量迭代的Rust箱子实现了它们的巨大速度提升，部分原因是从零开始，因此带来了创新不行可以轻松应用于已建立的箱子。

此外，如果我基于这些箱子的创新为现有项目创建一个拉取请求，这本质上就是带有氛围编码的PR，可能造成烦恼即使我避免了典型的公关失误。

从这个角度看，没错我应该做的是维护自己的项目：这是合规，而不是恶意的那种.有人可能会说这是反社会，但我认为更准确的术语是我这里定义的内向编码。

简而言之;我的比SOTA更快的软件项目将在准备好时发布，整个过程需要几个月时间。幸运的是，我目前失业由于重组除了找工作外没有其他计划，所以我有充足的时间全职投入这些项目的发布。

如果你想关注它们发布的时间，可以订阅我的博客RSS订阅想看随附的博客文章或关注我蓝天或Patreon.不，我不会在Twitter/X上发那些令人烦躁的模糊帖子。

当我五年前第一次对Rust产生兴趣时，我的梦想是打造有史以来性能最高的软件工具。然而，随着过去几个月我发现的代理迭代优化技术，新软件的速度和稳健性进展比我预期的还要快。

再次强调，欢迎随意修改我的AGENTS.md还有我的your-提示词看看它们对你来说是否和对我一样有效（不过如果有人推荐我会很感激！）。

如果你觉得我因为公开了提示就没什么可做的，我还有不少惊喜在我手里，比如如何将这些底层项目组合成一个超高速复杂的应用，甚至开发新工具帮助代理更高效地找到这些优化。

1. 我确实在纯Python项目中测试了重构提示，因为Python是一种解释型语言。它不过导致部分基准测试速度提升了两位数百分比，这也引发了更多疑问。
2. 顺便说一句，这些由代理编码的仓库的测试基础设施会比我所有流行的人工编写的Python包（零）都要好。