Claude API 成本优化：两个 gate 机制减少无效调用

上下文与成本管理

• 先规划关卡。 对于任何预计需要超过约3次工具调用的任务，在首次调用工具之前，先输出一份清晰可见的3—6条要点式计划，并按此执行，而非逐轮试探。如果一项看似简单的任务在未明确规划的情况下已超出3次工具调用，应立即停止并补写计划，再进行下一次调用——切勿让“我只查一下”的念头悄然演变为一场无计划的多步调查。
• 探索委托关卡。 一旦发现为定位正确来源/位置/API所需进行的探索性查找超过2次（包括模式搜索、grep扫描、文档阅读、表或工具发现等），就应停止在主流程中继续推进，将剩余的探索工作交由子代理完成（通过分叉，或使用专门用于纯搜索的“Explore”子代理）。仅将子代理得出的1—3句话结论带回主线程，而非其原始工具输出。即使每次查找的成本都很低（如find_tables或模式查询），也应以次数而非单次调用的规模作为触发委托的依据。
• 默认采用轻量模型关卡。 派生子代理时，优先选择Haiku；只有当该子任务确实需要判断力、综合能力，或超越机械查找/转换的多步推理时，才为其选用Sonnet 5及以上版本——且在选用更高级模型时，应在说明中简要注明任务为何必须如此。在主循环中，将Sonnet 5+保留用于编排与决策类调用。
• 不要按固定节奏主动对上下文进行重总结或裁剪——改写或丢弃早期交互会破坏提示缓存的稳定前缀，迫使下游内容被昂贵地完全重写，往往得不偿失。让框架的自动压缩机制来应对上下文增长；若需手动压缩，也应在自然的阶段边界处进行（例如在完成调研后、开始实施前），而非单纯依据工具调用次数。
• 切勿将完整文件内容、完整命令输出或完整日志直接粘贴进推理过程。应使用rg -n、sed -n，或head -n 50/tail -n 50，仅提取与当前步骤相关的内容行。
• 将相关操作合并为一次交互（如读取+编辑+验证），而非每一步都单独发起一次工具调用。
• 编辑文件时，优先采用针对性的补丁方式，而非整文件重写。
• 若任务天然可拆分为相互独立的阶段，宜为每个阶段开启全新会话，仅传递一段简短的书面交接摘要，而不搬运完整的先前对话记录。
• 根据任务匹配代理类型：选用最适合该工作的最窄口径代理（如纯搜索使用“Explore”），而非默认使用通用型代理，以降低工具调用与上下文开销。
• 默认采用并行化策略：当子任务彼此独立（互不依赖彼此的输出）时，应尽可能并发执行——可在一次交互中批量调用工具，或在一条消息中同时发起多个代理调用——而非串行处理。