工具结果压缩体系：如何用“指针”驯服上下文膨胀-北京尧图网络

在 AI Agent 执行任务的过程中工具调用结果的体积往往是上下文的头号杀手。一个 grep 搜索可能返回上万字符的匹配列表一次 bash 命令可能输出几十 KB 的编译日志如果把这些结果原封不动地塞进 LLM 的上下文窗口不出几轮 Token 就会爆炸轻则成本飙升重则直接触发 API 限制。Gliding Horse流马作为面向长周期、多步执行的 Agent 操作系统设计了一套纵深防御式的工具结果压缩体系。它并非简单截断而是通过 “指针摘要” 的模式将大块结果替换为轻量引用同时保留 LLM 随时通过微工具查询完整细节的能力。信息不丢失上下文不爆炸。一、三层压缩架构纵深防御流马的工具结果管理分为三个层次在结果注入上下文的不同阶段递进式压缩16KB: 原样IRI16~32KB: 截断micro-tool32KB JSON: 图谱化micro-tool32KB 非JSON: 摘要micro-tool安全网: 二次压缩保留最近4条中间摘要工具执行结果(可能数万字节)① ResultRouterroute_tool_result()注入 messages[]② ToolResultCompressorcompress_tool_messages()更新后的 messages[]③ ContextWindowManager消息数/Token 超限时最终上下文第一层 (ResultRouter)结果进入上下文之前根据大小和类型自动选择处理策略——小结果原样放行大结果截断或图谱化并注册微工具供 LLM 按需查询。第二层 (ToolResultCompressor)在上下文已有压力时对 message 列表中的旧工具结果做二次摘要压缩作为兜底安全网。第三层 (ContextWindowManager)当消息总数或估算 Token 超过硬上限时对整个消息序列进行结构化压缩保留最近关键信息中间段用摘要替代。三层相互配合既保证了单条结果不撑爆上下文又防止了多次小结果累积膨胀。二、第一层ResultRouter 的智能路由ResultRouter 是整个压缩体系的核心防线。它在工具结果返回后、注入 messages 前工作能够访问 L0 存储和 ToolExecutor拥有完整上下文。 16KB16KB ~ 32KB32KB JSON32KB 非JSON3KB 时预注册 micro-tool原始工具结果结果大小?PassThrough原样 IRITruncatesmart_truncate micro-toolGraphify知识图谱化 micro-toolsSummarizetext_summary micro-tool注入上下文截断结果 IRI micro-tool图谱摘要 IRI micro-tools文本摘要 IRI micro-tool关键机制Micro-tool 模式任何被压缩或截断的结果系统都会自动注册一个专用微工具如 read_full_result_{call_id}LLM 可以随时调用它来获取完整原始数据。信息零丢失。PassThrough 增强即使结果小于 16KB 原样放行只要超过 3KB系统也会预注册微工具。这为后续的“智能回收”埋下伏笔——当上下文压力增大时这些较大的 PassThrough 结果可以被替换为轻量引用而不丢失可回溯性。Graphify 图谱化对于大型 JSON 结构数据如 API 返回的复杂对象自动提取关键实体和关系存入知识图谱L0/L2LLM 拿到的是简洁的图谱摘要后续可通过 SPARQL 或微工具深入探索。下面是一个 Python 代码示例展示 ResultRouter 如何根据结果大小和类型选择不同的压缩策略from typing import Any, Optionalimport jsonclass ResultRouter:“”“智能路由根据结果大小和类型选择压缩策略”“”def __init__(self, micro_tool_registry: dict): self.registry micro_tool_registry # 微工具注册表 def route_tool_result(self, call_id: str, result: Any) - dict: 路由工具结果返回注入上下文的压缩内容 raw json.dumps(result) if not isinstance(result, str) else result size len(raw.encode(utf-8)) # 策略 1小于 16KB —— 原样放行超过 3KB 预注册微工具 if size 16 * 1024: if size 3 * 1024: self._register_micro_tool(call_id, raw) return {content: raw, iri: firi://tool-result/{call_id}} # 策略 216KB ~ 32KB —— 截断微工具 if size 32 * 1024: truncated self._smart_truncate(raw, max_bytes2048) self._register_micro_tool(call_id, raw) return {content: truncated, iri: firi://tool-result/{call_id}} # 策略 3大于 32KB —— 根据类型选择图谱化或摘要 if self._is_json(result): graph_summary self._graphify(result) # 提取实体关系图谱 self._register_micro_tool(call_id, raw) return {content: graph_summary, iri: firi://tool-result/{call_id}} else: summary self._summarize(raw, max_chars500) # 文本摘要 self._register_micro_tool(call_id, raw) return {content: summary, iri: firi://tool-result/{call_id}} def _smart_truncate(self, text: str, max_bytes: int) - str: 智能截断保留开头和结尾的关键信息 encoded text.encode(utf-8) if len(encoded) max_bytes: return text head encoded[:max_bytes // 2].decode(utf-8, errorsignore) tail encoded[-max_bytes // 2:].decode(utf-8, errorsignore) return f{head}\n...中间省略 {len(encoded) - max_bytes} 字节...\n{tail} def _is_json(self, result: Any) - bool: 判断结果是否为 JSON 结构数据 if isinstance(result, (dict, list)): return True if isinstance(result, str): try: json.loads(result) return True except (json.JSONDecodeError, ValueError): return False return False def _graphify(self, data: Any) - str: 将大型 JSON 图谱化为摘要示意实现 if isinstance(data, dict): keys list(data.keys())[:5] return f[图谱摘要] 包含 {len(data)} 个字段: {, .join(keys)}... if isinstance(data, list): return f[图谱摘要] 包含 {len(data)} 条记录首条字段: {list(data[0].keys()) if data else 空} return [图谱摘要] 非结构化数据 def _summarize(self, text: str, max_chars: int) - str: 文本摘要示意实现 return text[:max_chars] f\n...全文 {len(text)} 字符请调用微工具查看... def _register_micro_tool(self, call_id: str, full_result: str): 注册微工具供 LLM 按需查询完整结果 self.registry[call_id] { name: fread_full_result_{call_id}, description: f获取工具调用 {call_id} 的完整原始结果, handler: lambda: full_result } 使用示例 router ResultRouter(micro_tool_registry{})场景 1小结果 16KB—— 原样放行small_result {“status”: “ok”, “count”: 42}print(router.route_tool_result(“call_001”, small_result))输出: {‘content’: ‘{“status”: “ok”, “count”: 42}’, ‘iri’: ‘iri://tool-result/call_001’}场景 2中等结果16KB ~ 32KB—— 截断微工具medium_result “A” * 20_000 # 约 20KB 文本routed router.route_tool_result(“call_002”, medium_result)print(f截断后长度: {len(routed[‘content’])} 字符)print(f微工具已注册: {‘call_002’ in router.registry})场景 3大型 JSON 32KB—— 图谱化微工具large_json {“users”: [{“id”: i, “name”: fuser_{i}“} for i in range(1000)]}routed router.route_tool_result(“call_003”, large_json)print(f图谱摘要: {routed[‘content’]}”)场景 4大型文本 32KB—— 摘要微工具large_text “B” * 50_000routed router.route_tool_result(“call_004”, large_text)print(f摘要长度: {len(routed[‘content’])} 字符)代码要点说明route_tool_result 是核心路由方法根据结果字节大小和类型分发到四种策略PassThrough、Truncate、Graphify、Summarize。任何被压缩的结果都会通过register_micro_tool 注册一个微工具LLM 可随时调用 read_full_result{call_id} 获取完整原始数据实现信息零丢失。_smart_truncate 采用“头尾保留”策略避免截断丢失关键上下文_graphify 和 _summarize 为示意实现生产环境可接入 LLM 或知识图谱引擎。三、第二层ToolResultCompressor 安全网当上下文中的工具消息累积到一定数量默认 10 条时ToolResultCompressor 会启动对最旧的工具结果执行二次压缩超过长度限制的仅保留前几行并附加“已压缩”标记。这一层是有损压缩的安全网主要覆盖那些未被第一层充分处理的小结果累积情况。在实践中由于第一层已将大结果截断到 2KB 左右第二层真正触发压缩的概率很低——但它提供了一个兜底保障。四、第三层ContextWindowManager 全局控制当前消息总数超过 30 条或估算总 Token 超过 16000 时ContextWindowManager 介入保留最近 4 条消息包括 user/assistant/tool 配对原样不动。中间段消息用智能摘要替代提取每轮的关键动作、涉及 IRI、工具调用次数等信息生成结构化历史引用。确保不拆散消息对工具调用assistant role和工具结果tool role始终成对保留避免孤儿消息导致 API 报错。压缩后的历史引用示例[历史摘要][轮1/PA] 制定分析计划 → iri://archive/task/xxx/turn_1[轮2/DA] 搜索认证接口 (grep×3) → iri://archive/task/xxx/turn_2[轮3/DA] 分析JWT流程 → iri://archive/task/xxx/turn_3如需详细信息请使用 kg_search / knowledge_query 查询 IRI。LLM 可以清晰知道此前做过什么并随时通过 IRI 检索任意轮次的完整详情。五、智能回收两阶段压缩优化在第一层和第三层之间我们引入了一个智能回收环节形成完整的“准备—回收”闭环阶段一准备ResultRouter 在 PassThrough 分支中对大于 3KB 的结果预注册微工具。此时消息内容不变仍为全文但已具备“可回收”的条件。阶段二回收当 ContextWindowManager 或 ToolResultCompressor 触发压缩后系统扫描 messages 中的所有 tool 消息对于内容仍较大500 字节且已有对应微工具的结果将其替换为轻量引用[已压缩 10240 字节] 完整结果请调用read_full_result_call_abc工具IRI: iri://tool-result/call_abc原始内容已安全存储在 L0 中LLM 只需调用微工具即可随时查看。上下文瞬间瘦身 98%而信息零丢失。六、流式与非流式路径统一Gliding Horse 同时支持流式和非流式 LLM 调用两条路径均完整实现了三层压缩非流式路径 (execution.rs)每轮调完 LLM 后执行完整的 route_tool_result → ToolResultCompressor → ContextWindowManager 链路。流式路径 (utils.rs)同样在工具结果路由后执行压缩ContextWindowManager 改为每 3 轮触发一次以减少流式场景下的额外延迟。两条路径共享相同的 ResultRouter 和 ContextWindowManager 逻辑压缩效果一致。七、给平台带来的核心优势指标优化前优化后说明单次 grep 搜索 (15KB) 15KB 原文注入 ~200 字节摘要 IRI 缩减 98.7%10 次 bash 命令 (各 10KB) 100KB 累积压缩后丢失信息 10 条引用微工具可查询全文信息零丢失大型 JSON (50KB) 结果截断或硬丢弃图谱摘要微工具结构可探索语义不丢失长对话 (30 轮) 超过限制被截断前文丢失历史结构化引用IRI 可回溯关键决策链完整整体上单次任务的平均工具结果 Token 消耗降低 90% 以上同时实现了 100% 的关键信息可追溯——因为每个被压缩的结果都有一个 IRI 和对应的微工具Agent 永远不会真正“遗忘”。

工具结果压缩体系：如何用“指针”驯服上下文膨胀

相关推荐

MDX-M3-Viewer终极指南：在浏览器中渲染魔兽争霸3和星际争霸2模型的完整实战方案

MDX-M3-Viewer终极指南：在浏览器中零安装查看魔兽争霸3和星际争霸2模型

2026 实时视频总结工具怎么选：这份靠谱实用指南帮你不踩雷

更多资讯

基于ADS122U04IPWR与STM32F427ZI的工业测温方案设计

Dubbo服务下线实时告警：基于ZooKeeper Watch的轻量级监控方案

SSM超市管理系统源码解析：从分层架构到本地部署与业务修改

SSM超市管理系统实战：从课设跑通到二次开发全解析

锂电池PACK生产数字孪生平台架构与实现

PIPE4.3.0安装排错：JDK版本、JAVA_HOME与Petri验证

今日更新

多智能体协作系统架构设计与实践优化

大模型系统性入门实战指南：从原理到部署微调的全链路路线

鸿蒙文件系统沙箱机制解析与开发实践

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？