工具输出压缩：决定上下文质量的注入策略

你的智能体调用了一个数据库工具。查询返回了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付费。

提取准确率下降表现为模型对它曾经自信回答的问题开始含糊其辞。输出中出现"根据提供的信息"或"我不确定但"等措辞，而之前这些问题能产生干净、直接的答案，这是模型被竞争性或无关上下文混淆的信号。这与真正的模型不确定性不同——这是上下文噪声导致的精度问题。

与会话长度而非查询复杂度相关的延迟增加指向上下文膨胀。如果你的首Token时间随着会话变长而攀升，瓶颈是上下文处理，而非计算。

成本监控中特定工具类型的预算超支会告诉你哪些工具是罪魁祸首。如果某个工具的结果平均8000个Token，你每次会话调用它20次，无论管道其余部分如何工作，这个工具都需要压缩策略。

加剧问题的反模式

大多数团队没有一个注入策略——他们有一个偶然演化出来的隐式策略。

上下文填塞是最常见的反模式：将大型上下文窗口视为注入一切的许可。100万Token的上下文窗口没有改变模型的有效注意力分布，它改变的是你能注入多少噪音、在模型完全崩溃之前的上限。用未压缩的工具输出填满窗口在演示中有效，因为演示查询直接，相关信息显而易见。在生产中，查询是模糊的，会话是漫长的，模型必须在不断增长的干草堆中寻找信号。

多智能体上下文传播会复合这个问题。智能体A在15次工具调用中积累了30000个Token，为一个子任务生成智能体B，并传递了完整上下文"以便B拥有一切所需"。B对C做同样的事。每个智能体为完整继承的上下文付费，每个智能体又添加更多。解决方案是在智能体边界处的显式上下文契约：定义每个子智能体需要什么信息，只传递那些。

不加区分的观察日志记录将每个中间步骤——工具调用输入、状态变更、调试元数据——注入智能体的上下文流。这使早期智能体架构易于调试，但在生产规模下意味着模型花费大量注意力阅读自己的管道。记录到外部系统；只注入动作-结果对。

无论工具类型使用固定序列化格式将结构化数据库输出与非结构化网络搜索结果同等对待。数据库输出从字段提取中获益巨大；网络搜索结果通常需要语义摘要。对两者使用相同的注入策略，保证你对其中至少一个是错误的。

分层压缩架构

最健壮的生产方式将注入视为分层决策而非单一策略。

第一层是对所有有稳定模式的工具进行字段提取。编写提取配置，将每个工具的输出模式映射到智能体实际使用的字段。这以最小开销处理大多数管道中大多数工具调用。

第二层是对高价值、非结构化输出进行选择性模型内压缩。不是每个工具结果都值得一次压缩调用——将其保留给输出大、非结构化，且相关内容真正难以通过编程识别的情况。

第三层是会话级别的上下文窗口管理。当总上下文超过阈值（通常是限制的80%）时，对较旧的工具交互应用摘要。保留最近几轮原文——上下文窗口最后10%是不应压缩的活跃工作内存。较旧的交互通常可以提炼为动作-结果对，而不会丢失任务相关信息。

LangChain对深度智能体上下文管理的实现遵循这一模式：将大型工具结果卸载到文件系统引用，当上下文填满时摘要旧历史，并给智能体一个可以在判断需要更多上下文时自主调用的压缩工具。"苦涩的教训"洞察在这里适用——给智能体更多对自身压缩的控制权，往往比手工调整启发式规则产生更好的结果，因为智能体对其当前任务的相关性有更多信息。

需要测量什么

如果你从这篇文章只实施一件事，请将这三个指标添加到你的智能体监控中：

上下文占用率：使用的峰值Token除以上下文窗口限制，作为时间序列跟踪。在没有任务复杂度上升的情况下呈上升趋势，就是压缩问题。

提取覆盖率：对于结构化提取，工具响应中提取成功与回退到原始注入的比例。下降的比率意味着你的模式需要更新或提取逻辑有缺口。

按会话长度划分的准确率：如果你的智能体任务准确率随会话变长而下降，工具输出积累很可能是原因。这需要一个包含不同会话深度任务的评估框架，但这是衡量你的压缩策略是否有效的最直接方式。

把工具输出压缩做好的团队不会把它视为一种优化。他们将其视为与工具选择和智能体架构同时做出的一等设计决策。你早期确定的注入策略会成为你的智能体日后所能做一切的无形约束。