Token 的概念及其对 Agent 成本与性能的影响一、什么是 TokenToken是 LLM 处理文本的最小单位可以理解为词块——它可能是完整单词、词的一部分、标点符号或空格。Token 的切分示例文本切分结果Token 数Hello worldHello/ /world3unbelievableun/believ/able3你好世界你好//世界/4中文通常 1~2 个汉字 1 TokenThe quick brown foxThe/ /quick/ /brown/ /fox7关键特点不同语言密度不同英文约 1 Token ≈ 0.75 个单词中文约 1 Token ≈ 1.5~2 个汉字。同样内容中文通常消耗更多 Token。代码 Token 密度高代码中符号多通常比自然语言消耗更多 Token。Token 是模型输入/输出的计量单位模型按 Token 读取和生成不是按词或字。二、Token 数如何影响成本1. 计费方式大模型 API 几乎都按 Token 计费分输入 Token 和输出 Token类型说明通常价格输入 TokenInput用户输入 系统提示词 上下文历史较低输出 TokenOutput模型生成的内容较高约为输入的 2~4 倍2. Agent 场景下 Token 消耗放大普通 API 调用输入(1次) 输出(1次)就结束。Agent 多步循环第1步系统提示词 用户任务 工具定义 → 模型输出动作 → 调用工具 第2步上一步全部历史 工具结果 → 模型输出动作 → 调用工具 第3步…… 第N步……每多一步全部历史都要重新作为输入发给模型。10 步的 Agent 任务累计输入 Token 可能是单轮调用的50~100 倍。3. 成本构成系统提示词每步都携带可能几千 Token工具定义每步都携带工具越多越大对话历史累积线性增长多步输出每步都有输出 Token三、Token 数如何影响性能1. 上下文窗口限制每个模型有最大上下文窗口如 8K、128K、1M Token。超出窗口长对话/长文档会被截断Agent 丢失早期信息导致忘记目标。接近窗口上限推理质量下降注意力被稀释。2. 推理延迟Token 数越多处理时间越长输入 Token 多 → 预填充prefill阶段变慢输出 Token 多 → 逐词生成时间线性增长Agent 每步都要等完整响应多步累积延迟显著3. 注意力质量Transformer 的注意力机制在长上下文下效率降低中间迷失问题——关键信息埋在长上下文中模型可能忽略。4. 成本-质量权衡Token 越多 ≠ 效果越好。冗余信息会干扰模型注意力有时精简上下文反而提升效果。四、Agent 中控制 Token 的策略策略说明精简系统提示词只保留必要规则减少每步重复消耗上下文压缩/摘要将历史对话压缩为摘要工具按需加载不把所有工具定义都放入上下文RAG 检索只检索相关片段而非塞入全文控制步数上限限制循环次数防止无限累积流式处理长文档分块处理避免一次性载入五、总结Token 是 LLM 的字数计量单位直接决定两件事成本API 按 Token 计费Agent 多步循环使 Token 消耗成倍放大性能Token 过多导致超出上下文窗口、延迟增加、注意力稀释因此 Agent 工程中Token 管理上下文管理是核心课题——既要保留足够信息保证质量又要控制规模以降低成本和延迟。
Token 的概念及其对 Agent 成本与性能的影响一、什么是 TokenToken是 LLM 处理文本的最小单位可以理解为词块——它可能是完整单词、词的一部分、标点符号或空格。Token 的切分示例文本切分结果Token 数Hello worldHello/ /world3unbelievableun/believ/able3你好世界你好//世界/4中文通常 1~2 个汉字 1 TokenThe quick brown foxThe/ /quick/ /brown/ /fox7关键特点不同语言密度不同英文约 1 Token ≈ 0.75 个单词中文约 1 Token ≈ 1.5~2 个汉字。同样内容中文通常消耗更多 Token。代码 Token 密度高代码中符号多通常比自然语言消耗更多 Token。Token 是模型输入/输出的计量单位模型按 Token 读取和生成不是按词或字。二、Token 数如何影响成本1. 计费方式大模型 API 几乎都按 Token 计费分输入 Token 和输出 Token类型说明通常价格输入 TokenInput用户输入 系统提示词 上下文历史较低输出 TokenOutput模型生成的内容较高约为输入的 2~4 倍2. Agent 场景下 Token 消耗放大普通 API 调用输入(1次) 输出(1次)就结束。Agent 多步循环第1步系统提示词 用户任务 工具定义 → 模型输出动作 → 调用工具 第2步上一步全部历史 工具结果 → 模型输出动作 → 调用工具 第3步…… 第N步……每多一步全部历史都要重新作为输入发给模型。10 步的 Agent 任务累计输入 Token 可能是单轮调用的50~100 倍。3. 成本构成系统提示词每步都携带可能几千 Token工具定义每步都携带工具越多越大对话历史累积线性增长多步输出每步都有输出 Token三、Token 数如何影响性能1. 上下文窗口限制每个模型有最大上下文窗口如 8K、128K、1M Token。超出窗口长对话/长文档会被截断Agent 丢失早期信息导致忘记目标。接近窗口上限推理质量下降注意力被稀释。2. 推理延迟Token 数越多处理时间越长输入 Token 多 → 预填充prefill阶段变慢输出 Token 多 → 逐词生成时间线性增长Agent 每步都要等完整响应多步累积延迟显著3. 注意力质量Transformer 的注意力机制在长上下文下效率降低中间迷失问题——关键信息埋在长上下文中模型可能忽略。4. 成本-质量权衡Token 越多 ≠ 效果越好。冗余信息会干扰模型注意力有时精简上下文反而提升效果。四、Agent 中控制 Token 的策略策略说明精简系统提示词只保留必要规则减少每步重复消耗上下文压缩/摘要将历史对话压缩为摘要工具按需加载不把所有工具定义都放入上下文RAG 检索只检索相关片段而非塞入全文控制步数上限限制循环次数防止无限累积流式处理长文档分块处理避免一次性载入五、总结Token 是 LLM 的字数计量单位直接决定两件事成本API 按 Token 计费Agent 多步循环使 Token 消耗成倍放大性能Token 过多导致超出上下文窗口、延迟增加、注意力稀释因此 Agent 工程中Token 管理上下文管理是核心课题——既要保留足够信息保证质量又要控制规模以降低成本和延迟。
