token-efficiency

高效使用计算机，节省 Token

优化总成本和获得已验证结果所需的时间。在保留正确完成任务所需证据的前提下，减少输出会有所帮助；额外的搜索、重试和协调可能抵消这些节省。

调用工具前，先问自己：现有证据是否已经能回答问题？下一步决策实际需要哪些信息？

有选择地读取，必要时再扩展

• 使用符合任务需求和工具环境指南的可用筛选读取与搜索功能。对于原生工具无法覆盖的数据转换和查询，使用 shell 管道。
• 先通过文件名、数量或限定范围的匹配来定位文件或符号，然后读取相关片段及其依赖项。结果有歧义时再扩大范围。搜索结果被限制或截断，并不能证明没有其他匹配项。
• 对结构化代码模式使用 AST 搜索；对字面值、配置或日志使用文本搜索。除非反复使用能证明值得安装，否则不要安装新的搜索工具。
• rg 默认会递归。其 -r 标志表示 --replace，而非递归。其 -m 匹配数限制针对每个文件，而不是整个搜索。
• 对于大量 Git 更改，先运行 git diff --stat 或 --name-only，再检查相关文件。直接阅读小范围、针对性强的差异。

在数据源处查询和生成

• 使用 jq 处理项目 JSON；使用支持相应格式的工具处理 YAML、TOML 和 XML。使用 yq 前，先确认安装的是哪个实现，以免误用其选项。
• 简单的分隔文本使用 cut 或 awk；包含带引号字段或嵌入换行符的内容则使用支持 CSV 的解析器。选择既紧凑又能保留数据结构的格式。
• 如果使用短脚本生成重复内容、执行格式转换和机械式编辑，比手动输出更简单可靠，就使用短脚本。选择语言时以正确性为准，不要一概偏向 shell 或 Python。

减少噪声，同时不丢失证据

• 在支持的情况下，使用静默标志并禁用颜色，同时保留故障诊断信息。
• 将不确定或冗长的输出保存到文件，再检查相关部分。重用工具环境已保存的输出，不要仅为重新获取内容而再次运行命令。
• 捕获或管道传输输出时，保留原命令的退出状态；格式化工具执行成功并不能证明原命令成功。
• 保留准确的错误信息、相关限制、失败的尝试，以及用于找回详细信息的路径或 URL。底层状态发生变化时，重新核查证据。

将执行开销纳入考量

• 在支持且获准的情况下，并行运行互不依赖的调用。适合时用 && 串联依赖命令，同时明确区分审批边界。
• 优先使用完成通知，而非轮询。如果必须轮询，在元数据或哈希能以更低成本回答问题时，就使用它们，而不要重新读取内容。
• 只有在隔离或并行能带来足够收益时，才委派工作量大且可拆分的任务。父级上下文更小，不代表总成本更低：应计入子 Agent 的使用成本，并要求其结论附带支持证据的引用。

保留有用上下文并复用缓存

尽可能保持提示词前缀稳定，避免不必要地更改影响提示词的配置。缓存行为和定价取决于服务提供商和模型。

必要时使用工具环境的压缩或上下文管理机制。保留任务限制、已核实的发现、失败的尝试、后续步骤，以及可用于找回详情的引用。评估上下文精简效果时，应考量后续正确性、重试次数、总成本和延迟。