英特尔10月6日介绍了一组智能体工作流性能测试，采用记录后重放的方法，尽量让不同平台处理相同任务轨迹。测试关注一段时间内完成的工作量。厂商给出的比较结果有明确测试条件，不代表任意模型、工具和业务环境都会获得同样表现。
围绕AI硬件的讨论经常使用每秒生成多少文本作为指标，但智能体可能还要检索资料、转换文件、运行程序和核对结果。从应用评估角度看，模型响应速度和任务完成速度应分别观察。
回答快，不一定把事情做得快
设想一个采购分析助手，收到问题后先下载资料，再整理格式、计算差异，最后撰写说明。如果资料下载和计算占据大部分时间，模型快一点，对最终完成时刻的影响可能有限。相反，工具执行或数据访问得到改善，用户可能更早拿到完整结果。
这种差异并不意味着模型推理不重要，而是说明评估对象发生了变化。只测试其中一个组件，无法回答整套应用能同时服务多少用户，更难预测业务高峰时会在哪个环节排队。
重放测试帮助比较，也有适用范围
固定执行轨迹有一个直接好处：不同平台不会因为模型临时选择了不同工具，而承担完全不同的工作。这样比较出来的差异，更容易用于定位基础设施问题。
但真实用户的请求不会永远重复。模型升级、文档长度变化、工具出错，都可能改变执行路径。因此，固定轨迹适合作为基线，还应搭配开放请求和异常场景测试，观察系统在变化条件下的表现。
统计完成量时，别把失败也算进去
任务吞吐量需要先定义什么叫完成。一份报告生成出来，却遗漏关键表格，不能与正确交付同等计算；某个流程提前退出，耗时虽短，也不能被当作性能提升。比较时应同时统计成功率、重试次数和输出质量。
还要防止用无限增加并发的方式换取漂亮数字。并发提高后，总完成量可能上升，但单个用户的等待也可能变长。合适的测试应该在可接受的响应范围内，看系统能持续处理多少有效任务。
CPU、内存和输入输出要一起看
实际排查可以先绘制任务时间线，标出处理器忙碌、等待数据和等待外部服务的区间。CPU利用率不高时，不应立即认定算力充足，也可能是请求被存储或网络阻塞。内存不足引起的额外数据交换，同样会影响执行节奏。
这类分析有助于避免只升级最显眼的硬件。例如，增加处理器核心后，如果文件读取仍然串行，应用未必获得预期改善。先找出限制完成速度的环节，再调整资源，更容易验证投入效果。
英特尔的这次讨论提示了一个实用方向：评估智能体服务器时，把规格表延伸到业务流程。系统最终应交付的是可用结果，而每个环节的等待、失败和重试，都应进入同一份性能账本。