【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 编码助手之一。它的上下文管理策略非常务实：

策略	机制	核心价值
Continue	Token 预算充足时持续追加对话	保证流畅体验
Rewind	回滚到历史任意检查点，重新开始	消除错误分支，像 Git reset
Clear	完全清空上下文，仅保留系统提示词	彻底重置，适合全新任务
Compact	将历史对话压缩为结构化摘要文档	保留关键信息，砍掉冗余
Subagent	创建子 Agent，携带部分上下文独立执行任务，父 Agent 只关心结果	上下文隔离，解决注意力污染

这 5 种策略的核心特征是：基于文件系统的线性恢复 + 粗粒度压缩 + 任务级隔离。它们解决的是“单 Agent 在长对话中如何不丢上下文”的问题。

二、流马的 6 种策略 + 原生 Subagent 体系

流马因为从底层就是多 Agent 架构，它的上下文管理策略天然就要处理“多个 Agent 共享记忆、协同工作”的场景。

策略	机制	与 Claude Code 的差异
Continue	正常追加	同
回溯	利用 L2 黑板中的 Named Graph 快照，可回滚到任务树上的任意节点状态	比 Rewind 粒度更细：不是回滚到“某个对话轮次”，而是回滚到“某个子任务的某个阶段”
重置	清空 L1，但保留系统骨架和历史 IRI	Clear 是彻底失忆，流马的重置是“暂时放下，随时能捡起来”
主动摘要 + 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 事件链存入 L0，IRI 精确追溯

四、各自的适用场景

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 的工程化落地，希望这个系列能给你一些启发。