在 GitHub 查看原文

L05 练习

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

练习 1：给审批加 escalation（动手类）

README 流派对比承认了收件箱待办的短板：动作延迟到人出现。对紧急审批（如「检测到疑似重大安全事件，要不要立即发布预警」），干等收件箱不行。

1. 给 file_approval_request 加 urgency 参数（"normal" | "urgent"）。
2. urgent 的审批条目同时投一条 notify 条目（占用 L04 打扰配额吗？想清楚再写——提示：审批请求是「需要你决策」，不是「内容更新」，建议走独立通道不占内容配额，但要有自己的频控）。
3. 写测试：urgent 审批产生两条条目（approval + notify），normal 只产生一条。

验收：测试绿 + 一句话说清「审批打扰」和「内容打扰」为什么要分开记账。

练习 2：设计实验——act 模式的「留痕」到底防什么（设计实验类）

1. 假设：没有留痕条目的 act 模式，在「发布结果出错」时无法回答三个审计问题：什么时候发的？发的什么内容（幂等键）？是首发还是重放？
2. 实验设计： - 注释掉 apply_agency act 分支的 add_entry 留痕行，跑 code.py Part 3。 - 假想事故：用户发现 outputs/ 里有一份不该发布的报告。分别在「有留痕」「无留痕」两种状态下，写出你能回答的审计问题清单。
3. 预期：无留痕时你只有 publish 注册表（有 key 和时间，但没有「谁决定发的、当时 agency 是什么级别」）；留痕条目补上了决策上下文。
4. 思考：留痕该记到什么粒度？（提示：至少要能回答「如果当时是 propose 模式，人会看到什么草稿」——所以留痕里要有内容指纹，而不只是「发过了」。）

验收：两份审计清单对比 + 留痕字段设计（3-5 个字段）。

练习 3：digest 的送达时机（取舍类）

build_digest 只负责「汇总」，没规定「何时送」。三种送法：

• A. 固定时刻（每天 18:00 一封）
• B. 攒够 N 条就送（如满 5 条）
• C. 有 major 降级进来（quota_exhausted）就提前送

1. 分别给出三种送法的最坏情况（A：早上的 minor 等 10 小时；B：安静的一周攒不满 5 条，digest 永远不来；C：≈把配额的墙打了个洞）。
2. 你的组合方案是什么？（常见答案：A 做底 + C 做例外；B 单独用几乎总是错的——为什么？提示：送达保证。）

验收：一个组合方案 + 「B 为什么不能单用」的一句话（时间触发保证送达下限，数量触发不保证）。

练习 4：思考题——为什么 approve_entry 是幂等的（架构类）

test_approve_entry_idempotent 验证了：同一审批条目 approve 两次，第二次返回 already_resolved，不重复 resume。

1. 思考：如果不做这个检查，重复 approve 会发生什么？（提示：submit_approval 会对一个不在 interrupt 状态的图再 invoke 一次 Command(resume)——行为未定义，最好情况报错，最坏情况把图从头再跑。）
2. 思考：这和 L01 的「mark_fired 先于 dispatch」、agent-ops L04 的幂等键，是同一个什么原则的三次出现？（提示：面向重试设计——凡是可能被人/调度器/网络重复触发的入口，都要自带「已处理」短路。收件箱按钮会被双击，班次会被补跑，HTTP 会重发。）

验收：在你自己的项目里找一个「会被重复触发但没做短路」的入口，写出它的翻车剧本。