From dc213feb0e3a548ea36fed3759d21b2f6ae13661 Mon Sep 17 00:00:00 2001 From: cfdaily Date: Tue, 26 May 2026 08:20:00 +0800 Subject: [PATCH] auto-sync: 2026-05-26 08:20:00 --- docs/design/v2.7.2-counter-lifecycle-fix.md | 30 ++++++++++++++------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/docs/design/v2.7.2-counter-lifecycle-fix.md b/docs/design/v2.7.2-counter-lifecycle-fix.md index c61c55a..6fa2ec8 100644 --- a/docs/design/v2.7.2-counter-lifecycle-fix.md +++ b/docs/design/v2.7.2-counter-lifecycle-fix.md @@ -1,9 +1,9 @@ # v2.7.2 Counter 生命周期修复 -**版本**: v1.0 +**版本**: v1.1 **日期**: 2026-05-26 **作者**: 庞统 -**状态**: 待评审 +**状态**: 评审修订中（v1.1 采纳部分评审意见） --- @@ -312,11 +312,23 @@ Gateway timeout = 600s（10 分钟），3 次续杯 = ~30 分钟。 --- -## 7. 请评审 +## 7. 司马懿评审意见处理（mail-1779726169654） -1. counter 下沉到 spawn_full_agent 的方案是否合理？ -2. A5/A6 不应出现，出现时标 failed + escalate 的处理是否过重？ -3. 冷却时间 120s 是否合适？ -4. 进程存活性检查放在 ticker 还是独立机制？ -5. dispatcher 简化后，Mail 的 on_complete（幻觉门控）是否受影响？ -6. 遗漏风险？ +| 评审意见 | 结论 | 理由 | +|---------|------|------| +| wrapped_on_complete 加 try/finally | ✅ 采纳 | 防御性编程，确保 counter release 和业务回调都执行 | +| A5/A6 加 context 日志 | ✅ 采纳 | 排查方便 | +| per-provider 冷却 | ⏭ 延后 | 低优先级，先做 per-agent | +| crash_count per-agent 累计，禁用 agent | ❌ 不采纳 | 崩溃可能是任务问题不是 agent 问题。保持 per-task 3 次标 failed，通过 escalate 通知用户自行判断 | +| can_acquire 失败推回 claimed | ❌ 不采纳 | retry 路径下 can_acquire 不会失败（asyncio 单线程无竞态）。release → can_acquire → acquire 是内存同步操作，中间无 await | +| release 和 acquire 之间有竞态窗口 | ❌ 不存在 | Python asyncio 单线程，三步都是内存同步操作，无竞态 | + +## 8. 实现检查清单 + +- [ ] counter.py：新增 cooldown 机制 +- [ ] spawner.py：spawn_full_agent 加 counter acquire/release + wrapped_on_complete（try/finally） +- [ ] spawner.py：_classify_outcome 去掉 release_counter，只有 A2/A3 触发 retry +- [ ] spawner.py：_do_retry 通过 spawn_full_agent 重试 +- [ ] spawner.py：_handle_exit 简化（A9 推回 pending，A5/A6 标 failed + context 日志） +- [ ] dispatcher.py：去掉 counter acquire/release 逻辑 +- [ ] ticker.py：_check_timeouts 加进程存活性检查（per-task crash_count）