Agent 全链路可观测体系建设调研分析报告

版本： v1.5
更新日期： 2026-10-15
发布范围： 公开
适用对象： Agent 应用研发、平台工程、SRE、安全治理和技术决策人员
文档性质： 公开技术调研。架构、阈值和验收口径为工程建议，不代表任何组织已经部署或验证。

摘要 #

Agent 的结果由模型、编排、工具、检索、记忆、推理服务和外部系统共同决定。请求成功不等于任务完成，更不等于答案正确或操作获准。多智能体失效研究在 150 条执行记录中归纳出 14 类失效模式，并提供跨 7 种框架的 1600 余条标注记录；另一项针对个人助理类运行时的单作者预印本，在 8 周内记录 22 起事件。两项研究说明失效机制可能跨越组件边界，但样本不能外推为行业故障率。[1] [2]

本报告以任务结果、执行路径、运行状态与性能、资源成本、安全控制、遥测健康六类证据为统一分析口径。推荐以 OpenTelemetry（OTel）/OTLP 连接异构组件，以应用任务账本和受控生命周期契约确认业务事实，以评估和人工反馈检验质量，以独立核对机制标出遥测缺失。调研覆盖埋点、Trace 后端和 Agent 评估平台；产品能力只以公开官方资料为依据，选型结论须由同一工作负载的验证形成。[3]

核心结论： 全链路可观测应同时具备业务事实、调用关联、质量验证和遥测可信性。业务终态由权威账本裁决；Trace、评估分数和采样后的记录分别提供受限证据。本文提出以下可执行建议，其具体阈值与部署效果须在目标环境验证：

章节导读 #

1. 范围、方法与术语 #

报告讨论生产 Agent 系统的数据契约、采集与查询、质量评估、运营告警、安全治理、候选项目及验收证据。模型训练与具体业务审批规则不在范围内。标准资料用于确认接口定义，产品文档用于确认公开能力，论文只支持其研究样本中的观察；本文提出的状态协议、架构及门禁属于工程建议。未进行产品压测或生产上线验证，不给出性能收益、成本节省比例和产品排名。文中各方案表、数据字段与验收反例除明确引用标准定义或研究结果外，均为本文工程建议；其适用负载、阈值及部署条件须由实施方确认。

2. 对象、证据与参考架构 #

flowchart LR
    A[Agent／工作流／工具] -->|OTLP 遥测| W[接收鉴权与租户网关]
    M[模型网关／推理服务] -->|OTLP／指标| W
    W --> C[Collector 与处理层]
    C --> T[Trace／Log 存储]
    C --> G[指标与告警]
    C --> H[管道健康]
    G --> N[告警路由／值班]
    H --> N
    A -->|生命周期事件| L[专用 API／耐久消息队列]
    L --> B[业务任务账本／结果系统]
    A -->|完整性清单分块| K[清单对象存储]
    B --> R[独立核对服务]
    L --> R
    K --> R
    T --> R
    R --> U[Run 视图／调查界面]
    T --> U
    T --> E[评估器／人工标注]
    B --> E
    E --> D[版本化数据集／评估结果]
    D --> U
    D --> Q[回归测试／发布门禁]
    Q -->|发布准入／回滚| A
    A --> P[唯一内容写入服务]
    P --> X[受控内容存储]
    X -->|服务端对象授权| U
    X -->|服务端对象授权| E

业务账本、专用生命周期通道和清单对象存储应位于普通 OTLP 管道之外，至少跨独立故障域持久化；否则不能作为核对“未观察到的任务”的独立证据。内容存储的对象键只能用于定位，读取仍需服务端鉴权。评估从任务结果和执行证据取样；其分数不能替代业务结果。闭环是生产信号 → 评估和反馈 → 版本化数据集 → 回归验证 → 发布门禁 → 生产监测，每一环应保留输入、版本、判定和责任人。

2.1 观测对象与运行层次 #

观测范围应包括业务 Agent 和子 Agent、编排框架、工具/MCP、RAG 与长期记忆、沙箱、模型网关、外部模型 API、自建推理服务，以及被调用的业务服务和算力基础设施。模型网关提供路由、降级、预算和护栏事实；推理服务提供排队、prefill/decode、缓存与抢占事实；宿主/GPU 信号用于解释资源约束。应用调用耗时不能独立证明推理服务或 GPU 的瓶颈，需通过请求、实例与部署版本关联。vLLM 的可用指标及名称按目标版本核验。[4]

评估执行器和供 Agent 查询的可观测接口也属于被观测对象：前者需独立记录用量与故障，后者需审计调用主体、范围与读取用途。观测链路的排队、清单和质量信号健康不能依赖被诊断的同一条故障通道。

2.2 公开实践与可借鉴边界 #

阿里云公开方案包含接入、统一数据模型、分析及 Agentic Ops，并提供拓扑、链路、会话、指标与告警视图，可作为会话聚合、场景化分析和评估闭环的信息架构参考；产品宣传不能作为性能或治理效果的实测证据。[5]

Anthropic 的多 Agent 研究系统实践强调生产追踪对排障的价值，并描述了监测决策模式和交互结构、同时不监测单个会话正文的隐私取舍。该做法说明结构化证据可以服务诊断，但其效果只适用于该公开案例，不能推出所有场景都无需受控内容取证。[6]

PawBench 的评测工程实践将 Model 与 Harness 分开比较，并提供任务标签、混合评分和执行记录；可借鉴任务切片和配置交互分析。它提供评测环境中的证据，不是生产可观测平台部署案例；生产诊断仍需匹配业务状态、权限和环境。[7]

3. OTel 映射与跨链路关联 #

3.1 标准、版本与字段 #

以 2026-09-10 合并的 0c875949 提交为规范基线，OTel GenAI 的 Span、Metric、Event 约定均处于 Development，不能把名称稳定性视为已承诺。实施须固定规范提交、SDK 和自动埋点版本，维护字段映射表；升级先双读或映射旧新属性，再灰度双写和回放典型查询，最后切换报表并记录回退条件。OTLP 互通并不保证产品的索引、UI、语义约定映射或多租户语义互通。[3] [8]

标准对 Agent、工作流、工具及模型 Span 的定义见固定提交。[8] 业务 ID 不宜默认放进 W3C Baggage：Baggage 可跨信任边界传播，接收端不得把它当授权凭据。跨异步队列、人工等待和多 Agent 协作时，优先由受鉴权的任务信封传递 Run/Attempt、租户与代次；仅传递最小关联标识，并校验发送者、租户和重放。W3C Trace Context 用于同步调用的 Trace 续链，跨独立阶段使用 Span Link 连接原因关系。[9]

除基线之外，业界并存其他开放语义约定，须在字段映射表中显式处理。OpenInference（Arize 维护）以必需属性 openinference.span.kind 标注操作类型（LLM、AGENT、CHAIN、TOOL、RETRIEVER、RERANKER、EMBEDDING、GUARDRAIL、EVALUATOR、PROMPT 等），并以 llm.、tool.、agent.* 等命名空间记录属性，是 Phoenix 的原生数据约定；其规范明确每个 OpenInference Trace 都是有效 OTLP Trace，AI 语义由属性约定赋予。[10] Phoenix 自 arize-phoenix 15.10.0 起在摄入时将 gen_ai.* 自动转换为 OpenInference（已有 OpenInference 属性优先、转换只补齐缺失），该转换的版本门槛、覆盖清单与优先级须按目标版本验证；不具备自动转换能力的消费端或 Collector 归一化环节必须显式映射，并对未映射属性做丢弃审计。双约定并行的管道须验证：模型、Token、消息与工具参数等关键字段在两个方向均可恢复且映射可回放。

3.2 长时 Run、MCP、RAG 与流式输出 #

短时、连续执行的 Run 可以由一个 Trace 表示。跨小时或跨天的等待、异步分支及人工审批应按有界执行段各建一个 Trace，用相同 Run ID 及 Span Link 关联前后段；等待本身记录为任务账本状态和时间区间，不能为等待数天而保持开放 Span。尾部采样仅在每个有界段内决策，并验证片段汇聚和等待时间；Run 视图不得因为某段未采样而显示“完整”。[9]

MCP 客户端和服务端应分别记录操作 Span、端点、工具身份、版本、耗时、错误及授权判定。OTel MCP 约定建议将已配置传播器生成的 traceparent、tracestate 注入请求的 params._meta，服务端默认以提取到的上下文为父上下文；如启用 Baggage 传播器，Baggage 也会进入 params._meta。HTTP 传输上下文与 MCP 消息上下文分别验证。面向第三方 MCP 服务端，应在出站方向限制传播器或剥离 Baggage，并验证敏感信息不会外传。A2A 或其他多 Agent 协议也须保存发送/接收主体、消息 ID、因果关联和授权结果，但不应将协议元数据直接赋权。RAG 和长期记忆应记录检索索引/快照版本、文档来源与权限、召回片段 ID、写入/污染检测和删除链路；正文只在受控存储中按需留存。[11]

流式响应须区分客户端首块到达时间（time_to_first_chunk）与服务端首 Token 生成时间（time_to_first_token）；网络缓冲、排队和前后处理会使两者不同。首块时间、完整响应耗时和中断比例应分别统计，未收到首块时标记缺失而非零。[12]

3.3 埋点接入与可替换性 #

Spring AI 基于 Micrometer 提供观测，文档中的 ChatModel 观测名为 gen_ai.client.operation；观测名、指标导出名与配置属性不是同一层概念。库原生字段也可能使用旧版 GenAI 约定，例如所引 Spring AI ChatModel 文档仍使用 gen_ai.system；须按字段实际含义对齐 §3.1 基线，不能将框架标识和模型提供者直接混写。LangChain4j 的 ChatModelListener 提供请求/响应/错误扩展点，但文档说明其回调并非每次底层重试都触发，流式回调还可能跨线程；不能据此单独还原所有收费尝试。[13] [14]

接入清单应记录语言、框架、Provider、版本、采集方式、覆盖信号与已知缺口。每个调用层指定一个主埋点责任方；库原生观测与自动探针组合后验证是否重复，不能假设双探针必然兼容或必然崩溃。替换厂商维护的埋点库时，保留语义映射并回放代表性查询，核对替代实现的覆盖缺口。OTLP 互通降低协议适配成本，仍需重做目标后端的索引、查询与 UI 验证。[15] [13]

3.4 与异构存量服务链路的互通 #

调用时上下文传播与遥测上报协议分别验证。存量服务可使用 B3 等传播格式并保留原有数据管道；支持某种上报格式，不证明请求头提取、续传与父子关系兼容。事后转换报文不能补回调用时未记录的因果关系。OTel 定义传播器注入/提取接口及 B3 要求；B3 的共享 Span ID 表示与 OTel 服务端新建 Span 的要求存在差异，查询层必须明确处理来源模型。[16] [17]

这是本文的交付能力分级，不是 OTel 标准。实测至少覆盖双传播头冲突、不同方向的 ID 接受行为、未采样父上下文、共享 Span ID、边界映射及跨集群查询。冲突优先级由策略明确，并在目标语言 SDK 上验证；不预设所有实现具有相同覆盖顺序。

查询以显式身份和父子/Link 关系关联，不以时间戳猜层级；须处理缺父、跨日、精度差、各侧数据迟到和查询截断。取各侧时间范围并集并受控扩窗，不能用单侧窄窗裁掉另一侧。L3 只说明能统一展示，完整性须按各侧生产者、采样及损失证据分别标注；存量侧未纳入 §4.3 清单时，不得随 Agent 侧获得“完整”结论。

4. 应用级生命周期与完整性契约 #

4.1 Run 与 Attempt 双状态机 #

Run 是业务目标的权威状态，Attempt 是执行租约的一次代次；二者分别持久化。Run 维持 pending、running、waiting_human、succeeded、failed、cancelled 六态。一次 Attempt 失败但仍有重试机会时，Run 保持 running；仅当重试策略用尽、业务判定无法继续，或不可重试的高后果失败发生时，Run 才进入 failed。Run 终态须附权威结果 ID、结果校验、原因和决策主体。

stateDiagram-v2
    [*] --> pending
    pending --> running: 任务受理／调度
    pending --> cancelled: 取消
    running --> running: Attempt 失败后重试／接管
    running --> waiting_human: 等待人工
    waiting_human --> running: 有效审批后继续；或拒绝／超时后按策略重试或回退
    waiting_human --> waiting_human: 重新发起审批或延长等待
    running --> succeeded: 权威结果校验通过
    running --> failed: 重试用尽／不可重试失败
    running --> cancelled: 取消
    waiting_human --> failed: 超时或拒绝且不可继续
    waiting_human --> cancelled: 取消
    succeeded --> [*]
    failed --> [*]
    cancelled --> [*]

Attempt 的 finished 表示该次执行已报告结果，另有 outcome=success/failed；它不直接决定 Run 终态。人工等待后如原租约仍有效，可由同一 Attempt 从 suspended 恢复 active；若调度器签发新执行者接管且旧 Attempt 尚未终止，旧 Attempt 进入 superseded；若已先撤销租约并判定 abandoned，则保留该终态。新 Attempt 由调度器签发更高 epoch 后进入 claimed；无有效租约不得恢复旧 Attempt。abandoned 表示调度器在撤销租约后判定该 Attempt 失效；单纯心跳超时只产生 lost 活性标记，不自动进入 abandoned。新执行者提交外部副作用前，目标服务仍须校验 fencing token，避免旧执行者继续写入。

对不支持单调 fencing token 的第三方 API 与存量 MCP 服务端，工具网关须提供兜底契约（本文建议）：副作用请求携带由 (tenant_id, run_id, attempt_id, epoch, logical_action_id) 派生的幂等键，网关对支持幂等的端点去重、对无幂等能力的端点按“可能重复执行”定级；撤销、接管与取消事件须传播到工具网关及出站凭据层，并记录传播时延与失败；对不可去重且不可中止的端点采用执行后核对与补偿动作，并记录“已执行、结果未确认”的残留副作用。兜底不能等价于目标端点自身的代次校验；无法闭环的端点须列入已知残余风险清单，在 Run 视图与安全评审中可见，不得默认其重复副作用风险已消除。

审批拒绝或等待超时且该 Attempt 仍是当前未终止代次时，授权调度器可根据权威审批记录提交 suspended → finished、outcome=failed，附审批/超时结果 ID 与原因；不是用模型自报结果代替审批。该事件按控制权限校验，执行者自行提交仍须有效租约。Run 是否失败由业务重试与高后果策略裁决，不因 Attempt finished 自动推断：重试或回退路径使 Run 保持 running 并由调度器签发新 Attempt；重新发起审批或延长等待使 Run 保持 waiting_human 并更新等待记录与期限；仅当策略判定不可继续时 Run 进入 failed。已 abandoned/superseded/cancelled 的 Attempt 不改写终态，等待结果关联到 Run；若 Run 被取消，当前未终止 Attempt 级联 cancelled。

本文的人工等待契约是：suspended 期间不要求执行者继续发心跳或保持开放 Span；调度器耐久保存等待原因、审批期限、当前代次与租约归属，并监测等待协调组件自身健康。有效等待显示 waiting，不因无执行者心跳标 lost；租约仅证明当前授权归属，不能证明执行进程存活。租约失效须撤销并按 abandoned/接管规则处置，审批超时按上述失败结果规则处置；两者不得混同。审批获准后，只有原租约仍有效才可恢复同一 Attempt，否则签发新 Attempt/epoch；恢复生效时重新起算心跳期限，随后按 active 契约检查心跳与进展。claimed 的领取期限从租约签发起算，active 的首个心跳宽限从激活/恢复生效起算；期限、起算证据和逾期动作均须预先固定，宽限内无心跳不记 fresh。

stateDiagram-v2
    [*] --> claimed: 调度签发 epoch／租约
    claimed --> active: 执行者领取
    claimed --> cancelled: Run 取消
    claimed --> abandoned: 租约撤销
    claimed --> superseded: 新 Attempt 接管
    active --> suspended: 等待人工
    active --> cancelled: Run 取消
    active --> finished: 提交成功或失败结果
    active --> abandoned: 租约撤销／执行者失效
    active --> superseded: 新 Attempt 接管
    suspended --> active: 同一租约内恢复
    suspended --> cancelled: Run 取消
    suspended --> finished: 审批拒绝／超时（outcome=failed）
    suspended --> abandoned: 租约撤销／执行者失效
    suspended --> superseded: 新 Attempt 接管
    finished --> [*]
    abandoned --> [*]
    superseded --> [*]
    cancelled --> [*]

事件经专用 API 或耐久消息队列进入任务账本，采用 outbox 与幂等消费持久化；可复制成 OTel Log 供查询，副本不成为权威来源。同 ID 同内容重投无副作用；同 ID 不同内容进入协议冲突；接收端先验证来源身份与租户归属；执行者的旧 epoch 或过期租约事件、跨租户事件及非法转换被拒绝并审计。调度器的撤销、失效和接管事件按独立控制权限验证，可引用已撤销租约，但不得冒充执行者继续写入。seq 只能在已定义的流内比较；时间戳不能替代代次授权。activated 对应 claimed → active；heartbeat/progress 只更新当前合法状态下的活性或进展证据。各生产者流不形成全局总序，权威状态服务负责裁决状态转换；乱序事件可补入历史，但不得按到达顺序倒退当前状态或跨越终态。控制事件与执行者事件的允许来源须分别限定。heartbeat 的事件 seq 递增不等于业务进展；进展超期另以受信 progress/已完成 step 水位和等待状态判断。

4.2 活性、完整性和覆盖范围 #

业务状态、活性标记、完整性结论与覆盖范围在界面上分列；不得把 lost、unknown、open_or_abandoned 作为 Run 业务终态。下表的“可修订”指新证据进入后保留旧结论及修订水位，不能静默覆盖历史。

心跳新鲜度仅适用于要求心跳的执行状态，人工等待按 §4.1 的等待契约判定；等待记录或协调组件证据不可用时显示不可判并告警。心跳新鲜度须结合有效租约、受信时间界限与接收时刻判定；延迟批量到达的旧心跳不能仅因刚被接收就刷新活性，时钟偏差超界时须显示时间证据不可判并独立告警。心跳丢失可能由进程、网络、调度或遥测故障造成，归因须有宿主、队列或网络独立证据。业务成功但遥测缺失、业务失败但遥测完整都是有效组合。

4.3 完整性清单与成本边界 #

对约定为全量的生产者，生产端维护独立于普通 OTLP 的清单：manifest_id、tenant_id、run_id、attempt_id、epoch、producer_id、segment_id、采样策略版本、created_count、ended_count、export_intended_count、sampled_excluded_count、分块数、摘要与 seal 状态。清单记录 Span 创建、结束及导出意图；分块按有界 ID 数量写入受控对象存储，并由任务账本保存块摘要和地址。普通 Span 的处理与导出时机须按 SDK Span Processor 配置核验。[18]

清单写入会增加业务热路径的持久化 I/O、尾延迟和吞吐压力，必须在目标负载下测量。建议用本地有界缓冲与批量耐久写降低同步开销，同时明确可承受的清单丢失窗口。清单写失败时业务请求 fail-open，该执行段立即通过独立健康通道或任务账本标为 unverifiable，不得继续宣称完整；若标记通道也故障，核对服务根据任务账本中存在的 Run 与缺失的生产者声明给出 unknown/unverifiable_timeout。业务与授权失败策略仍由业务系统独立决定。

export_intended_count 只计入生产端采样后已结束且拟导出的 Span；生产端采样排除数另记 sampled_excluded_count。尾部采样若在下游丢弃，须取得可核对的采样决策记录并把被排除 ID 从预期集合 E 中剔除；缺少决策证据时，该段不能做逐 Span 完整性声明（实施选项与边界见 §6.2）。计数与摘要只能发现差异，不能定位缺失 ID；需要逐项定位时才保留完整 ID 分块，并以分段、大小上限、保留期和压测控制开销。

清单封闭要求业务执行段终止、已声明生产者提交最后水位、分块可读及迟到窗口结束。生产者崩溃后由调度器记录失效和接管；未结束 Span 归为 open_or_abandoned。到期仍缺声明或分块时标记 unverifiable_timeout 并保留恢复窗口。对已封闭、采样决定已核实的范围，E 是应导出的已结束 Span 身份集，O 是实际入库身份集，均以 (tenant_id, trace_id, span_id) 为键并绑定生产者、执行段与采样范围；E−O 为 missing，O−E 为 unexpected，二者可同时存在。迟到补齐可修订结论但须留版本和水位。身份到齐不等于属性、Event、Link 或正文完整，截断、映射损失与内容引用状态须另行校验。根 Span 结束不会自动结束子 Span，不能据此宣布链路完整。[19]

5. 指标、评估、SLO 与运营 #

5.1 指标口径 #

GenAI 指标名称与单位以固定提交的官方约定为准；上述同名指标不是“业务成功率”。[12] 推理引擎还应核对排队、缓存、抢占与逐 Token 延迟；vLLM 的生产指标应按目标版本的使用文档和实际 /metrics 输出配置。[4]

建议维护统一指标字典：名称、来源与计算服务、统计单位、分子/分母、窗口、去重键、缺值处理、标签基数上限、业务/探针/Judge 隔离方式、告警路由和责任人。不同指标采用不同的有效样本集合时，必须公布各自分母，不能用同一“成功率”名称掩盖差异。

模型用量及终止字段以固定约定和供应商实际返回为准。[8] 上表扩展维度为本文指标设计建议。人工反馈有选择偏差，固定任务只覆盖已设计场景，自动 Judge 有校准与注入风险；三者须交叉核验，不能相互替代。

5.2 质量与评估数据 #

确定性业务断言应先核验权威结果；固定任务集保存输入、前置状态、工具权限、参考结果和全部执行版本；生产样本分层抽检并接收用户反馈。τ-bench 的 pass^k 提醒多次执行一致性与单次通过率不同。[20] 自动评估器须版本化、与人工标注校准，并单独统计超时、错误、Token 和成本。评估器不可用应显示“未评分”，不能算通过。

标准 gen_ai.evaluation.result 事件使用 gen_ai.evaluation.name；gen_ai.evaluation.score.value 和 gen_ai.evaluation.score.label 按条件设置，可附 gen_ai.evaluation.explanation、gen_ai.response.id、error.type。事件应关联被评估操作的 Span 上下文；异步评估通过携带目标上下文的事件记录关联，不能追加修改已结束 Span；无法关联该上下文时以 response.id 关联。评估器版本、样本来源、标注者、规则版本和数据集版本是本地扩展，须另定保留与权限。解释文本可能含敏感内容，应按正文策略处理。[21]

满足二项比例设计的通过率可报 Wilson 区间；存在同一任务重复时，先核验依赖结构与统计单位，不能把全部 Run 当独立样本。成本、延迟及新旧差异可在条件适当时按任务簇重抽样；具体限制和放行规则见 §5.4.1。模型或提示词变更保留配对任务、失败样本和未评分比例，重复次数与可检测差异由试验设计和功效分析确定。[22]

5.2.1 四类活动与数据资产 #

任务定义、沙箱执行、规则断言和轨迹留存可复用；日常调参集、准入保留集、生产反馈集须分别版本化并限制用途。生产失败沉淀有助于发现先验任务集的盲区，但在上线前也应依据业务契约和威胁模型构造测试，不能把“先有生产观测”视作开展任何评测的必要条件。

5.2.2 金标准任务的可重复性与判定 #

金标准任务保存输入、业务前置状态、允许工具与权限、参考结果、断言、执行版本及环境快照，按场景、原子能力、复杂度、风险、模态、环境标签切片。规则断言校验实际结果及副作用，语义 Judge 评价文本质量，分数分列；必须通过的业务和安全断言失败时，不允许高语义分抵消。τ-bench 以执行后的数据库状态与目标状态比较，支持从实际结果判定任务完成；本文把该原则推广为任务级断言设计。[20]

每次重复及每个新旧变体均须重置数据库、队列、缓存、记忆和配额等外部状态，或使用可验证的独立快照/资源；串行执行与容器隔离不足以恢复业务状态。生产栈探针须使用专用身份，声明真实依赖与沙箱替身、允许出网和副作用范围，并由业务负责人验证不会改动非测试资产。

执行记录分列业务失败、评分基础设施失败、缺结果、未执行及超时；这些是评测记录的分类，不扩充 §4 的 Run 业务状态。附上计划数、已执行数、可判定数、成功数与基础设施故障数，未知不计成功，也不得静默剔除。频率、任务数与重复次数按发现时延、统计目标和成本共同确定，变更事件可额外触发回归。

5.2.3 防评分投机与 Judge 风险 #

BenchJack 对选定 Agent 基准做对抗性审计，揭示评分资产隔离、答案暴露、评分逻辑和 Judge 注入等缺陷；这是对受测版本与攻击条件的研究，不能推断所有公共基准或当前版本都不可用。[23] 据其设计检查思路，本文建议：

1. 评分代码、参考答案和判定权限不得由被测 Agent 读取或修改；评分器仍须通过受控只读接口核验实际产物和副作用。
2. 参考答案不得放在 Agent 可读的任务元数据、工作区、缓存或网络位置；日常调参集与准入保留集隔离，保留集使用须登记并周期性更新。
3. 评分器不得执行被测输出中的可控字符串；格式合法不等于结果正确。
4. Agent 输出作为不可信数据传给 Judge，采用结构化边界、转义、最小权限及对抗用例；隔离与转义不保证免疫提示注入，异常与高后果判定仍需人工复核。
5. 沙箱网络默认关闭，按任务开放必要目的地；定期测试评分篡改、答案获取、Judge 注入和结果伪造。

Judge 校准须保存人工标签、分歧类型和评分版本，并监测分布变化；判官自身也可能错误高分。确定性业务断言提供不同来源的证据，但其代码和结果读取路径同样需要验证，不能称为天然可靠的“金标准”。

5.2.4 评估工作台、执行器与健康信号 #

工作台承担评估器创作、调试、人工标注、校准和数据集/实验管理；执行器按批准的规则、提示词、输出 schema、模型与版本消费不可变定义，采样执行并写回结果。可用 Git 或受控制品库管理定义，但权威来源只设一处；产品是否能完整导出这些资产必须逐项验证。工作台是可替换组件，不应成为生产执行器的必需在线依赖。这是本文的职责划分建议。[24]

生产与测试的关键执行语义、字段映射、评分版本和写回契约应一致，凭据、规模及允许数据范围可以不同；配置同源不保证行为一致，仍需代表性回放和故障测试。生产衍生样本跨环境使用须定级、授权、脱敏、限定用途、保留和删除；脱敏不能免除来源治理。评估旁路须有独立预算、队列和资源限额，故障时业务及主遥测通道应在声明范围内继续服务。

为防递归，评估入口只接收由受信埋点/网关确认的业务角色样本，如 org.telemetry.role=subject；evaluator、probe 和 unknown 默认不进入生产在线评估旁路；探针/离线回归通过独立受控调度器执行评分，模型或工具不得自行赋予角色。漏标表现为覆盖率下降并告警。Judge 调用有独立关联与记账身份，不并入被评估 Run 的业务步数、延迟或成本；“全体系总成本”可以另行汇总。

评估结果按 (tenant_id, target_id, evaluator_version, evaluation_attempt_id) 幂等写入，重投不新增逻辑分数；重新评分产生新 attempt 并保留旧结果。写回超时但实际成功须通过身份核对，不能直接启动重复业务执行。耐久恢复的介质故障与保留期亦须纳入演练。

5.3 SLI、告警模板与运营闭环 #

先固定准入、窗口和判定期限：A 为进入窗口且已到约定判定期限的合格 Run 集，D 为 A 中权威结果可判定的子集，S 为 D 中结果通过的子集。结果质量 SLI=数量(S)/数量(D)，同时公布未判定比例=数量(A−D)/数量(A)；端到端达标 SLI=在时限内完成且结果通过的 Run 数/数量(A)，不因缺结果或超时缩小分母。另列遥测不完整比例，空分母标记无数据。排队、人工等待和流式首块时延按业务目标分别展示，SLO 须明确采用哪个 SLI。SLO 应绑定业务后果、窗口和明确排除项；错误预算等于窗口内允许失败数，燃烧率为实际预算消耗速度与均匀消耗速度之比。预算告警采用短窗与长窗组合并经历史数据和演练校准，不照搬固定阈值；低流量任务应单独评估窗口和样本量。Google SRE Workbook 给出了多窗口、多燃烧率告警的方法。[25]

周度运营应报告质量、SLO、预算、成本归属和缺数；把用户反馈、人工复核与生产事故转为受控数据集案例，定期校准评估器，再以回归结果进入发布门禁。输入分布、供应商实际模型、工具 schema、检索语料和评估器自身都应监测漂移。运行时的步数、时间、Token 和工具预算由有权组件执行；可观测系统记录判定与结果，不负责授予权限。

5.4 变更度量、放行与轨迹归因 #

5.4.1 重复可靠性与统计放行 #

τ-bench 的 pass^k 衡量同一任务重复 k 次均成功的可靠性；在每任务 n 次可交换、独立重复的设计下，任务 i 有 c_i 次成功，可用 C(c_i,k)/C(n_i,k) 估计，并按任务集权重汇总，要求 n_i≥k。pass@k 衡量至少一次成功，两者不同。单任务在独立同分布条件下为 p_i^k；异质任务集整体是各任务 p_i^k 的加权平均，通常不能用整体 pass^1 的 k 次方反推。状态残留或共享依赖引起的相关性会破坏该解释，必须披露。[20]

Wilson 区间适用于相应二项比例设计，不能直接套在 pass^k 组合估计或全部相关重复上；固定任务集与对真实任务分布的推断也须区别。若独立任务簇足够且任务抽样目标适当，可对整个任务簇重抽样比较新旧差异；少量任务簇或时间相关漂移时需重新设计，不能无条件宣称 cluster bootstrap 有效。配对同一任务也不消除外部状态和调用环境混杂。[22]

“未检出显著差异”不能证明不劣；ASA 强调不能仅依赖 p 值阈值作决策。[26] 本文建议在执行前冻结以下规则：

以“越高越好”的主指标为例，定义 Δ=新−旧，质量非劣要求预先选择的差异置信下界≥−δ，并同时通过安全硬门槛；成本/延迟按相反方向的上界判定。该规则是示例，置信水平、检验族、统计模型和 δ 须由业务及统计负责人选定。单次确定性高后果断言失败可以直接阻断，不等待聚合；通过少量重复不能证明高可靠。

5.4.2 变体记录与多维记分卡 #

以上 org.* 字段均为本地契约，须绑定受信发布/配置记录；配置哈希不授予权限。灰度期间按实际承接版本归属，不把混合时间段当成单一变体。无法归属者标记 transition/unknown；能准确分组且满足实验设计的灰度样本可使用。应从一开始留存版本证据，历史缺失无法可靠补造。

变更记分卡维度为质量、成本、时延、效率、工具健康、用户侧体验；分别观察通过率/重复可靠性、单 Run 成本、执行及首块时延、步数/预算触达、选择和参数错误、拒答/放弃/接管。它用于决策权衡，与第 2 章的六类证据分类分别管理。每维预先约定接受界和可判定样本，不能用综合高分抵消安全硬门槛。

5.4.3 从差异到诊断 #

轨迹归因按“任务标签切片 → 找到关键动作/依赖的分叉 → 核验分叉原因”展开。每步保留受控 step_id、父分支/消息因果关系、工具名及版本、输入/输出的受保护摘要、耗时、Token、状态和终止原因；摘要计算范围、归一化及脱敏版本随记录保存。低熵敏感值宜用受控密钥的摘要，仍按敏感关联数据治理，不能以哈希代替匿名化。

步骤数和顺序可能随变体改变，不能只靠 step_number+tool_name 强行一一对齐。先按任务阶段、关键动作和因果结构匹配，不可对齐部分显式展示；首个不同摘要是分叉线索，不能单独证明根因。可进一步标注多条允许路径，分析工具选错、参数错误、检索遗漏、越过权限或提前放弃；存在多种合法路径时，不要求机械复现唯一轨迹。

多智能体失效归因已有自动化研究：Zhang 等的 Who&When 基准把“定位失败 Agent 与关键错误步骤”形式化为归因任务，并评估 All-at-Once、Step-by-Step、Binary-Search 三类自动判官；其报告的最优方法 Agent 级准确率 53.5%、步骤级仅 14.2%，部分方法低于随机，推理模型参与时也未达到实用水平（结果限其数据集与受测方法）。[27] 该结果说明此类方法当前适合作为轨迹诊断的假设生成器：定位输出仍须回到因果结构对齐、步骤摘要比对、版本与工具证据及实际副作用核验；判官与数据集版本、已知混淆须随实验记录，不得把归因分数直接当作根因结论或发布裁决依据。

PawBench 将模型与 Harness 作为独立维度，提供任务切片、混合评分和执行记录，支持用同一任务检查二者的交互。[7] 本文据此建议受控交叉实验；不把该项目某次排名外推为“弱模型普遍更依赖框架”，也不预设工具数量的统一风险拐点。

5.5 生产漂移的分诊与确证 #

主动变更可从发布记录定位变量，生产漂移还可能来自同名模型更新、路由、远端工具描述、下游规则、检索语料、输入分布或评分器变化。下表为本文诊断建议；固定探针缩小搜索范围，不能替代归因取证。

矩阵末行表示三类探针中至少一类已证实退化而生产表现仍正常；分别记录三列实测结果，不以缺结果充当退化。缺探针结果必须标 unknown，不能填“正常”；多类同时退化须允许多因解释。确证使用网关实际路由、请求/响应模型、部署与配置记录、工具定义版本、依赖发布记录、检索快照、输入标签分布和失败 Run。模型别名解析或批准降级属于正常变化；同名字段下的权重更新可能不被字符串比对发现。下游 schema 不变但业务语义变化时，调用成功率也可能正常，需结果断言和受控重放进一步核验。

工具定义建议保存原始摘要及规范化摘要，并限定相同服务身份、工具作用域、主体权限集合与批准基线再比较。canonical 算法需版本化工具排序、字段范围、Unicode/数值等规则，可参考 RFC 8785；自然语言描述不得未经说明删除语义相关空白或大小写。规范化变化不证明语义变化或恶意篡改，原始摘要变化也可能只是表示变化；哈希不替代来源认证和签名。[28] 输入分布漂移确认后应扩充覆盖；证据不足时不直接归咎模型或自动回滚。

5.6 重复、振荡与无进展 #

本文建议按运行时受控步骤和分支因果顺序检测，不按入库到达顺序拼接。对同一执行分支，在有界窗口计算工具身份及受保护的输入/输出摘要；只有连续相同输入且结果未变化时，先输出“疑似重复/无进展”。连续次数、持续时间按工具契约与历史基线标定，不预设统一 N。间隔重复和多工具图环另行分析，图环本身不证明失控。

摘要相同只证明选定表示一致；脱敏合并、碰撞和归一化版本均须披露。无论诊断是否可判，运行时仍独立执行步数、时间、Token 和工具预算；循环算法不能代替硬限制。

5.7 公共基准的选择及证据边界 #

按应用所需能力选择基准并保存任务、Harness、工具、评分器、模型和环境版本，比较不同维度而非合并无同口径的榜单。行业应用还须用代表性业务约束、权限及副作用构造私有保留集；公共基准可以提供筛选线索，不能作为唯一或充分的准入依据。BenchJack 的受控攻击结果提示评分管道须接受对抗审计；不以“公开”或“私有”标签直接判定其可信性。[23]

6. 采集韧性、存储与容量 #

Collector 队列、重试及可选 WAL 可缓解短时下游故障，但不提供无条件零丢失。官方列举的七类损失场景应分别注入：下游不可用导致重试超期、下游不可用导致队列溢出、无持久化时 Collector 崩溃、持久化介质故障、外部消息队列故障、配置错误、关闭队列或重试机制。每项记录输入量、已确认量、丢失量、恢复时长和数据修订结果；Collector 自身指标须独立告警。[32] [33]

峰值 Span/秒 ≈ 日 Run 数 × 每 Run 平均 Span 数 ÷ 86400 × 实测峰值系数
遥测日增量 ≈ Span、Log、生命周期 Event 各自数量 × 各自平均字节数
热存空间 ≈ 各类实测压缩后日增量 × 保留天数 × 副本及运维余量
内容空间 ≈ 捕获率 × 每 Run 内容字节 × 日 Run 数 × 保留天数 × 副本余量
评估 Token/月 ≈ 月评估样本数 × 每样本评估次数 × 单次输入及输出 Token

还需预算索引、回放、跨区域传输、对象存储请求及 WAL 空间。指标序列基数应按租户、服务、模型、工具等标签组合估算；run_id、session_id、用户 ID 不得直接进入常规指标标签。成本口径选唯一计费源，保存价格版本；缺失用量记未知，重复事件按身份幂等核对。

ClickHouse exporter 官方将 traces/logs 标为 beta、metrics 标为 alpha，并建议生产环境自行管理 schema（create_schema: false）；持久化队列和重试形成至少一次交付风险。[34] 需按稳定事件 ID 在写入或查询时去重，验证重复率和修正成本。ReplacingMergeTree 的后台合并具有延迟，不能把它当即时唯一约束；需要查询时去重，应按排序键与版本规则验证 FINAL 或等价查询。[35] 分区、排序键、查询限额及热冷保留应由真实工作负载压测确定。

6.1 Collector 部署、发行版与故障隔离 #

Collector 的 Exporter Helper、Batch Processor 及 Contrib Tail Sampling、Redaction、ClickHouse Exporter 文档固定以各仓库 v0.162.0 为引用基线；核心仓库稳定模块与实验组件可采用不同版本号，部署仍须锁定实际发行版、组件版本和 feature gate。这里固定研究证据，不代表推荐直接部署该版本。[34] [36] [37] [38] [39]

Agent 部署模式用于就近采集或本地缓冲，Gateway 模式用于集中处理、策略和导出，也可组合。这里的 Collector Agent 是部署角色，与业务智能体分别命名。拓扑选择需权衡应用部署成本、跨网络损失、故障域、资源和运维能力；本地层也不能承诺无条件耐久。[40]

发行版按 receiver/processor/exporter 清单、稳定级、许可、CVE 与运维能力选择；core、contrib、厂商发行版和 ocb 自定义构建不设统一优劣。自定义构建可收敛组件范围，但须承担构建、制品签名、升级及漏洞修补责任。锁定 Collector 版本、组件清单与配置摘要，升级前回放和演练；不因组件开源就推断供应链风险已消除。[41]

6.2 批处理、队列和尾采样的不同状态 #

Exporter Helper 的 sending_queue 可配置 requests/items/bytes 计量，queue_size 单位取决于 sizer，不能统一按“批数”或“Span 数”估算。v0.162.0 Exporter Helper 文档的队列批处理默认关闭；需要时显式配置 sending_queue.batch，并在目标 exporter 及版本核验支持情况。启用 storage 时使用持久化队列，但永久错误、入队失败及重试耗尽仍可能丢失。[36]

batch processor 在持久化 exporter 队列之前缓冲，故其尚未进入耐久层的数据不受该队列保护；可以评估使用队列侧批处理以减少前置易失缓冲，但不存在“所有 pipeline 都应禁用 batch processor”的通用结论。实际确认边界、最大发送量和崩溃损失须注入测试，不能以接收端 ACK 单独证明最终入库。[37] [36]

尾采样按 Trace 维护内存状态，要求同一 Trace 的 Span 汇聚到同一决策实例；Exporter WAL 不保护它前面的等待缓存。须独立测试实例 kill、路由抖动、扩缩容、执行段超过等待期、决策后的晚到错误/成本字段和缓存淘汰。等待期、决策缓存、内存限制和接收负载共同标定；全保留场景可不加载尾采样，不能把 always_sample 策略等同于不存在等待缓存。[38]

标准 tailsamplingprocessor（v0.162.0）在作出决策后直接丢弃未选中的数据：它只维护用于决策的内存状态与有限的决策缓存（默认不启用），不输出可分发的逐 Span 丢弃收据；决策缓存只用于等待期内晚到 Span 的一致决策，不构成可核对的排除证据（按目标版本核验）。[38] 因此 §4.3 的逐 Span E−O 扣减只有在能取得决策证据时才成立。实施按二选一（本文建议）：或将逐 Span 完整性断言限定在头采样与全保留执行段，尾采样段仅按执行段/Trace 级声明覆盖范围并标注采样排除；或自行部署收据管道——在决策点旁路记录被排除 Span 身份，或以自定义 processor/connector 输出决策记录——并承担其可用性、性能与版本维护责任。收据管道本身须纳入完整性监测：收据缺失或损坏时，相应范围降级为不可验证，不得回退为“完整”。

成本、权威生命周期、安全审计及核对必需信号使用独立覆盖契约，不随诊断 Trace 采样自动丢弃。持久化队列不能被假定保留所有临时身份上下文：Exporter Helper 文档特别说明 Auth 扩展上下文不经持久化恢复；尾采样重组也会改变原请求上下文。接收端须从认证事实绑定租户与来源，以受保护的记录或隔离管道持久化该归属，导出和查询端再校验；不能信任客户端自填 tenant_id，也不能仅依赖入站内存上下文。[36] [38]

内部指标经 service.telemetry 暴露，与业务 metrics pipeline 分别接入；每个出口的排队、丢弃与恢复单独监测。[33] 指标拉取、正文写入和清单写入不必具有 Exporter Helper 队列，需分别申报状态及耐久边界。

6.3 存储与查询工作负载 #

Agent 元数据、业务生命周期、内容引用和评分结果采用明确实体及版本契约；若与存量服务数据同库，物理表与索引布局仍由查询和字段差异决定，不预设必须混表或分表。ClickHouse 排序、分区及跳数索引存在读写取舍，可比较时间窗/服务检索、整 Trace、Run/会话检索和变体聚合的真实扫描量、写吞吐、索引内存、parts 及 TTL 行为。[42]

保留期按元数据、正文、清单、评估结果、审计用途分别设置。时间范围辅助索引/物化视图只用于缩小查询，不作为完整性的权威来源；派生结构失败、空索引和主表中间可见状态须有受限回退与提示。跨集群查询复用 §3.4 的范围与身份规则，压测权限过滤、查询并发和截断行为。

6.4 用量记账与持续评估成本 #

上述为本文记账设计建议；若错误/高成本 Trace 全留、普通 Trace 抽样，样本均值不能直接作为总体均值。无有效纳入概率或关键路径从不纳入时，不承诺还原总金额；应转向计费账单与网关对账。供应商不提供独立收费请求 ID 时，须记录可用关联及剩余误差，不能假定已实现精确去重。

业务、定时探针、离线回归和 Judge 分列消耗，同一调用只归属一个计算类别；可另汇总体系总成本。金标准/回归日执行量≈任务数×每任务重复次数×日批次数，额外加变更触发批次；Judge 日调用量由实际评分样本数×每样本判官次数并计入真实重试。容量预算还包含 Worker 占用、环境重置、人工标注、对象请求、保留和回放。频率与发现时延共同决策，不把持续探针成本藏进生产 Run 均值。

7. 安全、隐私与调查证据 #

默认仅采集结构化元数据。OTel 对 gen_ai.input.messages、gen_ai.output.messages 采用 Opt-In，并提示内容可能包含个人信息；提示词、响应、工具参数和检索文本的全文采集须另行审批。[8] 唯一内容写入服务执行分类、脱敏、加密、租户绑定、保留期和审计；Trace 只保存不可直接访问的对象键。服务端读取时验证用户身份、租户、应用、对象权限与用途，不能凭合法格式的键放行。删除流程须覆盖 Trace/Log、Collector WAL、对象存储、评估数据集、导出副本和备份，并留完成证明及依法需保留部分的例外记录。

中国场景应评估《个人信息保护法》《数据安全法》对采集、处理、留存和跨境的适用要求；《生成式人工智能服务管理暂行办法》针对向境内公众提供生成式 AI 服务的情形，不能一概套用于内部系统。向公众提供生成合成内容时，还应按适用情形评估《人工智能生成合成内容标识办法》及 GB 45438-2025；二者均于 2025-09-01 施行。具体义务需结合服务性质和司法辖区由法律与安全负责人判定。[43] [44] [45] [46] [47]

下表以 OWASP Agentic Applications Top 10 的 ASI01–ASI10 为威胁建模索引。信号用于调查，阻断必须由运行时、网关、身份服务或工具服务执行；“有日志”不等于控制生效。[48]

7.1 内容写入契约与引用状态 #

以下为本文建议的一致性契约：默认关闭全文捕获，按环境、场景和字段 Opt-In；由唯一授权服务执行分类与脱敏，生成稳定 capture_id，并把租户、Run/Trace、用途、正文版本、保留期和内容摘要绑定到写入记录。正文确认写入后才发布可读取的引用，Trace 只存对象键及状态。Trace 中的状态是导出时快照；其后恢复、过期和删除由独立引用登记及状态事件更新，界面读取当前授权状态，不依赖修改已结束 Span。对象存储与 Trace 库通常没有同一事务，不能把先后顺序称作原子提交。

脱敏后上传、确认写入、发布引用及清除遥测全文分别验收。Trace 属性、Event、Log body、嵌套工具参数、SDK/组件错误日志和队列均须扫描；未验证时不能宣称“全文已不进入遥测或 WAL”。观测旁路写失败可降级为缺内容，业务侧法定或授权所需记录的失败策略由业务系统独立决定。

7.2 内容读取、安全渲染与副本脱敏 #

服务端将合法对象键解析到固定受控端点，拒绝任意 URL、路径穿越和不属于当前对象归属的取值；工具或模型不能直接写受信引用。该设计用于降低 SSRF 和越权风险，仍须验证端点、网络和对象级授权。[49]

按 Trace 批量获取受授权的引用清单，正文随节点展开懒加载，缓存键绑定租户、对象版本和许可范围；每次响应仍校验当前权限及对象存续状态，撤销/删除需失效缓存。批量接口不能用一项授权放行整批。正文作为不可信文本安全渲染，禁用活动脚本及未经批准的远程资源；链接与下载走独立授权，取证时保留原始对象的完整性。日志内容的清洗、保护、查看权限和故障测试可参考 OWASP Logging 指南。[50]

业务侧脱敏处理提交给模型或交付用户的数据，观测侧脱敏处理用于存储的副本，两者覆盖对象与失败后果不同。观测默认按字段允许清单采集，协议必需身份字段由受信组件写入且不被误删；字符串模式匹配不覆盖所有嵌套结构、编码内容或敏感业务语义。redaction processor 的支持范围与属性/body处理须按版本验证；Metrics 标签、Log body、Event/Link 属性及组件日志分别验收，不能以单个 processor 配置声称全覆盖。[39]

WAL、评估结果缓冲和清单属于实际数据驻留，须声明内容、期限、加密介质、账号权限、磁盘水位和故障清理；不因临时性免除治理。脱敏、哈希和导出副本仍按可关联性和用途定级。[50]

7.3 资产、批准基线与过程/结果证据 #

建议建立 Agent、模型、工具/MCP、插件、提示模板、Harness、检索/记忆资源及评估器的版本台账，登记负责人、环境、服务身份、许可来源、数据级别、批准范围、依赖和撤销状态；与部署事实核对。台账记录批准状态，执行点仍独立校验实际权限；仅有版本标签或哈希不能证明授权控制生效。其威胁覆盖可与 ASI03/04/06/10 对照。[48]

适用生成内容标识义务时，分别记录显式/隐式标识的注入过程和对实际交付内容的独立抽检。组件自己报告“已注入”只能作为过程证据；文件转换、缓存、导出或界面展示后的实际标识需验证。内容编号和提供者编码按适用规范绑定到实际输出；可观测系统采集注入及验证事件，执行义务仍由提供服务的业务组件承担。[46] [47]

8. 候选项目与技术路线 #

项目按职责列示，单元格只代表官方资料可确认的公开能力，不是横向性能排名。“待核验”表示不能从所引资料确认目标部署版本的行为。共同准入条件是：在目标版本中以 OTLP 或经验证的 OTel 适配器接入，能够导出原始数据与评估定义，完成租户隔离、权限和删除测试；不能满足准入条件的候选不得因界面便利直接承担权威遥测库。

Phoenix 自托管接入按所引官方 FAQ 的 HTTP 6006 与 gRPC 4317 示例配置，端口与认证配置必须以目标部署实际监听及设置为准；其摄入侧自 arize-phoenix 15.10.0 起可将 gen_ai.* 自动转换为 OpenInference，转换覆盖与优先级按目标版本核验。[10] Langfuse 与 Opik 的 HTTP 限制按所引官方文档处理；接入验收仍须验证实际路径、鉴权与字段映射。

“有”指官方文档描述该能力；“—”指该角色不承担完整的 Agent 评估工作流，不能推断其所有版本绝无相邻功能。“目标版验证”要求现场试验，不能直接记为满足准入条件。表中许可指所引主仓库或公开版，插件、依赖和企业模块须逐项复核。对应官方许可依据见各项目主仓库与许可页。[64]

评估路线时，建议先设硬门槛：关联与原始数据可导出、内容权限、目标版本许可与部署位置、故障恢复、删除能力。通过门槛后，使用任务排障与质量闭环、互操作与数据出口、安全治理、运维可靠性、总成本五个维度评分；由业务方先填写权重和评分规则，改变合理权重范围做敏感性分析，报告排序是否稳定。已有列式存储的组织应计入 Langfuse v4 自带 ClickHouse 的重复运维与数据复制成本。三种可比较路线是扩展现有平台、引入专用平台、组合式架构；组合式方案须额外证明跨系统身份、时间、授权、评估定义和故障责任能闭合。未完成试验前，不给出某一产品“最优”的结论。

9. 验收证据与结论边界 #

每项通过须绑定目标版本、负载和故障范围。报告、配置或静态策略只能证明设计存在，不能证明运行时隔离、恢复或质量结果。对外结论应列明已验证范围、未覆盖路径、数据缺口、剩余风险和责任人。

9.1 关键反例与预期结果 #

下表为可复用的设计验收用例，尚未执行。每项须记录目标版本/配置摘要、输入/负载、操作、预期/实际、可见证据、是否通过、失败处置和责任人；状态协议以第 4 章为准。样本通过只支持该范围，不能外推为全生产证明。

10. 类似背景下的落地建议 #

对已有 APM、列式存储和告警平台，但缺少 Agent 语义与质量评估的组织，建议先核对现有平台能否接入 OTLP、按 Run/Trace 检索、隔离租户、处理敏感内容和导出数据；再用同一代表性任务链比较现有平台扩展、专用平台和组合式方案。建议实施顺序及进入/退出条件如下，属于通用落地建议，适用于具有此类基础能力的组织。

代表性任务链至少注入“模型调用成功而任务失败”“工具报错却生成可信答案”“执行者重启”“遥测断流”“越权内容读取”，并分别判定结果、路径、状态、成本、安全和遥测健康。业务团队负责结果与高后果断言；运行时维护任务账本与生命周期；平台团队负责采集和核对；安全团队负责权限与内容；评估团队维护数据集；SRE 负责告警与演练。跨团队指标须指定唯一口径负责人。

参考资料 #

沿用资料的访问日期为 2026-09-30；v1.4 轮重新核对的 [5]、[13]、[22]、[23]、[34]、[36]、[37]、[38]、[39]、[60] 访问日期为 2026-10-01；本轮（v1.5）新增 [10]、[27] 并重新核对 [22]、[38] 相关链接，访问日期均为 2026-10-15。Collector 组件文档固定 v0.162.0；所引规范与产品能力仍应按目标部署版本复核。

[1] Cemri 等，Why Do Multi-Agent LLM Systems Fail?，arXiv:2503.13657，v3，2025-10-26。
[2] Wu，When Errors Become Narratives，arXiv:2606.14589，2026；单作者预印本、个人助理运行时、8 周。
[3] OpenTelemetry，GenAI Semantic Conventions 仓库。
[4] vLLM，Production Metrics。
[5] 阿里云云原生，比扬，AI Agent 可观测公开方案，2026-06-03，阿里云开发者社区厂商账号产品介绍，非独立测试。
[6] Anthropic，How we built our multi-agent research system，2025-06-13，厂商工程实践；只支持该案例的经验。
[7] PawBench，官方仓库，Model × Harness、任务标签、评分及执行记录；当前仓库许可 Apache-2.0。
[8] OpenTelemetry，GenAI Agent Spans、Client Spans，固定提交 0c875949；对应合并日期 2026-09-10。
[9] W3C，Trace Context；OpenTelemetry，Baggage。
[10] Arize，OpenInference Specification；Phoenix，OTel GenAI 语义约定自动转换发布说明（arize-phoenix 15.10.0+）；属性与 span kind 清单以规范站为准，转换行为按目标版本核验。
[11] OpenTelemetry，MCP Semantic Conventions。
[12] OpenTelemetry，GenAI Metrics，固定提交。
[13] Spring AI，Observability，Micrometer、观测名及配置；不等同于本文 GenAI 固定提交。
[14] LangChain4j，Observability，ChatModelListener、流式线程与重试回调边界。
[15] Traceloop，OpenLLMetry 文档。
[16] OpenZipkin，B3 Propagation，传播身份及共享 Span ID；与上报格式分别处理。
[17] OpenTelemetry，Propagators API，传播器及 B3 服务端 Span 要求。
[18] OpenTelemetry，Tracing SDK：Span Processor。
[19] OpenTelemetry，Tracing API：End。
[20] Yao 等，τ-bench，arXiv:2406.12045，2024。
[21] OpenTelemetry，GenAI Events，固定提交。
[22] NIST，Binomial proportion confidence intervals；Efron 与 Tibshirani，An Introduction to the Bootstrap，Chapman & Hall/CRC，1994（所引版本版权页；见出版社预览）；Field 与 Welsh，Bootstrapping clustered data，Journal of the Royal Statistical Society B，2007。
[23] Wang 等，BenchJack，arXiv:2605.12673v1，2026-05-12；评分资产与对抗审计，另见 v1 PDF Appendix C：The Agent-Eval Checklist。
[24] Langfuse，Evaluation Overview。
[25] Google，SRE Workbook: Alerting on SLOs。
[26] American Statistical Association，Statement on Statistical Significance and P-Values，2016；统计决策不能仅依赖 p 值阈值。
[27] Zhang 等，Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems，arXiv:2505.00212，v3，2025-06-02，ICML 2025；Who&When 数据集与 All-at-Once、Step-by-Step、Binary-Search 三类自动归因方法；结果限其数据集与受测方法。
[28] RFC 8785，JSON Canonicalization Scheme，JSON 规范化；不提供语义等价或来源授权证明。
[29] UC Berkeley，BFCL 官方页面，按使用版本及子集复核。
[30] SWE-bench，官方文档，软件问题修复与评测环境。
[31] OSWorld，官方项目，桌面任务及执行环境。
[32] OpenTelemetry，Collector Resiliency。
[33] OpenTelemetry，Collector Internal Telemetry。
[34] OpenTelemetry Collector Contrib，ClickHouse Exporter README。
[35] ClickHouse，ReplacingMergeTree 指南。
[36] OpenTelemetry Collector，Exporter Helper，sending_queue、sizer、batch、storage 与持久化上下文边界；实现按目标版本核验。
[37] OpenTelemetry Collector，Batch Processor，批处理缓存、大小及元数据分组。
[38] OpenTelemetry Contrib，Tail Sampling Processor，内存状态、同 Trace 汇聚、等待与晚到决策；实现按目标版本核验。
[39] OpenTelemetry Contrib，Redaction Processor，属性/body支持和规则按目标版本验证。
[40] OpenTelemetry，Agent/Gateway deployment patterns，另见 Gateway。
[41] OpenTelemetry，Collector distributions 与 Builder，另见 ocb。
[42] ClickHouse，ClickStack Performance Tuning，查询、schema 与索引取舍；示例性能不作为本文保证。
[43] 全国人大常委会，中华人民共和国个人信息保护法。
[44] 全国人大常委会，中华人民共和国数据安全法。
[45] 国家网信办等，生成式人工智能服务管理暂行办法。
[46] 国家网信办等，人工智能生成合成内容标识办法。
[47] 国家标准全文公开系统，GB 45438-2025 人工智能生成合成内容标识方法。
[48] OWASP GenAI Security Project，Top 10 for Agentic Applications 2026。
[49] OWASP，SSRF Prevention Cheat Sheet，受控端点与请求验证。
[50] OWASP，Logging Cheat Sheet，日志数据排除、清洗、访问保护及测试。
[51] OpenLIT，项目概览。
[52] Jaeger，Jaeger v2.21 文档、架构。
[53] Grafana，Tempo Architecture。
[54] SigNoz，LLM Observability。
[55] ClickHouse，ClickStack。
[56] Langfuse，Self-hosting。
[57] Langfuse，OpenTelemetry 接入、RBAC。
[58] Arize，Phoenix 文档、自托管部署。
[59] Arize，Phoenix Authentication。
[60] Arize Phoenix，Endpoint FAQ，以官方重定向后的页面为准。
[61] Comet，Opik Self-hosting、Evaluation。
[62] Comet，Opik OpenTelemetry 接入。
[63] MLflow，Tracing、GenAI Datasets。
[64] 各项目官方许可资料：OpenLLMetry、OpenLIT、Jaeger、Tempo、SigNoz、Langfuse、Phoenix、Opik、MLflow、ClickHouse、HyperDX。