夜雨聆风日期：2026-07-07目标：不是简单“少用 AI”，而是让 AI 少读废话、少重复、少输出废话、少调用高价模型。
0. 为什么 Token 会失控
AI 编码助手和 Agent 系统的 token 浪费，通常不是模型“太贵”这么简单，而是工程流程没有治理：
终端输出太长：
npm test、pytest、mvn test、docker logs一次就塞进几千到几万 token。文件读取太粗：Agent 为了理解项目，把 README、日志、生成文件、lock 文件、构建产物都读进去。
上下文重复：每一轮都重复系统提示词、工具说明、项目规则、历史对话。
输出太啰嗦：模型解释一大堆“正确但没必要”的话。
Agent 系统没有缓存：同样的问题、同样的检索、同样的规划，每次都重新请求 API。
所以，解决 token 的关键不是一个工具，而是一套分层策略：
第一部分：AI 编码助手侧的 Token 节约
这一部分主要针对 Claude Code、Codex CLI、Cursor、Gemini CLI、Cline、Windsurf 等 AI 编码助手。目标是：让编码助手在不降低正确率的前提下，少读、少看、少说。
| RTK | npm testpytest、mvn test、docker logs、git diff 输出很长时 | ||||
| Context Mode | |||||
| Caveman | /caveman、normal mode 是在 AI 聊天里输入 | ||||
| Headroom |
1. RTK：先砍掉终端输出噪音
适合解决什么问题
RTK 的定位很直接：压缩命令输出。它不是替代 Claude Code 或 Codex，而是把终端命令结果变成更适合 AI 阅读的摘要。RTK 官方说明它会对命令输出降噪，并支持 Claude Code、Cursor、Gemini CLI、OpenAI Codex、Cline、Windsurf、GitHub Copilot 等工具；其官网还展示了对大量命令输出平均移除高比例噪音的测试结果。
最典型的场景：
npm testpytestmvn testgradle testdocker logsgit diffripgrep / rg
传统方式是把大量日志直接塞给模型，RTK 的思路是先过滤、聚合、突出错误，再交给 AI。
安装手顺
macOS / Linux / WSL：
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | shexport PATH=”$HOME/.local/bin:$PATH”rtk --versionrtk gain
[INFO] Verification: rtk 0.43.0
[INFO] Installation complete! Run 'rtk --help' to get started.rtk 0.43.0RTK Token Savings (Global Scope)═════════════════════════════════════
Total commands: 5389Input tokens: 9.3MOutput tokens: 1.7MTokens saved: 7.5M (81.3%)Total exec time: 44m19s (avg 493ms)Efficiency meter: ████████████████████░░░░ 81.3%
By Command─────────────────────────────────────
Command Count Saved Avg% Time Impact
─────────────────────────────────────
rtk grep 1282 4.7M 24.3% 12ms ██████████ rtk read 352 1.3M 34.0% 1ms ███░░░░░░░ rtk find 139 637.2K 60.7% 204ms █░░░░░░░░░ rtk git diff 6 164.0K 59.6% 64ms ░░░░░░░░░░ rtk ls -la tests/ 9 138.0K 64.7% 32ms ░░░░░░░░░░ rtk git diff HEAD 2 64.7K 49.0% 1.1s ░░░░░░░░░░ rtk pytest apps/sales... 1 55.8K 100.0% 57.8s ░░░░░░░░░░ rtk pytest apps/sales... 1 55.5K 100.0% 1m4s ░░░░░░░░░░ rtk diff 19 55.5K 60.4% 0ms ░░░░░░░░░░
Homebrew：
brew install rtk-ai/tap/rtkWindows 原生环境，RTK 从 v0.37.2 起支持 Windows native；官方说明要求安装二进制，并且需要 ripgrep。
# 先安装 ripgrep，例如使用 wingetwinget install BurntSushi.ripgrep.MSVC
然后从 RTK Releases 下载 Windows 版二进制，并确认：
rtk --versionAI 编码助手接入
全局接入：
rtk init -gCursor：
rtk init -g --agent cursorwindsurf / antigravity / 其他工具可按对应 agent 初始化：
rtk init -g --agent windsurfrtk init -g --agent antigravity
查看即将写入的配置：
rtk init --show统计节省效果：
rtk gainRTK 的 hook 会拦截 Bash 工具调用，并尝试把命令改写为 RTK 等价命令；官方也提醒该范围主要是 Bash 工具调用，不代表所有 GUI 操作都会被处理。
实战建议
RTK 应该优先装，因为它几乎不改变业务代码，也不要求重构项目。对于企业项目，第一批建议覆盖：
npm testpytestmvn testgradle testgo testdocker logskubectl logsgit diffrg
不要让 Agent 直接读取完整日志。正确做法是：
rtk run ”npm test”rtk run ”docker logs app --tail=2000”rtk run ”git diff”
2. Context Mode：让 Agent 少读原始文件，多用工具化上下文
适合解决什么问题
Context Mode 是一个 MCP 服务器，目标是让 AI 编码助手通过受控工具执行、SQLite / FTS5 / BM25 检索、上下文保存等方式处理项目知识，而不是每次都把大量原文塞进上下文。官方说明它面向 Claude Code、Cursor、Codex、VS Code Copilot 等工具，并强调“把上下文保存下来”和“用工具思考代码”。
适用场景：
大型代码库。
多轮修改同一模块。
需要跨文件调查影响范围。
需要反复查找设计文档、接口、历史结论。
希望减少“Agent 每次重新读项目”的浪费。
Claude Code 安装
前提：Claude Code v1.0.33+。官方推荐通过插件市场安装。
在 Claude Code 中执行：
/plugin marketplace add mksglu/context-mode/plugin install context-mode@context-mode/reload-plugins
验证：
/context-mode:ctx-doctorCursor 安装
Cursor 的官方说明里提到 marketplace 方案仍可能受限，也提供本地配置方式。核心步骤如下。
npm install -g context-modemkdir -p .cursormkdir -p .cursor/rules
创建 .cursor/mcp.json：
{”mcpServers”: {”context-mode”: {”command”: ”ctx”,”args”: [”mcp”]}}}
创建 .cursor/hooks.json：
{”hooks”: {”beforeToolUse”: [{”matcher”: ”*”,”command”: ”ctx hook before”}],”afterToolUse”: [{”matcher”: ”*”,”command”: ”ctx hook after”}]}}
复制规则文件：
CM_ROOT=”$(npm root -g)/context-mode”cp ”$CM_ROOT/configs/cursor/context-mode.mdc” .cursor/rules/context-mode.mdc
重启 Cursor 后验证：
ctx statsCodex CLI 安装
Context Mode 官方文档对 Codex 给出了插件方式和手动方式。Codex 侧需要启用 plugin hooks / hooks。
插件方式：
codex plugin marketplace add mksglu/context-modecodex plugin install context-mode@context-mode
编辑 ~/.codex/config.toml：
[features]plugin_hooks = truehooks = true
设置上下文目录：
echo 'export CONTEXT_MODE_DIR=”$HOME/.context-mode”' >> ~/.bashrcsource ~/.bashrc
重启 Codex CLI 后验证：
ctx stats使用原则
Context Mode 的价值不只是“压缩”，而是让 Agent 形成可复用上下文。建议把它用于：
1. 项目代码地图2. 影响范围调查3. 已确认设计结论4. 常见失败模式5. 测试命令与环境规则6. 历史 bug 原因
不要把所有原始文档都长期塞进上下文窗口。正确做法是：原文入库，回答时按需检索。
3. Headroom：从代理层压缩输入上下文
适合解决什么问题
Headroom 是一个面向 AI Agent 的 token 压缩与上下文管理工具。官方文档显示，它支持 Python SDK、OpenAI-compatible proxy、Agent wrapper、MCP 服务器等模式；支持 Claude Code、Codex、Cursor、Aider、LangChain、CrewAI、Agno、LiteLLM、MCP 等集成方式。
它适合处理：
Agent 读入大量文件。
多工具调用产生大量上下文。
多 Agent 之间需要共享记忆。
想通过 OpenAI-compatible proxy 统一治理请求。
安装
官方说明 Python 版本需要 3.10+，CLI 主要通过 PyPI 发布。
python3 --versionpip install ”headroom-ai[all]”
如果希望隔离安装：
pipx install ”headroom-ai[all]”验证：
headroom doctor性能与节省情况：
headroom perfheadroom dashboard
方式 A：作为 Python SDK
from headroom import compressmessages = [{”role”: ”system”, ”content”: ”You are a senior code reviewer.”},{”role”: ”user”, ”content”: large_context}]compressed = compress(messages)
方式 B：作为 OpenAI-compatible proxy
headroom proxy --port 8787然后把 AI 工具的 base URL 指向本地代理：
export OPENAI_BASE_URL=”http://localhost:8787/v1”适合内部 Agent 平台、LiteLLM 网关、OpenAI-compatible 客户端统一接入。
方式 C：包装 AI 编码助手
headroom wrap claudeheadroom wrap codex
需要回退：
headroom unwrap claudeheadroom unwrap codex
Headroom 官方还提供输出 shaping 相关环境变量，用于减少输出 token；但输出压缩要注意不能破坏错误信息、代码、命令和文件路径。
export HEADROOM_OUTPUT_SHAPER=1headroom proxy --port 8787
实战建议
Headroom 放在 RTK 和 Context Mode 之后更稳：
RTK 先减少命令输出噪音Context Mode 让项目上下文可检索Headroom 再做上下文压缩和代理层治理
不要一开始就粗暴压缩所有输入。对于代码生成、代码审查、SQL、错误堆栈，压缩过头会导致模型漏掉细节。
4. Caveman：压缩 AI 的输出废话
适合解决什么问题
Caveman 的目标是让 AI 编码助手回答更短、更直接。它支持 Claude Code、Codex、Gemini、Cursor、Windsurf、Cline、Copilot 等多种 Agent，并强调代码、命令、错误信息应保持原样。
这类工具适合解决：
模型解释太长每次都写背景介绍明明只要命令，却输出一堆推理说明修 bug 时给太多低价值总结
安装
macOS / Linux / WSL / Git Bash：
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash先 dry-run：
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash -s -- --dry-runWindows PowerShell：
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex◇ Security Risk Assessments ────────────────────────────────╮│ Gen Socket Snyk ││ cavecrew Safe 0 alerts Low Risk ││ caveman Safe 0 alerts Low Risk ││ caveman-commit Safe 0 alerts Low Risk ││ caveman-compress Safe 0 alerts High Risk ││ caveman-help Safe 0 alerts Low Risk ││ caveman-review Safe 0 alerts Med Risk ││ caveman-stats Safe 0 alerts Low Risk ││ ││ Details: juliusbrussee/caveman — Agent skills │├────────────────────────────────╯
针对 Codex / Cursor 等工具安装 skill
官方说明可通过 npx skills add 对不同 Agent 安装。
npx skills add JuliusBrussee/caveman -a codexnpx skills add JuliusBrussee/caveman -a cursor
查看支持对象：
npx -y github:JuliusBrussee/caveman -- --list使用时输入：
/caveman关闭时输入：
normal mode实战建议
Caveman 不应该让模型“少说到看不懂”。企业开发里建议规则是：
说明可以短代码必须完整错误信息必须原样命令必须可复制文件路径必须准确风险必须明确写
一篇关于 Cavewoman / 输出压缩的研究预印本显示，输出压缩在很多 API 模型上能降低实现成本，但输入压缩反而可能带来准确率或成本问题。因此，输出端可以大胆治理，输入端要谨慎压缩。
5. AI 编码助手推荐组合
最小组合
RTK + Caveman适合个人或小团队，成本最低，改动最少。
标准组合
RTK + Context Mode + Caveman适合中大型代码库。RTK 处理命令输出，Context Mode 处理项目知识，Caveman 控制回答长度。
企业组合
RTK + Context Mode + Headroom + Caveman适合公司内部统一治理 Claude Code、Codex、Cursor、Agent 平台和 API 调用。
推荐导入顺序
第 1 周：RTK第 2 周：Caveman第 3 周：Context Mode第 4 周：Headroom / LiteLLM Gateway
原因很简单：先处理最明显的浪费，再引入代理层和平台层治理。
第二部分：Agent 系统 / API 调用侧的 Token 节约
AI 编码助手解决的是“开发者本地使用”的 token 浪费。Agent 系统解决的是“平台级 API 调用”的 token 浪费。两者不同：Agent 系统更需要缓存、路由、预算、检索和记忆管理。
1. 第一步：先计量 token，不要凭感觉优化
OpenAI 提供了 input token count 能力，用于在发送请求前估算输入 token；官方说明它支持 Responses API 格式，并能比本地 tokenizer 更准确地处理工具、图片、schema 等情况。
示例：
from openai import OpenAIclient = OpenAI()result = client.responses.input_tokens.count(model=”gpt-5.5”,input=[{”role”: ”system”, ”content”: ”You are a coding agent.”},{”role”: ”user”, ”content”: ”Review this diff...”}])print(result.input_tokens)
建议每个 Agent 请求记录：
{”agent_name”: ”code_review_agent”,”model”: ”gpt-5.5”,”input_tokens”: 18000,”output_tokens”: 2200,”cached_tokens”: 12000,”tool_calls”: 6,”latency_ms”: 4800,”cost_usd”: 0.21}
没有计量，就无法判断 RTK、RAG、cache、短回答策略到底有没有效果。
2. Provider Prompt Cache：把固定前缀缓存起来
OpenAI Prompt Caching
OpenAI 官方说明，prompt caching 可以降低延迟和输入 token 成本；缓存对较新的模型自动启用，要求命中相同前缀，且静态内容应放在 prompt 前部，变量内容放后部。官方文档还说明，缓存通常在 1024 token 以上生效，并可通过 cached_tokens 字段观察命中情况。
正确结构：
[固定系统提示词][固定工具说明][固定项目规则][固定输出格式][变化的用户输入][变化的检索结果]
错误结构：
[当前时间][随机 request id][变化的用户输入][固定系统提示词][固定工具说明]
示例：
from openai import OpenAIclient = OpenAI()response = client.responses.create(model=”gpt-5.5”,instructions=STATIC_AGENT_POLICY,input=user_task,prompt_cache_key=”company-agent:v1:code-review”)
如果使用 GPT-5.5，官方指南还建议使用 text.verbosity 控制回答详细程度，并把工具专用说明放入工具描述而不是堆在系统提示词里。
response = client.responses.create(model=”gpt-5.5”,instructions=STATIC_AGENT_POLICY,input=user_task,text={”verbosity”: ”low”})
Anthropic Prompt Caching
Anthropic 官方文档支持通过 cache_control 设置缓存断点，适合缓存长系统提示词、工具定义、长文档、多轮任务背景等；默认缓存约 5 分钟，且可选择 1 小时缓存类型。
示例：
import anthropicclient = anthropic.Anthropic()response = client.messages.create(model=”claude-opus-4-1”,max_tokens=1024,system=[{”type”: ”text”,”text”: STATIC_SYSTEM_PROMPT,”cache_control”: {”type”: ”ephemeral”}}],messages=[{”role”: ”user”, ”content”: user_task}])
Agent 系统中，Prompt Cache 最适合缓存：
系统提示词工具定义安全策略输出格式项目固定规则长文档说明
不要把当前时间、用户临时输入、实时搜索结果放到固定前缀里，否则缓存命中率会下降。
3. LiteLLM Gateway：统一做响应缓存和模型路由
LiteLLM 是一个 OpenAI-compatible AI Gateway，可统一接入多家模型供应商，并支持 response caching。官方文档列出的缓存类型包括 memory、disk、Redis、Qdrant semantic cache、Redis semantic cache、S3、GCS 等。
安装
uv tool install ”litellm[proxy]”启动一个简单代理：
litellm --model openai/gpt-5-miniLiteLLM quick start 说明代理默认可作为 OpenAI-compatible endpoint 使用。
配置缓存
创建 config.yaml：
model_list:- model_name: gpt-5-minilitellm_params:model: openai/gpt-5-miniapi_key: os.environ/OPENAI_API_KEYlitellm_settings:cache: truecache_params:type: diskdisk_cache_dir: ./.litellm_cachettl: 600
启动：
litellm --config config.yamlLiteLLM 官方文档说明，Proxy 模式只要在配置中启用 cache: True 就可以打开缓存，并支持 TTL。
Redis 缓存
生产环境更建议 Redis：
litellm_settings:cache: truecache_params:type: redishost: os.environ/REDIS_HOSTport: 6379ttl: 600
Semantic Cache
LiteLLM 也支持 Qdrant semantic cache，可以设置相似度阈值。官方示例里展示了 Qdrant 配置和 similarity_threshold。
litellm_settings:cache: truecache_params:type: qdrant-semanticqdrant_semantic_cache_embedding_model: openai/text-embedding-3-smallqdrant_collection_name: agent_cachesimilarity_threshold: 0.86
缓存使用边界
可以缓存：
FAQ代码解释固定文档问答规范说明模板生成低风险分类任务
不要缓存：
付款、下单、删除、审批等副作用操作权限相关判断实时价格、实时新闻、实时库存安全审查的最终结论用户隐私数据混杂请求
缓存 key 必须包含：
tenant_iduser_rolemodelprompt_versiontool_versionretrieval_versionlocale
否则可能出现跨租户、跨权限、跨版本污染。
4. RAG：不要把所有文档塞进 Prompt
OpenAI Retrieval / Vector Stores 官方文档说明，Retrieval API 使用 vector stores 做语义搜索索引，可以创建 vector store、上传文件、搜索相关片段。
错误方式：
每次把 50 页设计书全文塞给模型。正确方式：
先检索，再只把相关片段交给模型。示例：
from openai import OpenAIclient = OpenAI()vector_store = client.vector_stores.create(name=”project-knowledge-base”,expires_after={”anchor”: ”last_active_at”,”days”: 30},chunking_strategy={”type”: ”static”,”static”: {”max_chunk_size_tokens”: 800,”chunk_overlap_tokens”: 200}})
上传文件：
with open(”basic_design.md”, ”rb”) as f:client.vector_stores.files.upload_and_poll(vector_store_id=vector_store.id,file=f)
检索：
results = client.vector_stores.search(vector_store_id=vector_store.id,query=”订单状态变更 API 的权限校验逻辑”)for item in results.data[:5]:print(item.content[0].text)
OpenAI 文档说明默认 auto chunking 的 chunk size 和 overlap，也支持 static chunking；这意味着我们可以通过 chunk 大小控制每次进入 prompt 的上下文量。
建议：
一般设计文档：chunk 600~1000 tokens代码说明文档：chunk 400~800 tokens错误日志：按异常块切分API 规格：按 endpoint 切分FAQ：按问答对切分
5. 短期记忆：历史对话要 trim / summarize
Agent 系统最容易犯的错误，是把完整对话历史无限追加。LangChain / LangGraph 官方文档给出的短期记忆治理方式包括 trim messages、delete messages、summarize messages、checkpoint、自定义策略等。
Trim Messages
from langchain_core.messages import trim_messagesfrom langchain_core.messages.utils import count_tokens_approximatelytrimmed = trim_messages(messages,strategy=”last”,token_counter=count_tokens_approximately,max_tokens=8000,start_on=”human”,end_on=(”human”, ”tool”))
Summarization
当历史消息超过阈值时，把旧消息总结成状态，而不是全部保留。LangGraph 文档中的 SummarizationNode 支持在超过 token 限制时总结消息，并保留 summary。
from langmem.short_term import SummarizationNodesummarization_node = SummarizationNode(model=model,max_tokens=8000,max_tokens_before_summary=6000,max_summary_tokens=1000)
建议状态结构：
{”current_goal”: ”修复订单取消接口的权限 bug”,”confirmed_facts”: [”取消接口在 OrderController.cancel 中”,”权限校验通过 PermissionService.checkCancelPermission”],”open_questions”: [”管理员角色是否允许跨部门取消订单”],”last_error”: ”403 returned for department admin”}
模型不需要每轮看到完整聊天记录，只需要看到当前目标、已确认事实、未决问题、最近错误。
6. 工具输出治理：让工具先整理，再给模型
Agent 系统里最贵的不是模型思考，而是工具返回内容失控。典型错误：
SQL 查询返回 5000 行日志工具返回 2MB 文本Git diff 返回整个仓库网页抓取返回完整 HTML
正确做法是工具层先加工：
SQL：返回 count、top N、异常样本日志：返回错误聚类、时间段、代表性堆栈Git：返回 changed files、核心 diff、风险文件网页：返回正文抽取、标题、时间、摘要
建议每个工具都加三个参数：
{”max_items”: 20,”max_tokens”: 4000,”summary_mode”: true}
工具返回格式：
{”summary”: ”发现 3 类错误，主要集中在 OrderService.cancel”,”key_findings”: [”403 错误占 82%”,”只影响 department admin”,”最近一次变更修改了 role mapping”],”evidence”: [{”file”: ”src/main/java/.../OrderService.java”,”line”: 128,”text”: ”checkCancelPermission(user, order)”}],”raw_output_truncated”: true}
Agent 需要证据，不需要垃圾桶。
7. 输出 token 控制：让模型按任务类型说话
建议按任务类型定义输出预算：
answer_profiles:bug_fix:max_output_tokens: 1200verbosity: lowcode_review:max_output_tokens: 1800verbosity: mediumarchitecture_design:max_output_tokens: 4000verbosity: highdaily_summary:max_output_tokens: 800verbosity: low
OpenAI 文档说明输出 token 也包含隐藏、格式化、工具和 reasoning 相关结构，max_output_tokens 限制的是整体输出 token，而不只是可见文字。
示例：
response = client.responses.create(model=”gpt-5.5”,input=task,max_output_tokens=1200,text={”verbosity”: ”low”})
8. 模型路由：不要所有任务都上最贵模型
建议分层：
规则判断：代码、正则、小模型分类任务：小模型摘要任务：中小模型复杂设计：高能力模型多文件修复：高能力模型最终审查：高能力模型
简单路由：
def choose_model(task_type: str, input_tokens: int, risk: str) -> str:if risk == ”high”:return ”gpt-5.5”if task_type in [”classification”, ”formatting”, ”simple_summary”]:return ”gpt-5-mini”if input_tokens > 50000:return ”gpt-5.5”return ”gpt-5-mini”
不要让高能力模型做所有“搬运、格式化、分类、截断、简单总结”的工作。
9. 推荐落地架构
企业导入顺序
Phase 1：计量- 记录 input/output/cached/tool tokens- 建立 token dashboardPhase 2：缓存- Provider prompt cache- LiteLLM exact cache- Redis cachePhase 3：上下文治理- RAG- memory trim- memory summary- tool output summaryPhase 4：模型路由- 小模型处理低风险任务- 高能力模型处理设计、修复、审查Phase 5：组织标准- Prompt version- Tool version- Cache key 规则- max token 预算- 禁止 raw log 直接进入模型
方针
API 调用也要分阶段使用：减少无效 token、成本和副作用风险
在 AI Agent 开发中，需要节省的不只是 prompt token，API 调用本身也应该被纳入 token 节约设计。原因很简单：API 返回的响应内容、日志、错误信息、JSON 数据、检索结果，很多时候都会被重新塞回 Agent 的上下文中。也就是说，API 调用越多，返回内容越长，输入 token、外部 API 成本、延迟和调试成本都会一起增加。
特别是在 AI 编码 Agent 或业务 Agent 的开发过程中，不应该一开始就全部接入真实 API。更合理的做法，是按照开发阶段逐步放开 API 调用范围，先确认单点，再确认程序级别的疏通，最后再进入真实 API 的结合验证。
尤其要注意的是，在还没有充分理解某个 Agent 框架或产品的行为之前，不要轻易接入真实 API。因为你可能并不知道它内部会自动调用多少次 tool，失败后是否会自动重试，是否会把完整响应、日志、异常堆栈全部返回给 LLM。这样一来，token 消耗可能会突然变大，调试信息也会变得非常混乱。
更严重的是，如果这些 API 具备副作用，例如新增数据、更新状态、删除记录、发送邮件、创建工单、调用云资源等，那么问题就不仅是 token 成本，而是会变成实际业务风险。
因此，AI Agent 开发中的 API 调用，建议按照下面的顺序推进：
1. API个别调试2. Mock API 疏通3. 最小范围真实 API 结合4. 本番相当验证
这种设计的好处是，早期开发阶段可以只把短小、可控的 mock response 返回给 Agent，避免每次都让 LLM 读取真实 API 的长 JSON、详细日志和异常堆栈。等程序流程、参数结构、异常分支都确认之后，再逐步切换到真实 API。
这样做不仅可以节省输入 token，还能减少外部 API 调用费用、降低调试复杂度，并避免误调用真实业务接口带来的副作用风险。
结论
AI 编码助手侧，最有效的顺序是：
RTK：减少终端输出噪音Context Mode：减少重复读项目Headroom：代理层压缩上下文Caveman：减少输出废话
Agent 系统侧，最有效的顺序是：
Token 计量Prompt CacheLiteLLM Response CacheRAGMemory Trim / SummaryTool Output SummaryModel Routing
真正的 token 优化不是“压缩一切”，而是：
该保留的证据完整保留该检索的内容按需检索该缓存的前缀稳定缓存该总结的历史及时总结该短答的任务不要长篇大论该用小模型的任务不要上大模型
一句话总结：
Token 降本的本质，是把 AI 从“什么都读、什么都说”，改造成“只读必要证据，只说可执行结论”的工程系统。
