过程比结果重要：一个不给标准答案的调参框架，让Agent自己把数据库性能榨出来

数据库自动调参，一直是大模型Agent的“看似完美、实则翻车”名场面。

明明喂足了官方文档、参数攻略，LLM Agent上手调参依旧状况百出：

要么照搬老旧参数适配新硬件翻车，要么参数互相”打架”，越调性能越拉胯。

行业折腾许久，核心症结终于浮现，问题从来不是大模型不会读文档，而是传统调参文档本身就有致命缺陷。

为应对这一挑战，中国科学院软件研究所的智能软件研究中心和基础软件与系统重点实验室团队，联合推出PerfEvolve框架。

它不教LLM死记参数答案，而是把枯燥的静态调参文档，转化为Agent可直接执行、可自主落地的过程化调参技能——

让AI从“抄答案的应试者”，变身为会实测、会研判、会优化的“资深调参工程师”。

传统调参两大死穴：文档过时+参数互搏

当下主流的LLM数据库调优方案，基本都卡在三个无解难题上。

1、静态文档严重滞后，标准答案早已过时。

市面上绝大多数数据库参数推荐值，都源自多年前的旧版本、旧硬件环境。最典型的就是PostgreSQL，不少核心参数的官方建议值还停留在机械硬盘时代。

如今服务器早已全员SSD、负载模式全面迭代，老旧参数放到新环境里，不仅没用，反而会拖垮整体性能。

2、同一个参数，换个场景可能就完全反过来。

传统调参文档往往会给出一个“通用推荐值”，但同一取值，在一种场景下是性能神器，换个场景却瞬间变成性能杀手。

最经典的就是PostgreSQL里：shared_buffers = 25% RAM。

这个推荐值几乎所有DBA都见过，但不同负载对缓存策略的需求大相径庭。

实验发现，仅这一个参数配置不合适，就可能带来5%-16%的性能损失。

问题在于，系统文档无法提前覆盖所有负载，只能给出“平均经验”，但真实线上环境从来不存在所谓“万能默认值”。

3、参数并非独立存在，互相“打架”成常态。

数据库调参从来不是“1+1=2”的简单叠加。

单个参数单独调试，数值完美合规，但一旦和其他参数搭配使用，就可能出现性能暴跌、系统卡顿甚至崩溃。

过去行业一直误以为，只要让大模型多读文档、吃透参数释义，就能做好自动调优。但PerfEvolve的研究结论彻底颠覆这一认知：

真正的瓶颈，是传统文档只给“最终答案”，却从不教“解题过程”。

只给固定参数值的文档，适配不了千变万化的硬件、负载与系统版本。结论永远会过期，唯有调参过程可通用、可迁移。

PerfEvolve核心革新：把“读说明书”升级为“会做剖析”

PerfEvolve的关键变化，可以用一句话概括：“授之以鱼，不如授之以渔”——从“告诉Agent参数应该设成多少”，变成“告诉Agent如何判断参数应该设成多少”。

传统文档给的是结论式指令，比如：shared_buffers建议设置为内存的25%。

PerfEvolve则赋予了Agent完整实操SOP：

先测默认配置性能→再扫描候选参数值→观察吞吐量变化曲线→找到峰值区间→检查它和其他参数是否存在强交互→如果存在，就进入联合优化→最后跨负载验证结果是否稳定。

这就像导航软件和纸质地图的区别：旧文档只给你一个终点坐标，路况、路线、风险全靠猜；PerfEvolve则是实时动态导航，全程告诉你每一步该怎么走、遇到不同情况该如何调整。

为了让Agent的调参能力标准化、可落地，PerfEvolve将零散的调参知识梳理成结构化可执行技能文档。

每一项技能都包含前置条件、实操步骤、判断标准、后置校验和离线实测数据。

针对PostgreSQL v16，框架最终沉淀出23项可执行调参技能、160份参数特征剖面，覆盖三类任务：

• 1、单参数调优。

告诉Agent哪些参数值得调、哪些基本不用管、每个参数的安全范围在哪里、响应曲线大概是什么形状。

• 2、参数组联合调优。

识别出哪些参数强相关，必须放在一起调，避免”单参最优、组合翻车”。

• 3、全流程编排。

把基线测试、参数扫描、交互检测、联合优化和跨负载验证串成完整工作流，让Agent不只是会调用工具，而是知道下一步该做什么。

两招压缩搜索空间：先找关键参数，再找参数关系

调参痛点莫过于庞大的参数空间。PostgreSQL有数百个可配置参数，如果让Agent在所有参数上盲目搜索，成本会非常高，结果也容易不稳定。

PerfEvolve用两招高效破解维度灾难。

第一招：敏感度降维，精准筛选核心参数

PerfEvolve首先对PostgreSQL中116个整数或区间类型的参数进行单参数扫描——

每次只改变一个参数，其他参数保持默认，然后观察性能变化。

如果某个参数怎么调都几乎不影响性能，那它就不是关键参数；如果一调性能变化明显，就值得Agent重点关注。

实测结果十分惊人：绝大多数参数对性能几乎无影响，真正决定调参效果的核心参数仅15个。这一步直接将搜索空间从116维压缩至15维，大幅降低调参难度与成本。

与其在一堆影响很小的参数上浪费时间，不如先找到真正会影响性能的旋钮。PerfEvolve不是让Agent猜哪些参数重要，而是通过profiling把重要性提前测出来。

第二招：拓扑图挖掘，破解参数互搏难题

找到关键参数之后，还不能直接一个个单独调——因为这些关键参数之间可能存在强交互。

PerfEvolve会进一步做成对实验，并用ANOVA方差分析来衡量参数之间的交互强度：一个参数调优的性能曲线，是否会随着另一个参数的变化而明显改变？

如果答案是肯定的，那这两个参数之间就存在强关联，应该放进同一个参数组里联合优化。

PerfEvolve将强关联的参数两两相连，最终构建一张“参数交互拓扑图”：有连线的参数互相影响，应该一起调；没有明显关联的参数则可以分开处理。

这一步把一个巨大的全局搜索问题，拆成多个小规模的局部优化问题，让每一次调参都精准有效。

实测战绩：最高提速58.9%，彻底杜绝调参翻车

研究团队在PostgreSQL上进行了系统评测，覆盖三类典型负载：TPC-C读密集、TPC-C写密集、TPC-H分析型，对比GPTuner、E2ETune等主流方案。

数据显示，相较传统文档驱动调优方案，PerfEvolve最高实现58.9%的性能提升。

更亮眼的是，PerfEvolve无需替换原有调优系统，可直接作为通用知识模块无缝接入各类主流Agent调优框架。

以GPTuner为例：原版模型会从文档中抽取57个参数做贝叶斯优化，不仅搜索空间大，还有19%-32%的概率调出崩溃、严重退化的异常配置，实验有效率极低。

接入PerfEvolve后，参数空间精准压缩至15个，同时叠加安全阈值、参数相关性约束，实验有效率直接拉满100%。

跨硬件迁移场景下，优势更为极致。从8GB虚拟机迁移至192核、1TB内存的高端服务器时，原版GPTuner出现大幅性能退化；

搭载PerfEvolve过程化调参技能后，最高可挽回58.9个百分比的性能损失，适配性、鲁棒性远超传统方案。

反直觉发现：给Agent正确答案，反而可能害了它

论文中还有一个非常适合AI时代讨论的实验。研究团队比较了两类知识输入：

一类是声明式知识（直接告诉模型参数应该设成多少），另一类是过程式知识（告诉模型应该怎么调参、怎么测量、怎么判断）。

最终结果出人意料：哪怕给LLM完全正确的参数标准答案，依旧可能导致性能变差。

核心原因是数值会对大模型形成“认知锚定”，让AI过度依赖固有答案，主动探索、适配新场景的能力大幅下降。

旧环境的最优解，从来不是新环境的万能解。反观仅输入调参步骤、不给出固定数值的方案，已然能实现性能增益。

而PerfEvolve这种“实操步骤+离线实测参考数据”的组合模式，实现了最优调优效果。

给Agent一百个标准答案，不如给它一套自主解题的能力。

论文链接：https://arxiv.org/abs/2605.19988

GitHub：https://github.com/ISCAS-OSLab/PerfEvolve

文章来自于"量子位"，作者 "潭柘寺"。