在 GitHub 查看原文

L02 练习

改 code.py 或 research_assistant/watcher.py，运行观察变化。零联网、零等待。

练习 1：给哈希法制造一次「语义误报」（理解类）

content_hash 对「真实改写」会判变更，即使语义没变。

1. 改 eval_agent/ambient_timeline.py 的 Day2 剧本：把 item-a 的内容换一种说法（语义不变，字面全换，如「LangGraph 1.2 稳定版已发布」→「1.2 版的 LangGraph 现已稳定」）。
2. 跑 code.py：Day2 从「确认无变化」变成「变更 1」。

验收：说清这次「误报」的责任分层——机械层诚实上报「这条动了」没有错；判断「动了但没实质内容」是谁的职责？（L04 语义判级。）为什么不让机械层直接调 LLM 判语义？（每轮必跑的层要便宜。）

练习 2：设计实验——故障期清不清快照（设计实验类）

scan_source 在 fetch 失败时不动快照。

1. 假设：如果故障时清空快照，恢复后的第一次扫描会把所有条目误报为「新增」，触发一轮不必要的全量研究。
2. 实验设计： - 复制 scan_source 改出一个 scan_source_clearing()：except 分支里多一句删该 source 的全部快照。 - 序列跑：Day1（建仓）→ Day5（故障）→ Day4（恢复），对比两种实现的第三步 ChangeSet。
3. 预期：原版恢复扫描 ≈「变更 0 新增 0」或只有真实差异；清空版把 6 条全报「新增」——每次信源抖动都变成一次「假建仓」。
4. 思考：这和 agent-ops L03 熔断器「半开试探」有什么共同精神？（故障期间保存「最后已知好状态」，恢复时增量验证，而不是推倒重来。）

验收：两种实现的恢复 ChangeSet 对比 + 一句话共同精神。

练习 3：写一个新适配器（动手类）

仿照 make_dir_fetch，写 make_search_fetch(query)：用 ddgs 把搜索结果变成条目（item_id 用结果 URL 的 md5，title/content 用标题/摘要）。

• 标注：需联网，不进测试（测试只用 mock 信源）。
• 思考：搜索结果的排序天天变、同一 URL 的摘要可能微调——你的 item_id 和 normalize 设计能不能扛住这两类噪声？（这正是「item_id 要稳定、指纹要规范化」的真实压力测试。）

验收：适配器能对同一 query 连扫两次报「无变化」（在搜索结果稳定的前提下）；说清 URL 做 item_id 的坑（跳转参数/utm 后缀要不要洗）。

练习 4：思考题——gone 为什么「只报一次」（取舍类）

消失的条目从快照删除：下次扫描不再重复报 gone，条目回归时按 new 报。

1. 思考：如果不删（快照永久保留 gone 条目），每次扫描 prev - current 都包含同一批消失条目——「消失」这个事件会被报多少次？下游（L04 判级）会怎样？
2. 思考：删除方案的代价是什么？（「回归」被当成「新增」——对盯梢场景，一条旧闻反复上下架会被反复报新。哪种场景这个代价不可接受？提示：盯「下架商品回归」的监控恰恰想要这个行为。）

验收：一句话说清「事件只报一次」和「状态持续可查」是两种不同需求，本课的 ChangeSet 是事件语义。