# Feedback Engineering：agent 自动化工程卡在哪，卡多久

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-09-20T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/57868
- 原文：https://yage.ai/share/feedback-engineering-20260920.html

## 摘要

Z.ai 复盘了用 GLM-5.3 驱动的 Infra Agent 在国产芯片集群上部署推理服务的经历。核心发现是：只给 agent 一个端到端性能总分，它就会陷入盲猜循环，根本不知道代码坏在哪。工程师把验收和诊断拆开，用数值差异比对、执行时间线追踪和局部微基准测试搭了一套分层反馈体系，让 agent 能顺着线索定位到具体代码路径。文章用三个真实故障案...

## 推荐理由

Z.ai 用 GLM-5.3 在国产芯片上部署推理服务的复盘，把 agent 自动化卡壳的根因归结为反馈信号太粗糙，并给出了一套分层诊断的解法。概念新鲜、痛点尖锐，三个真实故障案例让方法论落地。分数没给更高是因为正文对部分技术细节（比如微基准测试的具体指标）展开不够，但整体对 agent 工程实践者很有参考价值。

## 锐评

Z.ai 这篇复盘的价值不在跑分，在于把 agent 工程化中“卡在哪”的问题拆清楚了。核心判断很朴素：优化之前先测量，这个原则对 AI 比对人更致命，因为 agent 完全依赖环境递给它的信息。文章用三个真实故障把分层反馈的链条跑通了——精度丢失靠数值差异比对定位到 TF32 模式，GIL 争用靠时间线追踪发现传输与计算从未重叠，算子冗余计算靠微基准测试揪出重复执行四次的门控计算。每个案例都走了“定目标、看现象、提假设、修复、验证”的完整闭环，不是纸上谈兵。

但有几个信息缺口得说清楚。第一，端到端吞吐达到约 3 倍基线，厂商自述这是多项技术组合的结果，且没有做消融实验来剥离诊断反馈的单独贡献，所以不能直接把 3 倍全算在 feedback engineering 头上。第二，GIL 争用那个案例，DeepEP 社区早在 2025 年 5 月就有相关 PR，智能体的贡献是在特定集群上完成本地定位和迁移，不是首次发现。第三，KDA 精度修复那条路径默认关闭，管的是算得对不是跑得快，不能计入性能账。

这篇文章真正稀缺的地方，是把“工程师该干什么、agent 该干什么”这条分工线画明白了。工程师定目标和系统边界，搭反馈环境，审高风险改动；agent 在分层验证体系里自己跑假设和代码变更。这和 Elastic 的 atune、DeepMind 的 AlphaEvolve 思路一致，都是把性能分析工具提供的“梯度信息”看得比最终判决更重。还缺什么？缺这套方法在不同模型、不同芯片集群上的可迁移性验证，也缺更长期的稳定性数据——两周跑通到生产就绪，但跑一个月后会不会出现新的长尾故障，正文没提。