引言:从怀疑到实践
你可能见过很多关于AI智能体编码的博客文章,作者们谈论着智能体现在能做的各种美妙事情,以及它们将如何导致编程技能退化等等。这篇帖子不是其中之一。
去年五月,我曾写过一篇题为《作为经验丰富的LLM用户,我其实并不常用生成式LLM》的文章,作为对当时智能体编码热潮的回应。当时我认为,虽然LLM并非无用,但智能体仍难以让人信服:它们不可预测、成本高昂,且炒作远超实际效果。然而,我当时的结论是开放的:如果LLM改进到足以解决我所有的顾虑,智能体变得更加可靠,我愿意重新考虑。
从那时起,我在继续数据科学家本职工作的同时,也密切关注着最新LLM的发展。一系列实验让我逐渐改变了看法,尤其是在某机构发布Opus 4.5之后。
智能体配置文件:AGENTS.md 的关键作用
在深入测试之前,我发现一个至关重要的文件:AGENTS.md。这个文件放在项目根目录,可以控制智能体的特定行为,如代码格式、规范等,相当于LLM调用的系统提示词。
我让Opus 4.5为我创建了一个面向Python的、极其详细的AGENTS.md文件,并添加了许多个人偏好,例如:
- 使用
uv和.venv而不是基础Python安装 - 数据处理使用
polars而非pandas - 密钥和密码只存储在
.env文件中,并确保.env已加入.gitignore - 绝不使用表情符号或模拟表情符号的unicode字符
- 必须避免包含冗余的代码注释
这个文件成为了我之后所有智能体项目成功的基础。每当遇到不喜欢的智能体行为,我就添加一条规则到AGENTS.md中,效果显著。
Opus 4.5 初体验:Python项目一蹴而就
带着精心配置的AGENTS.md,我开始测试Opus 4.5。我选择了一个自己熟悉但代码质量不佳的旧项目:使用YouTube Data API抓取频道视频元数据并存入SQLite数据库。我编写了一个详细的提示词文件,要求实现以下功能:
- 使用REST API(
httpx库)而非Google Client SDK - 包含有意义的聚合指标(如视频评论数)
- 数据库schema中包含
channel_id和retrieved_at
生成的脚本首次运行就成功抓取了多达20,000个视频(API上限)。代码质量非常高,完全遵循了AGENTS.md中的规则。虽然存在一个小问题(日志中泄露了API key),但这很快通过添加新规则得到解决。
随后,我让Opus 4.5创建一个使用polars进行探索性数据分析的Jupyter Notebook,它生成了一个极其详尽的分析报告,甚至能推断出需要进行时间序列分析(如每月视频上传总量),尽管提示词中并未明确要求。
接着,我又让它基于FastAPI、Pico CSS和HTMX构建一个展示每月热门视频的小型Web应用。它生成的代码不仅逻辑清晰、集成了HTMX路由和局部更新,还创造性地实现了点击缩略图加载嵌入式视频播放器的功能,完整代码已开源。
这些测试结果远超我之前的糟糕体验,让我开始对智能体编码重拾信心。
Rust 项目实战:从怀疑到折服
Rust语言以其高性能和内存安全著称,但学习曲线陡峭。历史上,LLM在生成Rust代码方面表现不佳。然而,Opus 4.5的表现让我大吃一惊。
项目1:icon-to-image - Rust + Python 绑定的图标渲染器
我想创建一个能从图标字体文件(如Font Awesome)中渲染出任意分辨率图像的Rust/Python混合包,并通过pyo3提供Python绑定。Opus 4.5完成了一次性交付,实现了所有指定的功能约束,包括:
- 支持Solid、Brands和Regular字体文件
- 输出PNG和WEBP格式,默认分辨率1024x1024
- 支持2倍超采样抗锯齿
- 使用
fontdue作为文本渲染引擎 - 支持图标颜色、背景色(HEX/RGB)、透明背景、图标尺寸/画布尺寸分别指定、锚点位置和像素偏移
虽然最初选择的fontdue crate在高分辨率下渲染图标曲线有问题,但在我指出后,Opus 4.5迅速调研并改用ab_glyph完美解决了问题。
最终生成的icon-to-image包已开源,其速度比我的旧Python方法快一个数量级,渲染质量也更好。更重要的是,通过智能体辅助,我还得到了一个自动化构建所有目标OS的Python wheels的GitHub Workflow。
项目2:ballin - 终端物理模拟器
在一个灵光一闪的夜晚,我让Opus 4.5创建一个基于rapier 2D物理引擎的终端物理模拟器,并使用Braille unicode字符实现高细节ASCII艺术渲染。它一次性完成了任务,生成的Rust代码库可以轻松处理超过10,000个物理球体的实时模拟!我还让它添加了彩色效果,使模拟更加生动有趣。
项目3:机器学习算法的极致优化
作为数据科学家,我注意到近年来缺乏有影响力的新Python数据科学工具,且现有工具对Apple Silicon GPU(Metal API)的支持不佳。我决定让智能体挑战更高难度:将UMAP(一种降维算法)用Rust重新实现,并通过pyo3提供Python绑定,同时最大化其性能。
我设计了一个8步的优化流程,并让两个顶尖模型(某机构的Codex和Opus)协同工作:
- 实现与基准测试:根据功能需求实现包,并创建代表典型使用场景的基准测试。
- 代码清理与初步优化:第二轮清理代码并做初步优化。
- 算法弱点分析:扫描crate,找出极端情况下的算法弱点,并量化问题、提出解决方案。
- 针对性优化:利用发现的问题进行优化,目标是让所有基准测试运行时间缩短60%以上(即速度提升1.4倍以上),反复进行直至性能收敛,但要避免过拟合基准输入。
- 性能调优:利用输入数据的固有特性、CPU线程饱和/调度/并行化,创建自定义调优配置,再次追求60%以上的速度提升(可使用
flamegraphcrate辅助分析)。 - 添加Python绑定:使用
pyo3和maturin添加Python绑定,并确保兼容性。 - Python基准对比:创建相应的Python基准测试,并编写与现有Python包的对比脚本。
- 准确性验证:质疑模型可能在优化过程中“作弊”(例如牺牲算法准确性来换取速度),要求它在保证与已知良好实现输出结果高度相似的前提下进行优化(例如,对于回归任务,最小化预测值的平均绝对误差)。
这套流程被应用于多个算法(UMAP、HDBSCAN、GBDT等),并在每个步骤中通过链式调用不同模型(如先用Codex优化速度,再用Opus在保证准确性的前提下进一步提升速度)获得了惊人的结果。
在我的MacBook Pro上,与现有的、久经考验的实现相比:
- UMAP: 比Rust的
fast-umap快 2-10倍,比Python的umap快 9-30倍。 - HDBSCAN: 比Rust的
hdbscancrate 快 23-100倍,比Python的hdbscan快 3-10倍。 - GBDT: 拟合/预测速度比Rust的
treeboostcrate 快 1.1-1.5倍,比Python的xgboost拟合速度快 24-42倍,预测速度快 1-5倍。
为了证明这不是个例,我同期发布了另一个小型Rust-with-Python项目 nndex(一个内存向量存储,用于快速最近邻检索)。经过几轮优化,即使在单次查询场景下,它的速度也能与重度依赖BLAS库的numpy持平甚至超出(最高5倍),尽管numpy已经是高度优化的数学库。
基于这些成功,我目前正在开发 rustlearn(暂定名),一个旨在用Rust实现标准机器学习算法(逻辑回归、k-means等)并超越 scikit-learn 性能的库,同时提供Python绑定。
结论与反思
Opus 4.5及后续模型(如Codex 5.3)在编码能力上的提升是革命性的。它们不再是简单的代码片段生成器,而是能够理解复杂需求、遵循严格规范、并能通过多模型协同进行深度优化的智能体。
- 智能体的价值:它们让我能够实现那些“我确切地知道想要什么,但不一定知道如何实现”的创意项目。从终端MIDI合成器到高性能机器学习库,智能体极大地扩展了我的能力边界。
AGENTS.md是成功关键:一份详尽、针对特定领域的智能体配置文件,是获得高质量、符合预期结果的基石。- 对技能的影响:与许多人担心的相反,与智能体协同工作反而加深了我对技术栈(如Rust生态系统)的理解,并促使我养成每天花一小时编码和学习新想法的习惯。
- 对未来的展望:智能体生成的代码能超越现有的、手写的成熟库,这挑战了我们对“AI生成代码质量低下”的固有认知。尽管围绕AI的讨论依然喧嚣,但其带来的实际效用是不可否认的。
如果你在去年11月之前对智能体有过糟糕的体验,我强烈建议你给现代智能体(如Opus 4.5/Codex 5.3)一个机会,并从一个精心定制的AGENTS.md文件开始。FINISHED