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