AWS 的多 Agent 评测:局部表现不错,任务为何仍会失败?

作者关注的问题是：企业让 AI 执行的工作，已经从回答问题变成查询数据、调用工具、协调多个步骤。回答即使流畅，也不能说明它选对了工具、遵守了业务限制，或给出一份能够执行的方案。团队还需要知道建议依据什么，以及多个助手给出的结果能否彼此配合。原文因此把通用回答质量、业务规则和可解释性分别纳入检查。〔1〕

整篇博文以零售供应链为背景，先介绍协调者与各个专职助手的分工，再配置通用和业务专用的评分，沿着一次备货建议演示怎样读取执行记录、运行评测、理解结果。它也说明开发期间按需评测与上线后持续评测的用途；文中实际带读者操作的是按需模式。这里使用虚构公司，优化接口采用模拟返回，应当作为方法和工程实现的示范来读。〔1〕

下文保留这条供应链主线：先讲规划人员需要什么建议，再看预算、需求和仓库容量怎样变成检查条件，最后讨论局部通过与整体可用的区别。原文里多个评分之所以有必要，只有放回这项工作中才容易理解。

AWS 的这篇博文用虚构零售公司 AnyCompany Retail 展示多 Agent 供应链方案。规划人员提出需求，由一个协调 Agent 分派工作，专职 Agent 分别处理库存优化、库存调拨、配送路线和数据分析。优化接口使用模拟返回，整个方案是参考实现。〔1〕

这里的 Agent，可以理解成能够按要求调用工具、查询信息并组织结果的 AI 助手。多 Agent 则把一项复杂工作交给多个助手分工，再由协调者汇总。

这些分工对应的业务问题并不相同：

规划人员最后需要的是能够支持决策的建议。不同助手各自给出一段流畅回答，还不足以证明组合后的建议满足业务要求。

原文具体走了一遍优化 Agent 的评测：询问某个产品未来 30 天的合适库存水平。系统取得需求预测，调用工具形成建议，再保存这次交互的记录用于评分。〔1〕

接下来，作者检查三个明确的业务条件：新增持有成本是否在剩余预算内；库存是否至少覆盖预测需求、又不过度超过需求；建议数量是否放得进仓库。示例将库存上限设为预测需求的两倍。〔1〕

先知道这些条件，才能判断建议好在哪里。一个回答即使切题、完整，也可能建议了仓库根本放不下的数量。这里的问题出在方案的业务有效性，继续润色解释并不能让仓库多出空间。

相反，数量满足条件，也还可以继续检查：规划人员是否知道这个数量为什么成立、哪些限制影响了取舍。

原文为解释这种区别，举了一组数字：预测需求 1,200 件，按 1.25 倍形成 1,500 件建议；预算允许最多 1,800 件，仓容允许最多 1,600 件。它们是说明性数字，不是这次评测运行后报告的实测成绩。〔1〕

读者现在可以自己核对：1,500 件覆盖了预测需求，也没有超出两倍需求；它低于示例给出的预算和仓容上限。但还要检查建议是否讲清需求依据，以及最终选择怎样受到这些限制影响。不能只因为出现了一个库存数字，就认为业务和解释两项都通过。

在这份参考方案中，AWS 将一般质量、业务准确性和可解释性分开检查。〔1〕

一般质量先检查回答是否有帮助、是否回应了问题等通用要求。它适合发现偏题、没有提供可用信息等表现。

业务准确性加入当前场景的具体规则。对备货建议来说，预算、需求覆盖和仓储容量都需要被满足。

可解释性继续检查建议是否说明依据，例如引用了哪些工具数据、哪些约束影响了决定。它并不与前两层自动等价。

这样，同一条建议可能出现不同结果：业务条件通过，但理由没有说清；也可能解释听起来完整，建议却违反业务条件。

批注：先区分缺陷，再看分数。业务规则没满足，就调查建议怎样产生；依据没有表达出来，就检查输出怎样交代证据。把这两项混成一个总分，会丢失修复方向。

不同专职助手的评分对象不同。一个负责库存，一个负责路线，它们各自的回答“有帮助”，并没有直接检查两份建议合起来是否相容。

原文因此也为协调 Agent 设置了方案一致性检查，关注能否把子 Agent 输出组合为有效、没有矛盾的建议。〔1〕

这一步可以从分工本身理解：局部任务的完成条件，只覆盖各自负责的范围。最终方案还要核对它实际采用了哪些输出，以及共同条件有没有保持一致。

用同一供应链场景作一个解释性例子：这批货约定周三前到达，调拨计划按这个时间安排，路线方案却预计周四才能送到。两位助手都给了计划，交付时间却没有对齐。

协调者若原样合并，就没有形成可执行的整体方案。此时需要回查调拨与路线使用的交付期限，以及协调者怎样处理冲突。即使两段回答都被评价为有帮助，日期冲突仍然存在。这个例子用于说明原文的整体一致性检查，不是原文报告过的事故。

多 Agent 的评测因而需要同时保留两种观察：某个助手具体做得怎样，以及它的输出进入整体以后是否仍支持最终任务。

AWS 文档把相关交互分组称为 session，把一次执行记录称为 trace。可以把前者理解成相关交互的集合，把后者理解成其中一次执行留下的记录。〔2〕

这里说的裁判，就是读取记录、按指定标准给出评价的评测器。

不同评测器读取的范围也不同。官方模板中，目标完成度检查会话，有帮助程度检查当前回答，工具选择与参数检查则针对工具调用；它们使用的上下文并不完全相同。〔3〕

具体来说，会话级检查可以读取多轮交互；当前回答的检查会使用此前轮次和当前输入、调用等记录。普通工具选择与参数模板通常看到被评调用之前的上下文，用来判断当时的选择与参数是否合适。不能把这个分数直接理解为工具执行后的业务状态也已经核验。〔3〕

所以，一个备货回答得到较好的帮助度评价，只能先按这个评分的对象和标准理解。它没有自动证明其他助手的输出、完整协作过程和所有业务条件都通过了检查。

如果关键工具返回没有进入裁判可见记录，评分也就缺少相应证据。此时需要先检查采集与输入范围，不能单靠一个高分填补记录缺口。

解释性评分也有边界：它可以检查回答是否给出了依据、依据是否对应可见数据；这不等于已经读取并验证模型内部的真实思考。

AWS 的演示先运行优化问题，留下会话标识，再针对这批记录运行业务条件和解释性检查。读者因此能把不同评分对应到同一次工作，而不必拿几次不同的演示互相替代。〔1〕

博文与在线评测文档还说明，可以指定数据来源、评测器等配置，在运行中继续观察质量；博文同时介绍了采样方式。采用抽样时，结果对应被抽取的记录，不能当作所有线上任务都已检查。〔1〕〔4〕

如果某项检查失败，应先回到它评价的那份记录：业务条件没满足，就调查建议和工具数据；说明缺少依据，就检查证据是否进入记录及回答。修改之后产生新的执行，再接受同样检查，才能观察问题是否改善。这里是对这组评测机制的使用解释，不是原文报告过的修复实验。

回到规划人员的备货需求，完整理解这篇博文，需要把几个问题分开：是否回应了备货问题，建议是否满足业务条件，依据是否说得清楚，以及多个助手的输出能否合成有效方案。

知道每个分数在回答哪一个问题，才能看出“局部不错”究竟覆盖了什么，以及整体任务还有哪些地方需要核验。

〔1〕Kanishk Mahajan：Evaluating multi-agent systems for explainability and helpfulness with Amazon Bedrock AgentCore，2026-10-05。本文使用虚构零售公司、角色分工、备货检查和分层评测的参考方案。

https://aws.amazon.com/blogs/machine-learning/evaluating-multi-agent-systems-for-explainability-and-helpfulness-with-amazon-bedrock-agentcore/

〔2〕AWS：Evaluation terminology。本文使用 session 与 trace 的定义。

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations-terminology.html

〔3〕AWS：Prompt templates。本文使用评分对象与可见上下文的区分。

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/prompt-templates-builtin.html

〔4〕AWS：Online evaluation。本文使用运行时采样评测的配置范围。

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/online-evaluations.html