工具输出压缩：决定上下文质量的注入策略
你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。
这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。
根本原因几乎总是未压缩工具输出导致的上下文污染。平均智能体会话长度从2023年末的不到2000个Token增长到2025年末的5400个Token以上，增长的绝大部分来自工具结果在上下文中的积累。仅序列化格式不当就会浪费40–70%的可用Token，全都花在格式开销上——JSON缩进、冗余的模式包装器、没有人需要的元数据。
你对工具输出注入方式的决策不是细节问题。它是一个承重的架构选择，决定了你的成本上限、延迟下限，以及随着会话变长时的准确率曲线。
三种注入策略
处理工具结果进入上下文之前，恰好有三种方式，每种都有截然不同的成本-质量特征。
原始注入意味着你将工具输出不经任何预处理直接传给模型。这是大多数实现的默认方式——便于推理，且保留完整信息。问题在于它把压缩问题交给了模型本身。模型必须读取并处理你注入的每一个Token，包括不相关的那些。在小规模下这没什么问题。在生产规模下，将塞满内容的上下文与精心整理的上下文相比，70B模型的首Token延迟增加高达719%。质量损失更微妙但同样真实：注入无关上下文的模型开始含糊其辞、给出不确定答案，有时甚至自相矛盾。原始注入只适合工具结果不超过约500个Token且整个输出都可能相关的场景。
模型内压缩将工具输出先通过LLM摘要步骤，再注入结果。你要求一个模型（通常是更小、更便宜的模型）提取或总结相关信息，然后注入压缩后的版本。这比基于规则的提取更好地保留语义意图，也能处理多样或不可预测的输出模式。代价是你要付两次费——一次生成工具结果，一次压缩它——并且增加了延迟步骤。还存在幻觉风险：压缩模型可能悄悄丢弃关键边缘情况或抹平数值精度。当工具输出很大、非结构化，且相关内容只占整体一小部分时，模型内压缩效果最好。
结构化字段提取在工具结果到达模型之前拦截它，根据已知模式解析，仅注入你指定的字段。这是成本最低、延迟最短的选项——基于规则的提取不需要LLM调用——当模式完整时质量上限很高。约束在于你需要提前知道哪些字段重要。这种策略适合输出模式稳定、可预测的工具：SQL查询、REST API调用、结构化日志、内部服务响应。当工具输出真正异构或相关字段因查询类型而变化时，它就会失效。
实用启发式：对有已知模式的工具从结构化提取开始，仅当输出本来就紧凑时使用原始注入，将模型内压缩保留给两者都不适用的情况。
质量-成本矩阵
了解何时切换策略需要知道每种策略的具体成本。
原始注入的前期成本看似很低——没有额外处理步骤，没有额外LLM调用。但下游成本会复利增长。上下文污染会降低需要模型跨多条信息进行推理的任务的准确率。随着会话变长，即使名义上的上下文窗口很大，模型的有效注意力窗口也会缩小。你也会更快触达提供商限制，导致截断（静默信息丢失）或报错。
模型内压缩在最坏情况下将每步Token成本翻倍。一个10000 Token的工具结果要经过一次摘要调用，这次调用本身也会生成和消耗Token。对于高吞吐量管道，这可能是主要的成本驱动因素。质量收益是真实的，但难以衡量——很难将准确率提升归因于压缩而非其他变化。
结构化字段提取一旦提取逻辑写好，每次调用的边际成本趋近于零。投入在前期：模式定义、边缘情况处理、针对真实输出的测试。隐性成本是维护：当工具的输出模式变化时，提取会静默失效，你直到准确率开始下降才会发现。
ACON是一个针对长周期智能体上下文压缩的研究框架，通过将结构化提取与选择性摘要相结合，实现了26–54%的峰值内存减少，同时保持了95%以上的任务准确率。AutoTool通过动态选择工具子集而非压缩输出，将每步上下文Token减少了95%，端到端成本降低了70%。这些结果在受控环境中获得，但它们说明了朴素注入与精心上下文管理之间数量级的差距。
提示你需要改变策略的生产信号
注入策略出问题的第一个迹象几乎从来不是崩溃或报错，而是质量指标的漂移，容易被归因于错误原因。
上下文Token数量上升是领先指标。如果你的p95会话长度在没有对应任务复杂度增加的情况下逐周增长，工具输出正在上下文中积累。采取行动的阈值通常是会话定期超过上下文窗口的80%——此时你正在为可能弊大于利的Token付费。
