你的 AI Agent 每天在烧钱，你知道吗？

你有没有算过，你的 AI Agent 系统每轮对话，光系统 prompt 就吃掉多少 token？
我算过。答案是 34,500。每一轮。不管用户问的是"今天天气怎样"还是"帮我写个报告"，这 3 万多 token 雷打不动地注入进去。人设规则、工作指南、长期记忆、工具说明——全量加载，一个不少。
按 Claude 的价格算，一个月下来光系统 prompt 就烧掉几百美金。这钱花得值吗？

全量注入：一个看似合理的坑

大多数 AI Agent 框架的默认做法很简单粗暴：把所有配置文件拼成一个大 system prompt，每轮对话都塞进去。逻辑上没毛病——Agent 随时可能需要任何一条规则，提前加载总比漏掉好。
但实际跑起来你会发现，90% 的对话根本用不到 80% 的规则。
你的 Agent 在闲聊时，需要知道简报模板的详细格式吗？回答一个简单问题时，需要加载完整的定时任务配置规则吗？不需要。但它们就是静静地躺在 context window 里，吃着你的钱。
这还不只是钱的问题。Context window 是有上限的。系统 prompt 占得越多，留给真正对话内容的空间就越少。你花钱买的 200K context，结果自己先占了 34K，这合理吗？

分层加载：核心常驻，细节按需

解决思路其实很直觉——不是所有规则都需要时刻在场。
把配置文件分成两层：
  • 常驻层：精简到极致的核心规则，每轮必须有
  • 按需层：详细的执行规则，用到时再加载
听起来像废话？关键在怎么切。

人设文件：从 16K 砍到 5K

这是最大的一块。原始的 Agent 人设文件塞了所有东西：身份定义、行为准则、各种任务的详细规则、输出模板……16,400 token。
拆法：
  • 常驻：路由表（Agent 知道自己能干什么）、优先级规则、安全红线
  • 拆出去：活动日志规则、简报模板、定时任务规则、数据过滤逻辑、决策日志格式、反馈采集流程、迭代框架、任务管理细则
一共拆出 8 个 reference 文件。Agent 接到具体任务时，read 对应的文件就行。
结果：16.4K → 4.8K，砍掉 71%。

工作指南：从 12K 砍到 3K

工作指南是第二大户。里面大量的内容是"遇到 X 情况怎么办"的详细流程。
但说实话，大部分 session 里 Agent 就是在聊天或者做简单任务。那些复杂流程一周可能触发一次。
保留什么：Session 保护规则（防止 context 溢出的自救机制）、安全底线（绝对不能违反的红线）。其他全部移入 reference。
结果：12.2K → 2.8K，砍掉 77%。

长期记忆：优先级标注 + 定期淘汰

记忆文件相对难砍——每条都觉得重要。但仔细看，里面混了不少工具类信息，比如频道 ID 表、各种配置参数。这些东西 Agent 只在特定操作时需要。
做了两件事：
  • 工具类信息迁移到专门的工具说明文件
  • 每条记忆标注优先级 [P0] / [P1] / [P2] 加上日期，定期淘汰过时的 P2 条目
结果：5.8K → 5.2K，砍掉 12%。幅度不大，但建立了淘汰机制，长期收益可观。

数据说话

三个核心文件的 token 变化：
  • 人设文件：16.4K → 4.8K（-71%）
  • 工作指南：12.2K → 2.8K（-77%）
  • 长期记忆：5.8K → 5.2K（-12%）
  • 合计：34.5K → 12.7K（-63%）
每轮对话省下 21,800 token。按月估算，光这一项就省 $80-110。
💡 关键点：零信息丢失。 所有详细规则都还在，只是从"无脑加载"变成了"按需读取"。Agent 该知道的一样都不少，只是不再每次都把整本手册背在身上。

双模型策略：再砍一刀

光靠分层加载还不够狠。
想想看：你的 Agent 系统里，有多少任务真的需要最强模型？定时检查、日志清理、简单通知推送——这些用顶级模型跑，纯粹是烧钱。
策略很简单：
  • 主力模型（Claude Opus / Sonnet）：处理用户对话、复杂推理
  • 轻量模型（Haiku 或更便宜的选项）：跑定时任务、后台批处理
定时任务往往是 token 消耗的隐形大户。它们每隔几分钟就触发一次，每次都要加载完整 context。用轻量模型跑，单次成本直接降一个数量级。
两招组合拳打下来，月成本从 $568 降到 $120-150。降了 70-80%。

实操要点

如果你也想做类似优化，几个坑提前踩给你：
💡 先量化再动手。 用 tokenizer 工具算清楚每个文件占多少 token。不量化就优化，等于蒙眼开车。
💡 常驻层要够用但不要贪。 路由表必须留——Agent 得知道自己有哪些能力、该调哪个 reference。安全红线必须留——这个没有"按需"一说。其他的，问自己：这条规则 90% 的对话都需要吗？不需要就拆出去。
💡 Reference 文件的命名要让 Agent 能找到。 在常驻层的路由表里写清楚：做 X 任务 → 读 Y 文件。别指望 Agent 自己猜。
💡 监控优化后的表现。 分层加载理论上零损耗，但实际可能出现 Agent 忘记读 reference 的情况。头两周密切观察，发现问题及时调路由表。
💡 记忆文件需要淘汰机制。 不然它会无限膨胀，几个月后又回到原点。优先级标注 + 定期清理，这个习惯要从第一天就建立。

这件事的本质

Token 优化不是抠门，是工程素养。
你不会让一个 Web 应用每次请求都加载全部数据库吧？你不会把所有 JS 文件打成一个 bundle 不做 code splitting 吧？同样的道理，AI Agent 的 context 管理也该有分层、有缓存、有淘汰。
但现在大多数 Agent 框架在这方面几乎是空白。默认全量注入，没有任何优化手段。这不怪框架——早期大家关注的是"能不能跑起来"，而不是"跑起来花多少钱"。
问题是，当你的 Agent 从玩具变成生产系统，7×24 小时运行，每天处理几百轮对话，成本就不再是可以忽略的事了。
我比较好奇的是：当 context window 越来越大（100 万、1000 万 token），这种优化还有意义吗？还是说，未来我们会像对待内存一样对待 context——管它浪不浪费，够大就行？
你怎么看？