Interview Bank

How to reason about it · think before answering

1. The hinge is differ. Saying add logs and metrics is a non-answer; name the structural difference.
2. In one sentence: a single agent's call is a line, a multi-agent request is a tree. One request goes supervisor routing, planner splitting into three, three executors in parallel, a critic rejecting one, that one rerunning, then aggregation — flattened by time you cannot see nesting or which two ran concurrently.
3. So spans must carry a parent pointer; that is the whole game. With it you have a tree, without it a flat list where you know what happened but not what triggered what. A span needs surprisingly few fields — id, parent, name, start and end, a few attributes — to reconstruct the entire tree.
4. How the parent propagates is itself an interview point: do not thread a parentSpanId parameter through every function, because each new node then changes a signature and one omission breaks the chain. Use the language's implicit context — AsyncLocalStorage in JS, contextvars in Python, TaskLocal in Swift, and ScopedValue or ThreadLocal with explicit propagation across thread pools in Java.
5. Then the four questions a dashboard must answer: how much is wrong (pass rate, routing accuracy, degradation rate, fallback rate), where is it slow (p50/p95), what did it cost, and which role spent the money (cost attributed per node). That last one is multi-agent specific and the most actionable — measured, executor nodes took over a third of spend, telling you immediately where to optimise.
6. One foundational point: the dashboard is not a second instrumentation layer, it is an aggregation of traces. The same raw data read across is a tree and stacked up is a dashboard. Two separate sources will eventually disagree, after which nobody trusts either.
7. Finally, tie back to routing: the routing decision is made by a model and the same sentence may route differently next time, so the routing rationale must be recorded — if you do not capture it then, that judgement is gone forever. It is the easiest thing to omit and the thing most needing post-hoc audit.

分析过程 · 先想清楚再作答

1. 题眼在「不一样」。答「加日志加监控」等于没答，要说清结构上的差别。
2. 结构差别一句话：**单 Agent 的一次调用是一条线，多 Agent 是一棵树。** 一次请求走监督者路由、规划者拆三件、三个执行者并行、评审者打回一件、那件重跑、最后汇总——按时间平铺看不出谁在谁里面，也看不出哪两个是并行的。
3. 所以 span 必须带**父指针**，这是全部关键：有它才是树，没它只是一张平铺列表，你知道发生过什么，却不知道谁触发了谁。一条 span 的字段少得出奇——id、父指针、名字、起止时刻、几个属性，就够还原整棵树。
4. 父子关系怎么传下去也是个考点：**不要在每个函数上加一个 parentSpanId 参数**，每加一个节点都要改签名、漏一处断一截。用语言自带的隐式上下文——JS 的 AsyncLocalStorage、Python 的 contextvars、Swift 的 TaskLocal，Java 用 ScopedValue 或 ThreadLocal 配合线程池的显式传播。
5. 然后说面板要回答哪四个问题：错了多少（通过率、路由准确率、降级率、兜底率）、慢在哪（p50/p95）、花了多少、**钱花在哪个角色身上**（按节点分摊）。最后一样是多 Agent 特有的，也最有用——实测执行者节点占了成本三分之一强，一眼就知道压成本先压哪儿。
6. 还有一条地基性的：**面板不是另一套埋点，是 trace 的聚合**。同一份原始数据横着看是树、竖着堆是面板。两套数据来源迟早会对不上，然后没有人相信任何一个。
7. 最后回指路由：路由决策是模型做的，同一句话下次未必给同样的答案，所以必须把**路由理由**一起记下来——当时不记，那次判断就永远丢了。这是多 Agent 里最容易漏、又最需要事后审计的一条。

How to reason about it · think before answering

1. This probes your sensitivity to who holds the state, the SDK-level echo of 'you carry the history yourself'.
2. Ask three questions: can the history be audited, trimmed or replayed, and kept within data-residency rules? previous_response_id keeps history server-side with minimal requests but answers all three poorly; sessions keep it in your store and answer all three, at the cost of managing storage.
3. Conclude: prototypes and internal tools take previous_response_id; user-facing production keeps its own copy, for which sessions are the ready-made path; both can coexist.
4. Of the four session operations, pop_item deserves mention: removing the last turn to honor a user's undo is only possible when you own the history.
5. Tracing makes multi-agent behavior explainable: on by default, one trace per run recording turns, tool calls, handoffs and guardrail results; group a conversation with withTrace or group_id; disable via env var or swap in your own exporter for sensitive data.
6. Expect the follow-up: does tracing ship user data out? By default it goes to the platform dashboard, so regulated settings must disable it or replace the processors.

分析过程 · 先想清楚再作答

1. 这题考的是对「状态放在谁手里」的敏感度，是 30 天课 D1「历史靠你自己搬」在 SDK 层的翻版。
2. 拆法是问三件事：历史能不能审计、能不能裁剪或重放、能不能满足数据驻留要求。previous_response_id 的历史在服务端，请求最小、代码最简，但三个问题都答不好；session 的历史在你手里（内存、SQLite、Redis），三个都能做，代价是自己管存储。
3. 结论：原型与内部工具用 previous_response_id 省事；面向用户的生产系统至少自己落一份历史，session 是现成的落法；两者可以同时用。
4. session 的四个接口（取、追加、弹出最后一条、清空）里 pop_item 值得点出：用户撤回上一句时把最后一轮拿掉再重跑，这是自己持有历史才能做的事。
5. tracing 的作用是让多 Agent 系统的行为可解释：默认开启，每次 run 一条，记录每轮、每次工具调用、交接与护栏判断；用 withTrace 或 group_id 把一段对话归到一起；敏感数据场景用环境变量关掉或换成自己的导出器。
6. 可预期的追问：tracing 会不会把用户数据传出去？默认会传到平台面板，所以合规场景要么关、要么 setTraceProcessors 换成自己的后端。