Claude Code vs 流马两种上下文管理哲学的对决之前我拆解了 Claude Code 的 5 种上下文管理策略也介绍了流马Gliding Horse的 6 种策略。但有读者提醒我漏了一个关键点流马的 PA、DA、CA、AA 本身就是 Subagent而且比 Claude Code 的 Subagent 做得更深。今天就把这个拼图补上来一场公平的、深度的上下文管理策略对决。一、Claude Code 的 5 种策略Claude Code 是目前开发者体验最好的 AI 编码助手之一。它的上下文管理策略非常务实策略机制核心价值ContinueToken 预算充足时持续追加对话保证流畅体验Rewind回滚到历史任意检查点重新开始消除错误分支像 Git resetClear完全清空上下文仅保留系统提示词彻底重置适合全新任务Compact将历史对话压缩为结构化摘要文档保留关键信息砍掉冗余Subagent创建子 Agent携带部分上下文独立执行任务父 Agent 只关心结果上下文隔离解决注意力污染这 5 种策略的核心特征是基于文件系统的线性恢复 粗粒度压缩 任务级隔离。它们解决的是“单 Agent 在长对话中如何不丢上下文”的问题。二、流马的 6 种策略 原生 Subagent 体系流马因为从底层就是多 Agent 架构它的上下文管理策略天然就要处理“多个 Agent 共享记忆、协同工作”的场景。策略机制与 Claude Code 的差异Continue正常追加同回溯利用 L2 黑板中的 Named Graph 快照可回滚到任务树上的任意节点状态比 Rewind 粒度更细不是回滚到“某个对话轮次”而是回滚到“某个子任务的某个阶段”重置清空 L1但保留系统骨架和历史 IRIClear 是彻底失忆流马的重置是“暂时放下随时能捡起来”主动摘要 IRI 解引用LLM 每次输出带summary上下文只保留摘要 IRI完整内容和工具大结果存 L0 知识图谱需要时按 IRI 查询这是 Claude Code 没有的能力。Token 从 O(n) 变成 O(1)且不丢任何细节智能压缩score w1*(1/time) w2*(1/semantic_relevance) w3*token_cost基于向量相似度动态淘汰低价值摘要Compact 是一次性粗粒度压缩流马是逐条、动态、语义驱动的细粒度淘汰截断压缩兜底策略极端情况滑动窗口同PA/DA/CA/AA 原生 Subagent每个角色就是一个 Subagent且它们共享 L2 黑板有 MESI 协议保证一致性这是最大的差异点最关键的就是最后一条。Claude Code 的 Subagent 是一个“被父 Agent 派出去干活、干完回来报告”的独立进程。它带一部分上下文出去执行完返回结果父 Agent 完全不关心中间过程。流马的 PA、DA、CA、AA 也是 Subagent但它们不是孤立执行的——它们通过 L2 黑板实时共享状态。DA 执行到一半CA 已经可以在黑板上看到中间产物并提前预警。多个 DA 并行时MESI 协议保证它们对共享数据的修改不会冲突。AA 做决策时已经掌握了所有 Subagent 的完整执行轨迹。这就像Claude Code 是一个老板派了五个员工出去干活每个员工干完回来单独汇报。流马是一个老板派了五个员工但他们都在同一块白板上边干活边交流老板随时能看到全局进度。三、一张表看清两种哲学维度Claude Code流马 (Gliding Horse)架构基础单 Agent 文件系统多 Agent 图数据库 JSON-LD压缩粒度粗粒度整段对话 → 一篇摘要细粒度每条对话独立摘要 IRI记忆可寻址性文件系统级靠文件名定位图原生每个记忆有全局唯一 IRI可 SPARQL 精确查询大工具结果写入上下文或截断存知识图谱仅 IRI 注入上下文Subagent 隔离完全隔离仅返回结果共享 L2 黑板 MESI 一致性实时协同回滚粒度检查点对话轮次Named Graph 快照可恢复到任务树上任意节点压缩智能性LLM 一次性摘要向量相似度动态计算每条摘要的重要性可审计性检查点文件全量 JSON-LD 事件链存入 L0IRI 精确追溯四、各自的适用场景Claude Code 的上下文管理更适合单人开发、单会话编码任务任务相对线性不需要多 Agent 协同快速迭代、灵活调整对审计要求不高轻量级使用开箱即用流马的上下文管理更适合长周期、多阶段的软件工程项目需求→设计→编码→测试→部署需要多 Agent 协同并行、互相检查的复杂任务企业级合规场景每个决策、每次操作都需要完整审计链知识密集型任务需要持续积累和复用历史经验五、两种哲学没有高下Claude Code 的上下文管理是优秀的工程折中。它用相对简单的文件系统机制解决了单 Agent 编码场景 90% 的上下文问题。它的 Rewind 和 Subagent 设计非常务实易于理解和上手。流马的上下文管理是面向未来的系统工程。它从第一天就把“记忆”当作一等公民用图数据库、JSON-LD、IRI 地址总线、MESI 协议构建了一套“永不丢失、随时可查、多 Agent 共享”的记忆体系。它的代价是实现复杂度更高但带来的收益是 Token 消耗的指数级下降、多 Agent 协同的安全性、以及全链路的可审计性。这就好比Claude Code 是一辆优秀的燃油车——成熟、可靠、开起来顺手。流马是一辆正在建造的电动超跑——很多零件还没装好但它的底层架构决定了它能跑到燃油车去不了的地方。六、最后说句人话如果你只是一个开发者需要 AI 帮你写代码、查 Bug、做代码审查Claude Code 够用而且很好用。如果你在构建一个 AI Agent 平台需要多个 Agent 协作完成复杂工程任务需要审计、需要知识复用、需要上下文管理不丢细节不爆 Token——那你大概会需要流马的这套设计。我这套系统叫Gliding Horse流马所有代码都在 GitHub 上https://github.com/doiito/gliding_horse这是系列的第 13 篇了。从 JSON-LD 到 CPU 缓存从丰田安灯绳到硬核门禁从技能图谱到上下文管理。这些文章不是宣传而是我对自己设计选择的诚实记录。如果你也在思考 AI Agent 的工程化落地希望这个系列能给你一些启发。
【Agent Harness实战】Claude Code vs Gliding Horse（流马）：两种上下文管理哲学的对决
Claude Code vs 流马两种上下文管理哲学的对决之前我拆解了 Claude Code 的 5 种上下文管理策略也介绍了流马Gliding Horse的 6 种策略。但有读者提醒我漏了一个关键点流马的 PA、DA、CA、AA 本身就是 Subagent而且比 Claude Code 的 Subagent 做得更深。今天就把这个拼图补上来一场公平的、深度的上下文管理策略对决。一、Claude Code 的 5 种策略Claude Code 是目前开发者体验最好的 AI 编码助手之一。它的上下文管理策略非常务实策略机制核心价值ContinueToken 预算充足时持续追加对话保证流畅体验Rewind回滚到历史任意检查点重新开始消除错误分支像 Git resetClear完全清空上下文仅保留系统提示词彻底重置适合全新任务Compact将历史对话压缩为结构化摘要文档保留关键信息砍掉冗余Subagent创建子 Agent携带部分上下文独立执行任务父 Agent 只关心结果上下文隔离解决注意力污染这 5 种策略的核心特征是基于文件系统的线性恢复 粗粒度压缩 任务级隔离。它们解决的是“单 Agent 在长对话中如何不丢上下文”的问题。二、流马的 6 种策略 原生 Subagent 体系流马因为从底层就是多 Agent 架构它的上下文管理策略天然就要处理“多个 Agent 共享记忆、协同工作”的场景。策略机制与 Claude Code 的差异Continue正常追加同回溯利用 L2 黑板中的 Named Graph 快照可回滚到任务树上的任意节点状态比 Rewind 粒度更细不是回滚到“某个对话轮次”而是回滚到“某个子任务的某个阶段”重置清空 L1但保留系统骨架和历史 IRIClear 是彻底失忆流马的重置是“暂时放下随时能捡起来”主动摘要 IRI 解引用LLM 每次输出带summary上下文只保留摘要 IRI完整内容和工具大结果存 L0 知识图谱需要时按 IRI 查询这是 Claude Code 没有的能力。Token 从 O(n) 变成 O(1)且不丢任何细节智能压缩score w1*(1/time) w2*(1/semantic_relevance) w3*token_cost基于向量相似度动态淘汰低价值摘要Compact 是一次性粗粒度压缩流马是逐条、动态、语义驱动的细粒度淘汰截断压缩兜底策略极端情况滑动窗口同PA/DA/CA/AA 原生 Subagent每个角色就是一个 Subagent且它们共享 L2 黑板有 MESI 协议保证一致性这是最大的差异点最关键的就是最后一条。Claude Code 的 Subagent 是一个“被父 Agent 派出去干活、干完回来报告”的独立进程。它带一部分上下文出去执行完返回结果父 Agent 完全不关心中间过程。流马的 PA、DA、CA、AA 也是 Subagent但它们不是孤立执行的——它们通过 L2 黑板实时共享状态。DA 执行到一半CA 已经可以在黑板上看到中间产物并提前预警。多个 DA 并行时MESI 协议保证它们对共享数据的修改不会冲突。AA 做决策时已经掌握了所有 Subagent 的完整执行轨迹。这就像Claude Code 是一个老板派了五个员工出去干活每个员工干完回来单独汇报。流马是一个老板派了五个员工但他们都在同一块白板上边干活边交流老板随时能看到全局进度。三、一张表看清两种哲学维度Claude Code流马 (Gliding Horse)架构基础单 Agent 文件系统多 Agent 图数据库 JSON-LD压缩粒度粗粒度整段对话 → 一篇摘要细粒度每条对话独立摘要 IRI记忆可寻址性文件系统级靠文件名定位图原生每个记忆有全局唯一 IRI可 SPARQL 精确查询大工具结果写入上下文或截断存知识图谱仅 IRI 注入上下文Subagent 隔离完全隔离仅返回结果共享 L2 黑板 MESI 一致性实时协同回滚粒度检查点对话轮次Named Graph 快照可恢复到任务树上任意节点压缩智能性LLM 一次性摘要向量相似度动态计算每条摘要的重要性可审计性检查点文件全量 JSON-LD 事件链存入 L0IRI 精确追溯四、各自的适用场景Claude Code 的上下文管理更适合单人开发、单会话编码任务任务相对线性不需要多 Agent 协同快速迭代、灵活调整对审计要求不高轻量级使用开箱即用流马的上下文管理更适合长周期、多阶段的软件工程项目需求→设计→编码→测试→部署需要多 Agent 协同并行、互相检查的复杂任务企业级合规场景每个决策、每次操作都需要完整审计链知识密集型任务需要持续积累和复用历史经验五、两种哲学没有高下Claude Code 的上下文管理是优秀的工程折中。它用相对简单的文件系统机制解决了单 Agent 编码场景 90% 的上下文问题。它的 Rewind 和 Subagent 设计非常务实易于理解和上手。流马的上下文管理是面向未来的系统工程。它从第一天就把“记忆”当作一等公民用图数据库、JSON-LD、IRI 地址总线、MESI 协议构建了一套“永不丢失、随时可查、多 Agent 共享”的记忆体系。它的代价是实现复杂度更高但带来的收益是 Token 消耗的指数级下降、多 Agent 协同的安全性、以及全链路的可审计性。这就好比Claude Code 是一辆优秀的燃油车——成熟、可靠、开起来顺手。流马是一辆正在建造的电动超跑——很多零件还没装好但它的底层架构决定了它能跑到燃油车去不了的地方。六、最后说句人话如果你只是一个开发者需要 AI 帮你写代码、查 Bug、做代码审查Claude Code 够用而且很好用。如果你在构建一个 AI Agent 平台需要多个 Agent 协作完成复杂工程任务需要审计、需要知识复用、需要上下文管理不丢细节不爆 Token——那你大概会需要流马的这套设计。我这套系统叫Gliding Horse流马所有代码都在 GitHub 上https://github.com/doiito/gliding_horse这是系列的第 13 篇了。从 JSON-LD 到 CPU 缓存从丰田安灯绳到硬核门禁从技能图谱到上下文管理。这些文章不是宣传而是我对自己设计选择的诚实记录。如果你也在思考 AI Agent 的工程化落地希望这个系列能给你一些启发。
