本页目录
L00 练习
改
code.py或时间线剧本，运行观察变化。本课零外部依赖、零真实等待。
练习 1：把「人肉盯梢」的年账单算出来（理解类）
基线里 5 天烧了约 5010 token（估），其中 Day2 型「世界没变的日子」占多少？
- 假设真实世界里「无实质变化日」占 70%（资讯类主题的常态），盯梢周期一年。
- 用基线数字外推：一年人肉盯梢的总 token 中，纯重复劳动占多少？
- 再算注意力账：一年 365 次全量报告推送里，值得读的有几次？
验收：给出两个数字（浪费 token 比例、值得读的推送比例），并用一句话说明为什么「成本累积」和「通知疲劳」是常驻场景的一等风险，而 agent-ops 的轨迹治理管不到它们。
练习 2：设计实验——文本 diff 到底有多不可靠（设计实验类）
Day2 的文本相似度 49% vs 内容相似度 94%，差距来自条目顺序打乱。
- 假设：基于全文 diff 的变化检测，对「顺序变化」「空白变化」会大量误报；对「新增一条」的信号又会被稀释。
- 实验设计：改
eval_agent/ambient_timeline.py的 Day2 剧本—— - 变体 A：只打乱顺序（不动空白） - 变体 B：只动空白（不打乱顺序） - 变体 C：打乱顺序 + 把某条内容真实改写一句 分别跑code.py，记录文本/内容两个相似度。 - 预期：A 文本掉、内容不变；B 两者都≈100%；C 两个指标都动，但你无法从「文本相似度 45%」里读出「其实只改了一句」。
- 思考：这说明变化检测应该在什么粒度上做？（提示：L02 的答案是 item 级内容哈希——粒度对了，「哪一条变了」是免费得到的。）
验收：三组数字 + 一句话结论「为什么全文 diff 不能当变化检测」。
练习 3：给你的真实场景画「五环节倒置」表（迁移类）
从你的工作/生活里挑一个真实盯梢需求（如：盯一个竞品的更新日志、盯一个 GitHub 仓库的 release、盯某个价格）。
仿照 README 第 1 节，画出它的五环节表：现在谁发起？研究什么？谁 diff 增量？何时值得打扰你？谁守着？
验收：五行表格 + 标出「最痛的一环」——大多数场景最痛的不是定时（cron 就能解决），而是「何时值得打扰」。如果你的答案也是它，你就理解了为什么 L04 是全课程的价值观核心。
练习 4：思考题——为什么 Day5 抛异常而不是返回错误字符串（取舍类）
ambient_timeline.py 的 Day5 设计成 raise SourceUnavailableError，而现状 web_search 的兜底是返回「搜索失败」字符串。
- 思考：返回字符串的调用方可以「假装没看见」继续往下走（基线里它就混进了报告）；抛异常的调用方必须显式 catch——两种设计把「处理失败的责任」放在了谁身上？
- 思考：agent-ops L03 已经修过一次「失败字符串污染材料」（结构化降级协议）。本课的 Day5 和它是什么关系？（提示：同一纪律在两个层面——L03 管「一次工具调用的诚实」，本课管「一天的扫描结果的诚实」：failed ≠ 空变化集。）
验收：一句话说清「异常 vs 错误字符串」的责任分配差异，以及「没能看到 ≠ 没有变化」在 L02 会落成什么数据结构。