Agent Lifecycle Management

Agent 生命周期管理

这是什么

这个 skill 解决的问题不是“怎么启动一个 agent”，而是：

1. 子 agent 什么时候该创建
2. 创建时应该继承哪些上下文
3. 如何限制它的工具与权限
4. 如何记录执行过程，方便恢复和审计
5. 结束后如何做干净的资源回收

如果这些环节缺失，多 agent 系统很容易出现：

1. 上下文污染
2. 权限外溢
3. 任务跑完但状态没收口
4. session 留一堆垃圾
5. 后续无法 resume 或定位问题

在 OpenClaw 里何时使用

当你要做下面这些事时，用这个 skill 的思路：

1. 用 sessions_spawn 启动新的 ACP / subagent session
2. 设计长期运行的线程型 agent
3. 设计一次性后台 agent
4. 审计子 agent 为什么越跑越乱
5. 调查子 agent 结束后是否遗留状态、文件句柄、上下文映射、未清理的外部连接

不适用场景

1. 单轮直接用 read / edit / exec 就能完成的小任务
2. 只是分析架构概念，不涉及本地 agent 运行方式

核心原则

1. 生命周期是协议，不是一次调用。
2. 编排决定“派谁去”，生命周期决定“这个 agent 怎么活、怎么死”。
3. 子 agent 默认应当最小继承，而不是完整复制父上下文。
4. 清理逻辑必须进入 finally 思维，而不是只在成功路径里处理。
5. 能恢复的前提是：你在运行时就记录了足够元数据。

OpenClaw 实战工作流

1. 先判断这个任务是否真的需要独立 agent。
2. 决定用哪种运行方式：
   • sessions_spawn + runtime="acp"：适合明确要求 Codex / Claude Code / ACP harness 的场景
   • sessions_spawn + runtime="subagent"：适合本地隔离推理或任务拆分
3. 决定 mode：
   • mode="run"：一次性任务，完成就结束
   • mode="session"：持续会话，适合线程式长期协作
4. 明确上下文来源：
   • 只给任务摘要
   • 给必要文件路径
   • 给少量历史片段
   • 避免把整段父会话原封不动塞进去
5. 明确权限边界：
   • 子 agent 是否能写文件
   • 是否能执行 shell
   • 是否能对外发送消息
   • 是否允许继续派生子 agent
6. 规定进度与结果格式：
   • 任务开始
   • 中间进度
   • 最终产出
   • 是否需要人工接管
7. 结束时检查：
   • session 是否还需要保留
   • 是否要把结果写回主线程
   • 是否要保留 transcript 便于审计

给 OpenClaw 的落地建议

1. 短任务优先本地完成，别为了“高级”乱开 agent。
2. 长任务、重构、大规模搜索、独立验证，才值得开子 agent。
3. 线程型 agent 要有明确标签和用途，避免越积越多。
4. 结果回传要摘要化，不要把海量过程直接灌回主上下文。
5. 如果子 agent 要长期存在，必须有清晰 owner 和退出条件。

常见失败模式

1. 把父会话整段复制给子 agent，导致上下文臃肿。
2. 让子 agent 继承了不该有的高权限。
3. 任务结束后没有清理 session 或状态映射。
4. 需要恢复时，发现没有记录任务类型、模型、工具面。
5. 主 agent 把关键责任都甩给子 agent，自己不做最终把关。

你可以产出的东西

1. 一个“子 agent 生命周期检查清单”
2. 一个“哪些上下文允许继承、哪些必须裁剪”的表
3. 一个“spawn / 运行 / 回传 / cleanup”流程图