AWS 于 2026 年 9 月 18 日介绍新 AgentCore 运行时，重点包括内存回收和更稳定的启动表现。官方同时区分了运行时启动耗时与 Agent 实际执行工作的耗时。企业验收时也应采用这种拆分，避免把启动优化直接等同于整项工作提速。AWS 官方公告
用户等待的组成
一项任务可能先排队，再启动环境，随后查询资料、调用模型和业务接口，最后生成文件。每个阶段记录时间，才能判断优化应该落在哪里。
| 阶段 | 记录内容 | 可能的影响因素 |
|---|---|---|
| 排队 | 请求到获得执行机会 | 并发与额度 |
| 环境启动 | 可执行环境准备完成 | 镜像、初始化、资源 |
| 模型调用 | 首次输出与完整输出 | 输入长度、模型、限流 |
| 工具调用 | 接口与文件操作 | 业务系统、网络、资料量 |
| 任务完成 | 结果保存并可核对 | 重试、确认、产物生成 |
界面第一次显示文字，可以改善等待感受，但不能替代任务完成时间。需要同时记录“开始回应”和“完成可用成果”两个指标。
真实任务的选择
测试至少包含短查询、多资料分析、文件生成和一次需要补充信息的多轮任务。纯回声接口有助于观察平台本身，却无法代表实际 Agent 的工作过程。
每个样本固定输入资料和目标结果。比较新旧环境时，保持模型、工具与业务条件一致。若同时换了模型和知识库，就不能把所有变化归因于运行时升级。
并发与等待分布
记录典型请求和高峰请求的等待差异。平均耗时下降时，仍可能有少数任务持续卡住；应查看等待较长的样本、失败比例及其原因。
并发测试使用真实工作组合，并遵守外部系统限额。业务接口被限流后增加 Agent 并发，可能只会制造更多重试。先确认限制所在，再选择排队、减少重复查询或申请容量调整。
长任务的内存与文件
文件处理完成后，观察内存是否释放以及费用如何变化。但降低内存占用不能以丢失必要工作状态为代价。后续继续任务时，应能够找到原始资料、中间成果和已完成步骤。
环境重建或任务恢复后，核对数据库连接、临时凭据和文件访问是否仍有效。写入操作需关联稳定请求编号，避免恢复时把已执行步骤再做一次。运行环境快照也不能替代业务数据备份。
费用与交付结果
按完整任务统计计算、模型、存储和外部服务费用，失败与重试也计入。不同任务类型分别看分布，避免大量便宜短问答掩盖少量昂贵长任务。
最终报告说明任务是否完成、结果是否正确、人工介入多少，以及用户实际等待多久。厂商基准用于理解产品设计，采购和上线依据应来自组织自己的样本。版本升级后优先复测过去出现过的慢任务和恢复失败案例。
测试报告还应说明哪些任务使用已有会话，哪些任务需要新建环境。把这两类混在一起，会掩盖启动差异。对于需要人工确认后继续的流程，单独测量暂停、恢复与最终完成，并检查等待期间的资源计费及授权是否仍有效。
执行环境可结合云栖大会计算选型与ACS 文件隔离比较，具体业务验收见企业 Agent 落地。
