L02 练习

改 code.py 或 research-assistant 的代码，运行观察变化。本课零外部依赖。

练习 1：读分摊表，定位吞金兽（理解类）

跑 python code.py，看「before：裸奔（预算炸弹）」的分节点成本分摊表。

哪个节点占了 99% 以上的 token？为什么？
如果要给这个节点做成本优化，有哪几种思路？（提示：截断搜索结果长度 / 对搜索结果先做一次便宜摘要再喂 LLM / 限制单子题的 web_search 返回条数）
为什么 writer/summarize 占比这么低？（提示：它们处理的是已经过 researcher 提炼的短文本，不是原始搜索结果。）

验收：能指出 researcher 是吞金兽，并给出至少 2 种针对性优化思路。

软预算（80%）触发节俭模式降级 flash。阈值太高（如 95%）来不及降级就烧穿，太低（如 50%）正常任务也被降级（质量损失）。

假设：软预算阈值应在「正常任务不会误触，但故障能提前降级」的区间。
实验设计： - 在 code.py 的 CostConfig 加一个 soft_ratio 参数（已给）。 - 跑正常场景（无炸弹），设 soft_ratio=0.5 / 0.8 / 0.95，看哪个会让正常任务误进 frugal 模式。 - 跑预算炸弹场景，看 soft_ratio=0.95 时降级是否来得及（还是直接撞硬预算）。
预期：正常任务 70 token，预算 5000，soft_ratio=0.5 时阈值=2500，正常任务远低于此 → 不误触。但若把预算调小（如 100），正常任务 70 token，soft_ratio=0.5 阈值=50，正常任务就超了 → 误触。
思考：这引出一个结论——软预算阈值要和 max_budget_tokens 联动设，不能孤立看 80% 这个比例。

验收：给出一个「正常不误触、故障能降级」的 (max_budget_tokens, soft_ratio) 推荐组合，并说清依据。

方案对比里提到「预测性预算」——按历史估剩余成本提前拒单。本练习做一个最简雏形。

假设：可以用「已完成步数的平均 token/步」估「剩余步数的预期成本」。
实验设计： - 在 cost_budget.py 加一个函数 estimate_remaining(steps_done, tokens_used, estimated_total_steps)：返回 avg_token_per_step × (estimated_total_steps - steps_done)。 - 逻辑：avg = tokens_used / steps_done；剩余成本 = avg × remaining_steps。 - 若 tokens_used + estimate_remaining > max_budget_tokens → 提前告警（甚至拒单）。
预期：这只是一个线性外推（真实 Agent 的 token/步方差很大），但它演示了「预测性」的思路——中途刹车比事后刹车更省。
思考：为什么这个雏形不可靠？（提示：Agent 的 token 消耗不是均匀的——researcher 步巨贵，split 步极便宜。线性外推会被前几步的节点类型带偏。要可靠需要按「节点类型」分别统计历史均值。）

验收：函数能算出一个剩余成本估计值；能说清线性外推的局限和改进方向（按节点类型统计）。

本课的 token 计量优先取 usage_metadata，取不到按字符/4 估算。

思考：中文文本按字符/4 估算会偏高还是偏低？（提示：智谱的 tokenizer 对中文，一个汉字常是 1–2 token，所以字符数 ≈ token 数 × 1～2，字符/4 会偏低。）
思考：这个偏差影响「有无预算刹车」的结构性结论吗？（提示：不影响——绝对值差几倍，但「预算炸弹 vs 正常」的相对差异、吞金兽的定位都不变。）
结论：为什么 mock 测试用估算也够？（提示：测的是机制（预算怎么触发），不是绝对数字。真实数字用 usage_metadata，文档逐处标注。）

验收：能说清估算的方向性偏差（中文偏低），以及为什么它不影响结构性结论。