为什么你的智能体正在大量消耗 Token
你部署了一个编程智能体。它会自动拉取任务单并提交 PR。运行效果很好。
然后，账单寄到了。
智能体消耗的费用超出了你的预期，而你却不知道原因。每个任务单它都要调用模型 50 次。有些调用是缓慢的重试，有些则是对相同上下文的冗余读取。
这不是模型的问题，而是基础设施的问题。你的团队缺乏对支出的可见性。在失控的智能体烧光你的预算之前，你根本无法阻止它。
智能体本质上是循环。它们读取任务、调用工具、读取输出，然后不断重复。每一步都会消耗 Token。如果智能体在每一轮都重新读取系统提示词 (system prompt)，成本会迅速飙升。一个小小的 Bug 就会导致数百次额外的读取。
你看到的是账单，而不是具体的调用过程。这时已经太晚了。
成功的团队从第一天起就会建立成本控制机制。他们使用以下方法：
- 设置每月预算上限。
- 记录每一次调用是由哪个智能体、哪个任务触发的。
- 能够解释为什么某个任务的成本比另一个更高。
要在生产环境中运行智能体，你需要：
- 按智能体追踪：了解每个用户和每个任务的成本。
- 虚拟密钥：隔离团队，防止单个开发人员烧光整个预算。
- 预算控制：设置硬性限制。当智能体达到限制时，应当向你发出警报或停止接收任务。
- 支出可见性：使用仪表板查看趋势和每个任务的平均成本。
- 详细日志：查看调用类型的分布情况。
如果你忽略了这些，你就像在盲目驾驶。
LiteLLM 使用一种特定的模式来避免这种情况：
- 大脑与沙箱分离：推理过程在一个地方运行，执行过程在另一个地方运行。这可以防止不断的重复读取。
- 清晰的工具接口：使用结构化定义，而不是长文本。
- 网关追踪：每一次调用都通过网关路由，并携带智能体和团队的 ID。
- 强制预算执行：智能体在开始任务前会检查剩余预算。
如果你在没有这些工具的情况下构建智能体，你将面临成本爆炸。智能体在遇到边缘情况或循环之前表现良好，但到那时，钱已经花光了。
现在就采取以下步骤：
- 审计你最近的一份 API 账单。
- 为每一次调用添加智能体 ID 和任务 ID 进行埋点。
- 今天就设置一个预算上限。
- 记录工具调用，以找出失败的重试。
- 每周审查调用模式。
构建能够将可靠的智能体与昂贵的错误区分开来的基础设施。
为什么你的智能体正在悄无声息地消耗 Token 以及如何阻止它们
构建自主智能体（Agents）是 AI 领域最令人兴奋的前沿方向之一。但它有一个巨大的陷阱：它们可能会变得极其昂贵。你可能最初只是写了一个简单的提示词（Prompt）并进行了几次工具调用，结果却发现 API 账单在飞速飙升。
如果你正在构建基于 LLM 的智能体，你可能已经发现，成本并不是线性增长的，而是呈指数级增长。
ReAct 循环：Token 吞噬者
大多数现代智能体都遵循 ReAct（Reasoning and Acting，推理与行动）模式。其工作流程通常如下：
- 思考 (Thought)：智能体决定下一步该做什么。
- 行动 (Action)：智能体调用一个工具（例如搜索网页或查询数据库）。
- 观察 (Observation)：智能体获取工具返回的结果。
- 重复：智能体根据观察结果进行下一次思考。
问题在于，为了让智能体保持上下文连贯，每一次迭代都必须将整个对话历史（包括之前的思考、行动和观察结果）重新发送给 LLM。
这意味着，随着步骤的增加，你的 Prompt 会变得越来越长。第 1 步可能只需要 500 个 Token，但到了第 10 步，由于包含了前 9 步的所有信息，单次调用可能就会消耗 5,000 个甚至更多的 Token。
上下文窗口与“膨胀”问题
随着智能体尝试解决复杂问题，上下文窗口会迅速膨胀。这不仅会导致成本上升，还会带来其他问题：
- 注意力分散：随着上下文变得极其冗长，LLM 可能会开始忽略 Prompt 中的关键指令或丢失早期的重要信息（即“迷失在中间”现象）。
- 延迟增加：处理更长的上下文意味着更长的推理时间，这会直接影响用户体验。
“无限循环”陷阱
这是最危险的情况。有时，智能体会陷入一种逻辑死循环。例如：
- 它尝试使用某个工具，但工具返回了一个错误。
- 智能体试图修复错误，但它采取了相同的错误方法。
- 它在两个相似的推理步骤之间来回跳跃。
由于智能体是“自主”的，它会不断尝试，直到达到 Token 限制或你手动停止它。在这种情况下，一个简单的任务可能会在几分钟内消耗掉数十美元。
如何止损：控制成本的策略
要构建可持续运行的智能体，你必须实施严格的成本控制措施。以下是几种有效的策略：
1. 设置最大迭代次数限制 (Max Iterations)
永远不要给智能体无限运行的权限。在你的代码逻辑中，必须设置一个硬性的 max_iterations 参数。如果智能体在达到设定步数后仍未完成任务，应强制停止并返回错误或当前状态。
2. 实施历史记录总结 (Summarization)
不要总是将完整的原始历史记录传回给 LLM。你可以引入一个“总结机制”：当对话历史超过一定长度时，调用一个更廉价的模型（如 GPT-4o-mini）来总结之前的步骤，然后只保留“总结后的历史 + 最近的几次交互”。
3. 修剪工具输出 (Trim Tool Outputs)
这是最容易被忽视的一点。如果一个工具（例如网页爬虫）返回了 50KB 的 HTML 或 JSON 数据，直接将其塞进 Prompt 是极其浪费的。
- 截断：只保留前 1000 个字符。
- 提取：使用正则表达式或小型模型仅提取与问题相关的关键信息。
4. 使用模型路由 (Model Routing)
并非所有步骤都需要最强大的模型。
- 路由/决策：使用廉价模型来决定是否需要调用工具。
- 复杂推理：仅在需要进行深度逻辑分析时，才将任务交给昂贵的模型（如 GPT-4o 或 Claude 3.5 Sonnet）。
通过实施这些策略，你可以从“盲目燃烧 Token”转变为“高效利用 Token”，从而构建出既强大又经济的 AI 智能体。