Appearance
如何量化运行质量：Cost、Latency、Task Success 与 Component Metrics
前置：如何把一次 Run 串成完整链路：Correlation、Distributed Trace 与 Redaction
核心问题：总成本或总延迟变坏时，怎样判断问题来自 Model、Tool、Retrieval 还是 Retry，并用什么事实定义 Task Success？
成本突然上涨时可分辨是 prompt 变长、检索 chunk 变多，还是 retry 增加，而不是只看到日账单。代码任务以测试通过+期望文件变更为成功，而不是 final answer 包含“已修复”。
Mental Model
先让 Runtime 的真实事件形成 trace/log/metrics，再让 deterministic test 验软件 contract，最后用版本化 Eval 衡量模型/Agent 语义质量。
Token / Cost / Latency Metrics
这些指标的价值在于把“这个 Agent 又慢又贵”拆成可定位的成本来源。
至少区分：
text
Model: input/output/cache/reasoning tokens、TTFT、generation time
Tool/Retrieval: latency、timeout、retry
Runtime: queue wait、turn/node count、total wall time
Outcome: task success / failure / degraded例如总 latency 上升并不一定是模型变慢：可能是 Queue wait 从 50ms 变成 8s。只有把组件指标和同一个 run_id/trace_id 关联，优化才不会找错对象。
Task Success Rate
Success 需要基于任务 completion criteria，而不是“模型返回了 final text”。对可确定任务优先程序化判定；开放任务才使用 rubric/human/model judge。
Task Success Rate 必须有可重复的完成定义；不同任务类型可用 deterministic validator、human label 或 rubric。不能把“模型说完成了”当成功。
Component Evaluation
Component eval 定位 retriever/tool/planner/context 子系统；end-to-end eval 看真实任务是否完成。只做后者很难定位回归来源。
它与端到端成功率同时存在。
把一次 18 秒 Run 拆开
假设端到端耗时 18 秒：
text
queue wait 2.0s
context assembly 0.4s
model call #1 5.1s
search tool 3.0s
model call #2 6.2s
serialization/etc 1.3s只记录 run_latency=18s 几乎不能指导优化。拆成 component metrics 后才知道：把 Python 代码优化 30% 可能只省几十毫秒，而减少第二次模型调用或 Tool latency 才是主矛盾。
成本同样要能聚合到 Run：input/output token、cached token、模型单价、Tool 费用、重试次数。然后再看 cost_per_successful_run，而不是只看平均 token。一个便宜但成功率很低、经常 retry 的 routing policy，最终可能更贵。
Failure Modes
Trace/Eval 看不到 MCP/Tool 轨迹
症状： 外部协议调用没有统一 span/domain event。
为什么危险： 失败时不知道是 model、adapter、server 还是 policy。
处理： MCP/Tool/Model/Retrieval 映射统一 trace hierarchy，Eval 关联 run_id/trajectory。
如何验证
| Case | 断言 |
|---|---|
| Trace/Eval 看不到 MCP/Tool 轨迹 | MCP Tool 失败 Run 可从 eval case 下钻 request/span/error。 |
自测
- Task success 不变但成本翻倍。仅看总 token 无法定位原因时，应拆哪些 component metrics？
- p95 latency 上升可能来自 model、queue 或 tool。怎样用分段指标避免把所有慢都归因到 LLM？