开源JCR：用Jev树状路由解决agent上下文窗口优化
内容提要
Niaz Morshed 开源了 JCR，利用 Jev 树状路由在六层能力目录中逐层筛选，将 11360 条 API 命令的检索压缩为少量结果。实测显示，Claude Opus 5 的输入 token 减少 85%、成本降低 67%，但 GPT-5.6-Sol 耗时增加 2.5 倍。JCR 仅返回文档而不执行命令，适用于按 token 计费昂贵且可接受延迟的场景。
延伸解读
JCR与RAG的检索逻辑差异
JCR采用树状路由，在六层能力目录中逐层筛选，每次只让Jev模型在当前节点的子目录中做选择题，搜索空间从11360条命令迅速缩小到少量选项。而传统RAG将全部命令向量化，通过相似度匹配返回结果，容易因语义重叠返回多个相似命令，导致上下文窗口被无关信息占据。JCR的逐层路由更精准，但依赖目录结构的合理性。
束搜索的权衡：准确率与成本
JCR使用束搜索在每层保留得分最高的前三条路径，且路径得分不低于最佳路径的60%，以避免因单层打分接近而选错分支。束搜索宽度和带宽比可通过环境变量调整。宽度越大，探索路径越多，准确率越高，但Jev调用次数成倍增加，延迟和成本上升。开发者需在准确率和成本之间找到平衡点。
不同模型下的收益与代价
实测显示，Claude Opus 5在JCR模式下输入token减少85%，成本降低67%，墙钟时间从105.5秒缩短到77.7秒；而GPT-5.6-Sol的token仅减少23%，成本降低16%，墙钟时间却从25.3秒增加到62.4秒，慢了2.5倍。这表明JCR的收益与模型本身的token消耗和阅读习惯强相关，对于按token计费昂贵且可接受延迟的场景更有利。
JCR的适用边界与未解矛盾
JCR仅返回文档，不执行命令，职责单一，适合作为检索层集成到agent中。它通过MCP服务器提供resolve_capabilities命令，方便接入。但benchmark中Opus 5变快而Sol变慢的矛盾尚未解释，作者仅建议重复运行以分离延迟因素，未公布更多数据。因此，在实际采用前需结合自身场景评估延迟影响。
Q&A
JCR是什么？它主要解决什么问题？
JCR（Jev能力解析器）是Niaz Morshed开源的一个工具，它利用Jev树状路由在六层能力目录中逐层筛选，将11360条API命令的检索压缩为少量结果，从而解决agent上下文窗口被冗余文档塞满的问题。
JCR如何通过树状路由减少上下文窗口的token消耗？
JCR将11360条API命令组织成六层目录树，Jev路由模型在每一层只做选择题，逐步缩小搜索空间，最终只将命中的少量命令的context字段返回给agent，避免将全部命令塞入上下文窗口。
JCR在Claude Opus 5和GPT-5.6-Sol上的实测效果如何？
在Claude Opus 5上，JCR将输入token从108585降至15819，减少85%，成本从0.37美元降至0.12美元，降低67%；在GPT-5.6-Sol上，输入token从61952降至47669，减少23%，成本从0.1377美元降至0.1151美元，降低16%。
使用JCR会带来哪些性能上的代价？
JCR可能增加延迟，例如GPT-5.6-Sol在JCR模式下的平均墙钟时间从25.3秒增加到62.4秒，慢了约2.5倍，因为JCR需要调用Jev路由模型和OpenAI进行拆分和搜索，网络延迟叠加。
JCR与传统的RAG向量搜索有什么区别？
传统RAG将全部命令向量化，通过相似度匹配可能返回多个语义重叠的结果，导致上下文窗口被垃圾信息塞满；JCR则通过树状路由逐层筛选，每次只在当前节点的子目录中选择，搜索空间从11360缩小到少量选项，只返回精确命中的命令。
如何在自己的agent中集成JCR？
可以启动JCR内置的MCP服务器，它封装成了标准的stdio MCP服务，任何支持MCP协议的agent框架都可以调用resolve_capabilities命令。启动命令为：CAPABILITIES_DIRECTORY="$PWD/capabilities" node --env-file=.env --import tsx src/jcr/server.ts。
