[Feature] 子代理复用：同一会话内恢复已结束的委派，而不是新建冷启动

[Tioit-Wang]

背景

主代理把一块活派给子代理 A，A 读了一圈文件、干完、报告回来。过一会儿主代理又要改同一批文件——现在系统会派一个全新的子代理 A2，它对之前的进展一无所知，要重新读、重新摸结构。A 已经建立的上下文全部作废。

这带来两个实际损失：重复消耗 token 和时间；以及新代理可能基于过时的文件版本下结论，踩过一遍的坑再踩一遍。

目标

同一会话内，再次委派同一个子代理时，让它接着上次没干完的话继续，而不是从零开始。

用户场景

1. 主代理："派 fixer 把 abc 的登录按钮改成红色"
2. fixer 干完报告："已改，第 42 行"
3. 主代理："再把同一个按钮的圆角去掉"
4. 主代理带上次的委派编号再派 fixer → fixer 记得自己改过第 42 行，直接接着干，不通读 abc

功能规则

触发方式

• 主代理想复用，必须显式传上次的委派编号（Task 工具新增 resume 参数）
• 只在文字里说"复用一下"不算，系统按新建处理
• 恢复时不允许换模型：想换模型就开一个新子代理，不要在历史上下文上换脑子

哪些能恢复

上次结局	能否恢复
正常完成	✅ 主力场景
失败（没写报告 / 网络抽风）	✅ 它读过的东西还有价值
被叫停或被中断	❌ 叫停的语义是"这条线不要了"，想接着走得走"唤醒"流程（二期）
还在跑	❌ 报"该委派仍在运行，请先 TaskWait"

关于"还在跑"：不做排队、不做消息追加。子代理一次只处理一个任务，处理完才能派新的。一条链在任何时刻最多只有一个活跃记录，链始终是一条直线。

系统提示

每次给主代理注入一份实时可复用清单：代理名、委派编号、上次的目标、它读过哪些文件（只读工具的产物，最多 8 个，超出截断）。被修改过的文件不列入。

清单里只会出现已结束且达标的链，不会把还在跑的放进去诱导误用。

安全边界

• 每种子代理最多保留 2 条可恢复的链，超出按"最久没用"淘汰
• 一条链累计读过的内容超过 5 万行时，静默从可复用清单里消失，主代理只能开新的——这是防止复用把自己的上下文撑爆
• 只能在自己这个会话内恢复，不跨会话
• 被淘汰的链再被引用时，统一报"找不到该委派"并列出当前可用的，不区分"不存在"和"已回收"
• 恢复时若用户已编辑过该子代理的定义，用最新的定义继续并记一条诊断

用户看到的

• 不做任何"已恢复"的特殊标记
• 点开委派卡片，这条链的所有历史按多轮对话样式连续呈现（任务1→回复1→任务2→回复2），像一个人连续聊天
• 计数器按新的一次从 0 开始，底层保留"接的是哪一次"备查

持久性

应用重启后链关系自动重建——系统扫描历史记录里的委派信息把链接回来，重启不丢链。

不做的事

• 不做常驻子代理进程：复用是"把对话接上"，不是"把进程留着"
• 不做跨会话恢复
• 不做被叫停任务的唤醒（二期）
• 不做链内摘要压缩或占位替换（二期）
• 不做任务排队 / 追加消息
• 不新增用户可见的设置项，阈值都是代码常量

不能被破坏的现有机制

• 主代理的上下文里永远只有子代理的最终报告，中间过程不进主代理上下文
• 停止、权限、并发上限的规则对"恢复来的"和"新建的"一视同仁
• 不新增数据库表、不改存储格式

验收标准

1. 带编号再派同一子代理，它能引用上次的具体结果（文件/行号），不重复读取
2. 不带编号一定是全新冷启动，绝不自作主张接上下文
3. 一条链读得再多也不会把请求撑爆报错
4. 重启应用后链仍可恢复
5. 卡片里看到的是连续多轮对话，不是两段割裂的记录

里程碑

• 一期（本 issue 范围）：显式恢复 + 全套安全边界 + 重启重建 + 实时清单
• 二期：被叫停任务的唤醒、链内压缩、任务排队

[Tioit-Wang]

已在开发处理。

一期范围：Task 工具新增 resume 参数 + 链式委派记录 + 从 transcript 重建子代理上下文 + 父代理系统提示注入可复用清单 + 安全边界（每代理 2 条链 / 5 万行退池 / 严格同会话）+ 重启后链索引重建。

实施在专门的功能分支与 worktree 中进行，完成后按仓库流程提交 PR 关联本 issue。