用Blame图在OpenSearch上追踪多Agent级联决策失败
译文 AI 逐段翻译
使用亚马逊 OpenSearch Service 上的责任图追踪级联决策故障
多智能体系统易于构建，但难以调试。你将几个智能体串联起来，每个智能体各司其职，大多数情况下系统都能正常工作。一旦出错，你面对的是海量日志。日志告诉你每个智能体说了什么，却无法告诉你是哪个智能体导致了不良结果。
在与构建多智能体系统的 AWS 客户合作时，我们反复遇到同样的问题。一个智能体管道做出决策，结果证明是错的，却没人能指出是哪个智能体造成的。日志虽完整，却无法回答这个问题。因此，我们两位 AWS 解决方案架构师构建了一个股票研究管道来重现问题，并展示一种解决方案。
五个智能体按顺序工作，最后一个发出买入、卖出或持有信号。在我们的测试用例中，该智能体持续建议买入，而持仓持续亏损。每一步都有日志记录，但日志仍然无法告诉我们是谁破坏了管道。
在本文中，我们将展示如何构建一个责任图，利用Amazon OpenSearch Service进行图存储，并利用Amazon Bedrock进行嵌入和推理，从而追踪多智能体管道中哪个智能体导致了故障。
前提条件
要跟随本文进行操作，你必须具备以下前提条件。
- 五智能体管道。
- 插桩层。
- AWS CloudFormation 模板。
- OpenSearch UI 仪表板导出
- 示例数据。
- 分步设置说明（README.md、DEPLOYMENT.md）。
一个 AWS 账户，具有访问 Amazon Bedrock（在 us-west-2 启用了 Anthropic Claude Sonnet 4.5 和 Amazon Titan Text Embeddings V2）的权限。一个 OpenSearch Service 域。Python 3.11 或更高版本。AWS 命令行界面（AWS CLI）v2配置了有效凭证。
挑战
该管道是一条由五个智能体组成的链。一个研究员收集事实，一个风险分析师评估下行风险，一个估值分析师计算数字，一个宏观经济学家设定市场背景。每个智能体都基于前面智能体的输出。最后，策略师（AI 智能体）将所有这些整合成一个单一信号：买入、卖出或持有。
我们设置了三种故障，每种都是生产环境中常见的智能体部署模式（来自检索的幻觉事实、被压制的少数派信号、来自延迟摄取的数据过期）：
- 一个幻觉。 研究员捏造了一个不存在的公司合作关系。
- 一个被埋没的警告。 风险分析师标记了一个监管风险，但被否决了。
- 数据过期。 研究员遗漏了一份三天前发布的文件。
我们确定性地设计了每种故障，使演示可重现且答案已知。对于每个场景，我们手工编写了五个智能体的输出作为固定的 JavaScript 对象表示法（JSON）。管道重放这些输出，同时插桩实时计算嵌入、影响和责任。我们记录了每种场景的真实根因（例如，幻觉的研究员）。
在每种情况下，管道都建议买入，而持仓下跌。标准日志记录了每个智能体的输出，但它无法告诉你哪个声明驱动了最终决策。缩小日志与根因归属之间的差距正是我们着手要解决的问题。
解决方案
我们将智能体推理视为一张图，并衡量智能体之间的影响，然后从失败的决策开始沿图向后遍历，以找到根因。
以下三项服务构成整个技术栈：
- Strands Agents 运行五智能体管道。
- Amazon Bedrock提供模型：Amazon Titan Text Embeddings V2 为每个声明生成嵌入，Anthropic Claude Sonnet 4.5 用于智能体推理和事件报告撰写。
- 一个OpenSearch UI 应用，这是一个在 AWS 云中托管的、拥有单一端点的分析界面，它作为数据源连接到域，并提供我们用于调查的仪表板、Discover 和 Dev Tools 控制台。
以下是责任归属的工作原理。每个智能体做出的每条声明都成为一个带有 Amazon Titan 嵌入的文档。当下游智能体引用某些内容时，我们计算该引用与每个上游声明之间的余弦相似度。余弦相似度成为某个智能体对另一个智能体的影响。
我们将这些存储为边。为了找到根因，我们从失败的决策开始，沿边向后遍历。贡献最大的智能体承担最多的责任。
除了图之外，我们每次运行还记录三件事：决策在多大程度上可追溯到证据的可解释性得分、归属的置信度，以及持异议的智能体是否被否决。
关于方法的一个说明：目前对于多智能体大语言模型（LLM）管道中的根因归属，尚无行业标准。我们的方法结合了两个已有的理念：信用分配（将结果归因于产生它的步骤）和嵌入相似度 用于追踪声明的传播，并辅以 LLM 作为评判者的风格检查。本文中的指标（影响、可解释性）是我们定义的实用、可重现的度量，而非标准化基准。
架构
流程包含五个部分：
- 智能体在 Strands Agents 上运行，推理基于 Claude Sonnet 4.5。
- 插桩层提取每个声明，使用 Amazon Titan Text Embeddings V2 嵌入，通过余弦相似度计算影响，执行反向遍历，并生成事件报告。
- Amazon OpenSearch Service 保存七个索引，包括带有 k-最近邻（kNN）向量的声明索引以及责任、指标和事件索引。
- 分析师在 OpenSearch UI 应用中（仪表板、Discover 和 Dev Tools 控制台）查看结果，该应用从 Amazon OpenSearch Service 控制台启动。
- 我们使用 OpenSearch UI 而非域的内置仪表板。由于 OpenSearch UI 托管在 AWS 云中，应用在域维护期间仍可保持可用，并能将多个数据源整合到一个视图中。管道仍然写入域，而 OpenSearch UI 将其作为已注册的数据源读取。
图1a：五代理运行时流水线
图1b：插桩和OpenSearch Service数据平面
走查一次失败
我们在一个运行OpenSearch 2.17的Amazon OpenSearch Service域上运行了该流水线九次，每个场景三次。调查的决策是最终的买入。我们知道它失败了，因为每个场景都带有真实结果：仓位亏损。失败是我们从后往前追溯的已知不良结果，而不是系统推断出的东西。流水线产生的所有内容都是可以查询的文档，因此调查是我们从OpenSearch UI应用程序的Dev Tools控制台运行的一系列查询。
要跟着操作，请从Amazon OpenSearch Service控制台启动OpenSearch UI应用程序，打开您的工作区，然后选择Dev Tools（靠近左侧导航面板底部）。将下面的每个查询粘贴到左侧窗格中，然后选择运行按钮。本节中的每个查询都在仓库中，位于devtools_queries.md，顺序与走查相同，因此您可以从那里复制而不是重新输入。对应的Python查询在queries.py。
从结果开始
每次运行都是买入，每次亏损都是负数，低至72%。标准日志在此停止。您知道它失败了，但您不知道要修复谁。
图2：流水线运行结果：所有九次运行推荐买入，亏损高达72%
接下来，查看谁影响了谁
在所有代理中，研究员产生的边最多。几乎每个下游节点都从研究员获取数据，使其成为第一个要查看的地方。这是一个线索，而不是定论。
图3：按源代理聚合的影响边
查询每个场景的归因指标
归因落在研究员身上，得分约0.45，并且归因在所有三次运行中都是正确的。一个捏造的合作伙伴关系直接导致了最终的买入。过时数据场景表现相同：又是研究员，分数0.46，正确。
图4：幻觉运行的根因归因
以下是Discover中的原始边，按影响从高到低排序
在OpenSearch UI应用程序中，选择Discover并选择agent-blame索引模式，然后将时间范围设置为最近30天并按influence_score降序排序。每一行是一条边——从源代理（source_agent.agent_id）传递给下游代理（target_agent.agent_id）的声明，按其对该代理输出的影响程度打分。顶部的行是影响最大的边：那些最能影响最终买入的边。
图5：按影响得分排序的归因边
当归因困难时
被埋没的警告场景是图出错的场景，也是这篇文章中最有用的结果。
风险分析师是对的。它标记了监管风险。策略师看到了警告，将其权重设为0.15，并且仍然买入。实际上谁失败了？策略师。
但归因图指向风险分析师，在该运行中得分最高，为0.37。为什么？我们的方法衡量影响，异议是一个独特的声明，方法直接追踪它，所以它得分高。影响不同于责任。
为什么策略师忽略它？在场景中，策略师承认了异议，但认为临床数据的强度使该化合物与过去的失败“差异化”。它将看涨证据权重设为0.85，而风险分析师的为0.15。策略师将警告合理化掉，而不是将高置信度、有时限的监管风险视为硬性停止。模型记录了该推理，这正是我们能看到异议如何被折扣的原因。
影响与责任之间的差距正是我们自行跟踪异议的原因。
异议存在，被承认，权重为0.15。标志捕捉到了图遗漏的东西：有效的警告被听到然后被忽略。一个信号是不够的。影响告诉您传播了什么。异议标志告诉您什么被错误地驳回了。您两者都需要。
图6：被抑制的异议检测
查看指标仪表板
OpenSearch UI汇总了所有九次运行。要打开它，请启动OpenSearch UI应用程序，打开您的工作区，然后在左侧导航中选择Dashboards，然后打开Multi-Agent Blame Game — Observability仪表板。将时间范围设置为Last 30 days以查看所有九次运行。如果您还没有导入它，请转到Manage Workspace并选择Import下的Assets。上传blame-game-dashboard.ndjson来自仓库，将索引模式映射到您的域的数据源。
图7：完整的指标仪表板
每个面板都有其价值。有几个值得指出。根因分布将研究员标记了六次，将风险分析师标记了三次。风险分析师的切片是之前的异议错误归因，而不是真正的罪魁祸首。
图8：根因分布
可解释性平均为0.826，这是我们定义的指标，而不是标准分数。
图9：可解释性得分
可预防损失与实际损失的区别，将归因可以归咎于某个代理商的损害与不能归咎于某个代理商的损害区分开来。平均影响力是聚集而不是尖峰，表明没有单一原因。这正是归因求和影响力而不是信任单个边缘的原因。
图10：可预防损失
图11：实际损失
图12：责备与损失表
图13：按来源代理的平均影响力
图14：传播类型分解
交互式探索
对于演示，我们将相同的管道包装在一个小型Streamlit应用中。要运行它，从存储库根目录安装依赖项并启动应用：
source .env
streamlit run src/app.py --server.address localhost它在您的浏览器中打开，地址为http://localhost:8501。它有两种运行方式：选择预先准备的场景并重放，或输入您自己的公司，让五个代理在Amazon Bedrock上实时运行。无论哪种方式，您都可以观看代理执行，形成责备图，并在一个屏幕上显示裁决和事件叙述。历史记录选项卡读取指标索引，因此您无需离开应用即可查看过去的运行。
实时运行没有真实依据，因此应用不声称归因是对还是错。您只会看到影响力落在哪里。预先准备的场景仍然是演示特定已知故障的方式。
图15：Streamlit演示应用
解释每个决策：每个代理权衡的证据
只有您能看到其背后的证据，责备归因才有用。每个代理做出的每个声明都存储有代理分配的置信度和来源。来源包括SEC文件、临床试验注册、FDA页面或收益电话会议。责备分数从来不是一个裸数字。您可以打开任何代理并阅读它在发言之前权衡的确切声明和来源。
考虑最终决策作为最清晰的例子。策略师不仅发出买入信号。策略师记录它依赖的上游声明以及每个声明给予的权重。记录这些权重将最后一步从黑盒转变为可审计的引用列表。
可解释性正是捕捉到这一点。高分意味着大部分推荐可以追溯到特定、有来源的声明，而不是无法解释的推理。这就是模型说买入和模型说买入是因为这些声明、这些来源、以这种方式加权之间的区别。
图16：BioGenX运行的每个代理的证据和推理
性能和结果
在九次运行中，系统正确识别根本原因六次，即67%。三次未命中都是埋藏警告场景，其中影响力和责任存在分歧。我们宁愿报告真实数字并解释未命中，而不是四舍五入。
完整运行从端到端大约需要25秒。几乎所有时间都花在Bedrock调用上：每次运行约74个嵌入加上一次Claude撰写。
仅归因部分，即遍历图并分配责任的部分，大约运行74毫秒。这便宜到可以在每次管道执行时运行，而不仅仅是在出现问题时。
图17：端到端延迟场景
这对构建代理管道的意义
我们的数据指向三个具体的变化：
- 使研究员交叉检查任何重大声明都要与第二个来源进行核对。
- 给策略师一个硬性规则使得在二元事件附近的高置信度异议不能被默默覆盖。
- 添加新鲜度检查使得旧数据不能驱动决策。
更广泛地说，将影响力和责任视为单独的问题。两者都测量。责备图是追踪传播的强默认，但您需要侧信号如异议抑止来捕捉它看不到的情况。
从检测到预防：阻止损失的护栏
归因告诉您谁在事后破坏了运行。同样的信号可以在任何人行动之前阻止破坏。我们添加了一个护栏层，位于管道决策和行动之间，并在已知故障模式出现时覆盖调用。演示实现了这一层（使用--guardrails运行，或在应用中切换）。它回答了修复是否在代码中的问题：是的。
图18：决策和行动之间的护栏门
每个护栏针对三种故障模式之一：
- 异议覆盖（策略师）：当风险分析师在二元事件附近提出高置信度异议，而策略师低估它时，决策被强制为安全行动（持有）。
- 来源交叉检查（研究员）：依赖单一自我报告来源的重大声明不能驱动买入。必须得到证实，否则呼叫被阻止。
- 新鲜度（研究员）：如果重要信息在分析前刚刚发布且未反映在输入中，则呼叫被阻止。
启用所有三个检查，以前发出亏损买入的每个场景都会被捕获并阻止。在这三次运行中，这防止了约379万美元的示例性损失。
图19：护栏将实际损失转化为可预防损失
这三个护栏是演示级的启发式规则，我们想明确说明这一点。单一来源和新鲜度检查在这里之所以有效，只是因为场景数据是用已知来源和日期精心构造的。它们是代理，不是真正的控制。一个格式良好、引用看似合理的幻觉会在没有交叉检查检测的情况下通过，而新鲜度规则只知道交给它的数据。
要使其达到生产级，请将每个代理替换为真正的控制。
对于幻觉，不要数来源。要对照可信来源（如 Amazon OpenSearch Service 中的知识库或权威的申报文件和市场数据 API）验证决策所依赖的实质性声明。使用蕴含检查或 LLM 作为评判员的检查来确认证据确实支持该声明，并且在声明驱动买入之前要求来自独立来源的佐证。
对于新鲜度，接入实时数据源和预定的催化剂日历。每当决策依赖于实质性更新之前的输入或太接近二元事件时，就暂停。对于异议，保留覆盖，但根据历史结果校准其阈值，并将边界情况的高价值呼叫转给人工，而不是自动决定。
在这一切之下，将规则和阈值作为版本化策略存储在 OpenSearch Service 中。保持责任图谱的运行，以便确认护栏因正确的原因而触发。记录每次覆盖以供审计，并在真实结果上评估整个层。像关注捕获一样密切关注误报率，因为阻止好交易的护栏只是一个新的失败模式。保持保守：宁可持有好交易也不要进行坏交易，并使每个阻止都可解释。
负责任的人工智能考虑因素
此解决方案使用 Amazon Titan Text Embeddings V2 和 Anthropic Claude Sonnet 4.5 进行代理推理和事件叙述生成。LLM 生成的责任归因和事件报告是信息辅助，不是权威裁决。在做出运营决策之前，始终将自动归因与人工审查相结合。影响力分数衡量的是语义相似性，而不是真正的因果关系。本文中的埋藏警告场景正好说明了这一区别的重要性。
所有公司名称、财务数据和场景均为虚构。不使用真实的 market data 或客户信息。股票研究管线是演示责任归因和可观测性的说明性载体。它不是投资建议，BUY/SELL/HOLD 输出也不是股票推荐。不要按原样使用此系统做出财务或投资决策。
在将此方法应用于生产管线之前，请使用自己的 ground-truth 数据验证归因准确性，并根据您的风险水平实施适当的安全措施。此仓库中的护栏模块是起点，不是完整解决方案。有关更多信息，请参阅 使用 AWS 负责任地开展人工智能。
清理
为避免持续产生费用，请在完成后删除 Amazon OpenSearch Service 域。演示使用单个 CloudFormation 堆栈，因此一条命令即可删除所有内容。
aws cloudformation delete-stack --region us-west-2 --stack-name blame-game-demoAmazon Bedrock 按请求计费，因此那里无需拆除任何内容。
结论
多代理管线以日志无法解释的方式失败。通过使用 Amazon Titan Text Embeddings V2 嵌入每个声明，在 Amazon OpenSearch Service 中评分影响力，并从失败的决策向后遍历图谱，我们将“出问题了”变成了“这是导致问题的代理，这是证据”。我们还展示了该方法不足之处，以及弥补这些不足的额外信号。
代码、查询和部署步骤在仓库中。困难的部分不是基础设施。而是决定将影响力和责任作为两件不同的事情来衡量。
了解更多
要深入了解，请在 GitHub 仓库 中获取完整源代码，并参阅 Amazon OpenSearch Service 和 Amazon Bedrock 文档，以便将其适应您自己的管线。