数据库自动调参，一直是大模型 Agent 的"看似完美、实则翻车"名场面。明明喂足了官方文档和参数攻略，LLM Agent 上手依旧状况百出：要么照搬老旧参数适配新硬件翻车，要么参数互相"打架"、越调性能越拉胯。

中科院软件所智能软件研究中心和基础软件与系统重点实验室团队联合推出 PerfEvolve 框架，给出了一个反直觉的结论：问题从来不是大模型不会读文档，而是传统调参文档本身就有致命缺陷——它只给"最终答案"，却从不教"解题过程"。结论会过期，过程才能迁移。

PerfEvolve 不教 LLM 死记参数值，而是把静态调参文档转化为 Agent 可直接执行、可自主落地的过程化调参技能。在 PostgreSQL v16 上实现最高 58.9% 性能提升，已开源。

PerfEvolve 的核心：把"读说明书"升级为"会做剖析"。

开始前的准备

• Python 3.10+
• 一个可访问的 PostgreSQL v16 实例（推荐 Docker 起一个干净的测试库，别在生产上调）
• 资源地址：
  • 论文：https://arxiv.org/abs/2605.19988
  • GitHub：https://github.com/ISCAS-OSLab/PerfEvolve
  • 已沉淀：23 项可执行调参技能 + 160 份参数特征剖面

预计跑通最小示例：1 小时。

第一步：理解传统调参的三个死穴

动手前先认清问题，你才会知道 PerfEvolve 在解决什么：

1. 静态文档严重滞后：大多数数据库参数推荐值停留在多年前的旧版本、旧硬件时代。比如 PostgreSQL 不少核心参数官方建议值还停留在机械硬盘时代，放到全员 SSD 的新环境里不仅没用、反而拖垮性能。
2. "通用推荐值"在不同场景下完全反转：最经典的是 shared_buffers = 25% RAM——所有 DBA 都见过，但仅这一个参数配置不合适就可能带来 5%–16% 性能损失。
3. 参数互相打架：单参数单独调试数值完美合规，一旦组合使用就性能暴跌甚至崩溃。数据库调参从来不是 1+1=2。

PerfEvolve 的诊断是：只给固定参数值的文档，适配不了千变万化的硬件、负载与系统版本。真正的瓶颈不是"Agent 没读够文档"，而是"文档只给了终点坐标、没给路线"。

第二步：克隆仓库，加载 PostgreSQL v16 技能包

git clone https://github.com/ISCAS-OSLab/PerfEvolve.git
cd PerfEvolve
pip install -r requirements.txt

# 启动一个干净的 PG v16 测试实例
docker run -d --name pg16-test \
  -e POSTGRES_PASSWORD=test \
  -p 5432:5432 postgres:16

# 加载官方沉淀的 23 项调参技能 + 160 份参数特征剖面
python -c "
from perfevolve import SkillPack
pack = SkillPack.load('skills/postgres_v16')
print(f'{len(pack.skills)} skills, {len(pack.profiles)} profiles loaded')
"

每一项技能不是一段参数推荐值，而是结构化的可执行 SOP：前置条件 → 实操步骤 → 判断标准 → 后置校验 → 离线实测数据。

第三步：把 PerfEvolve 接入你的 Agent

PerfEvolve 把 Agent 的调参流程标准化成一条完整工作流：

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

接入方式（伪代码，对接你自己的 LLM Agent）：

from perfevolve import TuningWorkflow, AgentAdapter

class MyLLMAgent(AgentAdapter):
    def decide_next_step(self, observation, history):
        # observation: 当前 perf 曲线、参数当前值、负载特征
        # PerfEvolve 已经把"下一步该做什么"结构化了
        # Agent 只需要在结构化选项里选，而不是凭直觉编命令
        return self.llm.choose_action(observation, history)

wf = TuningWorkflow(
    db_url="postgresql://postgres:test@localhost:5432",
    skill_pack="skills/postgres_v16",
    workload="tpcc",  # 或 sysbench / 自定义
)

result = wf.run(agent=MyLLMAgent(), iterations=10)
print(f"improvement: {result.improvement_pct}%")
print(f"best_config: {result.best_config}")

第四步：理解它压缩搜索空间的两招

PerfEvolve 之所以能把搜索成本打下来，靠两个机制：

1. 敏感度降维：先快速扫描判断"哪些参数值得调、哪些基本不用管、每个参数的安全范围在哪里、响应曲线大概什么形状"。160 份参数特征剖面把"无效搜索空间"提前砍掉。
2. 参数交互拓扑图：识别出哪些参数强相关、必须放在一起调，避免"单参最优、组合翻车"。这是它解决"参数互搏"的关键。

敏感度降维 + 参数交互拓扑图，把搜索空间从指数级压到可执行规模。

验证结果

跑完后你会得到一份调参报告：

Workload: tpcc (PG v16)
Default throughput:    1240 TPS
Optimized throughput:  1968 TPS
Improvement:           58.9%

Top changed params:
  shared_buffers:        25%RAM → 38%RAM  (内存型负载)
  work_mem:              4MB    → 64MB
  effective_io_conc:     1      → 200     (NVMe 检测到)
  max_worker_processes:  8      → 16

Cross-load validation: stable across tpcc/sysbench/read-heavy

如果 Agent 调参后性能不升反降，先不要怀疑模型，去检查 PerfEvolve 的离线特征剖面是否覆盖了你的负载类型——它是这套框架正确性的地基。

常见问题

• Agent 调参后性能反而下降：八成是触发了"参数互搏"。检查参数交互拓扑图里被标红的强相关参数组，确保它们是联合调优而非单独调整。
• shared_buffers 一直被调回 25%：这是 LLM 死记文档"标准答案"的典型表现。PerfEvolve 论文里专门验证过——哪怕给 LLM 完全正确的参数标准答案，依旧可能导致性能变差，因为数值会对模型形成"认知锚定"。把声明式知识切换为过程式技能即可解决。
• 跨负载验证不通过：说明调参结果对单一负载过拟合。在 workflow 里提高 cross_load_validation 的严格度，让 Agent 重新进入联合优化阶段。

💡 提示：PerfEvolve 的核心 insight 不只是"调数据库"——它揭示了一个对所有 Agent 都有用的范式：给 Agent 一百个标准答案，不如给它一套自主解题的能力。这个思路同样适用于运维、网络配置、CI/CD 流水线等其他"过程比结论重要"的领域。