用途：帮助判断某个代理框架或执行器缺少或不完整支持 NeMo Relay 时，应选择何种集成方式与深度。先识别宿主如何运行工具、模型调用、流式输出、子代理和生命周期事件，以及扩展点可控制的范围，再决定集成深度与 Relay 挂载方式（扩展、独立适配器、核心接线或混合）。
工作模式：一次只选一种，不得从评估悄悄转为实施。Assess 仅检查，不修改宿主、Relay、issue 或 PR；Implement 执行已批准的集成改动；Qualify 在精确的宿主与 Relay 修订上测试既有集成，默认只读。若宿主已有维护中的集成，先以其为起点核验覆盖范围；仅在证明存在缺口后才另建适配器。若应用只直接拥有少量工具或模型回调，转交 nemo-relay-instrument-calls。
证据基线：固定宿主精确修订与所有发行形态；单独建立 Relay 发布基线，查最新稳定版与预发布版及对应发布说明、支持矩阵、迁移指南与 API 文档，选定并记录一个目标版本。建立宿主到 Relay 的打包矩阵，核对运行时、扩展语言、OS、架构、libc 与包格式是否与已发布的 Python、Node.js、Rust、网关或高级 FFI/旁路产物兼容，并在真实发行形态中验证安装与加载。在源码与测试中追查工具与模型调用经重试、流、错误、取消和子代理的路径，判断各表面是拥有回调、执行决策或变更、暴露成对生命周期事件，还是仅观察。
所有权矩阵：独立评估进程/会话/运行/回合/压缩生命周期、工具请求与执行及 MCP 桥、LLM 请求与流式收尾、子代理创建与上下文传播、审批与人机决策及重试、配置激活健康与关闭等表面；拥有者或钩子不同的路径应拆行。记录调用路径、Relay 挂载点、逻辑与物理基数、作用域栈、回调线程、是否可阻塞或变更、成功失败取消与关闭归属。
集成深度与 Relay 方法：可选既有维护集成、宿主插件或扩展、独立集成包、宿主核心直连或混合，依所需覆盖、宿主架构、支持与发布归属、运维生命周期与性能决定。按表面选择方法：宿主交出真实回调时用托管执行包装；仅有成对事件时用显式生命周期 API（仅观察）；可阻塞前置钩子用条件执行；可变请求钩子用请求拦截；兼容 OpenAI/Anthropic 基础 URL 时用 Relay 网关（仅覆盖提供商流量）。能力表述需区分可观察、可关联、可评估、可强制、可变、托管与完整。输出决策记录，包含精确修订与目标、带证据的所有权矩阵、各表面推荐方法与已证能力、已知缺口、所需上游与 Relay 及部署改动及归属、确定性验证计划。限制：仅凭绑定可用不能证明所需 API 或语义存在；仅有闭源二进制或公开文档时须说明限制，不声称完整覆盖；其余细节暂未提供。