LLM可观测性

与传统微服务应用所关注的黄金三指标（请求数，错误，耗时）类比，我们认为 AI 应用的黄金三指标可能是 Token，Error，Duration。

1. 耗时主要关注的是模型推理延迟，也就是在推理过程中我们通常需要关注模型的首包延迟，即 TTFT(Time to first token)，这个指标反映了相应的速度，还有像 TPOT (Time Per Output Token) 反映生成的效率和流畅度。另外一个比较重要的指标就是吞吐率。吞吐率可以衡量我们这个模型本身，能够同时去支撑多少个推理请求。所以这几个指标是需要进行一些平衡的，三个指标不可能同时满足得特别好。
2. Token 可能是 AI 应用最重要的一个指标，所以每次请求会记录 Token 的消耗情况，甚至我们需要精确地区分 Input Token 和 Output Token 的消耗，因为大家知道模型的定价里面 Input Token 和 Output Token 是不一样的，我们在成本核算的时候，会将输入 Token 和输出 Token 分别进行统计。
3. 不同卡的负载情况也是不一样的，这个也应该上报，并在扛不住的时候，自动熔断降级（比如用其他的卡）

耗时耗在哪？ ==> 全链路追踪

问答质量

我们要解决模型回答得好不好，每次模型的升级和优化，都需要建立一个基线，并且确保模型的迭代满足这个基线，否则回答的质量会导致用户体验受损。为此，我们把模型的 input/output 全部都采集到日志平台中，接下来我们可以筛选出一批记录，通过数据加工，引用外部的裁判员模型，对当前这个模型回答的输入输出结果进行一个评估。

要把Trajectory做好

Trajectory 直译是：轨迹、路径、运行过程。

在 LLM Agent / AI Agent 里，Trajectory 通常指：

Agent 为了完成一个任务，从接收用户问题开始，到最终输出答案为止，中间经历的完整执行过程。

它不只是最终答案，而是包括中间所有步骤。

例如用户问：

“帮我查一下某个法规，并总结适用条件。”

一个 Agent 的 trajectory 可能是：

1. 接收用户问题
2. 判断用户意图：法规查询 + 条件总结
3. 改写检索 query
4. 调用知识库检索工具
5. 读取召回的法规条文
6. 判断哪些条文相关
7. 再次调用工具补充查询
8. 组织答案
9. 输出最终回答

这些步骤合起来，就叫一条 Agent trajectory。

在评估里，trajectory evaluation 就是评估这整条过程是否合理，而不是只看最后答案对不对。比如：

工具选对了吗？
参数填对了吗？
调用顺序对吗？
有没有多余步骤？
有没有漏掉关键检索？
最终答案是否基于前面的工具结果？

所以你可以这样理解：

在你的文档里，Trajectory 建议翻译成：

执行轨迹 或 任务轨迹

如果偏工程可观测性，写 执行轨迹 更自然；如果偏论文和 Agent 评估，写 任务轨迹 或 Agent 轨迹 更合适。

下面是一篇按你给出的对话材料整理出来的文档版总结。核心结论是：AI Agent 可观测性不能只做传统 APM，而要做“轨迹采集 → 轨迹评估 → 失败归因 → 轨迹优化”的闭环。你上传的材料中，已经把相关资料分成了 Survey、AgentTrace/Pockit/Phoenix/Arize、TRAJECT-Bench/LangSmith/AgentEvals、失败归因、ETO/AgentTrek/T-PRA 等几类，这个划分可以直接作为文档主线。

AI Agent 可观测性应该如何做

1. 先明确：AI 可观测性不是普通日志系统

传统服务监控主要看延迟、错误率、吞吐量、HTTP 状态码。但 LLM Agent 的问题是：一次 HTTP 200 也可能返回错误答案；一次请求内部可能包含多次 LLM 调用、RAG 检索、工具调用、参数提取、结果比较和最终生成；失败也不一定来自程序异常，而可能来自模型推理、工具选择、参数构造、检索上下文或多步依赖错误。你上传材料中的 Pockit 翻译明确指出，传统 APM 对“自信地犯错”“无限工具调用循环”“token 成本失控”等问题不可见。

因此，AI Agent 可观测性的目标应该是：

不只是知道系统有没有报错，而是知道 Agent 在每一步做了什么、为什么这么做、工具是否调对、参数是否填对、检索是否靠谱、输出质量是否下降、成本是否失控，以及失败发生在哪一步。

这与 AgentTrace 的观点一致：AgentTrace 将 Agent 可观测性提升为安全性、可复现性、问责性和实时监控的基础层，并强调应捕获 operational、cognitive、contextual 三类结构化轨迹。(arXiv)

2. 总体架构：建议做四层

你给出的材料中，Pockit 把 LLM Observability 拆成四层：Instrumentation、Tracing、Evaluation、Dashboards。这个分层非常适合作为工程落地架构。

这四层可以进一步对应到 Agent 工程闭环：

采集轨迹 → 评估轨迹 → 定位失败 → 优化 Agent → 新版本继续采集。

你上传材料中也明确把这个闭环总结为：记录 reasoning / tool use / retrieval / external I/O / latency / token / errors，然后评估 final answer、tool selection、argument correctness、ordering、dependency，再做失败归因和轨迹优化。

3. 轨迹采集应该怎么做

3.1 用 trace/span 记录完整执行链

每一次用户请求都应该有一个 trace_id，每一个内部步骤都应该有 span_id，并保留父子关系。这样才能把一次 Agent 运行还原成调用树。你上传材料中举过类似结构：root span 是 agent.process_query，下面包括意图分类、RAG 检索、工具调用、响应生成等子 span，并统计 token、cost、latency。

一个比较合理的 trace 结构是：

Trace: agent_run_xxx
├── 用户输入
├── 路由/意图识别
├── RAG 检索
│   ├── query
│   ├── top_k
│   ├── score
│   └── retrieved_docs
├── 工具调用
│   ├── tool_name
│   ├── tool_args
│   ├── tool_result
│   └── tool_latency
├── LLM 生成
│   ├── model
│   ├── prompt_tokens
│   ├── completion_tokens
│   ├── cost
│   └── latency
└── 最终输出

AgentTrace 论文也支持这种结构化记录方式，它提出所有日志应共享 envelope schema，包括 UUID、surface type、trace ID、span ID、UTC timestamp 和结构化事件主体。

3.2 按三类 surface 采集

AgentTrace 的三类 surface 很适合直接转化为工程设计。(arXiv)

这里需要注意：不是所有 cognitive 内容都要完整记录。你上传的 Pockit 翻译中明确建议，生产环境中可以 100% 采集 token、latency、model 等 metadata，但完整 prompt/completion 应采样保存，例如 10% 到 20%；embedding 向量和原始 API 响应通常不建议全量落库。

3.3 自动插桩 + 手动业务 span

工程上建议两种方式结合：

第一，使用 OpenTelemetry 或类似 SDK 自动捕获 LLM 调用、HTTP 调用、数据库调用、Redis、向量库等外部 I/O。AgentTrace 和 Phoenix 相关材料都强调了 OpenTelemetry 在 LLM tracing 中的作用。

第二，对业务语义强的步骤手动加 span，例如：

agent.route_intent
agent.retrieve_knowledge
agent.rerank_docs
agent.select_tool
agent.execute_tool
agent.generate_answer
agent.run_safety_check
agent.generate_followup_questions

因为自动插桩只能知道“调用发生了”，但不一定知道“这一步在业务上代表什么”。AgentTrace 也指出，系统级追踪如果没有认知语义，就难以建立 Agent 推理与系统执行之间的因果联系。

4. 应该统计哪些指标

4.1 基础运行指标

这些指标相当于传统 APM 的延伸，必须全量统计。

但这些指标只能说明系统是否稳定，不能说明 Agent 是否回答正确。你上传材料中明确指出，LLM 应用即使错误率为 0，也可能准确率很低，所以还必须引入质量评估。

4.2 LLM 成本指标

LLM 可观测性必须把成本作为一等指标。材料中也强调 token 成本是真实云账单，失控 Agent 循环可能快速烧钱。

建议至少设置这些保护线：

单请求最大 token 数
单请求最大成本
单用户每小时成本
单组织每日成本
单次 Agent 最大 LLM 调用次数
单次 Agent 最大工具调用次数

你上传材料中的 deterministic guards 示例也包含 token 预算超限、工具调用循环、延迟预算和空响应检测。

4.3 RAG 检索指标

如果系统使用 RAG，检索链路也必须可观测。否则最终答案错了，很难判断是模型幻觉，还是召回内容本身就错。

Phoenix 相关材料也强调 LLM tracing 应记录请求在文档检索、embedding 生成、模型调用、响应生成等组件中的传播路径。

4.4 工具调用指标

Agent 的核心风险之一是工具调用错误。TRAJECT-Bench 的核心观点就是：很多评测只看 final answer，却忽略了工具选择、参数填写、调用顺序这些细粒度轨迹。(OpenReview)

TRAJECT-Bench 明确提出，除了 final accuracy，还应报告 trajectory-level diagnostics，包括 tool selection、argument correctness、dependency/order satisfaction。(arXiv)

4.5 输出质量指标

这是 AI 系统区别于普通后端系统的关键部分。Tracing 告诉你“发生了什么”，Evaluation 告诉你“发生得好不好”。你上传材料中也明确说，Evaluation 是很多团队会跳过但决定生产 AI 成败的一层。

建议不要一开始就做十几个维度。最小可行版本可以先做：

accuracy
relevance
groundedness
format correctness
task success

然后再逐步扩展。

4.6 轨迹质量指标

对于 Agent，最终答案正确不代表轨迹合理。它可能绕了很多弯、调用了多余工具、用了错误中间信息但碰巧答对。因此还要评估轨迹本身。

AgentTrace 论文结论中也提到，结构化 trace 可以为新的 Agent 评估指标奠定基础，例如 reasoning stability、goal fidelity、cross-agent behavioral benchmarking。

5. 应该做到什么程度

5.1 MVP 阶段：先做到“能复盘”

如果系统刚开始建设，不建议一上来就追求完整平台。最小可行目标是：线上出错后，能通过 trace 复盘这次 Agent 到底做了什么。

MVP 至少应做到：

每次请求有 trace_id
每次 LLM 调用记录 model、tokens、latency
每次工具调用记录 tool_name、args、result、latency
每次 RAG 记录 query、top_k、score、doc_id
最终输出和异常可追踪
成本可按请求聚合

你上传材料中的“第 1 天基础插桩、第 1 周添加成本追踪、第 2 周添加确定性 Guards、第 4 周添加 LLM-as-Judge Evals”可以作为落地节奏参考。

5.2 生产可用阶段：做到“能告警”

生产阶段不能只靠事后查 trace，必须有主动告警。

建议全量运行确定性 guard：

token 超预算
工具调用次数超限
同一工具重复调用过多
总延迟超预算
空响应
格式错误
RAG 空召回
工具异常率升高
单用户成本异常

对 LLM-as-Judge 这类成本较高的评估，可以采样运行。你上传材料中建议对 10% traces 做 LLM-as-Judge，同时确定性 guards 对 100% traces 运行，这个策略比较合理。

5.3 成熟阶段：做到“能评估、能归因、能优化”

成熟的 AI Agent 可观测性不只是监控平台，而应该进入研发闭环：

线上 trace → 自动评分 → 低分样本入库 → 失败归因 → 修 prompt / 工具 / RAG / 编排 → 回归评估 → 发布

你上传材料中的 Survey 部分把领域拆成失败分类、失败归因、系统增强与优化、轨迹监控/调试/分析工具、数据集与基准；这说明可观测性最终应服务于评估、归因和优化，而不是停留在日志层。

6. 是否存在 Agent 评估方面的论文？

存在，而且你给出的材料里已经包含了几类。

6.1 TRAJECT-Bench：专门评估工具调用轨迹

TRAJECT-Bench 是非常贴近 Agent 工具调用评估的一篇。它认为现有工具使用评测过于关注最终答案，忽视了工具是否选对、参数是否填对、调用顺序是否正确。因此它提出 trajectory-aware benchmark，用细粒度指标评估 LLM 的 agentic tool use。(OpenReview)

它适合支撑这些内容：

工具选择评估
参数构造评估
工具调用顺序评估
工具依赖关系评估
并行工具调用与链式工具调用评估

如果你论文或文档中要论证“Agent 评估不能只看最终答案”，TRAJECT-Bench 是很合适的引用。(arXiv)

6.2 LangSmith Trajectory Evals / AgentEvals：工程评估方法

LangSmith 和 AgentEvals 更偏工程落地。它们支持两类轨迹评估方式：

trajectory match：把实际轨迹和参考轨迹比较
LLM-as-Judge：让模型根据 rubric 判断轨迹质量

LangSmith 文档明确说，可以用 LLM 评估 Agent 的 execution path；与 trajectory match 不同，LLM-as-Judge 不一定需要参考轨迹。(LangChain 文档)

AgentEvals 的 GitHub 说明也指出，agent trajectory match evaluators 用于判断 Agent 执行轨迹，可以对照 expected trajectory，也可以使用 LLM。(GitHub)

这类材料适合支撑工程实现部分，例如：

严格匹配 strict
无序匹配 unordered
子集匹配 subset
超集匹配 superset
LLM-as-Judge 轨迹评分

6.3 AgentTrace：可观测性也能支撑评估

AgentTrace 不是传统意义上的 benchmark 论文，但它和评估强相关。它提出结构化日志和三层 surface，使 Agent 的推理、执行和外部交互可以被机器读取、分析和复盘。论文还明确提到，这些结构化 trace 可以为 reasoning stability、goal fidelity、cross-agent behavioral benchmarking 等新指标提供基础。

因此它适合支撑：

为什么评估之前必须先采集结构化轨迹
为什么只保存最终输入输出不够
为什么需要 operational / cognitive / contextual 三层 trace

6.4 ETO / AgentTrek / T-PRA：不是单纯评估，而是用轨迹优化 Agent

ETO、AgentTrek、T-PRA 更偏“轨迹优化”，但它们也说明轨迹数据不只是日志，还能反向用于训练和优化。你上传材料中总结了 ETO 的流程：Agent 探索任务，收集失败轨迹，构造成功/失败轨迹对，用 DPO 等方法训练，再进入下一轮优化。

T-PRA 则把主动推荐建模为序列决策/路径规划问题，用 Actor、Advisor、Critic 结构和 DPO 优化长期目标。

这类论文适合支撑：

失败轨迹可以作为优化数据
成功/失败轨迹对可以用于偏好优化
Agent 评估结果可以进入训练闭环
长期任务不能只评估单轮输出

7. 推荐你最终文档中的指标体系

你可以把指标分成 6 组写进文档：

如果只选最关键的一组，我建议是：

trace_id / span_id
LLM tokens / latency / cost
工具名称 / 参数 / 返回值
RAG 召回文档 / score / order
最终答案质量评分
工具选择正确性
参数正确性
调用顺序正确性
任务成功率
失败归因标签

这组指标刚好对应你材料中的核心闭环：采集、评估、归因、优化。

8. 最终结论

AI Agent 可观测性应该做到三个层次：

第一，能看见：每次请求的 LLM 调用、RAG 检索、工具调用、异常、token、成本、延迟都能通过 trace 还原。

第二，能判断：不仅知道请求成功，还要知道答案是否正确、是否基于证据、工具是否选对、参数是否正确、调用顺序是否合理。

第三，能改进：把低质量 trace、失败轨迹、人工反馈、LLM-as-Judge 评分沉淀下来，用于 prompt 回归测试、Agent 轨迹评估、失败归因和后续优化。

一句话概括：

AI Agent 可观测性不是“多打日志”，而是把 Agent 的执行轨迹变成可追踪、可评分、可归因、可优化的数据资产。

下面是我检索后整理出的结论：有类似框架设计，但目前还没有一个“统一标准”能同时完整覆盖 Agent 评估、Prompt 质量评估、Tool 设计评估。更合理的做法是把现有权威材料组合成一个分层评估框架。

1. 先给权威参考文献谱系

一、Agent 整体能力与轨迹评估

这一组文献说明：Agent 评估的基本单位应该是“任务轨迹”，不是单次回答。你前面材料中已经整理过类似闭环：轨迹采集 → 轨迹评估 → 失败归因 → 轨迹优化，其中 TRAJECT-Bench、LangSmith、AgentEvals 正好对应“轨迹评估”部分。

二、Prompt 质量评估

这一组文献说明：Prompt 质量评估不应该靠主观感觉，而应该靠测试集、扰动集、评分 rubric、LLM-as-Judge、人工抽检和回归测试共同完成。OpenAI 的 Prompt Engineering 文档也明确建议构建 evals 来衡量 prompt 行为，并在迭代 prompt 或更换模型版本时监控性能。(OpenAI开发者)

三、Tool / API 调用与工具设计评估

这一组文献说明：Tool 设计评估至少要拆成两层：工具本身设计得好不好，以及 模型是否能正确选择和调用工具。BFCL、API-Bank、ToolBench 更关注后者；OpenAI Function Calling / Structured Outputs 更适合支撑工具 schema 设计的工程规范。(OpenReview)

2. 可以整理成一个统一框架

我建议你把它命名为：

Agent 应用评估框架：Prompt–Tool–Trajectory–Outcome 四层评估模型

这个框架比单纯说“可观测性”更完整，因为它不仅统计运行数据，还能评价 Prompt、工具、轨迹和最终结果。

第 1 层：Prompt 质量评估

Prompt 质量不是看“写得好不好”，而是看它在任务集上的表现是否稳定、可控、可解释、可回归。

这一层的核心指标可以写成：

Prompt Pass Rate
Instruction Following Score
Format Correctness
Robustness Score
Safety Violation Rate
Average Tokens per Prompt
Regression Failure Rate

其中，PromptRobust / PromptBench 可以支撑“鲁棒性测试”，G-Eval 和 Prometheus 可以支撑“LLM-as-Judge 评分”，DSPy 可以支撑“用 metric 驱动 prompt 优化”。(arXiv)

第 2 层：Tool 设计评估

Tool 设计评估不是只看“模型能不能调用工具”，还要看工具本身是否适合被 LLM 调用。很多 Agent 失败并不是模型弱，而是工具 schema 设计太模糊、参数太复杂、工具粒度不合理。

这一层的核心指标可以写成：

Tool Selection Accuracy
Argument Correctness
Schema Adherence Rate
Tool Ambiguity Rate
Tool Redundancy Rate
Tool Error Recoverability
Unsafe Tool Call Rate
Tool Description Coverage

BFCL 很适合支撑“参数与函数调用正确性”；API-Bank 很适合支撑“planning、API retrieval、API calling”；ToolEmu 很适合支撑“工具使用风险与安全失败”；OpenAI Function Calling 和 Structured Outputs 适合支撑“工具 schema 和结构化输出设计”。(OpenReview)

第 3 层：Agent 轨迹评估

这是你前面可观测性文档里最重要的一层。Agent 不是一次输出，而是一条执行轨迹。轨迹评估要回答：它是否按正确顺序完成了正确步骤。

这一层核心指标可以写成：

Trajectory Match Score
Tool Order Accuracy
Dependency Satisfaction Rate
Redundant Step Rate
Step-level Success Rate
Trajectory Efficiency
Failure Attribution Label

LangSmith / AgentEvals 已经把工程方法拆成 trajectory match 与 LLM-as-Judge：前者适合有明确参考轨迹的场景，后者适合判断工具调用是否合理、路径是否高效、是否有不必要步骤。(LangChain 文档)

第 4 层：最终结果与业务效果评估

最终结果仍然要评估，但它应该放在最后，而不是唯一指标。

RAG 类系统可以额外引入 RAGAS。RAGAS 提出 reference-free RAG evaluation，用于评估 retrieval 和 generation 两部分，适合评估“答案是否基于知识库、上下文是否有用、回答是否忠实”。(arXiv)

3. 最终建议：你可以这样写成论文/文档框架

可以直接写成下面这套结构：

1. 评估对象层
   - Prompt
   - Tool Schema
   - Agent Trajectory
   - Final Output
   - Business Outcome

2. 评估方法层
   - Deterministic Check
   - Reference Match
   - LLM-as-Judge
   - Human Review
   - Online Feedback
   - Regression Test

3. 评估指标层
   - Prompt 指标
   - Tool 指标
   - Trajectory 指标
   - Output 指标
   - Cost / Latency 指标

4. 闭环优化层
   - 采集 trace
   - 自动评分
   - 失败归因
   - Prompt / Tool / RAG / Agent 编排修正
   - 回归测试
   - 发布新版本

这个框架的理论依据可以这样对应：

4. 我对“是否有现成统一框架”的判断

目前没有一个学术或工业框架能够完全覆盖：

Prompt 质量
Tool 设计质量
Tool 调用正确性
Agent 轨迹合理性
最终答案质量
业务成功率
安全风险
成本延迟

更准确地说，现在是多套框架分别覆盖不同层面：

• Prompt 层：PromptRobust、G-Eval、Prometheus、DSPy、OpenAI Evals、Promptfoo。
• Tool 层：API-Bank、ToolBench、BFCL、ToolAlpaca、ToolEmu。
• Agent 轨迹层：TRAJECT-Bench、LangSmith、AgentEvals。
• 任务环境层：AgentBench、WebArena、GAIA、SWE-bench。
• RAG 层：RAGAS。

所以你的文档里最好不要说“已有一个完整统一标准”，而应写成：

现有研究已经分别在 Agent 任务评估、轨迹评估、Prompt 鲁棒性评估、工具调用评估和 RAG 评估等方向形成了较成熟的 benchmark 与工程框架。本文可在这些工作的基础上，构建面向 Agent 应用开发的分层评估框架，将 Prompt、Tool、Trajectory、Final Output 与业务效果纳入同一评估闭环。

这句话最稳，也最适合放到论文或系统设计文档里。