什么是 Token 使用量？

Scrapeless Agent Browser 为基于网页的 AI 工作流程提供浏览器访问能力。

令牌使用量是指语言模型输入和生成输出的数量，以模型使用的单位来衡量。一个令牌可以表示一个单词、单词的一部分、标点符号或其他编码序列。使用量描述的是处理的数据体量；它并不直接衡量答案质量、事实准确性或完成任务的数量。

对于应用程序所有者来说，令牌使用量很重要，因为它有助于解释上下文限制和消耗情况。一个简短的可见回答可能是基于一个包含说明、对话历史和工具结果的大型请求得出的。应衡量整个模型交互，而不是仅根据最终回复来估算使用量。

模型输入的范围

输入标记使用可以包括应用程序说明、当前用户请求、保留的对话历史、检索到的证据以及提供给模型的工具定义。具体的计算方式取决于接口和模型。用户消息的字数统计因此只能对请求提供部分视图。

设想一个假想的研究助理打开了一个很长的产品页面。浏览器传输本身并不会自动产生语言模型的 token 计费。只有当应用程序将选定的内容序列化并发送给模型时，该文本才会成为模型输入的一部分。发送整个 HTML 文档在上下文空间中的花费，可能会比只发送相关的产品部分昂贵得多。

保留您的应用程序实际提交内容的记录。为了调试，在可能的情况下，将指令部分、对话部分和证据部分分开。您不需要无限期地存储敏感文本来衡量这些类别。汇总长度和带有范围的跟踪元数据可以帮助识别请求在不保留每个原始文档的情况下是如何增长的。

输出用量和可见响应长度

输出令牌使用量根据所选服务的计费规则来衡量模型生成的内容。用户看到的文本可能不会体现所有的计费类别。一些界面会报告用于推理或其他模态的额外细节，因此应使用返回的使用记录，而不是假设可见的文字就能解释总量。

输出长度限制是对生成过程的控制，而不是对任务实际耗费内容的预测。简洁回答的指令可以减少不必要的冗长措辞，但不会移除已经发送的输入。同样地，如果对答案长度进行限制，在任务需要详细解释或结构化记录时，可能会导致空间不足，从而无法给出完整的结果。

对于一个假设的抽取任务，需要区分被截断的记录和有效的短记录。两者都可能只使用很少的输出 token。前者是任务失败；后者则可能是任务成功。将记录的完整性和验证结果与使用情况一并记录，这样在优化过程中就不会悄然用不完整的答案取代有用的答案。

标记、词语和上下文窗口

标记是特定于模型的单位，而单词是人类语言的单位。固定的词与标记比率只是一个粗略估计，会随着语言、标点、源代码或标识符密集型文本而变化。不同的分词器可以以不同的方式拆分同一字符串。当精度很重要时，请使用适合于你的模型的分词器和请求格式进行测量。

原文 子词表示研究 解释了更小的单元如何表示罕见或不熟悉的词语。这种设计有助于说明为什么一个很长的技术名称不一定只是一个 token。可见文本长度限制和模型上下文限制是相关的约束，但它们并不能互相替代。

上下文窗口限制了模型在其既定规则下能够考虑的信息量。令牌使用记录了消耗情况；上下文上限描述的是容量。一个请求可以在容量范围内，却仍然把大部分容量浪费在无关文本上。对……的研究 长上下文信息使用 说明了为什么将证据放入窗口并不能证明模型会可靠地使用每一段相关内容。

为什么代理会快速累积用量

一个代理在生成最终答案之前可以进行多次模型调用，因此任务级的 token 使用量是相关调用的总和，而不是单次响应的用量。每个决策可以包含指令、当前状态和观测结果。反复携带大量观测数据向前传递，会使得后续请求变得比最初的问题大得多。

在你的跟踪中保持模型调用与工具调用的区分。浏览器操作具有其自身的执行成本和结果。读取该结果的规划调用则属于模型使用。 实时网络数据获取工作流程 关注工具层。你的编排负责决定哪些观察会成为模型的上下文，以及它们在其中保留多长时间。

并行代理也可能会重复输入。如果每个工作单元都接收到相同的完整证据包，即使耗用时间缩短，总体使用量也可能增加。对于独立工作而言，这可能是一个合理的权衡，但应在任务账本中清晰可见。与其仅根据响应时间来判断效率，不如比较已完成任务的质量和总消耗。

构建一个实用的使用分类账

一个有用的用量分类账会将每次模型调用与任务、模型配置、用途、报告的 token 类别和结果关联起来。按原样保留提供方返回的数值，并将缺失字段标记为不可用。把缺失的数字转换为零会让你的预算报告看起来更精确，却掩盖了测量不完整的事实。

在多个层级进行汇总：单次调用、完整任务以及定义好的报告周期。任务层级的汇总对代理尤其有用，因为规划和验证调用否则可能会被掩盖在一个最终答案后面。如果失败或被取消的工作消耗了资源，应保持其可见。只报告成功输出会低估运营成本。

在对账之前，将使用量预估和计费用量视作两类独立记录。本地分词器的预估可以用来做准入检查，而服务返回的使用量可以支持运行时监控。计费可能会采用单独的类别或调整。当服务文档提供了更细粒度的核算时，不要从一个原始总数中推断最终账单。

在不移除必要证据的前提下减少浪费

当优化 token 时，最佳做法是移除无关内容，同时保留任务所需信息。先从检查超大请求开始。常见候选包括重复的对话轮次、网页中的导航文本、重复的工具说明，以及无法回答当前问题的文档。

使用抽取和检索来有选择地挑选段落。保留来源标识符以及足够的上下文，以便正确理解一段内容。更小的片段如果丢掉了某个条件或例外，可能会让答案更便宜但错误。在压缩前后比较证据支撑情况，而不是把更低的计数当作改进的充分证据。

“The” “effects of irrelevant context” 提供了另一个要仔细选择输入的理由。减少上下文既可以是质量干预，也可以是消耗干预，但结果取决于你移除了什么。摘要同样需要检查，因为它们可能丢弃后续问题所需的细节。

将浏览成本与模型成本分开

浏览器基础设施和模型推理属于不同的消耗类别。如果你使用 Agent Browser for web interactions，请将这部分工作与模型调用并行追踪，而不要把它重命名为 token 使用量。即使最终证据摘录很短，一个页面也可能需要大量浏览器工作。

“The” “Scrapeless pricing options” 描述的是 Scrapeless 服务，而推理核算由你的模型提供方决定。在保留各自原始单位的前提下，完整的任务成本报告可以将这些类别合并。这样在调查预算增加时，你就能区分是由于浏览会话过长，还是模型提示过大。

作为一个假设例子，用相关摘录替代整页上下文可以减少模型输入，同时保持浏览器执行量不变。反过来，重用已收集的文档可以减少收集工作，而不改变发送给模型的文本。这些干预影响工作流的不同部分，其收益应分别报告。

围绕已完成的工作设定预算

任务预算应定义当预期消耗超过可用配额时会发生什么。你可以缩小来源集合、要求更小的范围，或返回一个明确不完整的结果。在应用逻辑中预先决定这些行为，以便保持可预测性，而不完全依赖模型自己注意到某条预算指令。

根据已完成的工作评估优化：被接受的记录、得到支撑的答案或其他任务特定结果。将延迟和失败率与使用量一起追踪。一种虽节省 token 但让人工修正工作量翻倍的配置，可能是糟糕的运营选择。在比较配置时保持评分标准稳定，这样表面上的节省才能反映同一完成标准。

要点

token 使用量衡量的是模型在输入和输出上的处理体积。请在调用和任务层级进行追踪，使用报告的核算字段，并将上下文容量与消耗区分开来。通过谨慎选择证据来提高效率，然后验证更便宜的工作流仍能完成同一任务。