在 GitHub 查看原文

L04 练习

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

练习 1：给现状工具做副作用分级（理解类）

现状 research-assistant 的工具：web_search / kb_search / browser_tool.browse_for_evidence / code_interpreter.execute_code / publish_report（新加的）。

1. 把每个工具归到三级（只读 / 可重放 / 不可重放）。
2. 哪些需要幂等键？哪些不需要？
3. code_interpreter 是哪一级？（提示：它写临时文件 + 执行代码，重复执行覆盖无害，算可重放。但如果它把结果写进持久存储呢？）

验收：五张分级卡片，每张说清「重复执行的后果」和「需要幂等吗」。

练习 2：设计实验——内容指纹 vs 纯 thread_id（设计实验类）

幂等键用 thread_id + 内容指纹，而不是纯 thread_id。

1. 假设：纯 thread_id 会误挡改进版（reviewer 打回重写后的新内容被当成重复不发布）。
2. 实验设计： - 在 publish.py 里临时改 idempotency_key 只用 thread_id（去掉内容指纹）。 - 跑 code.py 的 Part 2，看「第 3 次 publish（内容变了）」是否还能发布。
3. 预期：纯 thread_id 下，第 3 次（内容变了）被当成重复 no-op——改进版发不出去，用户永远看到第一版。
4. 思考：这引出一个权衡——内容指纹让「改进版能发」，但也让「同一版被 LLM 微调一个字」就算新发布。怎么平衡？（提示：可以加「内容相似度」判断而非精确哈希，但那又引入模糊性。精确哈希最简单可靠。）

验收：能展示纯 thread_id 的误挡现象，并说清内容指纹为什么是更好的选择。

练习 3：证明幂等是 L06 断点续跑的地基（设计实验类）

L06 会做断点续跑——进程崩在 publish 后、END 前，重启续跑会再走到 publish。

1. 假设：没有幂等键时，断点续跑会导致 publish 被执行两次（一次崩溃前，一次恢复后）。
2. 实验设计： - 在 code.py 里模拟：第一次 publish_report("t1", "内容") 成功（seq=1），模拟「进程崩了」。 - 「重启续跑」：再调一次 publish_report("t1", "内容")（同 thread+同内容）。 - 对比有/无幂等键的发布历史记录数。
3. 预期：有幂等键 → 历史记录 1 条（第二次 no-op）；无幂等键 → 历史记录 2 条（重复发布）。
4. 思考：为什么 L06 必须等 L04 先做？（提示：断点续跑的语义是「已完成的节点不重做」，但「副作用」不能简单用「节点完成」判断——同一个 publish 节点崩前执行了一次、恢复后又执行一次，幂等键才能让它只生效一次。）

验收：能展示「幂等让断点续跑不重放副作用」的证据，并说清 L04→L06 的依赖关系。

练习 4：思考题——Saga 补偿什么时候才需要（取舍类）

方案对比提到「事务/Saga 补偿」是分布式正统，但讲概念不实现。

1. 思考：Saga 是什么？（提示：一个跨多服务的长事务，每步成功则继续，任一步失败则跑之前步骤的「补偿动作」回滚。如：下单→扣库存→扣款，扣款失败要补偿「加回库存」。）
2. 思考：research-assistant 的 publish_report 需要 Saga 吗？（提示：不需要——它是单进程单动作，没有「跨服务跨库」的分布式事务。幂等键就够。）
3. 结论：用一句话说清「什么规模才需要 Saga」（多服务跨库的长事务），以及为什么 Agent 单进程用不上。

验收：能说清 Saga 的适用场景（分布式长事务），以及为什么单体 Agent 用幂等键就够。