第 20 章测验

对应章节：可观测性与成本 v07

共 8 题，答对率 ≥ 80% 即通过。请完成全部题目后点击「提交」。

Q1为什么「只靠 print 日志」调试 Agent 不够？本章可观测性要回答的核心问题是什么？因为日志文件太大，容易占满磁盘，需要更节省的存储方案因为模型输出不稳定，每条回答都需要人工核对事件流瞬时而逝、print 混在一起分不清会话与先后、中间轮次的用量也不可见——「内部发生了什么、token 花到哪了、坏在哪一类」三个问题都答不上来因为 SSE 协议本身有 bug，需要靠日志定位协议缺陷

Q2事件行的 seq 与 ts 的正确设计是？ seq 是每个会话内部从 0 数的序号，跨会话无法比较先后；ts 是事件在 loop 里发生的精确时刻 seq 是全局递增序号（跨会话可比较先后），ts 是观测层「看到」事件的墙钟时间；两者是观测层自己的视图、不进协议，原始事件原样转发给 SSE seq 和 ts 都是协议字段，前端渲染必须依赖它们 ts 用本地时间戳即可，不需要 ISO 格式

Q3一条 trace 的生命周期是？一轮对话（loop 一次运行）= 一条 trace：该会话第一个事件开 trace（起点=其 ts），done 时累计 usage 并关闭（result ok），error 关闭（result fail）；多轮会话产生多条 trace 一个会话永远只有一条 trace，多轮对话跨轮持续累计 trace 在 POST /chat 时打开，在 SSE 连接断开时关闭只有 done 事件能开 trace，error 事件不计入 trace

Q4costOfCall 的成本数学（含 prompt cache 折扣）是？ (输入 + 输出) 按同一个单价计费，缓存命中只影响速度不影响价格只按输出 token 计费，输入免费缓存命中部分反而按更贵的输出单价计费未命中输入 × 输入单价 + 命中输入 × 缓存单价 + 输出 × 输出单价，除以一百万；cachedTokens 超过 inputTokens 时钳制为输入总量

Q5「稳定内容前置」这条 prompt cache 工程铁律的依据是？供应商按消息条数计费，前置几条能省包装开销 prompt cache 的机制是精确前缀复用——同一 prompt 的开头部分与之前请求逐字节相同才命中并按折扣价计费；所以 system prompt、工具列表等稳定内容放消息历史前面，变化的用户输入放末尾模型对靠前的消息更重视，回答质量更高只有 system prompt 能命中缓存，其余内容都不行

Q6「成本口径」坑——为什么按 trace 核算的成本是下界、不是精确账单？ ch15 协议只在 done 上带 usage，且只带最后一轮 LLM 调用的用量；多轮会话中间轮次的 usage 在协议里不可见，精确记账要在 provider 层按调用记录（或流式 include_usage、或扩展协议） provider 从不返回中间轮次的用量，这是所有供应商 API 的共同限制 trace 存储有容量上限，中间轮次的数据被主动丢弃中间轮次的 token 属于工具执行而非模型调用，不该计入

Q7失败看板三桶 error / tool / budget 的语义与分类优先级是？ budget 最严重（烧钱）排第一，tool 次之，error 最后三种失败各自独立计数，一条 trace 可以同时进三个桶 error（出现 error 事件、本轮崩溃、result=fail）> tool（tool_result ok:false、工具失败但循环存活）> budget（总 token 超预算）；第一条命中的桶胜出，一条 trace 只进一桶只有 error 事件才算失败，tool_result 失败和超预算都不算

Q8观测层为什么不塞进 core？分层红线怎么守？因为 core 代码太长，拆成独立文件只是为了组织代码结构 loop 只做一件事（emit 协议事件）；盖戳/聚合/记账/归桶全部在 onEvent 外面（createTraceRecorder）和纯函数里（cost/failboard）——删掉 server 和 cli，loop 照常能跑能测观测层必须依赖界面层（server/cli）才能工作可观测性需要真实模型 API，core 无法使用