Agent系统提示词从1.4万Token压缩至200：Token账单降85%的Pi方案

1. 从一次账单复盘说起：为什么我要动系统提示词

去年底做季度成本复盘的时候，我发现一个很尴尬的事实：团队里几个跑自动化任务的 Agent 服务，单月 Token 消耗里，真正用于“干活”的输出部分只占不到两成，剩下八成全是输入侧的开销。而输入侧里，最大的一块不是用户提问，也不是检索回来的上下文，而是每次请求都要原封不动带上的系统提示词。

当时我们用的是 Claude Code 这套方案，系统提示词加上工具定义、行为约束、格式规范、安全条款，打包下来稳定在 1.4 万 Token 上下。这个数字单看不算夸张，但你要知道，Agent 类应用的特点是一轮任务里会发起几十甚至上百次模型调用。每一次调用，这 1.4 万 Token 都要重新计费一遍。一个稍微复杂点的多步任务，光系统提示词就要烧掉上百万 Token 的输入量。

我算过一笔账：假设单次任务平均调用 60 次模型，系统提示词 1.4 万 Token，那就是 84 万 Token 的纯“背景开销”。按主流模型的输入价格折算，一个任务光背景就吃掉几块钱。一天跑几百个任务，一个月下来就是一笔相当可观的支出。更别提很多任务其实很简单，比如“把这段文本分类”“提取这个字段”，结果也要背着 1.4 万 Token 的包袱跑，性价比低得离谱。

所以这次迁移的核心目标非常明确：把系统提示词从 1.4 万 Token 压到 200 Token 级别，同时不牺牲任务完成质量。最终实测下来，Token 账单降了 85% 左右，任务成功率没有明显下滑。这套方案我内部叫它“Pi”，不是某个现成框架的名字，而是我们自己对“精简提示词 + 按需注入”这套思路的代号。下面我把整个拆解、设计、落地、踩坑的过程完整讲一遍，适合正在做 Agent 成本优化、或者被系统提示词膨胀困扰的同行参考。

2. 拆解 1.4 万 Token：系统提示词到底胖在哪

2.1 逐段拆解：哪些内容是“刚需”，哪些是“惯性”

动手砍之前，我先做了一件事：把那份 1.4 万 Token 的系统提示词完整打印出来，逐段标注用途和 Token 占比。不拆不知道，一拆吓一跳。大致分布是这样的：

看完这张表，问题就很清楚了：真正每轮都必需的，只有工具定义里跟当前任务相关的那一小部分。角色设定、格式规范、行为准则、示例，这些全是“以防万一”塞进去的，结果变成了每轮都付费的固定成本。

这里有个认知误区值得说透。很多人写系统提示词的心态是“多写点总没坏处，模型看到会更听话”。但在 Agent 场景下，这个心态是致命的。因为系统提示词不是写一次就完事，它是乘在调用次数上的。你多写 1000 Token，乘以 60 次调用，就是 6 万 Token 的额外成本。写得越多，边际收益越低，边际成本越高。

2.2 冗余的根源：把“文档”当成了“提示词”

我后来复盘，1.4 万 Token 膨胀的根本原因，是把系统提示词当成了一份产品说明书来写。里面充斥着大量解释性、描述性、防御性的文字，比如“你是一个专业的助手，你应该……”“请注意，在某些情况下……”“如果用户要求……那么你需要……”。

这些文字对人来说很友好，读起来清晰。但模型不需要这么多铺垫。模型需要的是指令，不是文档。一份好的精简提示词，应该像给一个熟练工写的便签，而不是给新人写的培训手册。熟练工你只需要说“把这批货按颜色分三堆”，不需要解释什么是颜色、为什么要分堆、分错了会怎样。

举个具体的例子。原来有一段关于输出格式的描述，洋洋洒洒 800 多 Token，讲了这个字段怎么填、那个字段什么含义、遇到空值怎么办、日期用什么格式。后来我把它压缩成一句：“输出 JSON，字段：id(int), name(str), date(YYYY-MM-DD)，空值用 null。” 效果几乎一样，Token 直接砍到 30 个。

2.3 一个关键判断：系统提示词的“边际价值”在递减

这里我要抛出一个可能有点反直觉的观点：系统提示词超过一定长度后，边际价值是递减的，甚至可能是负的。

原因有两个。第一，模型对超长提示词的注意力是会被稀释的。1.4 万 Token 里，真正影响当前任务的关键指令可能就那几百 Token，淹没在大量无关内容里，模型反而容易抓不住重点。第二，过长的提示词会引入指令冲突。你写了十条行为准则，其中两条在某个边界情况下是矛盾的，模型就会摇摆，输出不稳定。

我实测过一个对比：同一个任务，用 1.4 万 Token 的完整提示词，和用 200 Token 的精简提示词，在简单分类任务上准确率分别是 94% 和 93%，几乎没差别；但在多步推理任务上，精简版反而略高一点，因为干扰信息少了。这个结果直接坚定了我砍提示词的决心。

3. Pi 方案的整体设计：200 Token 是怎么做到的

3.1 核心思路：把“常驻”变成“按需注入”

Pi 方案的核心思想一句话就能说清：系统提示词只保留最底层的“身份 + 铁律”，其余全部改成按任务动态注入。

原来的模式是“一次性把所有可能用到的东西都塞进系统提示词”，Pi 的模式是“系统提示词只留骨架，具体内容在每次请求时根据任务类型拼装”。这就像原来你出门背一个装满所有工具的登山包，现在改成根据今天去哪、干什么，只带对应的工具腰包。

具体来说，Pi 的系统提示词骨架固定为 200 Token 左右，内容大致是：

• 一句话身份定义（约 20 Token）
• 三条不可违背的铁律（约 80 Token）
• 输出必须严格遵守当次请求中给出的格式（约 40 Token）
• 遇到无法处理的情况直接说明，不要编造（约 60 Token）

就这些。没有角色扮演，没有长篇行为准则，没有示例。剩下的所有信息——工具定义、格式规范、领域知识、少样本示例——全部通过任务模板在用户消息里动态注入。

3.2 为什么这样设计不会翻车

看到这里你可能会担心：系统提示词这么短，模型会不会不听话？会不会乱输出格式？

我的实测结论是：只要把关键约束放在“离任务最近”的位置，效果比放在遥远的系统提示词里更好。这是有依据的。模型处理上下文时，对靠近当前任务的内容注意力更集中。你把格式要求写在用户消息里、紧挨着任务描述，模型遵守的概率反而比写在 1.4 万 Token 开头的系统提示词里更高。

另一个保障是外置校验。原来系统提示词里那 10% 的安全合规条款，我全部挪到了模型输出之后，用规则引擎和轻量校验模型做后置检查。格式不对就重试或修正，内容违规就拦截。这样既省了每轮的输入 Token，又把校验做得更可靠——因为规则引擎是确定性的，比让模型“自己注意”靠谱得多。

3.3 任务模板的设计原则

动态注入的关键是任务模板。我设计模板时遵循三条原则：

第一，一个模板只服务一类任务。分类任务一个模板，抽取任务一个模板，多步推理一个模板。不要试图做一个万能模板，那又会回到膨胀的老路。

第二，模板里只放这类任务必需的信息。工具定义只放这类任务会用到的工具，格式规范只放这类任务的输出格式，示例只放一两个最典型的。

第三，模板本身也要精简。我给自己定了个硬指标：单个任务模板加上系统提示词骨架，总输入不超过 800 Token。实测下来，大部分任务模板能控制在 300 到 500 Token。

4. 实操落地：从迁移到验证的完整流程

4.1 第一步：给现有任务做“提示词审计”

迁移不是拍脑袋就改，先得摸清家底。我写了个脚本，把线上所有 Agent 任务的请求日志拉出来，统计每个任务的系统提示词 Token 数、平均调用次数、任务类型分布。这一步的目的是找出哪些任务是 Token 消耗大户，优先优化它们。

审计结果很有意思：消耗最高的不是最复杂的任务，而是调用次数最多的简单任务。比如一个字段抽取任务，单次调用系统提示词 1.4 万 Token，一个任务平均调用 40 次，总消耗 56 万 Token，但任务本身逻辑很简单。这类任务就是优化的重点，改起来收益最大、风险最小。

4.2 第二步：拆分系统提示词，建立“骨架 + 模板”结构

审计完之后，开始动手拆。我把原系统提示词按前面那张表的分类，逐块决定去向：

• 身份定义：压缩成一句话，进骨架。
• 工具定义：按任务类型拆分，进对应模板。
• 格式规范：按任务类型拆分，进对应模板。
• 安全合规：全部外置到后置校验，不进提示词。
• 行为准则：只保留三条最核心的，进骨架，其余删除。
• 示例：按任务类型拆分，每个模板最多留两个。

拆分过程中有个技巧：用“删除测试”判断一条内容是否必需。把这条内容删掉，跑一遍测试集，如果任务成功率没变化，那就说明它可有可无，果断删。我靠这个方法删掉了将近 60% 的内容，成功率纹丝不动。

4.3 第三步：搭建动态注入的请求组装逻辑

骨架和模板准备好之后，需要一个组装层。逻辑很简单：根据任务类型选择对应模板，把模板内容和用户输入拼在一起，加上固定的系统提示词骨架，发给模型。

伪代码大概长这样：

SYSTEM_SKELETON = """你是任务执行器。遵守三条铁律： 1. 只做被要求的事，不扩展。 2. 严格按用户消息中给出的格式输出。 3. 无法处理时直接说明，禁止编造。""" def build_request(task_type, user_input): template = TEMPLATES[task_type] messages = [ {"role": "system", "content": SYSTEM_SKELETON}, {"role": "user", "content": template + "\n\n任务：\n" + user_input} ] return messages

这个组装层是整个 Pi 方案的心脏。它把“什么任务用什么提示词”这件事从模型侧转移到了工程侧，用确定性的代码逻辑替代了不确定性的提示词堆砌。

4.4 第四步：A/B 对比验证，用数据说话

改完之后不能直接全量上线，得先验证。我搭了个 A/B 测试框架，把同一批任务分别用旧方案（1.4 万 Token）和新方案（200 Token 骨架 + 模板）跑一遍，对比三个指标：任务成功率、平均 Token 消耗、平均响应延迟。

测试集我选了 500 个真实任务，覆盖分类、抽取、多步推理、格式转换四类。跑下来的结果：

成功率掉了 0.6 个百分点，这个在可接受范围内，而且我分析了下失败案例，主要是几个边界情况，补进模板后成功率就追平了。Token 降了 85%，延迟还降了，因为输入短了，模型处理更快。

提示：A/B 测试一定要用真实任务，不要用构造的测试用例。真实任务里的边界情况和脏数据，才是检验方案的关键。

4.5 第五步：灰度上线与监控

验证通过后，我按 10%、30%、60%、100% 的节奏灰度上线，每档观察一天。监控重点看两个：任务成功率有没有异常波动，以及有没有出现新的失败模式。灰度期间我加了个告警，只要某类任务成功率跌破阈值就自动回滚。

全量上线后，第一个完整月的账单出来了：整体 Token 消耗下降 85.3%，跟测试预期基本一致。省下来的钱，够团队多跑好几个实验了。

5. 常见问题与排查技巧实录

5.1 精简后模型“不听话”怎么办

这是迁移后遇到最多的反馈。表现是模型不按格式输出，或者自作主张扩展任务。排查下来，九成情况是约束放错了位置。解决办法是把格式要求从模板开头挪到任务描述的正下方，紧挨着用户输入。位置一换，遵守率立刻上来了。

还有一种情况是骨架里的铁律写得太抽象。比如“严格按格式输出”就不如“输出必须是合法 JSON，不要有任何解释文字”来得有效。指令要具体到可执行，模型才知道怎么做。

5.2 模板选择错误导致的“答非所问”

动态注入的代价是引入了模板选择这一步，选错了模板，模型就会用错误的工具和格式干活。我遇到过一次，一个抽取任务被路由到了分类模板，结果模型输出了一堆类别标签。

解决办法是在组装层加一层任务类型校验。用简单的关键词匹配或轻量分类器先判断任务类型，置信度低的时候走一个通用兜底模板。兜底模板稍微长一点，但能保证不出大错。

5.3 Token 统计口径不一致的坑

优化过程中我发现，不同工具统计出来的 Token 数对不上。有的算上了系统提示词，有的没算；有的按字符估，有的用真实分词器。这会导致你优化了半天，账单没降，因为统计口径错了。

我的做法是统一用模型官方的分词器统计，并且在请求日志里把系统提示词、模板、用户输入三部分的 Token 分开记录。这样哪部分胖了一目了然，优化也有针对性。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是过度精简。我一开始把骨架压到 80 Token，结果模型连基本身份都不清楚，输出很飘。后来加到 200 Token，稳定了。精简有下限，不能为了数字好看牺牲可用性。

第二个坑是模板复用过度。我一度想用一个模板覆盖分类和抽取，结果两边都不讨好。后来老老实实拆成两个模板，各自精简，总 Token 反而更少。

第三个坑是忘了缓存。系统提示词骨架是固定的，很多模型服务支持提示词缓存，固定部分可以缓存起来，进一步降成本。我一开始没开，后来开了，又省了一截。

6. 一些关于成本优化的个人体会

这套 Pi 方案跑了大半年，最大的感受是：Agent 成本优化，重点不在模型选型，而在提示词工程。很多人一谈降本就去换更便宜的模型，但换模型往往带来质量下降，得不偿失。而提示词优化是纯赚的——你砍掉的每一 Token 都是真金白银，而且砍对了地方，质量还不降。

另一个体会是，系统提示词应该被当成代码来管理，而不是当成文案来写。它有版本、有测试、有评审、有回滚。我现在的做法是，任何对骨架或模板的修改，都要跑一遍回归测试集，通过了才能上线。这样能避免“改了一句话，线上炸一片”的事故。

最后分享一个判断标准：如果你发现系统提示词里有一半以上的内容，在单次任务里根本没被用到，那它就该被拆出去动态注入。这个标准简单粗暴，但很准。我靠它识别出了好几个可以优化的服务，效果都不错。

这套思路不限于某个特定框架，任何做 Agent、做自动化任务、被 Token 账单困扰的场景都能套用。核心就一句话：让每一次请求只为它真正需要的信息付费。