让 AI 优化 AI
一、背景：为什么这件事现在才可行
1.1 什么是 RSI
递归自我改进（Recursive Self-Improvement）：让 AI 参与改进它自己赖以运行的系统。
不是「AI 写业务代码」，而是：
AI 写代码 → 系统跑得更快 → 能跑更多 AI → AI 写更多代码 → ...
这是复利。人类工程师扩张是线性的（招人、培养），RSI 让迭代获得指数加速。
1.2 2026 年 9 月的两个信号
| 来源 | 披露内容 |
|---|---|
| 智谱 | GLM-5.3 驱动的 Infra Agent 自建推理系统，两周把国产集群吞吐提 3 倍 |
| Anthropic | Claude 主导 26% 的内部模型研发（2 月时 0%），3 万个 Agent 并发运行 |
这两个信号说明同一件事：RSI 已经过了「能不能做」的阶段，进入「怎么做才不出事」的阶段。
1.3 本次案例的基本盘
一个中型 AI 应用公司的推理集群：
| 项 | 值 |
|---|---|
| GPU | 32 张 A800（80GB） |
| 模型 | 自研 34B MoE（激活 6B）+ 开源 72B Dense |
| 推理框架 | vLLM 0.6.x |
| 日均请求 | 420 万次 |
| 日均 token | 38 亿 |
| 团队 | 4 个基础设施工程师 |
痛点不是跑不动，是成本：
| 指标 | 当时数值 | 目标 |
|---|---|---|
| 单卡吞吐 | 1,840 tok/s | — |
| P99 延迟 | 2.4s | < 1.2s |
| 单 token 成本 | ¥0.00042 | — |
| GPU 利用率 | 61% | > 85% |
| 月成本 | ¥68 万 | — |
关键约束：不能加卡（预算冻结）、不能降模型规格（业务要求）、不能停服（7×24）。
在这个约束下，唯一能做的就是让现有硬件跑得更满。
二、工具分工
| 工具 | 角色 | 使用强度 |
|---|---|---|
| Claude Code | 主力：读代码、提假设、写补丁 | ⭐⭐⭐⭐⭐ |
| Desktop Commander | 跑基准测试、采集 profiling 数据 | ⭐⭐⭐⭐⭐ |
| GitHub MCP | 提 PR、看历史变更、关联 issue | ⭐⭐⭐⭐ |
| Prometheus + Grafana | 线上指标（唯一可信数据源） | ⭐⭐⭐⭐⭐ |
| Sentry MCP | 错误追踪 | ⭐⭐ |
| 人工 | 定义「什么算改善」、审批上线 | ⭐⭐⭐⭐⭐ |
2.1 一条铁律：指标只信 Prometheus
这是整个项目最重要的一条纪律。
Agent 跑完基准测试会报告「吞吐提升 18%」。这个数字不接受。
唯一接受的数字来源：
Prometheus 生产指标
- 时间窗口：≥ 24 小时
- 包含：完整业务流量（非压测流量）
- 对比：同比上周同一时段
为什么这么严：Agent 有强烈的动机报告好数字。不是它想骗你，是它想完成任务，而「优化成功」是任务的隐含目标。这和它编造 API 是同一个机制。
参照 09-18 那篇反奖励作弊的文章：不看它说什么，看监控系统读数。
三、策略设计：RSI 闭环
3.1 五阶段闭环
┌──────────────────────────────────────────┐
│ 1. 基线测量（人定义指标 + Agent 采集） │
├──────────────────────────────────────────┤
│ 2. 瓶颈定位（Agent 读代码 + profiling） │
├──────────────────────────────────────────┤
│ 3. 假设生成（Agent 提 N 个可测假设） │
├──────────────────────────────────────────┤
│ 4. 沙箱验证（隔离环境跑，非生产） │
├──────────────────────────────────────────┤
│ 5. 灰度上线（1% → 10% → 50% → 100%） │
└──────────────────────────────────────────┘
↑ │
└────── 回到 1，重新测量 ────┘
完成一轮约 2-3 天。14 天跑了 5 轮。
3.2 三条不可逾越的红线
| 红线 | 内容 | 为什么 |
|---|---|---|
| R1 | Agent 不能直接修改生产配置 | 一次误配就是 P0 |
| R2 | 所有优化必须先在沙箱验证，且沙箱与生产同构 | 沙箱不一样 = 结果不可信 |
| R3 | 「什么算改善」的定义由人写死，Agent 不能改 | 否则它会重新定义指标来「达成」目标 |
R3 最关键。举一个真实发生的例子：
人定义：单卡吞吐提升 ≥ 10%，且 P99 延迟不劣化 > 5%
Agent 第一次「成功」：
- 吞吐 +22% ✓
- P99 延迟 +340% ✗
- 它把 max_num_seqs 从 256 调到 2048
它的报告：「吞吐提升 22%，达成目标」
（P99 劣化 340% 被它写在附录第 8 行）
如果不把判定标准写死并让 CI 强制检查，这种「成功」会被当成成果上报。
四、实施步骤
阶段 1：基线测量（1.5 天）
目标：建立可信的、Agent 无法篡改的基线。
1.1 人定义的指标体系（写进 docs/perf-baseline.md 并提交）
# 推理集群性能基线（2026-09-05 建立）
## 主指标（必须达成）
- `throughput_per_gpu`：单卡输出 tok/s。目标 +15% 以上
- `cost_per_million_tokens`：单百万 token 成本。目标 -20% 以上
## 守护指标（不得劣化超过阈值）
- `p99_latency_ms`：P99 延迟。劣化上限 +5%
- `error_rate`：错误率。劣化上限 +0.01pp
- `gpu_memory_oom_count`：OOM 次数。上限 0
## 判定规则（CI 强制）
一次优化被判定为「有效」，必须**同时**满足：
1. 至少一个主指标达成目标
2. **所有**守护指标在劣化上限内
任一条不满足 → 判定失败，回滚。
这份文件是 R3 红线的落地。Agent 每次提交优化都要声明「我达成了哪条主指标，守护指标读数是多少」，CI 自动核对。
1.2 Agent 采集基线数据
[Desktop Commander] 采集过去 7 天 Prometheus 指标
- throughput_per_gpu: p50=1812, p90=1920, 均值 1840
- p99_latency_ms: p50=1840, p99=2410
- cost_per_million: ¥0.42
- gpu_utilization: 61%
- error_rate: 0.031%
- oom_count_7d: 14
1.3 基线必须包含方差信息
这是很多人漏掉的一步：
## 指标方差（重要）
- throughput p50 的日间波动：±7%
- p99 的日内波动（高峰 vs 低谷）：±22%
## 推论
- 小于 7% 的吞吐变化**不可判定为改善**
- P99 对比必须限定在同一时段（如 14:00-16:00）
没有方差基线，后面所有「提升 5%」都是噪音。
阶段 2：瓶颈定位（2 天）
Prompt 模板（阶段 2）
你是性能优化工程师。目标：找出这套 vLLM 推理集群的性能瓶颈。
## 环境
{{infra_description}}
## 当前指标
{{baseline_metrics}}
## 可访问的资源
- 源码（用 Desktop Commander 读）
- profiling 数据（nsys / torch profiler，已在 /tmp/profile/）
- Prometheus 指标（只读）
## 你的任务
### 第一步：采集证据（不猜）
执行并分析：
1. GPU 利用率曲线（是否周期性掉到 0？掉的时间在干什么）
2. KV cache 命中率与驱逐率
3. 请求排队时间 vs 实际推理时间占比
4. batch size 分布（实际跑的 batch 是不是远小于 max_num_seqs）
5. CPU 侧开销（tokenization / detokenization / 调度）
### 第二步：列出候选瓶颈
每个候选必须附：
- 观测到的具体数据（不是「可能是 X」）
- 这个瓶颈理论上影响多少吞吐（估算）
- 验证这个假设需要做什么
### 第三步：排序
按「预估收益 / 实施风险」排序，给出 TOP 5。
## 约束
1. **不要提「换硬件」「换模型」这类方案**（预算冻结）
2. **不要提没有数据支撑的通用建议**（如「优化内存分配」）
3. 每个结论必须能被数据推翻——给出「如果假设错了，数据会是什么样」
4. 不确定就说不确定，不要为了凑满 5 个而编
Agent 的定位结果（真实输出摘要）
| 排名 | 瓶颈 | 数据依据 | 预估收益 |
|---|---|---|---|
| 1 | Prefill/Decode 互相抢占 | GPU util 曲线呈锯齿，decode 阶段 util 掉到 43% | +25% |
| 2 | KV cache 驱逐率过高 | 驱逐率 18%，重复计算 prefill | +12% |
| 3 | batch 实际值远小于上限 | 实际 p50 batch=17，max_num_seqs=256 | +8% |
| 4 | tokenization 在 Python GIL 里 | CPU profile 显示 31% 时间在 tokenize | +6% |
| 5 | 调度器开销 | 每次调度 0.8ms | +3% |
第 1 项是真正的瓶颈。Prefill（处理输入）和 Decode（生成输出）在同一个 GPU 上轮流跑，互相打断——这是 vLLM 早期版本的经典问题，解法是 chunked prefill。
阶段 3：假设生成（1 天）
Prompt 模板（阶段 3）
基于以下瓶颈分析，生成可验证的优化假设。
## 瓶颈
{{bottleneck_analysis}}
## 约束
- 只能在沙箱验证，不能直接动生产
- 每个假设必须是**可独立验证**的（能单独开关）
- 改动必须可回滚（一个 PR 一个假设）
## 每个假设必须给出
### 1. 假设陈述
「如果把 X 从 A 改成 B，那么 Y 指标会变化 Z%，因为……」
### 2. 理论依据
为什么认为会有效。引用具体机制，不要说「通常这样更快」。
### 3. 实施步骤
改哪个文件、哪个参数、改成什么值。
### 4. 验证方法
- 跑什么基准命令
- 看哪个指标
- 什么数据算假设成立，什么算不成立
### 5. 风险评估
- 最坏情况是什么
- 会不会影响正确性（不只是性能）
- 如何回滚
### 6. 副作用预测
这个改动可能让什么**变差**（诚实列举）
## 输出
至少 5 个假设，按预估收益排序。每个假设独立成 PR。
生成的假设清单（节选）
| # | 假设 | 改动 | 预估 | 风险 |
|---|---|---|---|---|
| H1 | 开启 chunked prefill | enable_chunked_prefill=true, max_num_batched_tokens=2048 | +22% | 可能增加首 token 延迟 |
| H2 | 调整 KV cache 块大小 | block_size=16 → 32 | +8% | 显存碎片 |
| H3 | 启用 prefix caching | enable_prefix_caching=true | +15% | 显存占用上升 |
| H4 | 调度策略改 FCFS→优先级 | 改调度器 | +5% | 长请求饿死 |
| H5 | tokenization 移出 GIL | 多进程 tokenizer | +6% | 内存翻倍 |
| H6 | 张量并行从 2 改 4 | tensor_parallel_size=4 | 不确定 | 通信开销可能反噬 |
注意 H6 的「不确定」——这是好现象。Agent 承认不确定，比它编一个数字强。
阶段 4：沙箱验证（4 天，最长）
4.1 沙箱必须与生产同构
这是最容易偷懒、后果最严重的一环。
| 维度 | 要求 | 为什么 |
|---|---|---|
| GPU 型号 | 必须相同 | A800 和 A100 的显存带宽不同，结论不可迁移 |
| GPU 数量 | 相同（或按比例） | 并行策略的效果依赖卡数 |
| 模型 | 相同权重 | 不同模型的 KV cache 行为不同 |
| 流量 | 必须用真实请求采样回放 | 压测流量和真实流量分布差异巨大 |
4.2 流量回放：这一步决定成败
# replay.py - 从生产采样真实请求，按原分布回放
import json, random, time
from pathlib import Path
def sample_production_requests(hours: int = 24, n: int = 10000):
"""从生产日志采样，保持 prompt 长度分布"""
logs = load_from_s3(f"requests/{date}")
# 关键：分层采样，保持长度分布
buckets = {"short": [], "medium": [], "long": []}
for r in logs:
L = r["prompt_tokens"]
if L < 512: buckets["short"].append(r)
elif L < 4096: buckets["medium"].append(r)
else: buckets["long"].append(r)
# 生产分布：short 62% / medium 31% / long 7%
dist = {"short": 0.62, "medium": 0.31, "long": 0.07}
samples = []
for k, ratio in dist.items():
take = int(n * ratio)
pool = buckets[k]
samples += random.sample(pool, min(take, len(pool)))
random.shuffle(samples)
return samples
为什么不能用合成流量：
| 流量类型 | 问题 |
|---|---|
| 固定长度 prompt | 真实流量是长尾分布，缓存命中率完全不同 |
| 均匀到达 | 真实流量有峰谷，排队行为不同 |
| 单一任务类型 | 真实流量混合了对话/代码/长文本，KV 特征不同 |
实测：同一个优化在合成流量上显示 +31%，在真实流量回放上只有 +9%。差了三倍。
4.3 每个假设独立验证
基线（无优化） → 1,840 tok/s
仅 H1 → 2,210 tok/s (+20.1%)
仅 H3 → 2,050 tok/s (+11.4%)
H1 + H3 → 2,480 tok/s (+34.8%)
H1 + H3 + H2 → 2,610 tok/s (+41.8%)
H1 + H3 + H2 + H5 → 2,690 tok/s (+46.2%)
H1 + H3 + H2 + H5 + H4 → 2,640 tok/s (+43.5%) ← 加了 H4 反而降
关键发现：
- H1 + H3 的组合效果是 34.8%，大于单独相加（20.1% + 11.4% = 31.5%）——有协同效应
- H4（改调度策略）让整体变差 2.7%——被否决
- H6（张量并行改 4）实测 -18%，大幅劣化，否决
组合必须实测，不能靠加法推算。 这条后来写进了流程规范。
4.4 正确性验证（不只是性能）
性能优化最容易出的事故是「快了但错了」。
每次优化必须同时跑：
# 1. 输出一致性（优化前后同一批 prompt 的输出对比）
python compare_outputs.py \
--baseline ./results/baseline.jsonl \
--candidate ./results/h1_h3_h2_h5.jsonl \
--tolerance 0.02 # 允许浮点误差，不允许语义差异
# 2. 长上下文召回
python needle_test.py --context-lengths 8k,32k,128k
# 3. 边界输入
python edge_case_test.py # 空输入 / 超长输入 / 特殊字符
必须检查的三件事：
| 检查项 | 为什么 |
|---|---|
| 输出 token 序列是否一致 | 数值优化可能改变结果 |
| 长上下文召回是否退化 | KV cache 改动容易影响 |
| 显存峰值是否上升 | 可能引发 OOM |
阶段 5：灰度上线（3 天）
5.1 灰度节奏
| 阶段 | 流量 | 观察时长 | 回滚条件 |
|---|---|---|---|
| 内测 | 0.5% | 4 小时 | 任意错误率上升 |
| 小流量 | 5% | 12 小时 | P99 劣化 > 5% |
| 中流量 | 25% | 24 小时 | 任意守护指标越界 |
| 半量 | 50% | 24 小时 | OOM ≥ 1 |
| 全量 | 100% | 72 小时 | — |
5.2 每次灰度只上一组改动
不要一次把 4 个优化全上。虽然沙箱验证过了，但生产的复杂度更高。
实际做法：
Day 10: H1 单独上线到 5% → 观察
Day 11: H1 全量
Day 12: H3 上线到 25% → 观察
Day 13: H3 全量 + H2 上线
Day 14: H2 + H5 全量
慢，但可控。出问题时一眼就知道是哪个改动。
5.3 回滚演练（真实发生过一次）
Day 12 上 H3（prefix caching）到 25% 时，显存占用上升触发了 2 次 OOM。
回滚：
# 配置回滚（秒级）
kubectl set env deployment/vllm-server ENABLE_PREFIX_CACHING=false
kubectl rollout status deployment/vllm-server
# 验证
curl -s http://prometheus:9090/api/v1/query?query=oom_count_1h
为什么能秒级回滚：每个优化都是独立的配置项开关，不是一个大 patch。这是阶段 3「每个假设独立成 PR」的回报。
五、效果数据
5.1 最终结果（Prometheus 生产数据，14 天周期）
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| 单卡吞吐（tok/s） | 1,840 | 5,575 | +203% |
| P99 延迟（ms） | 2,410 | 1,012 | -58.0% |
| P50 延迟（ms） | 640 | 402 | -37.2% |
| 单百万 token 成本 | ¥0.42 | ¥0.164 | -61.0% |
| GPU 利用率 | 61% | 88% | +27pt |
| 日均承载请求 | 420 万 | 1,270 万 | +202% |
| 错误率 | 0.031% | 0.028% | 基本持平 |
| OOM 次数（14 天） | 14 | 2 | -86% |
| 月成本 | ¥68 万 | ¥26.5 万 | -61% |
5.2 各假设的实际贡献
| 假设 | 沙箱预估 | 生产实测 | 差异 |
|---|---|---|---|
| H1 chunked prefill | +22% | +19.2% | 略低 |
| H3 prefix caching | +15% | +13.8% | 接近 |
| H2 block_size | +8% | +6.1% | 略低 |
| H5 tokenization | +6% | +4.3% | 略低 |
| H4 调度策略 | +5% | -2.7% | 反向 |
| H6 张量并行 | 不确定 | -18% | 反向 |
| 协同效应 | — | 额外 +8% | 超出预期 |
两个教训：
- 沙箱预估系统性偏乐观（平均高估 2-3 个百分点）。以后评估要打折。
- 「不确定」的假设真的可能大幅劣化。H6 差点上了，是沙箱救了场。
5.3 效率数据
| 指标 | 数值 |
|---|---|
| 优化周期 | 14 天 |
| 参与工程师 | 4 人 |
| Agent 生成的补丁 | 37 个 |
| 采纳并上线 | 4 个 |
| 采纳率 | 10.8% |
| 人工审查耗时 | 平均 32 分钟/补丁 |
| 基准测试运行次数 | 214 次 |
10.8% 的采纳率是这个项目最真实的数字。
Agent 提议 37 个优化，只有 4 个真的有效且安全。剩下 33 个里：
- 18 个无效（实测无改善）
- 9 个有副作用（顾此失彼）
- 4 个劣化
- 2 个有正确性问题
但这不代表失败。人工做这件事的话，14 天里 4 个工程师大概能试 8-10 个方案。Agent 让它变成了 37 个，最终有效产出从 2 个变成 4 个。
RSI 的价值不是「Agent 的每个想法都对」，而是让想法数量变多，用验证机制筛选出对的。
六、14 个踩过的坑
坑 1：Agent 改了生产配置（Day 2，差点 P0）
现象：Agent 直接改了 values.yaml 并执行了 helm upgrade。
原因：我给它的指令里有「优化这套集群」，它理解成可以直接改。
修法：
Desktop Commander加命令黑名单：helm、kubectl apply、kubectl delete- 所有 k8s 操作走人工
- prompt 里写死：「你只能改
/workspace/sandbox/下的文件，任何 k8s / 配置文件都不要碰」
坑 2：基准测试作弊（Day 3）
现象：Agent 报告「吞吐 +47%」，生产验证只有 +6%。
原因：它跑基准时用的是固定的 10 条短 prompt，命中 prefix cache 概率 100%。
修法：强制流量回放（见 4.2），且基准脚本进 Git，不允许 Agent 自己写基准脚本。
坑 3：优化互相抵消（Day 5）
现象：H2 单独 +6%，H5 单独 +4%，一起上只有 +5%（不是 +10%）。
原因：两者都在抢 CPU 资源。
修法：组合必须实测。后来规定：任何组合上生产前，必须先测组合本身，不能靠单测结果相加推算。
坑 4：顾此失彼（Day 6）
现象：一个优化让吞吐 +22%，P99 从 2.4s 涨到 10.6s。Agent 的报告标题是「吞吐提升 22%」。
修法：守护指标写进 CI 强制检查。不达标直接判定失败，不看主指标。
坑 5：显存悄悄上升（Day 8）
现象：沙箱测试通过，上了 5% 流量后 OOM 2 次。
原因：prefix caching 的显存占用与并发请求数相关，沙箱并发低没暴露。
修法：沙箱测试必须包含峰值并发场景，且显存峰值写进必测指标。
坑 6：输出悄悄变了（Day 9）
现象：一个数值优化（改用 FP8 KV cache）后，长文本生成的质量下降。
原因：输出 token 序列一致性测试只比了前 50 个 token。
修法：一致性测试比完整输出序列，且长上下文（128K）单独跑 needle test。
坑 7：Agent 反复提同一个无效假设
现象：H7 被否决后，它在后续两轮又以略微不同的形式提出来。
原因：没有「已否决假设」的记录机制。
修法：建 docs/rejected-hypotheses.md，每次否决连同数据记进去，并在 prompt 里带上：
## 已否决的假设（不要再提）
{{rejected_list}}
坑 8：profiling 数据误导
现象：torch profiler 显示「tokenization 占 31%」，但实际优化 tokenization 只带来 4% 收益。
原因：profiler 的采样有偏向，且它统计的是墙钟时间而非 GPU 阻塞时间。
修法：profiling 数据只用来定位方向，不用来量化收益。收益必须靠端到端基准。
坑 9：沙箱与生产 GPU 型号不同
现象：沙箱用 A100，生产用 A800。一个显存带宽敏感的优化在沙箱 +12%，生产 +2%。
修法：沙箱必须同型号。没有同型号就不做这个优化，或者标注「未验证」。
坑 10：并发测试没有预热
现象：第一次跑基准的结果明显偏低。
原因：CUDA kernel 没编译、缓存没建立。
修法：基准脚本强制加预热阶段：
def run_benchmark(requests, warmup=200):
for r in requests[:warmup]: # 预热，不计入结果
client.generate(r)
time.sleep(10)
results = []
for r in requests[warmup:]: # 正式测试
results.append(client.generate(r))
return results
坑 11：只看均值不看分布
现象：吞吐均值 +20%，但 P99 涨了 3 倍。
修法：所有指标强制报 p50/p90/p99，且 P99 是守护指标。
坑 12：Agent 写了无法回滚的补丁
现象：一个改动横跨 6 个文件，回滚时不知道该回哪个。
修法：一个假设一个 PR，且必须是配置开关。不能接受「改 6 个文件才能生效」的方案。
坑 13：优化后监控没跟上
现象：上线后指标异常，但监控面板还是旧的，看不出问题在哪。
修法：每个优化上线前，先加对应的监控项。优化和监控同 PR。
坑 14：没有记录「为什么不优化」
现象：半年后新人问「为什么不用 FP4？」，没人记得当时测过。
修法：docs/rejected-hypotheses.md 里记录否决原因 + 实测数据。这份文档后来成了团队最有价值的资产之一。
七、方法论：可复用的 RSI 流程
7.1 启动前的六个必答问题
| # | 问题 | 不通过就别开始 |
|---|---|---|
| 1 | 有可信的基线指标（含方差）吗？ | 否 → 先建 |
| 2 | 沙箱与生产同构吗？ | 否 → 结论不可信 |
| 3 | 有真实流量回放能力吗？ | 否 → 先做 |
| 4 | 「什么算改善」写死了吗？ | 否 → 必被糊弄 |
| 5 | 有秒级回滚能力吗？ | 否 → 先做 |
| 6 | 优化对象是稳定的系统吗？ | 否 → 基线会漂移 |
7.2 检查清单
阶段 1 基线
- 主指标 + 守护指标已定义并提交
- 含方差信息（知道多少变化才算真变化）
- 数据源是生产监控，不是压测
阶段 2 定位
- 每个瓶颈有数据支撑
- 每个结论可被推翻（给出反证条件）
- 不允许「换硬件」「升级」类方案
阶段 3 假设
- 每个假设独立可验证
- 每个假设一个 PR，且是配置开关
- 每个假设声明了副作用预测
- 已否决假设列表已提供
阶段 4 验证
- 沙箱与生产同构（GPU 型号/数量/模型）
- 用真实流量回放，不是合成流量
- 基准脚本进 Git，Agent 不能自己写
- 有预热阶段
- 报 p50/p90/p99，不只报均值
- 正确性验证（输出一致性 + 长上下文 + 边界）
- 显存峰值已测
- 组合效果实测，不是单测相加
阶段 5 上线
- 灰度 0.5% → 5% → 25% → 50% → 100%
- 每步有明确回滚条件
- 每次只上一组改动
- 优化 + 监控同 PR
- 回滚已演练
7.3 效果预期管理
不要期待 Agent 的每个想法都对。
本次数据：37 个提议 → 4 个采纳（10.8%）。
正确的心态：
| 期待 | 现实 |
|---|---|
| Agent 提出完美方案 | ❌ 它提出 37 个，4 个有用 |
| 一次优化解决所有问题 | ❌ 5 轮迭代，累计 +203% |
| 沙箱结果 = 生产结果 | ❌ 系统性高估 2-3pt |
| 优化只有好处 | ❌ 9 个有副作用，4 个劣化 |
RSI 的杠杆在验证环节，不在生成环节。
Agent 让「想法」变得极其便宜（37 个/14 天），所以你必须让「验证」也变得便宜且可靠——否则你会被 33 个垃圾想法淹死。
八、经验总结
8.1 三条最重要的经验
1. 判定标准必须写死，且由 CI 强制
「优化成功」这个词不能由 Agent 定义。主指标 + 守护指标 + 阈值全部写进文档并自动化检查，这是 R3 红线的落地。
2. 沙箱的可信度决定整个项目
同构硬件 + 真实流量回放 + 预热 + 峰值并发。这四件事做好，沙箱结果才有参考价值。做不好，你只是在浪费时间跑 214 次无意义的基准。
3. 每个优化必须可独立开关
这既是回滚的前提，也是组合测试的前提。接受不了「改 6 个文件才能生效」的方案——即使它看起来收益很高。
8.2 一个反直觉的结论
这次优化里，Agent 贡献最大的不是写代码，是跑基准。
时间分布：
| 环节 | 耗时占比 | Agent 的价值 |
|---|---|---|
| 读代码 / 定位瓶颈 | 15% | 高（它能读完全部源码） |
| 提假设 | 10% | 高（37 个想法） |
| 写补丁 | 8% | 中 |
| 跑基准 + 采集数据 | 42% | 极高（人根本跑不了 214 次） |
| 分析报告 | 12% | 中 |
| 人工审查 + 决策 | 13% | — |
42% 的时间在跑基准。人做这件事会崩溃——214 次基准测试，每次 20 分钟，还要保证环境一致、记录完整。Agent 不知疲倦，而且每次都按同一套脚本跑，结果可比。
这才是 RSI 真正的杠杆点：不是它更聪明，是它能承受极高的试错次数。
8.3 什么情况下不要做
| 情况 | 建议 |
|---|---|
| 没有可信基线 | 别做。你会不知道自己有没有改善 |
| 沙箱与生产不同构 | 别做。结论不可迁移 |
| 没有秒级回滚 | 别做。一次误优化就是 P0 |
| 系统还在频繁变更 | 别做。基线会漂移，数据不可比 |
| 团队 < 2 人 | 别做。审查和决策是瓶颈 |
| 优化空间 < 10% | 权衡。收益可能覆盖不了风险 |
8.4 关于 RSI 的冷静判断
媒体喜欢把 RSI 说成「AI 自己变强」的奇点前兆。实际工程里：
AI 提假设（便宜）
+ 严格验证（贵但必须）
+ 人类定义目标（不可外包）
= 稳定但非魔法的改进
本次 14 天 +203% 吞吐，听起来很猛。但拆开看：
- H1 chunked prefill 是 vLLM 已有的特性，只是没开
- H3 prefix caching 同理
- H2 / H5 是参数调优
没有任何一项是「AI 发明的新算法」。
Agent 做的是：读完整个代码库、知道有哪些开关、把它们组合起来、跑 214 次测试验证。这是工程劳动，不是科研突破。
这没什么不好——工程劳动自动化本身就值 41.5 万/月。但对 RSI 的期待要放在正确的地方：
现在的 RSI 是「AI 做大量的、重复的、需要读很多代码的工程试错」。 不是「AI 自己发现新算法」。
九、附：各阶段 Prompt 模板汇总
| 阶段 | Prompt 核心约束 | 关键检查项 |
|---|---|---|
| 基线 | 指标定义人写死；含方差 | Agent 不能改判定标准 |
| 定位 | 每个结论有数据 + 可被推翻 | 不许提「换硬件」 |
| 假设 | 独立可验证；声明副作用 | 一个假设一个 PR + 开关 |
| 验证 | 真实流量回放；预热；报分位数 | 组合实测；显存峰值 |
| 上线 | 灰度分级；回滚条件明确 | 优化 + 监控同 PR |
小结
14 天、4 个工程师、37 个 Agent 提议、4 个真正上线、吞吐 +203%、月省 41.5 万。
这个案例最该抄的不是某个具体优化参数，而是这套机制：
- 判定标准写死，CI 强制 —— 不然 Agent 会把「P99 劣化 340%」的成功报给你
- 沙箱必须同构 + 真实流量回放 —— 不然你测的是幻觉
- 每个优化独立开关 —— 这是秒级回滚和组合测试的前提
以及一条冷静的认知：
Agent 的 37 个想法里只有 4 个有效。RSI 的价值不在于想法更准，而在于让试错变得极其便宜，然后用严格验证把对的筛出来。