上周三翻 arXiv 的 cs.SE 新列表，标题里同时有 microservice 和 benchmark 的那篇，我点开先扫结论。看到 42.0% 那一行停了一会儿。不是因为这数低得离谱，是低得太合理了——脑子里立刻翻出几个改了半宿、功能测试全绿、profile 一跑曲线纹丝不动的 commit。
坐标先记下：arXiv:2610.29695，10 月 21 日提交，七个作者，做编码智能体在微服务系统上的端到端性能优化评测，基准叫 MicroPerf-Bench。下面是我读完真记下来的东西，不是摘要。
它凭什么另起一个基准
论文对现有评测的判断很直接：多数编码智能体的评测停在单个函数或单个仓库这一层，分布式系统里的表现基本没被考察过。这话说得不重，但捅到点子上了。微服务下一个应用的端到端性能，由好几个独立跑着的服务互相调用共同决定，你让智能体去改一个函数，改得再漂亮也只是局部正确。
作者的推论是这类任务要求智能体能跨出局部代码修改去推理，得看得见调用链和负载，而不只是眼前这个 diff。这段我读了两遍，因为它其实在说：我们平时拿来判断"这个模型行不行"的那套办法，到了这一层就不成立了。
难的是造样本，不是跑分
这类基准不好造，论文自己列了两条：可复现的系统级性能修复案例本来就稀少；性能一有变化，很难归因到具体某一处改动。第二条我尤其信——真实系统里你换个实例规格、隔壁同事跑个批处理，曲线就跟着晃，最后谁也说不清是谁的功劳。
他们的办法是往真实开源系统里注入有实证依据的性能反模式，同时保持原有功能还能用，并且保证这个退化是可被测量的。拆开看看这个设计，其实是拿"合成"换"可归因"：退化是你自己放进去的，最后才能算出一个干净的百分比，你到底修掉了多少。没有这一步做地基，42.0% 这个数字根本无从谈起。
规模大概是这样：
实例数 65
覆盖系统 7
性能反模式类别 9
总运行次数 1755
智能体×模型 9 组
最好一组的成绩 消除 42.0% 的注入退化
1755 这个数我顺手算了一下，65 × 9 = 585，正好三倍。猜是每个组合在每个实例上跑三次取稳定值，不然混合负载下的噪声很难压住。这条是我自己推的，论文里没写这么细。
失败原因那一栏，比 42% 更值得记
真正让我坐直的是失败归因。作者说最主要的失败原因不是代码无效——修改功能正确、也满足约束，就是没带来端到端的性能提升。
这条我认，认得很不情愿。因为我们评价 agent 的日常方式基本就两样：diff 看着对不对、测试绿不绿。单服务里这两件事勉强还能当代理指标，一到几个服务互相喊着跑就完全不成立。你把这个函数的复杂度降下来了，瓶颈在另一个服务的连接池上；你把某条查询优化了，上游的重试策略又把压力原样打回来。改得对，和改得快，中间隔着一整条调用链。
论文据此把系统级瓶颈定位列为核心难题。这个措辞还算克制，换成我的话会说：现在多数 agent 只会照着报错和代码气味改，不会先问一句"慢在哪一层"。
我打算怎么复现
论文说源代码和数据都公开了，我打算按这个顺序走一遍，先不碰大系统：
1. 拉仓库 → 起 7 个系统里体量最小的那个
2. 先跑功能测试，确认基线是绿的
3. 上混合负载，记下 p99 和错误率
4. 让 agent 改，再跑同一份负载，对比
5. 重点看它第一步往哪儿看，而不是最后改出了什么
第 5 步是我自己想加的。分数已经有人跑过了，我更想知道它在定位阶段的表现——是先翻监控和调用链，还是直接打开一个看起来最可疑的文件开始改。这个顺序基本决定了后面有没有意义。
坦白一句：混合负载具体怎么打、不同配置之间怎么保证可比，这部分我没完全搞懂，只记了结论。等真跑起来大概还得回来补一次，这条先留个坑。
划重点：函数级评测刷得再高，也说明不了系统级的表现，两层之间没有自动的传递关系；判断一个 agent 改得好不好，别只看测试绿不绿，得看端到端指标有没有动；这篇最值钱的不是 42.0%，是它把失败原因归到了"定位"而不是"写码"上。这条记下来了，下次再让 agent 碰性能问题，我会先让它输出一份瓶颈位置和依据，再让它动手。你也可以挑一个自己手上的小服务，照上面那个顺序走一遍，改完先别急着看 diff，先看曲线。