2026-07-31T06:15:00.166Z

多代理可观察性:审核协调拓扑

将观察到的代理到代理路由与版本化拓扑合约进行比较,以捕获漂移、不安全边缘、不明确的所有权和错误完成。

多智能体可观察性应该回答一个比“每个记录的跨度都完成了吗?”更严格的问题。它应该告诉您实际参与的代理以及他们实际使用的路线是否与本次运行批准的协调设计相匹配。 实际的默认值是 版本化拓扑契约 :允许的代理、允许的有向边以及当前运行阶段预期的边的小清单。将该清单加入到无内容交互收据中。然后,成功的跟踪可以分为工作、等待、不完整、不安全、不明确或错误完成,而不是默认变为绿色。 这很重要,因为跟踪记录了发生的事情。它不能包含从未发生过的所需委派的跨度。除非您提供预期的图表,否则它也无法决定禁止观察到的直接路线。当前架构指南中也出现了相同的区别:Microsoft 多代理参考架构 调用代理间消息流和协调模式作为特殊的可观测性信号,而 Azure Architecture Center 警告多代理编排会增加协调开销和新的故障模式。使用可靠地满足任务的最低复杂度;当多个代理合理时,使其拓扑可测试。 迹线无法证明预期的拓扑 OpenTelemetry的追踪API 提供正确的关联原语:跟踪和跨度身份、出身、链接、事件、时间戳、属性和状态。这些原语可以描述观察到的调用树或异步关系。他们没有声明哪些代理被允许,哪个路由版本处于活动状态,或者哪条边应该出现但没有出现。 假设协调者委托研究,研究人员将证据交给验证者,验证者返回裁决。每个观察到的事件都可以有 status: "ok" 至少在五种糟糕的情况下: 运行使用了昨天的路由策略; 研究人员直接致电出版商,绕过审核; 未注册的代理人进入图表; 协调器将同一条拥有的路由委托两次; 父级在验证者返回之前声明完成。 “所有事件正常”查询在这些记录中看不到错误。拓扑审核会比较两个集合: 保持该层无内容。收据需要稳定的运行和代理身份、路由类型、拓扑版本、事件身份、观察时间和本地状态。它不需要提示、响应、秘密、工具参数或绝对文件路径。 该合约故意与扇出完成法定人数分开。法定人数询问所需的分支是否返回。等待图询问哪个依赖项正在阻止进度。持久的移交收据会询问责任是否在队列或重新启动边界中幸存下来。拓扑一致性提出了一个先决问题: 这就是我们想要运行的协调图吗? 构建版本化协调合约 从显式恒等式和有向边开始。不要从最新跟踪中出现的任何内容推断允许的图表;这只会祝福事后的漂流。 允许的集合与预期的集合不同。仅研究阶段可能需要两个代表团,并且没有出版商优势。完整的发布阶段可能期望研究移交、验证者返回、出版商委托和出版商返回。运行开始时固定特定于阶段的设置。否则,可选边缘可能会在故障中途悄然变为强制边缘,或者所需边缘可能会在任何人注意到之前从定义中消失。 紧凑的分类器可以使用以下优先级: 1. 过时的合同 — 活动版本与固定版本不同; 2. 未知代理人 — 任一端点在批准的身份集之外; 3. 禁边 ——不允许定向路线和交互方式; 4. 模糊的路线 — 相同的拥有边在没有明确的重数规则的情况下出现多次; 5. 假完整 — 最终父母缺乏预期优势或经过验证的结果收据; 6. 等待 — 预期的边缘不存在,指定的依赖关系是明确的,并且截止日期尚未过去; 7. 不完整的 — 在截止日期之后仍然不存在预期的优势; 8. 健康或工作 — 观察到的集合与当前计划相匹配,“健康”保留用于经过验证的最终结果。 订购很重要。如果影子代理使用了禁止的路由,并且父代理也迟到了,那么“不完整”就太弱了:运营商首先需要包含未经批准的拓扑。相反,在截止日期之前宣布的等待并不是拖延。这是一个健康的依赖状态,应该到达正确的所有者,而不会触发破坏性重置。 动态路由是主要限制。系统可以在运行时合法地在专家代理中进行选择。将该选择表示为有界边缘类,或在分派之前生成准确的运行计划。通配符,例如 orchestrator 易于维护,但消除了大部分诊断价值。版本更改应该是可审​​核的,并且运行决不应该在中途默默地采用新版本。 采样是另一个边界。可以对大量痕迹进行采样,但用于健康决策的紧凑拓扑收据在相同策略下不能消失。如果无法提供所需的收据,请报告 uncertain 或者 incomplete ;不要从部分轨迹重建绿色。 在您相信完成之前重播漂移 我重审了九起针对上述合同的无内容案件。该固定装置包括健康完成、当前工作、合法等待、截止日期后错过的边缘、过时的拓扑、禁止的直接路由、未知的代理、重复的路由所有权以及没有回执的终端父级。 确定性审计符合所有九个预期状态。一个幼稚的规则——至少存在一个事件,每个本地事件状态都是 ok ,并且父级没有失败 标记 所有九个案例都是绿色的 。只有一名是健康的。这九种朴素果岭中的六种是不安全的、不完整的、陈旧的、不明确的或假完整的;剩下的两个正在工作和等待,状态不应该崩溃到完全健康。 案件 所有记录的事件都可以吗? 拓扑判定 运算符含义 : 完整的图表和结果收据 是的 healthy 规划图和最终结果得到验证 当前计划的边缘 是的 working 有用的工作可以继续;不要干预 未能在截止日期前归还 是的 waiting 通知或观察命名依赖项 截止日期后相同的退货丢失 是的 incomplete 研究第一个不存在的预期边缘 旧拓扑版本 是的 stale contract 停止将运行与错误的设计进行比较 未经批准的直达路线 是的 forbidden edge 在重试工作之前包含路线 未知参与者 是的 unknown agent 验证身份和权限 重复拥有的路线 是的 ambiguous route 协调所有权和可能的重复效果 父终端,返回缺席 是的 false complete 重新开启运行;完成缺乏必要的证据 您可以使用标准化边缘键上的一个小函数来重现该决定: 在进度、质量或结果评分之前运行拓扑检查。然后保持判决边界明确: 拓扑一致性仅证明遵守了批准的协调形状; working 需要有用运动的新证据,而不仅仅是更多事件; waiting 需要指定的依赖关系和截止日期; healthy 完成需要确定的目的地或可交付的收据(如果有); 不确定的证据必须保持不确定; 任何积极的恢复都需要有限的权力、可见性和行动后验证。 这为运营商提供了狭窄的采用规则: 在运行的固定拓扑、当前阶段和最终结果接收一致之前,不要信任多代理完成。 匹配图表是必要的证据,但不能证明答案是正确的。 Sidewisp 目前处于私密预览阶段。 其公共早期访问站点和交互式演示已上线,但生产多代理监控适配器、实时运行状况收集器和自动恢复执行器尚未发货。 Sidewisp 的预期作用是在现有运行时周围添加一个健康层,并使证据、严重性、不确定性和最安全的下一步操作更容易检查,而不是替换运行时或在没有人类授权的情况下采取行动。