你的智能体讨厌遍历知识图谱？那就别让它走了。

现在有一种观点批评知识图谱作为代理的内存不够高效，这是正确的。代理读取页面时，会根据链接标题猜测哪些链接重要，然后读取这些链接，如此往复。一个需要三跳的事实可能需要四次工具调用，每次几秒钟，而其中一半的读取内容都是噪音。图的连接性越强，问题越严重。这些都是事实。我开发了一个Markdown知识图谱工具，对此我完全认同。代理在遍历图方面表现糟糕。通常的结论是放弃图结构：将所有内容扁平化为一堆文件，添加嵌入索引，让语义搜索直接跳转到相关页面。这通过丢弃结构来降低遍历成本。但链接本身是信息：一个决策链接到它影响的组件，一个注意事项链接到它发布的版本。语义搜索能找到与问题相关的页面，但无法处理“并带来那些页面依赖的内容”这种情况。代理找到了决策，却忽略了背后的约束，只能基于片面信息自信地工作。我的解决方案更简单：保留图结构，但不再让代理自己遍历。遍历过程由工具处理。只需一次调用：iwe squash decisions/drop-the-cache-layer -d 2，引擎会深入跟踪链接两层，返回一个整合后的文档，包含页面及其所有依赖内容，内联显示。原本需要五六次串行调用并猜测链接标题的过程，现在只需一次调用，毫秒级完成，无需猜测，因为引擎无需预测链接背后的内容，直接读取即可。而且这是确定性的：相同的存储、相同的查询、相同的结果，我还可以在终端中运行相同命令来查看代理看到的内容。当检索结果有问题时，我调试的是查询，而不是相似性分数。如果你的想法是“直接用grep”，那我们立场基本一致。因为这是文件系统，是纯Markdown，grep仍然适用于所有内容。引擎只在grep无能为力时介入：grep找到匹配的行，但你还需要手动遍历链接来收集依赖内容。squash就是当你厌倦了这种手动操作时会构建的工具。诚实的局限：这里完全没有用到嵌入。词法搜索加上图扩展在处理“关于规范范围的笔记”这类查询时表现出色，但在处理“那件事情，用完全不同方式表述”的查询时则较弱。如果你的记忆是成千上万个没有值得保留结构的松散片段，那么扁平化加语义搜索可能更适合你。声明：这个工具是IWE，一个我维护的开源Markdown知识图谱CLI/LSP（使用Rust编写，MIT许可证，本地优先）。好奇大家的看法：如果你使用图状记忆，你的代理是自己遍历它，还是有其他工具为其组装？如果你采用扁平文件加嵌入，你真的会怀念图结构吗？