很多团队做 Agentic AI，第一笔冤枉钱不是花在模型能力上，而是花在混乱的上下文里。
表面看，账单来自一次次模型调用。实际上，真正拖垮成本的，往往是每次请求都在重复处理一大堆不该重复处理的内容。系统提示词、工具定义、MCP 描述、记忆文件、检索结果、日志、历史对话、失败尝试，全都被塞进输入里。模型还没开始回答，成本已经先跑了一大截。
一个智能体刚开始可能很轻，几百个 token 的系统规则，两个工具，几轮对话，看起来毫无压力。可随着功能增加，提示词越来越长，工具越来越多，状态越来越乱，输入 token 很快会从几千变成几万，甚至十几万。更糟的是，很多 token 每次都一模一样，却被反复计费、反复处理。
想让 Agentic AI 真正跑得起，关键不是盲目砍功能，而是把 token 当成工程资源来管理。
第一件事，是复用稳定内容。
大模型在生成答案之前，需要先处理输入。稳定的系统提示词、规则、示例、工具说明，如果每次都完全一样，就不应该每次都重新计算。prompt caching 的价值就在这里。它让服务端识别相同的前缀内容，复用已经处理过的中间结果，从而降低延迟和成本。
但缓存不是魔法，它很挑剔。要想命中缓存，稳定内容必须放在提示词前面，并且尽量保持完全一致。一个多余空格、一个变化的时间戳、一次工具顺序调整，都可能让缓存失效。
所以，提示词结构要像工程代码一样稳定。前面放固定规则、角色约束、示例、工具定义；后面再放用户问题、临时变量、动态状态。越稳定的内容越靠前，越易变的内容越靠后。这样做看似细节，长期下来省下的是持续性成本。
第二件事，是不要预加载沉睡信息。
很多智能体越做越臃肿，是因为开发者习惯把一切都提前塞给模型。几百个工具的完整定义、所有服务器说明、完整记忆、长篇项目背景，统统放进上下文。这样做的直觉是让模型知道更多，结果却常常让模型更糊涂。
上下文不是仓库，而是工作台。工作台上只应该放当前任务需要的东西。工具太多时，可以先提供工具索引或搜索入口，让模型先判断需要哪一类工具，再加载具体工具定义。记忆太多时，可以保留精简索引，把详细内容放在外部文件或数据库中，需要时再取。
这种懒加载思路有两个好处。第一，减少每次请求的输入成本。第二，降低干扰，让模型更容易选择正确动作。很多错误工具调用并不是模型太弱，而是上下文里候选项太多、描述太杂、噪声太大。
第三件事，是让不同难度的任务走不同模型。
并不是所有请求都需要最强模型。分类、格式整理、简单提取、代码库初步搜索、常规问答、低风险摘要，很多时候轻量模型就够了。真正复杂的推理、多步骤规划、高风险决策，再交给大模型。
这里有两种常见思路。
一种是请求进入时先路由。通过规则、关键词、嵌入相似度或轻量分类器，判断任务难度，再决定调用便宜模型还是强模型。这种方式省钱明显，但风险在于一旦路由错了，低能力模型可能从一开始就把任务带偏。
另一种是级联。先让便宜模型回答，再用检查器判断答案是否可靠。如果不可靠，再升级到强模型。它的优势是先看到产物再判断，判断依据更具体。但代价是被升级的请求会多付一次便宜模型成本，还会增加一些延迟。
无论哪种方式，核心都不是追求最低价，而是在可接受质量下减少不必要的大模型调用。最危险的不是小模型不会，而是小模型看起来很会。路由阈值应该保守，早期宁可多升级，也不要为了省钱牺牲可靠性。
第四件事，是持续清理上下文。
Agentic AI 很容易把上下文变成垃圾场。一次工具调用返回了几百行日志，塞进去。一次搜索返回十几段结果，塞进去。读了一个文件，全文塞进去。测试失败，完整错误栈塞进去。重试三轮，每一轮失败记录继续塞进去。
这些内容在刚产生时可能有用，但很快就会过期。模型每次再读它们，不仅浪费 token，还会被过时信息干扰。
更好的做法是把状态分层。原始输出可以进归档区，方便需要时回查。活跃上下文只保留当前推理必需的信息，比如任务目标、已确认事实、关键错误、相关文件、当前假设、下一步行动。重复日志、无关搜索结果、失败路径、完整文件转储，都应该及时移出。
这不是简单总结，而是一套状态管道。工具返回时就应该尽量结构化、降噪、提炼，而不是等上下文爆炸后再被动压缩。真正好的压缩，不只是把长文本变短，而是保留决策价值，删除推理废气。
Agentic AI 的成本优化，最终可以归结为四句话。
能缓存，就不要重复算。
能按需加载，就不要提前塞。
能用小模型，就不要动大模型。
能清理状态，就不要堆满上下文。
这四件事单独看都不复杂，难的是把它们做成系统默认行为。因为 token 成本不是一次性问题，而是每次调用都在发生的复利问题。今天多塞一点，明天多跑一点，月底账单就会把所有工程粗糙都算清楚。
真正成熟的 Agent，不是把所有信息都交给模型，而是知道什么时候给、给多少、给哪一层。上下文越干净，模型越稳定。调用越克制，系统越可控。成本降下来，能力反而更容易释放出来。