Z.ai 这篇复盘的价值不在跑分,在于把 agent 工程化中“卡在哪”的问题拆清楚了。核心判断很朴素:优化之前先测量,这个原则对 AI 比对人更致命,因为 agent 完全依赖环境递给它的信息。文章用三个真实故障把分层反馈的链条跑通了——精度丢失靠数值差异比对定位到 TF32 模式,GIL 争用靠时间线追踪发现传输与计算从未重叠,算子冗余计算靠微基准测试揪出重复执行四次的门控计算。每个案例都走了“定目标、看现象、提假设、修复、验证”的完整闭环,不是纸上谈兵。
但有几个信息缺口得说清楚。第一,端到端吞吐达到约 3 倍基线,厂商自述这是多项技术组合的结果,且没有做消融实验来剥离诊断反馈的单独贡献,所以不能直接把 3 倍全算在 feedback engineering 头上。第二,GIL 争用那个案例,DeepEP 社区早在 2025 年 5 月就有相关 PR,智能体的贡献是在特定集群上完成本地定位和迁移,不是首次发现。第三,KDA 精度修复那条路径默认关闭,管的是算得对不是跑得快,不能计入性能账。
这篇文章真正稀缺的地方,是把“工程师该干什么、agent 该干什么”这条分工线画明白了。工程师定目标和系统边界,搭反馈环境,审高风险改动;agent 在分层验证体系里自己跑假设和代码变更。这和 Elastic 的 atune、DeepMind 的 AlphaEvolve 思路一致,都是把性能分析工具提供的“梯度信息”看得比最终判决更重。还缺什么?缺这套方法在不同模型、不同芯片集群上的可迁移性验证,也缺更长期的稳定性数据——两周跑通到生产就绪,但跑一个月后会不会出现新的长尾故障,正文没提。