阻止Token流失：构建高效Token的多代理系统
内容提要
本文探讨了AI代理系统中隐藏的Token成本问题，指出模型并非最大开销，而是重复检索、冗余提示和低效架构。通过引入意图路由、语义缓存、上下文预算管理、自适应检索和模型选择等优化技术，可显著降低成本和延迟。核心原则是重新设计工作流，让LLM成为最终操作而非首选，仅生成必要Token，实现高效可扩展的AI系统。
延伸解读
架构设计比提示词压缩更关键
文章指出，多代理系统中Token消耗的大头往往不是模型本身，而是重复检索、冗余提示和低效架构。例如，一个典型的多代理流程中，每个阶段都可能重复检索相同文档、发送相同指令，导致大量不必要的Token消耗。因此，优化Token效率的核心在于重新设计工作流，而非仅仅缩短提示词。
将LLM作为最后手段
文章强调，在高效的系统中，LLM不应是首选组件，而应是最终、最昂贵的操作。通过引入意图路由，将简单请求（如状态查询）分流到确定性逻辑，避免不必要的模型调用。同时，采用语义缓存和精确匹配缓存，对重复问题直接返回缓存结果，从而大幅降低成本和延迟。
上下文预算与检索复用
文章建议为上下文窗口设定严格的Token预算，只保留最相关的文档片段，避免一次性塞入过多内容。此外，多代理系统应遵循“检索一次，处处复用”的原则，共享检索结果，避免每个代理独立发起检索，从而减少重复计算和Token消耗。
模型选择与可观测性
根据任务复杂度选择不同规模的模型，简单问题使用小模型，复杂问题才调用大模型，可显著降低成本。同时，文章强调Token用量监控的重要性，通过估算Token数来量化效率，帮助工程师发现成本异常。此外，结构化输出和优雅降级机制确保系统在生产环境中的稳定性。
Q&A
AI代理系统中隐藏的Token成本主要来自哪些方面？
隐藏的Token成本主要来自重复检索、冗余提示、不必要的工具调用、过大的上下文窗口，以及多个代理对相同信息的重复推理。这些架构决策在单个看来无害，但在生产规模下会显著增加延迟和云开支。
如何通过意图路由减少Token消耗？
通过意图路由，将简单、确定性的请求（如查询状态或运行手册）直接路由到非LLM的确定性逻辑，避免调用大语言模型，从而大幅降低成本。例如，根据问题关键词分类，将'status'路由到'metrics'，将'runbook'路由到'retrieval'，只有复杂问题才进入'generation'。
语义缓存如何帮助降低Token成本？
语义缓存通过存储之前生成的响应，当相同问题与相同检索文档出现时直接返回缓存结果，避免重复调用模型。文章中的示例使用精确匹配缓存，基于问题和文档标识生成哈希键，命中时直接返回缓存，从而节省Token和延迟。
什么是上下文预算管理？如何实施？
上下文预算管理是限制输入给模型的Token数量，避免将检索到的所有文档都塞入上下文。实施时，使用tiktoken编码器计算每个块的Token数，按顺序累加，直到达到预设的最大上下文Token数（如2500），超出部分截断，只保留最相关的部分。
在多代理系统中，如何避免重复检索？
避免重复检索的原则是'检索一次，复用所有'。在流水线中，先进行一次检索，将结果构建为共享上下文，然后所有下游代理都使用这个共享上下文，而不是各自启动独立的检索流程。这样可以显著减少重复的检索调用和Token消耗。
如何根据问题复杂度选择模型以节省成本？
根据问题复杂度选择模型：对于简单、短小的问题（如少于200字符），使用小模型（如gpt-4o-mini）；对于复杂问题，使用大模型（如gpt-4.1）。这样可以大幅降低运营成本，同时不影响响应质量。
为什么Token遥测对优化很重要？
Token遥测（监控Token使用情况）使优化可衡量，帮助工程师检测成本回归。通过估算输入Token数，可以了解每次调用的消耗，从而识别瓶颈和优化机会。没有遥测，优化就是猜测。
构建高效Token的多代理系统有哪些核心原则？
核心原则包括：将LLM作为最终操作而非首选；通过意图路由、语义缓存、上下文预算管理、自适应检索和模型选择等优化技术，在每次昂贵模型调用前进行优化；检索一次，复用所有；保持指令与用户输入分离；使用结构化输出；以及监控Token使用。最终目标是只生成必要的Token，实现高效可扩展的AI系统。
