核心用法
Task Delegator 是一种会话架构模式，核心机制是通过 sessions_spawn() 将需要工具调用的任务（搜索、文件读写、代码执行、API 调用、写入 soul.md 等）委派给临时子 agent 执行，主会话仅作为调度器与结果汇报者。
关键配置：
cleanup: "delete"：子 agent 记录自动清理，防止上下文膨胀- 可选指定轻量模型（如
zai/glm-4.7-flash）处理简单任务 - 显式触发短语："委托这个"/"delegate this"；隐式触发：任何工具需求自动激活
记忆判断双检查点：
- 委派前：存储重要决策、用户偏好、重大项目
- 结果后：存储事实、配置、决策结果；不存临时信息（新闻、天气）
汇报规范： 要点列表呈现结果，绝不提及"子 agent""委派"等元信息。
显著优点
1. 上下文优化：主会话永不堆积工具输出，长期对话保持轻量快速
2. 成本效益：减少 token 消耗，降低 API 调用成本
3. 架构清晰：职责分离，主会话专注交互，子会话处理脏活
4. 灵活性：可按任务复杂度选择不同模型，简单任务用轻量模型加速
5. 自动维护：cleanup 机制无需人工清理历史记录
潜在局限
- 调试难度：用户无法直接查看子 agent 执行过程，故障排查需额外日志
- 延迟增加：spawn 子 agent 引入额外网络/调度开销，简单任务可能反而变慢
- 过度委派风险：纯对话或简单计算若错误委派，造成资源浪费
- 记忆判断依赖：自动存储逻辑若误判，可能遗漏重要信息或堆积垃圾数据
- soul.md 写入限制：必须委派的设计增加操作复杂度，紧急场景不够直接
适合人群
- 长对话场景用户（研究、编程、项目管理）
- 成本敏感的多轮交互场景
- 需要保持上下文清晰的技术/专业工作流
- 已理解 agent 架构、愿意接受间接操作模式的用户
常规风险
1. 信息丢失：cleanup:"delete" 导致子会话不可追溯，重要中间过程若未显式存储则永久丢失
2. 权限边界：子 agent 若继承过多权限，可能误操作文件/数据
3. 模型错配：轻量模型处理复杂任务导致结果质量下降
4. 记忆污染：自动记忆判断失误，存储冗余或遗漏关键决策
5. 认知负担：用户需理解"主会话≠工作者"的抽象，误用可能导致困惑