Token Counting

System Prompt Token 统计：AI Agent 工作流中容易被忽略的隐藏成本

2026年7月27日TokenTest Editorial Team

System Prompt Token 统计：AI Agent 工作流中容易被忽略的隐藏成本

简短答案：只要 System Prompt 随模型请求一起发送，它就会计入输入 Token。Developer 指令、工具定义、JSON Schema、路由上下文、对话历史和检索文档也可能占用输入 Token。在 AI Agent 工作流里，这层固定指令可能会在每一轮调用、重试、工具调用或子 Agent 执行时再次发送。

因此，一个单独看起来不大的 System Prompt Token 统计结果，经过工作流放大后，可能成为总用量中的重要部分。

真正应该问的，不只是：

这段 System Prompt 有多少 Token？

而是：

在完整调用图中，这些固定指令一共被发送了多少次？

本文将说明如何计算这个隐藏倍数、定位重复发生的 Prompt 组件，并使用 TokenTest 验证端点返回的 Token 用量是否合理。

哪些内容会计入 System Prompt Token？

不同 API 的请求结构并不完全相同，但输入用量通常不只包含用户看得见的消息。

请求组件	终端用户通常可见吗？	可能消耗输入 Token 吗？	常见重复方式
System 指令	否	是	使用该 Agent 配置的每次模型调用
Developer 指令	否	是	应用工作流中的每次请求
工具名称与描述	否	是	每次向模型暴露这些工具时
工具 JSON Schema	否	是	每次发送这些 Schema 时
用户消息	是	是	当前轮次
对话历史	部分可见	是	如果不总结或截断，会随轮次增长
检索上下文	有时可见	是	每次带检索结果的调用
工具返回结果	有时可见	是	工具执行后的后续调用

对于 OpenAI API，请求前的官方输入 Token 统计端点支持与 Responses API 相同的输入结构，包括 instructions、messages、tools、图片和文件，并在生成前返回这次请求的准确输入 Token 数。因此，最安全的审计对象是完整序列化请求，而不是单纯根据字数估算。

Token 化方式会因模型而异。本地 tokenizer 适合做早期估算，但对于真正要发送的请求，生产端点的预统计结果和实际返回 usage 更值得作为依据。

为什么 Agent 工作流会放大 System Prompt Token 成本

普通聊天机器人可能在一个用户轮次中只调用一次模型，而 Agent 往往会连续调用多次：

Planner 理解任务并拆分步骤；
Retriever 检索知识库；
Worker 调用一个或多个工具；
Reviewer 检查结果；
失败步骤触发重试；
最终模型整理答案。

如果每次调用都携带同一套 3,000 Token 的固定指令和工具层，那么整个工作流承担的并不是 3,000 个固定 Token，而是“每个适用调用各承担一次”。

可以使用下面的公式：

单次固定输入 = System + Developer + Tools + 固定封装

重复固定输入 = Σ（第 i 次调用的固定输入）

工作流预计输入 = 重复固定输入
               + 用户消息与历史
               + 检索上下文
               + 工具结果

如果每次调用使用相同固定层，可以简化为：

重复固定输入 = 单次固定输入 × 适用调用次数

示例：隐藏的 45,500 个固定输入 Token

假设一个 Agent 请求包含：

固定组件	每次调用的 Token
System Prompt	1,800
Developer 与路由规则	350
工具描述与 Schema	1,250
固定消息封装	100
单次固定输入	3,500

工作流包含 8 次计划调用、2 次重试和 3 次子 Agent 调用：

3,500 个固定 Token × 13 次调用 = 45,500 个重复固定输入 Token

此时还没有加入用户请求、对话历史、检索结果、工具输出或模型生成内容。这个数字只是容量规划示例，不是费用预测。

隐藏成本的本质是：基础指令层会被工作流拓扑放大。

五种最常见的隐藏指令开销

1. 每个 Agent 都收到完整全局 Prompt

专业化 Worker 通常只需要全局策略的一部分。让 Retriever 同时携带最终写作、发布、升级处理和审查规则，会增加它的 System Prompt Token 统计，却未必改善检索任务。

更合理的方式是保留一小段共享安全核心，再为每个角色提供专属指令。

2. 每次调用都暴露全部工具

工具 Schema 可能很长。如果某个步骤只可能使用两个工具，就没有必要自动发送二十个工具定义。先完成路由，再暴露最小可用工具集。

3. 同一规则在多个层级重复

同一要求可能同时出现在 System Prompt、Developer 消息、工具描述、输出 Schema 和重试消息中。有意重复有时能提升稳定性，但无意重复只会制造额外开销。

为每条规则指定一个权威位置，只有在测试证明需要强化时才重复。

4. 重试会重新发送整个请求外壳

重试并不只是再次发送失败的用户指令。它还可能重发 System Prompt、工具、历史、检索上下文和之前的工具结果。即使重试率不高，也可能放大很大的固定请求。

应当把“重试造成的输入”与“首次尝试输入”分开统计。

5. 对话历史不断携带旧指令和轨迹

有些 Agent 框架会把规划笔记、工具轨迹、校验消息或旧摘要保存在对话中。这些内容会成为后续调用中的可变历史开销。

长期状态应当结构化、精简保存，不要把完整 transcript 当作无限数据库。

如何正确审计 System Prompt Token 统计

第一步：捕获完整请求

记录 API 调用前实际发送的完整 payload，包括：

System 与 Developer 指令；
当前消息和保留的历史；
工具定义与 JSON Schema；
检索上下文与文件；
工具结果；
模型和端点配置。

不要只统计代码仓库中的 Prompt 文件。框架序列化过程可能增加封装或改变请求结构。

第二步：获取准确的预统计结果

如果模型提供方支持，应把完整请求提交到官方输入 Token 统计端点。对于 OpenAI Responses API payload，可以使用 POST /v1/responses/input_tokens。

保存模型、请求哈希、tokenizer 或端点版本、时间戳和返回计数。只要模型、工具、Schema、指令或框架发生变化，就重新统计。

第三步：测量组件差值

基于同一请求创建受控版本：

版本	改动	差值可以估算什么
完整请求	不改动	生产基线
无工具版本	移除工具定义	工具与 Schema 开销
最小 System 版本	只保留关键不变量	可压缩的指令开销
无历史版本	移除保留轮次	对话历史开销
单检索文档版本	限制检索数量	单份检索内容的边际开销

每次只改变一个组件。两个准确计数之间的差值，比根据字符数猜测更有价值。

第四步：把计数映射到调用图

为每个节点记录：

最大计划调用次数；
固定输入 Token；
预计可变输入；
输出预留；
重试上限；
是否适用 Prompt Cache；
是否向模型暴露工具。

分别计算“预期路径”和“最大路径”。平均值可能掩盖昂贵的重试分支。

如果需要更完整的预算方法，可以阅读多智能体工作流的 Token 预算规划方法。

第五步：验证生产 usage

预统计告诉你请求理论上应当包含多少输入；运行时 usage 告诉你端点执行后实际报告了什么。

TokenTest 的 D4 Token 计量可信度会检查 usage 是否存在、总量是否一致、输入是否单调增长、输出是否合理、停止原因是否与 Token 限制联动、流式 usage 是否存在，以及 cache token 证据是否合理。这可以帮助团队发现计量或截断行为不符合预期的端点。

两个可以直接在 TokenTest 中执行的测试

测试一：运行真实端点评估

打开 TokenTest；
输入测试端点和测试专用 API Key；
自动发现或手动输入模型 ID；
开始评估；
在报告中打开 D4 Token 计量可信度部分。

重点检查：

usage 字段是否存在；
输入、输出和总量是否能够对齐；
更长 Prompt 是否产生更高的输入计数；
Token 上限是否与停止行为一致；
流式响应是否保留 usage 证据；
cache 相关字段是否只在适当场景出现。

TokenTest 不替代模型提供方的准确预统计端点。它用于验证 Prompt 修改后，真实端点报告的 Token 行为是否合理。

测试二：离线比较两份原始响应 JSON

TokenTest 界面提供离线响应分析器。先粘贴原始工作流返回的 JSON，再粘贴优化后工作流的 JSON。

优化前示例：

{
  "id": "msg_before",
  "model": "your-model-id",
  "content": [
    {"type": "text", "text": "MODEL_TRUTH_OK 42f7a9c1"}
  ],
  "usage": {
    "input_tokens": 7200,
    "output_tokens": 240
  }
}

优化后示例：

{
  "id": "msg_after",
  "model": "your-model-id",
  "content": [
    {"type": "text", "text": "MODEL_TRUTH_OK 42f7a9c1"}
  ],
  "usage": {
    "input_tokens": 4100,
    "output_tokens": 236
  }
}

生产使用时，请替换为真实模型 ID 和真实 API 响应。这个对比可以帮助确认 usage 是否存在，以及输入下降是否反映在返回结果中。它不能单独证明是哪一个组件带来了下降；组件归因仍然需要受控请求版本。

如何减少 System Prompt Token，同时避免行为退化

优先做结构优化，而不是激进删减：

先路由，再加载工具。 只暴露当前动作需要的 Schema。
拆分全局规则和角色规则。 保留紧凑的共享核心，每个 Agent 只接收自己的操作指令。
删除重复策略措辞。 除非行为测试证明必须强化，否则一条规则只保留一个权威版本。
把示例移到测试或检索中。 不要让每次请求都携带全部示范。
谨慎缩短 Schema 描述。 保留字段含义、约束和失败行为。
在明确阈值处总结历史。 保留决策与未解决状态，而不是所有中间消息。
限制重试和 fan-out。 创建新调用前，先预测它的完整输入。
每次精简都做回归测试。 只有在任务质量、安全、路由和输出结构保持不变时，更低的 System Prompt Token 统计才有价值。

配套文章为什么你的提示词太长：常见 Token 计数误区可以帮助定位可避免的 Prompt 膨胀。你也可以把统计结果加入Token 感知的 Prompt 审查流程，在上线前发现 Token 回归。

可复用的审查表

可以把下面的表格加入 Pull Request 或 Prompt Review：

节点	调用次数	System	Developer	Tools	其他固定输入	固定小计	重试	最大重复固定输入
Planner	1	900	200	0	100	1,200	0	1,200
Retriever	3	500	150	700	100	1,450	1	5,800
Worker	4	1,000	250	1,100	100	2,450	1	12,250
Reviewer	1	800	250	0	100	1,150	0	1,150
总计								20,400

每行公式：

最大重复固定输入 = 固定小计 ×（计划调用 + 重试调用）

把它当作容量规划表，而不是费用计算器。如果存在 Prompt Cache 或提供方特定计量方式，应同时保留“完整逻辑输入”和“提供方返回的 usage 明细”。

常见问题

System Prompt 会计入输入 Token 吗？

会。只要 System 指令被包含在模型请求中，它就会参与请求的输入表示。应统计完整序列化请求，而不是只估算用户可见文本。

工具定义会计入 Token 吗？

当工具名称、描述、参数和 Schema 被发送给模型时，它们可能计入输入用量。请使用模型提供方的官方统计方式，并传入真实的 tools payload。

System Prompt 在一次对话中只统计一次吗？

不要这样假设。模型 API 处理的是一次次请求，而 Agent 应用通常会在每次请求中重新发送相关指令。应检查工作流中每个调用的真实 payload。

Prompt Cache 会让 System Prompt Token 消失吗？

Cache 可能改变重复前缀的处理方式和 usage 明细，但不会消除审计完整逻辑请求的必要性。如果提供方建议前缀缓存，应把稳定内容放在前部，并检查运行时返回的 cached token 明细。

System Prompt 多长才合适？

不存在统一标准。更有用的指标是“每个 Token 的指令价值”：必要的行为、安全、路由和输出约束应当保留；重复措辞、未使用工具、过期示例和无关角色指令应当删除。

最终结论

System Prompt Token 统计只是起点。在 AI Agent 工作流中，真正决定用量的是固定输入在 Planner、Worker、工具调用、重试和 Reviewer 之间被重复了多少次。

捕获真实请求、测量组件差值、把结果乘以调用图，并使用 TokenTest 验证端点的实际 usage 行为。这样，Prompt 优化就不再依赖猜测，而会成为一个可以复现、比较和回归测试的工程流程。

你可以先运行一次 TokenTest 端点评估，并查看 TokenTest Product Manual 了解可用的 Token 计量可信度检查。

System Prompt Token 统计：AI Agent 工作流中容易被忽略的隐藏成本

哪些内容会计入 System Prompt Token？

为什么 Agent 工作流会放大 System Prompt Token 成本

示例：隐藏的 45,500 个固定输入 Token

五种最常见的隐藏指令开销

1. 每个 Agent 都收到完整全局 Prompt

2. 每次调用都暴露全部工具

3. 同一规则在多个层级重复

4. 重试会重新发送整个请求外壳

5. 对话历史不断携带旧指令和轨迹

如何正确审计 System Prompt Token 统计

第一步：捕获完整请求

第二步：获取准确的预统计结果

第三步：测量组件差值

第四步：把计数映射到调用图

第五步：验证生产 usage

两个可以直接在 TokenTest 中执行的测试

测试一：运行真实端点评估

测试二：离线比较两份原始响应 JSON

如何减少 System Prompt Token，同时避免行为退化

可复用的审查表

常见问题

System Prompt 会计入输入 Token 吗？

工具定义会计入 Token 吗？

System Prompt 在一次对话中只统计一次吗？

Prompt Cache 会让 System Prompt Token 消失吗？

System Prompt 多长才合适？

最终结论

资料来源