Amazon AWS 通过 Strands 和 AgentCore 将智能体评估变为生产准入门槛

Amazon AWS 与 Motorway 建立了一套评估流程，将智能体错误结果从每八次查询一次降至每 50 次查询一次。两家公司称，该系统还将问题发现时间从数小时缩短至数分钟。

这些改进并非来自简单替换底层模型。Motorway 改变的是其经销商库存搜索智能体的测试、发布和监控方式。这套流程结合了 Strands Agents SDK 与 Amazon Bedrock AgentCore Evaluations，覆盖开发和生产阶段。

这一区别至关重要，因为流畅的回答可能掩盖错误操作。智能体可能在选错工具、传入错误参数或遗漏先前约束后，仍给出一份看似可信的车辆列表。传统软件测试很少能覆盖所有有效回答，而人工审查发现故障的速度又太慢。

Motorway 的案例将智能体评估从最终质量检查转变为一个运行闭环。Strands 在部署前测试受控场景；AgentCore 在部署后对抽样的生产追踪记录评分；发现的失败案例随后会成为下一次发布的新回归测试用例。

这一结果给仍以演示、汇总用户评分或少量脚本化提示词来评判智能体的团队带来压力。它也为 AWS 提出了一个更棘手的问题：买方应在多大程度上信任那些往往依赖另一种语言模型的评估？

Amazon AWS 将评估纳入发布流程

关键变化不在于新增一张评分卡。评估如今决定智能体能否进入生产环境，以及团队之后能多快发现回归问题。

Motorway 运营着一个连接车辆卖家与专业经销商的在线市场。其经销商库存搜索智能体处理涉及车辆属性、地理位置、里程、价格及其他限制条件的自然语言请求。

一个请求表面上可能成功，实际操作却仍然有误。智能体可能搜索了错误的库存来源、遗漏某个筛选条件，或向工具传入格式错误的值。其最终回复可能依旧足够精致，以至于用户和基础文本检查都无法立刻发现问题。

Motorway 与 AWS 通过三层评估模型弥补了这一缺口。第一层检查工具选择和参数；第二层审视智能体的推理轨迹，即回答背后的决策与工具调用序列；第三层评估最终输出的质量及其是否符合政策要求。

这种分离很重要，因为可接受的回复并不能证明智能体走过了一条安全且可复现的路径。一次侥幸得出的正确答案可能掩盖糟糕的轨迹。反过来，智能体也可能选对工具，却生成令人困惑的最终回复。

AWS 报告称，Motorway 的工具选择准确率从 87% 提升至 98%。任务完成率从 82% 升至 96%，而多轮上下文保留率从 71% 提高至 94%。

每月生产事故从 12 起降至两起。平均检测时间从数小时缩短到数分钟。AWS 表示，经销商如今可在数分钟内完成车辆搜索，而此前这一过程需要数小时。

这些是来自一次部署的公司自报结果，并非独立的行业基准。不过，这些指标说明了为何智能体团队需要的不只是单一准确率数字。

该架构为不同故障类别设定不同阈值。AWS 在其生产蓝图中建议：工具使用率高于 95%、推理质量高于 85%、输出质量高于 90%。

低于这些门槛的构建版本不会继续推进。这使评估成为发布控制的一部分，类似集成测试或安全检查。随后，生产监控会检验获批行为在面对真实用户时是否依然成立。

这也构成了本文的核心张力。智能体评估承诺带来可量化的可靠性，但最有价值的行为并不总能用确定性断言来验证。因此，该流程将精确检查与概率性评判相结合。

为什么智能体可靠性正在给生产团队施压

智能体团队如今要对决策和行动负责，而不只是对生成文本负责，这使传统模型测试显得不够完整。

聊天机器人通常返回供人审核的文本。智能体则可以检索记录、调用业务系统、修改数据，或触发其他工作流。运营风险由不够完美的句子转变为错误的操作。

这一变化给工程负责人、产品负责人和企业买方带来压力。他们需要知道智能体是否选择了正确工具、提供了有效参数、遵循了先前指令，并完成了预期任务。

单一平均分无法回答这些问题。两个发布版本的输出质量评分可能相同，但工具行为却截然不同。一个可能只是在措辞上无害地出错，另一个则可能检索到过期或无关的记录。

非确定性进一步加剧了问题。语言模型可能针对相同请求产生不同路径。一次测试通过，并不能证明智能体会重复得到同样结果。

AWS 通过 pass^k 这一可靠性指标强调了这个问题：它询问任务在重复试验中能否持续成功。如果一项任务的成功率为 75%，那么连续三次成功的概率仅约为 42%。

这一计算改变了团队解读演示的方式。一次成功的演示只能证明系统能够完成一项任务，并不能说明它足够稳定地完成该任务以投入生产。

多轮对话会让挑战进一步扩大。用户可能先请求电动车，然后按距离缩小结果范围，之后再要求只显示近期发布的房源。智能体必须保留相关上下文，同时不能继续沿用用户已撤销的限制条件。

Strands Evals 将此视为会话问题，而非孤立的提示词评分。其评估器可以检查输出、轨迹、单个工具调用以及完整对话。该框架的评估指南还建议跟踪准确率、任务完成率、响应时间、幻觉、Token 使用量和用户满意度。

生产团队也面临组织层面的压力。一次智能体故障可能跨越应用、模型、数据和基础设施边界。产品经理看到的是错误结果，而根本原因可能是提示词变更、工具架构、过期索引、超时或模型更新。

没有追踪记录时，团队只能争论可见的回答。有了结构化追踪记录，他们就可以检查哪些工具可用、智能体选择了什么、发送了哪些参数，以及每一步如何促成最终回复。

这正是评估与可观测性必须协同工作的原因。评估决定行为是否达到既定标准；可观测性记录理解其通过或失败原因所需的证据。

Motorway 的结果表明，这种组合方法可以缩短检测时间。但这并不能证明每个组织都能获得同样的改善。收益取决于追踪质量、评估设计、流量模式，以及失败评分所对应的后果。

不过，举证责任已经转移。将智能体部署到客户工作流中的团队，越来越需要可重复的证据，而不是一组颇具说服力的对话记录。

Strands 与 AgentCore 的机制如何运作

Strands 在发布前处理受控评估，而 AgentCore 则将相同的质量模型扩展到抽样的生产流量中。

Strands Agents SDK 提供了用于构建和埋点智能体的框架。Strands Evals 将测试组织为案例、实验、任务函数和评估器。

一个案例定义一个场景，包括输入以及任何预期输出或工具轨迹。一个实验将多个案例分组，并运行一个或多个评估器。任务函数则将这些案例连接到实时智能体或先前捕获的执行数据。

这一结构支持两种测试模式。在线测试在评估运行期间调用智能体，适用于开发和持续集成。离线测试则评估已记录的追踪记录，有助于比较不同版本或研究历史生产行为。

Motorway 的流程从精选场景开始，这些场景代表常见的经销商搜索以及已知边界情况。每次运行都会捕获智能体的回复及其生成回复所走的路径。

工具层会询问智能体是否选择了正确能力，并提供了合适参数。这一层可以发现被发送到错误数据源的搜索请求，或以无效格式表示的筛选条件。

推理层审查轨迹。它会审视完整序列中的决策是否连贯，而不是孤立地判断一次工具调用。当一个有效结果需要多个相互依赖的操作时，这一点尤为重要。

输出层为呈现给用户的回复评分。它可以评估相关性、完整性、安全性和依据性等质量。这一最终层仍然不可或缺，因为正确的内部执行仍可能产生不清晰的回答。

这些开发检查充当发布门槛。团队可以将拟议的模型、提示词、工具定义或编排变更，与既定测试集进行比较。回归问题会在客户遇到之前阻止版本晋级。

部署后，AgentCore Evaluations 会读取 OpenTelemetry 追踪记录。OpenTelemetry 是一种用于记录分布式应用程序操作的开放标准。其生成式 AI 约定可以捕获提示词、补全内容、模型设置、工具调用及相关执行细节。

这种通用追踪格式降低了对单一智能体框架的依赖。AWS 文档称，AgentCore 支持通过 OpenTelemetry 或 OpenInference 埋点的 Strands 和 LangGraph 智能体。

AgentCore 提供按需评估和在线评估。按需评估会在开发和发布测试期间为选定追踪记录或会话评分。在线评估则对实时流量进行抽样，并将结果发送至监控工作流。

该服务可应用内置评估器、自定义语言模型评判器、真实答案对比，或基于 Lambda 的代码评估器。AgentCore 文档称，追踪记录会在评分前转换为统一格式。

语言模型评判器可处理难以精确匹配的质量维度。它们可以评估一个回答是否满足用户目标，或是否忠实于可用上下文。

代码评估器则处理确定性要求。一个函数可以验证精确标识符、必填字段、参数范围或响应架构。与要求另一个模型检查精确值相比，这种方式通常更可预测。

随后，该流程会将评分导入 CloudWatch 仪表板和告警系统。质量下降可能会创建事故、触发人工审查，或为回滚流程提供依据。

AWS 建议以 1% 的采样率开始生产监控。在了解评估器成本、延迟和信号质量后，团队可以提高覆盖率。即使语言模型评估仍采用抽样方式，高风险操作也可能需要更广泛的确定性检查。

生产故障会回流到开发套件中。一个罕见的经销商表述、超时模式或意外的后续追问，都会成为新的案例。因此，测试集会基于真实行为不断增长，而不是停留在一组静态的合成提示词上。

这一反馈闭环正是报告中性能提升背后的机制。没有任何单一评估器能够带来可靠性。可靠性来自于持续将观察到的失败转化为可衡量的发布标准。

真正的较量是证据与直觉之争

Motorway 的流程挑战了智能体开发中一种常见习惯：凭感觉修改提示词，再用少量有利示例验证结果。

提示词迭代速度很快，这也容易催生非正式的审查方式。开发者发现一个较弱的回答后，调整指令，测试几个提示词，然后发布看似有所改善的版本。

这一过程或许能修复眼前的案例，却可能损害另一项行为表现。更严格的指令可能改善工具选择，却降低任务完成率。更长的提示词可能保留更多上下文，但也会增加延迟，或鼓励不必要的调用。

因此，Amazon AWS 蓝图的主要对手并非另一家云服务提供商，而是以直觉驱动的智能体开发模式：团队缺少稳定的基线，只能通过客户投诉发现回归问题。

Strands 实验提供了受控的比较方式。团队可针对两个版本运行相同案例，并按评估层级检查变化。这样能在发布前让权衡取舍清晰可见。

AgentCore 将这种比较延伸至生产环境。真实用户会带来术语、信息不完整的请求、彼此冲突的约束条件和时序状况，而这些通常难以被精心整理的数据集覆盖。影子评估可以在不立即改变面向用户系统的情况下，对这些交互进行评分。

这一模式在一个重要方面类似成熟的软件交付流程：质量标准变得可执行、可重复。不过，智能体评估不能简单照搬单元测试实践，因为可能存在许多有效的输出。

传统断言可以验证函数是否返回特定值。智能体评估器则往往需要判断一项回答是否足够有帮助、是否有依据、是否完整。这些标准涉及解释与判断。

该流程通过根据所验证的主张选择评估器来解决这一冲突。精确的数据和格式规则交给代码处理；语义质量交给语言模型评审；工具调用路径则可采用预期轨迹、上下文判断，或两者结合。

这一区别应当影响采购决策。只报告一个综合质量分数的平台，可能掩盖具体发生变化的失败类别。企业买家应询问，是否能够在工具、追踪和会话层级查看分数。

他们还应询问，评估是否能够跨环境跟随应用运行。一个在部署后便消失的开发基准，无法检测由生产数据或用户行为模式引发的行为变化。

AWS 将 AgentCore 定位为保障这种连续性的托管层。根据其评估概览，该服务负责管理评估模型、推理基础设施、数据处理和扩展能力。

这种安排减少了基础设施工作，但也加深了对 AWS 服务在评估、遥测、仪表盘和部署控制方面的依赖。已经在 AWS 上运行的团队可能会将这种集成视为优势。

具有多云要求的组织则需要考察可移植性。OpenTelemetry 提供了可迁移的追踪格式，但仪表盘、评估器配置、IAM 策略和自动化响应仍可能具有平台特定性。

开放框架提供了另一条路径。LangSmith、Arize Phoenix、Braintrust 及其他智能体可观测性系统同样整合了追踪、数据集、实验和评估器。有意义的比较不在于可用评审器的数量。

更好的问题是，一个系统能否将生产故障与可复现测试及发布决策连接起来。Motorway 部署声称改善的，正是这一闭环。

团队还需要严谨的运营知识管理。评估发现、事故说明和领域规则，如果工程师能在追踪记录和测试案例旁检索到它们，就会更有价值。可检索的工程知识库能够在不同发布版本之间保留这些上下文。

报告中的准确率提升并不能证明什么

报告中的改进具有意义，但并不能消除评审器方差、抽样缺口、基准偏差或平台依赖。

第一项局限在于归因。Motorway 引入评估流程后报告了更好的表现，但公开结果并未拆分说明：提升中有多少来自新增测试、提示词调整、工具修复、运营关注，或 AgentCore 本身。

第二项局限在于基准构建。评估套件反映的是团队选择纳入的场景。如果案例未充分涵盖模糊语言、罕见库存状态或异常对话路径，即使通过率很高，覆盖度仍可能不足。

生产反馈可降低这一风险，但无法彻底消除。用户可能在一次失败交互后直接放弃，而不报告问题。组织随后需要通过搜索细化或任务放弃等业务信号来发现隐藏故障。

第三项局限在于抽样。1% 的监控比例能够控制评估开支，但不常见的故障可能逃过观察。抽样策略应反映流量规模和后果，而不应只遵循一个通用的起始百分比。

第四项局限在于评审器可靠性。LLM-as-a-judge 使用语言模型依据评分规则来评估另一个模型的行为。它可能引入位置偏差、评分不一致，或与回答风格相关的偏好。

详细的解释并不保证判断正确。团队应以人工审核的案例校准模型评审器，并定期测量一致性。重复评估可揭示单一分数所掩盖的方差。

评分规则也需要版本控制。修改评估器指令可能导致分数变化，即使智能体本身毫无改变。仪表盘应区分产品回归与测量变化。

AWS 在其 AgentOps 指导中承认了这项更广泛的运营负担。推荐模式是在发布前进行按需检查、在部署后实施在线监控。其AgentOps 框架还区分了框架、服务、基础设施和业务遥测。

第五项局限在于指标解读。将工具选择准确率提高到 98% 仍然意味着会有失败。可接受的剩余失败率取决于工具具体执行的操作。

遗漏车辆筛选条件会带来糟糕的搜索体验。涉及付款、医疗记录或访问策略的错误操作则承载着不同的风险。团队应围绕后果设定阈值，而不是原样照搬 Motorway 的目标。

上下文保留同样需要谨慎定义。AWS 报告该指标从 71% 提升至 94%，但公开摘要没有提供足够细节，无法将该分数与另一家公司的基准进行比较。

第六项局限在于评估器相关性。多个评审器可能奖励相同的表面质量，却共同遗漏同一个盲点。AWS 建议采用不同的标准，使每个评估器覆盖独立的质量维度。

对于高影响故障和存在争议的分数，人工审核仍然重要。人可以识别评分规则是否真正代表业务需求，而这并非自动化评审器能够独立决定。

最后一项局限涉及激励机制。一旦某项指标成为部署门槛，团队就可能针对测试套件进行优化。生产案例、轮换挑战集和保留评估有助于防止系统只在熟悉提示词上取得改善。

这些问题都不会使 Motorway 的结果失效。它们界定了负责任地解读这些结果所需的条件。评估是一套测量系统，而测量系统本身也需要测试。

Amazon AWS 蓝图之后值得关注的事项

下一项检验是，这一流程能否在新的智能体版本、真实流量增长和评估成本压力下保持其收益。

第一个信号是 Motorway 的事故趋势。报告中称，每月事故数量从 12 起降至两起，这构成了一个基线。若表现能够持续，将支持持续评估确实能发现回归问题、而非只完成一次性清理工作的说法。

这些事故的构成与数量同样重要。如果剩余失败集中在未见过的语言或多轮上下文中，Motorway 可以扩展其案例与评审器。反复出现的工具或参数错误则会削弱人们对发布门槛的信心。

第二个信号是新模型和提示词下的 pass^k 表现。团队应观察，当 Motorway 更换模型版本、工具模式或编排逻辑时，多次运行的可靠性是否仍保持稳定。

一次发布可能提高平均准确率，却降低一致性。报告重复试验的成功率，比单一通过率更能清晰揭示这一差异。

第三个信号是生产抽样范围的扩大。AWS 建议从 1% 开始，再逐步扩展。若能在不产生难以控制的评审器开支的情况下扩大覆盖范围，将加强托管服务的论点。

关注组织是否将抽样语义判断与覆盖更广的基于代码的检查结合起来。这种混合设计可以将语言模型留给模糊的质量问题，同时对每一项关键操作实施确定性验证。

AgentCore 在 Strands 之外的采用情况，也将检验其基于追踪的架构价值。对标准 OpenTelemetry 数据的支持，只有在团队能够迁移智能体并保留有用的评估历史时才真正重要。

更大的教训已经很清晰。生产级智能体需要一个在发布前开始、并在用户到来后持续运行的质量闭环。测试、追踪、告警、事故分析和新的回归案例应构成一个相互连接的流程。

对开发者而言，实际行动是选择一个高价值工作流，并在选择评估器前定义其失败模式。分别追踪工具选择、参数、任务完成、上下文、延迟和最终输出。然后在多次试验中重复运行相同案例。

企业买家应在智能体评审期间索取这些证据。询问哪些行为会阻止部署、如何对生产流量进行抽样、谁来验证评审器准确性，以及故障如何转化为未来测试。

知识工作者同样应当关注，因为这些控制措施决定了智能体是否能被信赖以处理重要工作。在评估 Amazon AWS 智能体部署时，不要只看流畅的回答。应要求查看其背后的追踪记录、重复运行结果和生产反馈闭环。