专栏AI Agent 开发07上一篇我们刚弄清楚 Runtime Context每一轮模型真正看到的工作材料。现在继续问一个最实际的问题——这些材料到底能放多少为什么对话越长、Agent 走的步骤越多请求往往会越来越“重”一、先别背定义为什么同样 100 个字消耗不一定一样很多人第一次看模型 Usage会自然把 token 当成“字数”。这只是最容易产生的误解。模型不会直接把“100 个汉字”“20 个英文单词”作为统一计量单位。文本要先经过 tokenizer变成 token 序列模型再处理这些 token。图 1 Token 是 tokenizer 切分后的模型处理单位它和人类看到的字数并不是一一对应二、Token 到底是什么对应用开发者来说可以先把 Token 理解成模型处理文本时使用的离散单位。一段文本会被 tokenizer 按模型对应的规则切分。一个 token 可能对应一个汉字、一个汉字的一部分、一个英文词的一部分、空格或标点组合。代码、JSON、URL 的切分方式也可能和普通自然语言很不一样。不要把“1 个汉字 12 token”之类经验值写进预算逻辑。它最多只能帮人做非常粗的估算。真正需要精确判断时应使用目标模型/Provider 提供的 tokenizer、计数接口或实际 usage。原稿用固定的中文/英文换算比例来讲 token这种写法对入门直观但容易让读者误以为有通用公式。这里我们把它改成“先理解机制再用目标模型实际计数”。三、Token 为什么会和成本、限流、速度扯上关系因为模型实际处理的是 token所以很多 Provider 会用输入 token、输出 token 等 Usage 来统计资源消耗价格和限流规则也常常围绕这些单位设计。但不要进一步推导成“所有 Provider 都只有输入价 输出价两项”。今天的模型服务还可能区分 cached input、reasoning、音频/图像等不同计量方式具体以目标模型文档和返回的 Usage 为准。对 Agent 来说真正需要形成的是成本意识• 每多一轮模型调用通常就多一轮输入和输出。• 如果后续轮次继续携带之前的历史和 Tool Result输入会变大。• 输入变大通常意味着更多计算、更多 Token 用量也可能带来更高延迟。四、Context Window模型这一轮到底能“看”多少图 2 Context Window 可以理解成这一轮可用的上下文容量不同模型/API 对输入与输出限制的暴露方式并不完全相同上一章我们说 Runtime Context 可能包含 Instruction、History、User Message以后还会加入 Tool Result、检索内容等。Context Window 就是在提醒你这些东西不能无限塞。不同模型会公布不同的上下文能力也可能单独给出最大输出限制因此工程代码不要假设所有模型都满足一个固定的“窗口 输入 某个 max_tokens”公式。最稳妥的理解是在一次模型调用里你能提供给模型的有效上下文以及模型能够生成的内容都受到目标模型的长度限制。五、为什么 Agent 比普通单轮问答更容易把 Context 撑大图 3 Agent 每走一步都可能新增模型输出和 Tool Result如果这些内容继续进入后续 Context输入会逐步增长假设一个 Agent 做“搜索资料 → 阅读网页 → 再搜索 → 写总结”。第一轮也许只有任务说明。第二轮增加搜索结果。第三轮又增加网页内容和上一轮模型判断。如果 Runtime 每次都把所有原始内容重新塞回去后续调用自然会越来越大。所以真正的问题不是“Agent 跑 5 步一定贵多少倍”而是第 n 步最终构造出来的 Context 到底有多大其中多少信息真的对当前决策有用。六、这一篇先学会三种最基础的治理思路1. 不要把所有历史永远原样保留较早且已经失去作用的内容可以在后续通过滑动窗口、选择性历史等方式减少。完整策略会在 Context Engineering 专章深入。2. Tool Result 不要默认全文回填网页抓取几万字、数据库查询几千行如果都原样进入下一轮窗口很快会被占满。Tool 层应该尽量返回完成下一步真正需要的数据。3. 长内容可以摘要但摘要也会丢信息摘要不是免费压缩。它会把大量原始内容变成更短表示同时也可能丢失细节。因此哪些内容能摘要、哪些必须保留原文需要由任务决定。这三点现在只建立概念。A28A35 的 Context Engineering 会系统讲 History、Compression、Selective Context 和 Token Budget不在 A07 提前写一个“完整 Context Manager”。七、怎么在代码里看到真实 Usage如果 Provider 的 SDK/响应提供 usage优先直接读取它而不是自己用字符数估。伪代码可以很简单response call_model(...) usage response.usage print(input tokens :, usage.input_tokens) print(output tokens:, usage.output_tokens)字段名会随 Provider / API 变化但思想不变实际请求结束后记录真实 Usage。如果需要在请求发送前做长度预估再使用目标模型对应的 tokenizer 或官方计数能力。不要拿一个模型的 tokenizer 长期估另一个模型。八、这一篇不要提前陷入“精确成本计算器”原稿已经开始给固定人民币单价、固定窗口、固定输出预留并写了完整 TokenBudgetedAgent。这些内容看起来很工程化但会带来两个问题• 模型价格、窗口和 API 参数会变化文章很快过时。• A07 的任务是建立 Token / Context Window 心智模型不是提前实现 A28A35 的 Context Manager。所以当前阶段只需要学会三件事看 Usage、知道模型有限长、知道 Agent 的上下文会随着任务推进而膨胀。九、几个常见误区• 误区 1Token 就是字数。不是同样长度的不同文本可能得到完全不同的 token 数。• 误区 2所有模型都用同一种 tokenizer。不同模型/Provider 可能不同。• 误区 3Context Window 只等于聊天历史。Instruction、Tool Result、当前输入等都可能占用上下文。• 误区 4只要窗口够大就应该把所有内容都塞进去。无关内容同样会增加成本、延迟和干扰。• 误区 5Context 越长timeout 就必须按某个固定比例增加。真实延迟受模型、缓存、服务负载等多种因素影响不能只用长度写死公式。十、这一篇只记住 4 句话• Token 是模型 tokenizer 产生的处理单位不等于字数。• Context Window 决定一轮调用能承载多少有效上下文具体限制以目标模型/API 为准。• Agent 的每一步都可能产生新的历史和 Tool Result因此 Context 容易越跑越大。• 治理的目标不是“机械砍历史”而是只把当前决策真正需要的信息送进模型。十一、下一篇下一篇 08《Structured Output 到底解决了什么问题》会从一个非常现实的失败开始模型明明说了“我会返回 JSON”为什么程序还是经常解析失败然后再进入 JSON Schema、Pydantic/Zod、Validation 和失败处理。 Token 和 Context Window 到底是什么？
专栏AI Agent 开发07上一篇我们刚弄清楚 Runtime Context每一轮模型真正看到的工作材料。现在继续问一个最实际的问题——这些材料到底能放多少为什么对话越长、Agent 走的步骤越多请求往往会越来越“重”一、先别背定义为什么同样 100 个字消耗不一定一样很多人第一次看模型 Usage会自然把 token 当成“字数”。这只是最容易产生的误解。模型不会直接把“100 个汉字”“20 个英文单词”作为统一计量单位。文本要先经过 tokenizer变成 token 序列模型再处理这些 token。图 1 Token 是 tokenizer 切分后的模型处理单位它和人类看到的字数并不是一一对应二、Token 到底是什么对应用开发者来说可以先把 Token 理解成模型处理文本时使用的离散单位。一段文本会被 tokenizer 按模型对应的规则切分。一个 token 可能对应一个汉字、一个汉字的一部分、一个英文词的一部分、空格或标点组合。代码、JSON、URL 的切分方式也可能和普通自然语言很不一样。不要把“1 个汉字 12 token”之类经验值写进预算逻辑。它最多只能帮人做非常粗的估算。真正需要精确判断时应使用目标模型/Provider 提供的 tokenizer、计数接口或实际 usage。原稿用固定的中文/英文换算比例来讲 token这种写法对入门直观但容易让读者误以为有通用公式。这里我们把它改成“先理解机制再用目标模型实际计数”。三、Token 为什么会和成本、限流、速度扯上关系因为模型实际处理的是 token所以很多 Provider 会用输入 token、输出 token 等 Usage 来统计资源消耗价格和限流规则也常常围绕这些单位设计。但不要进一步推导成“所有 Provider 都只有输入价 输出价两项”。今天的模型服务还可能区分 cached input、reasoning、音频/图像等不同计量方式具体以目标模型文档和返回的 Usage 为准。对 Agent 来说真正需要形成的是成本意识• 每多一轮模型调用通常就多一轮输入和输出。• 如果后续轮次继续携带之前的历史和 Tool Result输入会变大。• 输入变大通常意味着更多计算、更多 Token 用量也可能带来更高延迟。四、Context Window模型这一轮到底能“看”多少图 2 Context Window 可以理解成这一轮可用的上下文容量不同模型/API 对输入与输出限制的暴露方式并不完全相同上一章我们说 Runtime Context 可能包含 Instruction、History、User Message以后还会加入 Tool Result、检索内容等。Context Window 就是在提醒你这些东西不能无限塞。不同模型会公布不同的上下文能力也可能单独给出最大输出限制因此工程代码不要假设所有模型都满足一个固定的“窗口 输入 某个 max_tokens”公式。最稳妥的理解是在一次模型调用里你能提供给模型的有效上下文以及模型能够生成的内容都受到目标模型的长度限制。五、为什么 Agent 比普通单轮问答更容易把 Context 撑大图 3 Agent 每走一步都可能新增模型输出和 Tool Result如果这些内容继续进入后续 Context输入会逐步增长假设一个 Agent 做“搜索资料 → 阅读网页 → 再搜索 → 写总结”。第一轮也许只有任务说明。第二轮增加搜索结果。第三轮又增加网页内容和上一轮模型判断。如果 Runtime 每次都把所有原始内容重新塞回去后续调用自然会越来越大。所以真正的问题不是“Agent 跑 5 步一定贵多少倍”而是第 n 步最终构造出来的 Context 到底有多大其中多少信息真的对当前决策有用。六、这一篇先学会三种最基础的治理思路1. 不要把所有历史永远原样保留较早且已经失去作用的内容可以在后续通过滑动窗口、选择性历史等方式减少。完整策略会在 Context Engineering 专章深入。2. Tool Result 不要默认全文回填网页抓取几万字、数据库查询几千行如果都原样进入下一轮窗口很快会被占满。Tool 层应该尽量返回完成下一步真正需要的数据。3. 长内容可以摘要但摘要也会丢信息摘要不是免费压缩。它会把大量原始内容变成更短表示同时也可能丢失细节。因此哪些内容能摘要、哪些必须保留原文需要由任务决定。这三点现在只建立概念。A28A35 的 Context Engineering 会系统讲 History、Compression、Selective Context 和 Token Budget不在 A07 提前写一个“完整 Context Manager”。七、怎么在代码里看到真实 Usage如果 Provider 的 SDK/响应提供 usage优先直接读取它而不是自己用字符数估。伪代码可以很简单response call_model(...) usage response.usage print(input tokens :, usage.input_tokens) print(output tokens:, usage.output_tokens)字段名会随 Provider / API 变化但思想不变实际请求结束后记录真实 Usage。如果需要在请求发送前做长度预估再使用目标模型对应的 tokenizer 或官方计数能力。不要拿一个模型的 tokenizer 长期估另一个模型。八、这一篇不要提前陷入“精确成本计算器”原稿已经开始给固定人民币单价、固定窗口、固定输出预留并写了完整 TokenBudgetedAgent。这些内容看起来很工程化但会带来两个问题• 模型价格、窗口和 API 参数会变化文章很快过时。• A07 的任务是建立 Token / Context Window 心智模型不是提前实现 A28A35 的 Context Manager。所以当前阶段只需要学会三件事看 Usage、知道模型有限长、知道 Agent 的上下文会随着任务推进而膨胀。九、几个常见误区• 误区 1Token 就是字数。不是同样长度的不同文本可能得到完全不同的 token 数。• 误区 2所有模型都用同一种 tokenizer。不同模型/Provider 可能不同。• 误区 3Context Window 只等于聊天历史。Instruction、Tool Result、当前输入等都可能占用上下文。• 误区 4只要窗口够大就应该把所有内容都塞进去。无关内容同样会增加成本、延迟和干扰。• 误区 5Context 越长timeout 就必须按某个固定比例增加。真实延迟受模型、缓存、服务负载等多种因素影响不能只用长度写死公式。十、这一篇只记住 4 句话• Token 是模型 tokenizer 产生的处理单位不等于字数。• Context Window 决定一轮调用能承载多少有效上下文具体限制以目标模型/API 为准。• Agent 的每一步都可能产生新的历史和 Tool Result因此 Context 容易越跑越大。• 治理的目标不是“机械砍历史”而是只把当前决策真正需要的信息送进模型。十一、下一篇下一篇 08《Structured Output 到底解决了什么问题》会从一个非常现实的失败开始模型明明说了“我会返回 JSON”为什么程序还是经常解析失败然后再进入 JSON Schema、Pydantic/Zod、Validation 和失败处理。