刚读完GraphReAct的arXiv preprint，核心思路是把ReAct框架的“推理-行动”循环迁移到图数据上，让LLM在每一步推理中主动选择“读节点”、“查边”或“聚合子图”作为action，再基于新获取的上下文更新推理路径。技术上，他们设计了专门的action空间和状态编码器，将图拓扑与语义表示融合进prompt。坦白说，这个方向我关注已久——之前做知识图谱问答时，我们尝试过用ReAct-style agent去遍历子图，但效果不稳定，主要卡在action的粒度选择上：太细（逐节点遍历）会引发长程依赖崩溃，太粗（整子图检索）又丢失结构信息。GraphReAct的贡献在于给出了一个相对完整的action原语集，并在MULTI-STEP QA benchmark上提升了约12%的F1，这点值得肯定。
不过，我的质疑点在于其泛化性：论文实验集中在分子图和知识图谱上，对于社交网络这类节点语义稀疏、边权重主导的图，这种textual action是否还能有效？另外，多步推理中action的cost如何优化？我在实际部署中发现，每步调用LLM做action决策的延迟和token消耗会指数级增长，GraphReAct并未给出高效的注意力剪枝或缓存策略。
抛两个问题给各位：1）如果图规模达到百万节点级，这种逐层action的框架是否必须结合图神经网络做预剪枝？2）在工业场景中，你认为图推理agent更适合做离线预计算，还是在线实时推理？个人认为，短期看离线场景更可行，长期则需要端侧小模型做action的轻量化。
从行业格局看，GraphReAct标志着LLM+图推理从“纯检索”走向“交互式探索”，但离成熟落地还有一段路。它更像一个工程化的设计模式，而非底层算法突破。想听听大家在图数据上做ReAct的实践经验——特别是action空间设计上的坑。