可观测性

A2A 流量与模型流量使用相同的遥测管道。用量事件字段会标识调用方、Agent、方法和结果；Prometheus 标签则用于区分 Agent 流量与模型流量。

可以使用这些信号统计 Agent 调用量并监控失败。限流和上游错误会出现在与模型流量相同的可观测性工具中；在 AISIX Cloud 中，预算拒绝也会显示在这些工具中。

用量事件

当网关能够把请求归因到已启用的 Agent 和调用方时，AISIX 会发出一条 A2A 用量事件。因不支持的上游认证、限流、上游失败，或 AISIX Cloud 中配置的预算而被拒绝的调用也包括在内；格式错误的请求体则可能在产生事件之前就被拒绝。

事件会进入与模型用量相同的接收端，并标识调用方、Agent、方法、结果和时间：

字段	值
inbound_protocol	a2a
a2a_agent_name	被调用的已注册 Agent。
a2a_method	调用方原样写入的 JSON-RPC 方法，例如 message/send 或其 1.0 拼写 SendMessage；仅当 AISIX 能从请求体读取该方法时才有值。
a2a_operation	a2a_method 所对应的规范化操作。做聚合时请按此字段分组而不是原始方法：A2A 0.3 和 1.0 会把同一个操作拼成两种写法，无法识别的方法归为 unknown。
a2a_protocol_version	AISIX 向该 Agent 声明的协议版本，0.3 或 1.0。
a2a_task_id	本次调用创建或操作的任务。用它可以把 message/send、tasks/get、tasks/resubscribe 中所有涉及同一任务的请求汇集起来。调用未涉及任务时为空。
a2a_context_id	该任务所属的上下文（会话），用于把一次多轮交互中的多个任务串联起来。
a2a_task_state	Agent 最后上报的任务状态，已归一为 submitted、working、input-required、auth-required、completed、canceled、failed、rejected 或 unknown。没有任何响应携带状态时为空。
a2a_stream_event_count	流式调用中转发给调用方的事件数。非流式调用为 0。
upstream_ttft_ms	Agent 发出第一个流式事件的耗时。结合 upstream_latency_ms，可以区分长时间没有任何输出的流与很快开始输出的流。
prompt_tokens、completion_tokens	消息文本的 Token 数，由网关统计。参见 Token 统计。
api_key_id	发起调用的调用方 API Key。
status_code	调用结果状态。
upstream_latency_ms	上游 Agent 调用耗时。
downstream_latency_ms	调用方等待 Agent 调用的总时间。
request_id、occurred_at	关联 ID 和时间戳。

Token 统计

A2A Agent 不会上报自身用量——协议中根本没有 usage 字段——因此 AISIX 自行统计消息文本：用网关自带的分词器统计调用方消息和 Agent 回复中的文本部分。统计结果写入 prompt_tokens 和 completion_tokens，同时事件带上 usage_estimated: true，表示这些数字由网关得出而非上游上报。需要「供应商实际计费」口径时，请按该标志过滤。

只有 message/send 和 message/stream 会被统计。tasks/get 这类读取操作返回的是 Agent 生成时已经统计过的答案，重复统计会让一个答案按轮询次数被反复上报。

cost_usd 保持为零：Agent 如何收费不是网关能观测到的。这些统计只上报、不计费：它们不会计入调用方 Key 的 tpm / tpd Token 窗口。预算是另一套机制——它限制的是美元花费，而零成本不会产生任何花费。参见流量控制。

文件和数据部分不参与统计。它们的字节不是自然语言，把 base64 内容算进去会让估算失真。

Agent 网关目前只会执行一次贯穿整个请求的上游尝试，因此 upstream_latency_ms 和 downstream_latency_ms 会报告相同的持续时间。保留两个独立字段可使 A2A 记录与其他网关流量保持一致；在其他流量中，重试和网关处理可能使二者不同。

事件不会包含请求或响应消息内容。只有当某个可观测性导出器配置了完整内容采集时，消息文本才会到达该导出器，并且永远不会进入 AISIX Cloud 控制面。

A2A 用量事件通过与模型用量事件相同的路径投递。所有已配置的可观测性导出器都会接收这些事件，因此 A2A 流量会与网关的其余流量一起显示。在 AISIX Cloud 中，它们还会流向控制面的用量接收端。

指标

A2A 请求会出现在网关的 Prometheus 指标中。使用下表中的标签筛选相关指标序列：

目标	指标	过滤条件
按结果统计 A2A 请求。	aisix_requests_total	provider="a2a" 和 model="a2a"
跟踪正在处理的 A2A 请求。	aisix_proxy_in_flight_requests	endpoint="/a2a" 和 inbound_protocol="a2a"
检查 A2A 用量事件发送情况。	aisix_usage_events_emitted_total	handler="a2a"

aisix_a2a_* 系列承载了共享指标族无法表达的维度：调用到了哪个 Agent、调用的是哪个操作。

指标	标签	回答什么问题
aisix_a2a_requests_total	agent、operation、status	某个 Agent 某个操作的调用量和失败率。
aisix_a2a_ttfb_seconds	agent、operation	Agent 发出第一个流式事件需要多久。
aisix_a2a_stream_events_total	agent、operation	转发的事件数。除以流式操作的请求数即为每次调用的事件数。
aisix_a2a_task_state_total	agent、state	各个结束状态的发生速率，例如 failed 占比是否在上升。

aisix_a2a_requests_total 与 aisix_proxy_requests_total{endpoint="/a2a"} 的数字并不一致，这有两处是有意为之。在 Agent 解析出来之前就被拒绝的调用——Key 无效、Agent 未授权、Agent 不存在——没有可归属的 Agent，因此只计入 proxy 系列。被调用方中途放弃的流在这里是 4xx，在那里是 2xx，因为响应确实是以 200 开始的。看 Agent 健康度用这个系列，看路由流量用 proxy 系列。

任务 ID、上下文 ID 和 JSON-RPC 请求 ID 永远不会作为指标标签。正是它们让单次调用可追踪，也正因如此它们不能做标签值；请到用量事件和链路追踪中查找。

筛选用量事件发送情况时应使用 handler 标签。该计数器会限制协议标签的基数，并把 A2A 事件归入 other。

这种标签行为只影响 Prometheus 发送计数器。实际投递的用量事件仍会将流量标识为 A2A，并包含 Agent 名称和方法。

指标通过专用指标监听器的 GET /metrics 暴露。完整指标目录和标签语义请参见指标参考。

验证指标

要验证 A2A 指标是否发出，请先通过网关发送一次 A2A 调用，再抓取专用指标监听器。下例使用默认监听地址和路径；如果启动配置设置了不同的 observability.metrics.prometheus.addr，请相应调整地址。

指标族会在首次观测后注册，因此只有记录调用之后才会出现 A2A 序列：

curl -sS "http://127.0.0.1:9090/metrics" | grep -E 'handler="a2a"|provider="a2a"'

输出应包含以下两类指标样本：

指标	标签
aisix_usage_events_emitted_total	handler="a2a"
aisix_requests_total	provider="a2a"

下一步

你现在已了解 A2A 调用在用量事件和指标中的位置。使用以下指南查看完整指标目录，或调整产生这些信号的流量：

• 指标参考：查看完整指标目录、标签和 A2A 相关说明。
• 限流与预算：对 A2A 调用应用请求限制、并发限制和预算。
• 控制 Agent 访问：将调用方 API Key 的权限限定为特定 Agent 或全部 Agent。