Agent 的 observability：
记什么，慢了或贵了怎么查？

英文问法How would you design tracing and observability for an agent system? · Token usage suddenly went up. How do you find the cause? · An agent run is slow. How do you tell which layer is the problem?

考过别家面经原题和 JD，没有 Unity 自己的面经原题 · 阿里控股 Agent Infra 实习一面（2026-03）「如何对一个agent系统做链路追踪，可观测性」（牛客）· 字节火山方舟 Managed Agent 一面（2026-08）「如何记录每轮实验的耗时、Token 消耗、结果和失败路线？」（牛客）· 影石 AI Agent 一面（2026-08）「如果Token消耗突然增加，你会如何定位原因并进行优化？」（牛客）· JD：Etched Research Engineer (Kernels)（2026-10）"read their transcripts closely"（Ashby）· 中文样本里这一类有 17 帖

先弄清楚：每个概念是什么

Trace: 一次 run 的完整记录，形状是一棵树。像带时间的购物小票，每一步的耗时和 token 都列着。
Span: trace 里的一个节点，有开始和结束时间。一次 model call 或 tool call 是一个 span。sub-agent 是子树，主 agent 把 trace id 和当前 span 的 id 传给它。
Metrics: 把很多个 run 的 span 汇总出来的数字。
Transcript: 一次 run 里模型读到的和写出的原文。读了才知道是 tool 描述有歧义、context 里丢了约束，还是 agent 绕过了检查（见 reward hacking）。

看图：一次 run 的 trace 树

图 1：数字是示意。橙色是 model call，蓝色是 tool call，虚线框是 sub-agent 的子树。这个 run 慢在 benchmark 这个 tool call，贵在最后一次 model call，因为 benchmark 的输出整段进了 context。

30 秒回答

I trace each run as a tree of spans: one per model call and one per tool call, with a sub-agent as a subtree. Each span records latency, input and output tokens, the tool's arguments, and whether it succeeded. On top I aggregate metrics: success rate, step count, tokens and cost per task, and p50 and p95 latency. When a run is slow or expensive, the trace shows which span the time or the tokens went to. I still read raw transcripts, because metrics tell me a run failed, not why.

三层各记什么

层	记什么	用来回答
Span	latency、input 和 output token、tool 参数、成功或失败	这一步花了多少
Trace	全部 span，带 task id、model 版本和 harness 版本	这个 run 为什么失败，时间和 token 去了哪
Metrics	成功率、步数、每个 task 的 token 和成本、p50 和 p95 latency	这一版整体变好还是变差

Token 突然变多，按这个顺序查

先在 metrics 上按版本、task 类别和 tool 分组，看是都涨还是某一类涨
再分清涨的是每次 model call 的 input 还是次数
input 变大，就查 tool result 是否变大，比如某个 tool 开始返回整份日志（对策见 context compaction）
次数变多，就查重试和重复的 action（见 tool 失败与重试）
token 没怎么变、成本却涨了，就查 prefix cache 是否 miss，比如 system prompt 或 tool 定义被改过（见 KV cache）
最后挑几条最贵的 trace 读 transcript

第 3 条的算例。context 是累加的，一个 tool result 多出 5000 token，之后每次 model call 都要再读一遍。它在第 5 步进来，run 一共 20 步，就多出 5000 × 15 = 75000 个 input token。

必答点

一次 run 一个 trace，每次 model call 和 tool call 一个 span，sub-agent 是子树
span 里记 latency、token、tool 参数、成功或失败
metrics 看成功率、步数、token、成本、p50 和 p95 latency
慢了按 span 分解，看是 model call、tool call 还是排队
token 变多查三样：tool result 变大、重试变多、cache miss
metrics 只说明失败了，原因要读 transcript

追问

执行时间长，一定是异常吗？（字节原题）

不一定，跑 benchmark 的 task 本来就慢。阈值按 task 类别分开定，和同类的 p95 比。

怎么记录每轮实验的耗时、token、结果和失败路线？

每个 run 写一条记录，有 task id、版本、成功与否、步数、token、latency 和 trace 的路径。失败的 run 再标上失败类型，避免下次重试同一条路线（见 knowledge base）。

来源牛客：阿里控股 Agent Infra 一面 · 牛客：字节火山方舟 Managed Agent 一面 · 牛客：影石 AI Agent 一面 · 牛客：字节 AI大模型开发平台一面（「执行时间长是否一定代表异常？不同任务是否应使用同一规则？」）· PracHub：TikTok SWE 实习（tracing 一题是转述，候选人答 trace ID 和 span ID 串链路）· Etched JD · ml-八股 08 第 36 题

Agent 的 observability：记什么，慢了或贵了怎么查？