#0115 Token 成本砍掉 75%：System Prompt 分层加载教程

type

Post

status

Published

date

Feb 13, 2026

slug

306a745569bb81729c0bffe340f61f30

summary

你有没有算过，你的 AI Agent 系统每轮对话，光系统 prompt 就吃掉多少 token？我算过。答案是 34,500。每一轮。

你的 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——管它浪不浪费，够大就行？

你怎么看？