智能任务优化（省Token版）

问题在哪

长对话里 Agent 往往堆满工具 Schema、全量 file_read 和未裁剪的 code_run 输出，决策相关信息被稀释，轮次越多越容易重复试错。重复性任务若每次都从零规划，同样步骤会反复占用上下文。

技能如何工作

本技能（SOP-Manager）把 信息密度 当作第一性原理：上下文里每条信息都应服务于当前决策。

• 任务拆解：按依赖区分并行与串行；粒度控制在「一步可验证」（约 1～5 次工具调用）；拆解后合并重叠项，整体约 5～10 个子任务。
• 最小工具集：优先用 code_run 组合实现专用能力；file_read 用分段与关键词锚定，避免全量加载；控制工具膨胀带来的 Schema 与决策歧义成本。
• 四级压缩流水线：Stage 1 对工具结果做阈值截断（如 code_run 对称头尾保留）；Stage 2 定期压缩过期工作记忆与过长标签；Stage 3 在超预算时 FIFO 驱逐（不生成摘要）；Stage 4 在每次工具调用后注入工作记忆锚点（轮次摘要、key_info 检查点）。
• SOP 与三阶段进化：验证成功且可复用的经验写入 SOP；从自然语言 SOP → 优化执行 → 可编译为 code_script，并配合 Token 日志与省 Token 报告做对比。

典型流程：评估复杂度 → 查 SOP →（复杂任务）拆解并征得确认 → 执行并维持压缩纪律 → 更新 SOP 与消耗记录。

适用边界

• 依赖 WorkBuddy 侧配置（如 SOUL.md、SOP 库脚本与 token-logs），与通用「只改提示词」的轻量技能不同。
• Stage 3 直接丢弃被驱逐消息，适合接受「用锚点与 SOP 补偿」的场景，不适合必须完整保留每一轮原文的审计需求。
• 复杂度与技能组合规则见技能内 references；简单任务（预估工具调用 ≤3）不必强行走完整拆解与 SOP 流程。