[swarm] 403/timeout mid-batch: partial work lost, resume re-spends tokens, broken tree blocks others / 批次中途403或超时导致半成品丢失

[myagizmaktav]

Problem. When a swarm/parallel subagent batch hits a quota error (HTTP 403 "usage limit for this billing cycle") or the fixed subagent timeout mid-work, the affected subagents die with their workspace half-written (route files, styles, server functions left in a broken intermediate state). Worse:

1. Partial work is effectively lost — the failed subagent's context contains the research it did (which files exist, what design decisions were made, what was verified). On resume, the agent gets a fresh budget but in practice re-reads and re-verifies large parts of the tree, burning tokens on work it already did.
2. The broken intermediate state blocks everyone else — in our case, 4 of 6 parallel UI agents died mid-edit and left 16 TypeScript errors in the working tree, breaking tsc/build for the remaining agents and the parent agent.
3. Tokens are wasted at scale — each timed-out agent had already consumed a significant budget; resuming from scratch doubles that cost.

Environment: Kimi Code CLI (kimi.com/code), swarm = 6 parallel coder subagents, ~30 min fixed subagent timeout, provider 403 quota error mid-batch.

Expected behavior (feature request — one of):

• Checkpointing: subagents continuously persist a lightweight "research state" (files read, decisions taken, verification results, next steps) to their task dir, so a resumed agent continues where it stopped instead of re-exploring.
• Graceful degradation on quota errors: a subagent hitting 403 should checkpoint and park (resumable for free or near-free), not die mid-write. Ideally the batch scheduler pauses remaining unstarted agents instead of starting them into a known-exhausted quota.
• Token-independent worker mode (optional): a mode where long mechanical tasks (write files X/Y/Z per spec) continue on local compute without consuming the main session's quota, or where the resumed continuation of a quota-killed agent is not billed twice for re-reading its own prior work.

Why it matters: parallel agents are the main speed multiplier of the CLI; a single transient quota blip currently turns a 6-agent batch into 4 half-written file sets + duplicated token spend + manual rescue.

---

问题描述。 当并行子代理批次（swarm）在工作进行中遇到配额错误（HTTP 403 "usage limit for this billing cycle"）或固定的子代理超时时，受影响的子代理会在工作区处于半成品状态时死亡（路由文件、样式、服务端函数停留在损坏的中间状态）。更糟的是：

1. 部分工作实际上丢失 —— 失败子代理的上下文中包含它已完成的研究（读过哪些文件、做了哪些设计决策、验证了什么）。resume 后虽然获得新的预算，但实际上会重新阅读和重新验证大量内容，在已完成的工作上重复消耗 token。
2. 损坏的中间状态会阻塞其他代理 —— 我们的案例中，6 个并行 UI 代理中有 4 个在编辑中途死亡，留下 16 个 TypeScript 错误，导致其余代理和主代理的 tsc/build 全部失败。
3. token 被大规模浪费 —— 每个超时死亡的代理已消耗大量预算；从头恢复等于翻倍计费。

环境： Kimi Code CLI（kimi.com/code），swarm = 6 个并行 coder 子代理，约 30 分钟固定子代理超时，批次中途出现 provider 403 配额错误。

期望行为（功能请求，任选其一）：

• 检查点（checkpointing）： 子代理持续将轻量"研究状态"（已读文件、已做决策、验证结果、下一步）持久化到任务目录，使恢复的代理从断点继续，而不是重新探索。
• 配额错误时的优雅降级： 遇到 403 的子代理应当先保存检查点并挂起（可免费或低成本恢复），而不是在写入中途死亡。理想情况下，批次调度器应在已知配额耗尽时暂停尚未启动的代理，而不是让它们启动后立刻失败。
• 与 token 解耦的 worker 模式（可选）： 一种让长时间机械任务（按规格写文件 X/Y/Z）在本地算力上继续、不消耗主会话配额的模式；或者配额死亡代理的恢复续跑不因重读自己的工作而被二次计费。

为什么重要： 并行代理是 CLI 的主要速度倍增器；目前一次短暂的配额波动就会把 6 代理批次变成 4 个半成品文件集 + 重复 token 消耗 + 人工救援。