中科院软件所开源 PerfEvolve 框架，把静态调参文档转化为 Agent 可执行的过程化技能，在 PostgreSQL v16 上实现最高 58.9% 性能提升，专治 LLM 调参翻车。
中科院软件所开源 PerfEvolve 框架，把静态调参文档转化为 Agent 可执行的过程化技能，在 PostgreSQL v16 上实现最高 58.9% 性能提升，专治 LLM 调参翻车。
GitHub狂揽4.8万星的AI Agent框架，通过学习循环和四层记忆系统实现越用越强，支持多平台部署和主流大模型
数据库自动调参，一直是大模型 Agent 的"看似完美、实则翻车"名场面。明明喂足了官方文档和参数攻略，LLM Agent 上手依旧状况百出：要么照搬老旧参数适配新硬件翻车，要么参数互相"打架"、越调性能越拉胯。
中科院软件所智能软件研究中心和基础软件与系统重点实验室团队联合推出 PerfEvolve 框架，给出了一个反直觉的结论：问题从来不是大模型不会读文档，而是传统调参文档本身就有致命缺陷——它只给"最终答案"，却从不教"解题过程"。结论会过期，过程才能迁移。
PerfEvolve 不教 LLM 死记参数值，而是把静态调参文档转化为 Agent 可直接执行、可自主落地的过程化调参技能。在 PostgreSQL v16 上实现最高 58.9% 性能提升，已开源。
PerfEvolve 的核心：把"读说明书"升级为"会做剖析"。
预计跑通最小示例：1 小时。
动手前先认清问题，你才会知道 PerfEvolve 在解决什么：
shared_buffers = 25% RAM——所有 DBA 都见过，但仅这一个参数配置不合适就可能带来 5%–16% 性能损失。PerfEvolve 的诊断是：只给固定参数值的文档，适配不了千变万化的硬件、负载与系统版本。真正的瓶颈不是"Agent 没读够文档"，而是"文档只给了终点坐标、没给路线"。
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 的调参流程标准化成一条完整工作流：
测默认配置性能 → 扫描候选参数值 → 观察吞吐量变化曲线
→ 找到峰值区间 → 检查和其他参数是否强交互
→ 如有就进入联合优化 → 最后跨负载验证稳定性接入方式（伪代码，对接你自己的 LLM Agent）：
from perfevolve import TuningWorkflow, AgentAdapter
class MyLLMAgent(AgentAdapter):
def decide_next_step(self, observation, history):
# observation: 当前 perf 曲线、参数当前值、负载特征
# PerfEvolve 已经把"下一步该做什么"结构化了
# Agent 只需要在结构化选项里选，而不是凭直觉编命令
return self
PerfEvolve 之所以能把搜索成本打下来，靠两个机制：
敏感度降维 + 参数交互拓扑图，把搜索空间从指数级压到可执行规模。
跑完后你会得到一份调参报告：
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 的离线特征剖面是否覆盖了你的负载类型——它是这套框架正确性的地基。
shared_buffers 一直被调回 25%：这是 LLM 死记文档"标准答案"的典型表现。PerfEvolve 论文里专门验证过——哪怕给 LLM 完全正确的参数标准答案，依旧可能导致性能变差，因为数值会对模型形成"认知锚定"。把声明式知识切换为过程式技能即可解决。cross_load_validation 的严格度，让 Agent 重新进入联合优化阶段。💡 提示：PerfEvolve 的核心 insight 不只是"调数据库"——它揭示了一个对所有 Agent 都有用的范式：给 Agent 一百个标准答案，不如给它一套自主解题的能力。这个思路同样适用于运维、网络配置、CI/CD 流水线等其他"过程比结论重要"的领域。