跳到主要内容

3 篇博文 含有标签「token-optimization」

查看所有标签

Token 预算作为架构约束:在硬上限下设计可靠的 Agent

· 阅读需 9 分钟
Tian Pan
Software Engineer

你的 agent 在开发环境中运行完美。它能推理多步任务,自信地调用工具,生成精美的输出。然后你设置了每次请求 $0.50 的成本上限,它就崩溃了。不是优雅地降级——而是灾难性的崩溃。它在推理过程中截断自己的思考,忘记三步前的工具结果,并基于被静默丢失的上下文自信地给出错误答案。

这就是丰裕设计的 agent 和生产受限 agent 之间的差距。大多数 agent 架构都是在无限 token 预算下原型化的——长系统提示词、冗长的工具 schema、完整的文档检索、未压缩的对话历史。当你引入硬上限(成本上限、上下文限制、延迟要求)时,这些 agent 不会优雅地降级。它们以难以检测且调试成本高昂的方式崩溃。

规划税:为什么你的智能体把更多 Token 花在思考上而非执行上

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的智能体刚刚花了 6完成了一项直接API调用只需6 完成了一项直接 API 调用只需 0.12 就能处理的任务。如果你在生产环境中构建过智能体系统,这个比例大概不会让你感到惊讶。真正令人意外的,是那些 token 究竟去了哪里:不是工具调用,不是生成最终答案,而是智能体在推理下一步该做什么。分解任务、反思中间结果、在观察结果与预期不符时重新规划。这就是规划税——智能体在行动之前用于思考的 token 开销——对于大多数智能体架构而言,它在第一个有效动作触发之前就已消耗掉总 token 预算的 40–70%。

规划税本身并不是 bug。推理能力正是将智能体与简单的提示-响应系统区分开来的关键。但当决定做什么的成本超过实际去做的成本时,你面对的就是一个工程问题,再便宜的推理也无法解决它。自 2022 年底以来,每 token 价格已下降约 1,000 倍,然而智能体的总体支出仍在持续攀升——这是一个典型的杰文斯悖论:更便宜的 token 只会催生更多的 token 消耗。

隐藏的 Token 税:在用户开口之前,你的上下文窗口为何已消失了 30-60%

· 阅读需 10 分钟
Tian Pan
Software Engineer

你在为一个 200K token 的上下文窗口付费。你的用户可能只用到了其中的 80K。剩下的部分在第一条消息到达之前就消失了——被系统提示词(system prompt)、工具定义、安全前言和聊天历史填充所消耗。这就是隐藏的 Token 税,大多数团队直到在生产环境中达到上下文限制时才意识到自己在为此付税。

宣传的上下文窗口与实际可用的上下文窗口之间的差距是生产级 LLM 系统中最昂贵的盲点之一。它在多轮对话中不断累积,通过注意力开销增加延迟,并在有用信息被挤入模型停止关注的“迷失在中间”(lost in the middle)区域时,悄无声息地降低输出质量。