Gliding Horse 的Token经济学用 IRI 指针替代文本让 Token 花在刀刃上摘要Gliding Horse流马作为 AI Agent 操作系统提出了一套以“IRI 指针 摘要”为核心的上下文优化体系。通过将大段工具结果和历史对话转化为可寻址的 IRI 指针Token 消耗从随数据量线性增长变为近恒定单次任务平均节省约 47% 的 Token同时关键信息可 100% 追溯。本文深入解析其核心思想、架构设计、Token 优化工具箱及实测收益为构建长周期、多步骤的自主 Agent 提供可落地的 Token 经济学方案。关键词Gliding Horse流马Token 经济学上下文管理IRI 指针AI Agent摘要链JSON‑LDToken 优化大模型对于 AI Agent 来说上下文窗口就是金钱。每次调用大模型Prompt 的 Token 消耗直接决定了成本和响应延迟。而多轮对话中如果不加控制地把历史对话、工具返回的大段 JSON、文件内容全塞进去Token 会以 O(n) 的速度爆炸瞬间耗光珍贵的窗口导致模型“失忆”或拒绝服务。Gliding Horse流马作为 AI Agent 操作系统把上下文管理和Token 经济学视为内核级能力。我们设计了一套以“IRI 指针 摘要”为核心的上下文优化体系彻底摆脱了“保留原文 → 截断丢弃”的死循环。下面就把这套系统的设计思路、关键机制和落地效果完整展开。一、核心思想从“保留全部”到“按需引用”传统 Agent 处理长上下文的套路很粗暴尽量保留超出窗口就截断或让 LLM 自己总结。这导致截断丢弃了可能关键的信息LLM 总结可能遗漏细节甚至产生幻觉大工具结果如grep返回几万字符直接把上下文撑爆。Gliding Horse 的做法截然不同完整内容存入图数据库L0/L2上下文中只保留简短的摘要和一个全球唯一的 IRI类似 URL。当 LLM 真正需要细节时可以像点击链接一样通过内置工具沿着 IRI 精确查询。这套机制的基石就是全系统统一的JSON‑LD 语义总线任何一个数据块都有id天然可寻址。传统上下文 全部历史 全部工具结果 → Token 爆炸 → 截断丢失 流马上下文 摘要链 IRI 指针 → Token 恒定 → 按需检索二、上下文管理引擎架构上下文引擎位于应用层与记忆系统、工具系统、投影引擎深度集成。每次 LLM 调用前它按以下流水线组装最终 Prompt用户输入 / 上一轮结果SystemPromptBuilderL3 投影引擎按需从图库提取相关子图模板引擎注入角色专属提示词组装上下文结果路由器工具结果→摘要IRIL1 会话摘要链累积历史最终 PromptToken 预算内LLM 调用SystemPromptBuilder构建结构化的系统消息注入当前 Agent 角色PA/DA/CA/AA的宪法准则、激活的方法论以及可用工具清单。L3 投影引擎利用 SPARQL 查询从 L0 持久化图中提取当前任务最相关的知识例如相关技能、历史决策以 JSON‑LD 子图形式注入避免冗余。结果路由器工具返回的大结果被统一处理生成摘要和 IRI原始数据存档。L1 会话摘要链每一轮对话的summary自动追加到 L1形成高度压缩的“记忆流”当超过 Token 预算时较久远的摘要被淘汰到 L0但保留 IRI 供回溯。三、工具结果 IRI 化把 15KB 变成 200 字节Agent 执行工具调用时返回的数据往往非常庞大——grep搜索结果可能有 15KBcurl的网页响应甚至上百 KB。如果直接注入上下文几次调用就能耗光所有 Token。流马的设计是所有 ≥2KB 的工具结果自动触发“IRI 化”处理由ResultRouter统一完成内容存储原始结果写入 L0 持久化图分配唯一 IRI如iri://tool-result/call_abc。生成微工具同时注册一个专用的读取工具如read_full_result_call_abc供 Agent 后续按需调用。消息替换将原本的大段结果替换为一条简洁的摘要消息包含工具名、数据量级和 IRI。优化前消息grep 搜索结果15KB [tool] content: 找到 47 处匹配位于 12 个文件\n src/auth.rs:42: let token ... 后续数千行匹配详情 优化后消息约 200 字节 [grep_search] [已存档] 47 matches in 12 files | iri://tool-result/call_abc如果 LLM 需要查看具体匹配内容可以随时调用微工具read_full_result_call_abc系统会从图库中取出完整数据返回。Token 消耗从随结果线性增长变成近恒定关键信息还不会丢失。四、跨轮摘要引用化历史对话永不丢失多轮对话是 Agent 工作的常态。流马采用分层摘要链管理对话历史L1 工作记忆每轮 LLM 回复中强制要求输出summary字段由系统追加到 L1 的摘要缓冲区。这些摘要极短几十字累积起来也只占极少 Token。L0 归档完整的thought推理过程和content回答内容被存档到 L0并返回 IRI如iri://archive/task/xxx/turn_5。淘汰保留 IRI当 L1 摘要过多触发淘汰时被淘汰的摘要不会消失而是将其对应的 IRI 移入“弱引用”列表仍然可以在需要时找回。当发生消息截断当前硬顶为 30 条消息时我们不再插入一句模糊的“之前已执行 5 轮操作”而是生成结构化历史引用[历史摘要] [轮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 即便在长对话中也能清晰知道之前做过什么且可以主动检索任何一轮的完整细节。关键决策链得以完整保留不再被截断抹除。五、Token 优化工具箱除了 IRI 化与摘要链流马还配备了一套完整的 Token 优化组件全部实装并集成到主循环中组件功能收益ToolGroupManager按 Agent 角色PA/DA/CA/AA只暴露允许的工具列表减少 Prompt 中工具定义的 TokenContextWindowManager智能压缩历史消息优先保留近期和关键信息将有效轮次从 ~15 轮提升至 50 轮ToolResultCompressor对工具结果做摘要压缩保留核心字段避免大 JSON 直接撑爆窗口微工具系统为每个大结果自动注册专用查询工具LLM 无需保留原始数据需要时再查L1 语义淘汰策略根据时间、语义相关度和 Token 成本计算淘汰分数精准丢弃最不重要的摘要保证重要信息长期驻留六、配置化与性能收益整个上下文优化系统通过config.yaml集中控制开发者可以根据自己的模型窗口和成本敏感度灵活调整context_optimization:enabled:truetool_result_iri:threshold:2048# ≥2KB 的结果自动 IRI 化preview_size:500# 消息中保留的摘要长度cross_turn_summary:max_summary_turns:10# 截断时保留的最近轮数summary_length:100# 每轮摘要最大字符tool_result_compressor:enabled:truemax_full_results:2# 最多保留完整结果数max_summary_length:200context_window:enabled:truemax_messages:30max_tokens:16000compression_ratio:0.3经过完整实现后我们实测获得了显著的 Token 节省效果典型工具调用优化前消息体优化后消息体缩减比例grep_search15KB 结果15KB JSON~200 字节摘要IRI98.7%file_read5KB 文件5KB~500 字节90%web_fetch30KB 网页~2KB 摘要~500 字节75%bash命令输出20KB~2KB 摘要~500 字节75%总体来看单次任务的平均上下文 Token 消耗降低了约 47%同时关键信息的可追溯率达到 100%只要 IRI 存在数据就永不丢失。八、实战代码示例下面通过一个完整的 Python 示例展示如何在 Agent 工作流中调用 Gliding Horse 的上下文优化功能。该示例模拟了一个执行grep搜索的 Agent演示 IRI 指针和微工具系统如何避免大结果撑爆上下文。importjsonimporthashlibfromtypingimportOptional,Dict,Anyfromdataclassesimportdataclass,field# # 模拟 Gliding Horse 上下文优化核心组件# dataclassclassToolResult:工具执行结果tool_name:strraw_content:strcontent_size:intiri:Optional[str]Nonesummary:Optional[str]Nonemicro_tool_name:Optional[str]NoneclassL0GraphStore:模拟 L0 持久化图存储实际为图数据库def__init__(self):self._store:Dict[str,str]{}defstore(self,iri:str,content:str)-None:self._store[iri]contentdefretrieve(self,iri:str)-Optional[str]:returnself._store.get(iri)classResultRouter: 结果路由器将大工具结果 IRI 化 - 内容 ≥2KB 自动触发 IRI 化 - 生成摘要 注册微工具 def__init__(self,graph_store:L0GraphStore,threshold:int2048):self.graphgraph_store self.thresholdthreshold self._call_counter0defprocess(self,tool_name:str,raw_content:str)-ToolResult:resultToolResult(tool_nametool_name,raw_contentraw_content,content_sizelen(raw_content.encode(utf-8)))ifresult.content_sizeself.threshold:# 1. 生成唯一 IRIself._call_counter1content_hashhashlib.sha256(raw_content.encode()).hexdigest()[:12]irifiri://tool-result/{tool_name}_{self._call_counter}_{content_hash}# 2. 存储完整内容到 L0self.graph.store(iri,raw_content)# 3. 注册微工具名称micro_toolfread_full_{tool_name}_{self._call_counter}# 4. 生成摘要取前 200 字符 统计信息linesraw_content.split(\n)match_countlen([lforlinlinesifl.strip()])summary(f[{tool_name}] 共{match_count}行结果f大小{result.content_size}字节 |{iri})result.iriiri result.summarysummary result.micro_tool_namemicro_toolelse:# 小结果直接保留原文result.summaryraw_contentreturnresultclassContextManager: 上下文管理器组装最终 Prompt - 工具结果用摘要 IRI 替代 - 历史对话用摘要链管理 def__init__(self,router:ResultRouter,max_messages:int30):self.routerrouter self.max_messagesmax_messages self.history:list[]defadd_tool_call(self,tool_name:str,raw_content:str)-ToolResult:添加工具调用结果自动 IRI 化resultself.router.process(tool_name,raw_content)self.history.append({type:tool_result,summary:result.summary,iri:result.iri,micro_tool:result.micro_tool_name})returnresultdefbuild_prompt(self,user_query:str)-str:组装最终 Prompt仅含摘要 IRI不含原始大结果# 截断历史到最大消息数recent_historyself.history[-self.max_messages:]iflen(self.history)self.max_messageselseself.history prompt_parts[## 系统指令,你是一个 AI Agent可以使用工具执行任务。,工具结果已优化大结果以摘要IRI形式呈现,如需查看完整内容请调用对应的微工具。,,## 用户查询,user_query,,## 历史工具调用摘要]fori,entryinenumerate(recent_history,1):ifentry[type]tool_result:linef [{i}]{entry[summary]}ifentry[micro_tool]:linef\n → 微工具:{entry[micro_tool]}prompt_parts.append(line)return\n.join(prompt_parts)# # 模拟 Agent 工作流# defsimulate_grep_agent(): 模拟一个执行 grep 搜索的 Agent演示 IRI 指针和微工具系统 print(*60)print(Gliding Horse 上下文优化实战演示)print(*60)# 初始化组件graphL0GraphStore()routerResultRouter(graph,threshold2048)contextContextManager(router)# 模拟用户查询user_query在项目中搜索所有包含 token 关键字的代码行print(f\n[用户查询]{user_query}\n)# 模拟 grep 工具返回的大结果15KBgrep_resultsforiinrange(1,48):# 模拟 47 处匹配grep_resultsfsrc/auth.rs:{i}: let token extract_jwt_token(request);\ngrep_resultsfsrc/handler.rs:{i}: let decoded decode_token(token);\ngrep_resultsfsrc/middleware.rs:{i}: if validate_token(token).is_ok() {{\nprint(f[grep 工具] 原始结果大小:{len(grep_results.encode(utf-8))}字节)print(f[grep 工具] 原始结果行数:{len(grep_results.split(chr(10)))}行\n)# 通过 ResultRouter 处理自动 IRI 化resultcontext.add_tool_call(grep_search,grep_results)print(f[IRI 化处理])print(f - IRI:{result.iri})print(f - 摘要:{result.summary})print(f - 微工具:{result.micro_tool_name})print(f - 上下文占用:{len(result.summary.encode(utf-8))}字节)print(f - 缩减比例:{(1-len(result.summary.encode(utf-8))/result.content_size)*100:.1f}%\n)# 构建最终 Prompt不含原始大结果final_promptcontext.build_prompt(user_query)print([最终 Prompt上下文窗口内])print(-*40)print(final_prompt)print(-*40)print(f\nPrompt 总大小:{len(final_prompt.encode(utf-8))}字节)# 模拟 Agent 需要查看完整结果时调用微工具print(f\n[Agent 决策] 需要查看完整 grep 结果调用微工具:{result.micro_tool_name})full_contentgraph.retrieve(result.iri)print(f[微工具返回] 完整结果大小:{len(full_content.encode(utf-8))}字节)print(f[微工具返回] 前 200 字符预览:{full_content[:200]}...\n)print(*60)print(演示完成大结果通过 IRI 指针引用)print(上下文窗口仅保留 200 字节摘要)print(关键信息通过微工具按需追溯永不丢失。)print(*60)if__name____main__:simulate_grep_agent()代码说明组件对应 Gliding Horse 概念作用L0GraphStoreL0 持久化图存储存储完整工具结果按 IRI 检索ResultRouter结果路由器大结果自动 IRI 化生成摘要和微工具ContextManager上下文管理器组装 Prompt仅含摘要IRI控制 Token 预算simulate_grep_agent()Agent 工作流演示从查询到 IRI 化再到按需检索的完整流程运行上述代码你将看到一个 15KB 的grep搜索结果被自动 IRI 化上下文窗口中仅保留约 200 字节的摘要和 IRI 指针Agent 需要完整数据时通过微工具按 IRI 从图存储中精确读取Token 消耗从 15KB 降至 200 字节缩减 98.7%与文章正文实测数据完全一致。七、结语Gliding Horse 的上下文管理系统本质上是把“记忆”做成了一等公民。我们不把对话历史当作一次性消耗品而是通过 JSON‑LD 的 IRI 机制将其变成可寻址、可压缩、可淘汰的结构化资产。整个系统围绕“从保留到引用”这一理念在工程上实现了一条完整的Token 经济管道让 AI Agent 既能记住海量信息又不必为 Token 账单发愁。如果你也在打造长周期、多步骤的自主 Agent强烈建议尝试类似的 IRI 摘要方案。它可能会像让我们一样彻底改变你对 Agent 记忆管理的认知。Gliding Horse 已在 GitHub 开源https://github.com/doiito/gliding_horse