Scaling Graph Chain-of-Thought Reasoning: A Multi-Agent Framework with Efficient LLM Serving #

Chengying Huan, Ziheng Meng, Yongchao Liu, Zhengyi Yang, Shipeng Li, Xiabao Wu, Haitao Zhang, Yue Yun, Yun Zhu, Shaonan Ma, Rong Gu, Chuntao Hong, Guihai Chen, Chen Tian (Nanjing University, Ant Group, UNSW, SAIL, Tsinghua) | 2025-11 | https://arxiv.org/abs/2511.01633 Category: framework | Tags: agent, graph-cot, kv-cache, multi-agent, serving, prefix-caching Read: 2026-04-18 Venue: PVLDB 2026 (to appear)

Core Contribution #

GLM 是第一个把 Graph-CoT (LLM 在知识图谱上逐步推理) 的 reasoning 架构 和 LLM serving 架构 co-design 的系统：在上层用 C/R/A 三个专门化 agent + Graph-RAG retriever 取代"单 agent monolithic prompt"，在下层用 vertex-centric KV-cache reuse + 四级优先级驱逐 + retrieval/decoding pipelined execution，同时把 Graph-CoT 的 token 成本降 95.7%、延迟降 90.3%、吞吐升 15.1×，而准确率 R-L 提升 38%。

Summary #

背景与痛点：Graph-CoT（Jin et al., ACL 2024）让 LLM 在知识图谱上"查节点→取邻居→累积证据→再推理"的迭代闭环里解答多跳问题，但现有实现把所有功能（判断是否该停、生成下一步动作、总结当前已知）塞进一个 agent 的 monolithic prompt。其后果双重：(1) accuracy-cost 剪刀差：每轮都把完整上下文 + 中间痕迹重新喂回去，一个 query 40k+ tokens，GPT-4.5 单次 \$1.9–\$3.6，但 R-L 只有 0.31–0.46，远低于业界 0.50 的"可靠推理"门槛，并随着步数从 3 涨到 9，GPTScore 反从 0.42 跌到 0.17（lost-in-the-middle）；(2) serving 失效：每步 prompt 都是"不同的 prefix + 飘动的中间状态"，vLLM 标配的 prefix caching 命中率只有 61%，LRU 会把马上要复用的图事实驱逐掉，而图检索（向量相似度搜索）又占了 23% 端到端时间却完全序列化。

方法：GLM 从两个层面 co-design。上层多 agent 框架把单 agent 拆成 C-Agent（判定 deterministic vs. non-deterministic）、R-Agent（基于 notebook 累积的事实判断是否已经能答，否则给出"缺什么"）、A-Agent（把"缺什么"翻译成一段可 exec 的 Python 代码段，调用 Graph-RAG 原语）和 Graph-RAG Retriever（执行代码、返回 vertex chunk）。Determinstic 分支 1 次分类 + 1 次代码生成 + 1 次检索直接结束；non-deterministic 进入 R/A 轮换，每轮 notebook 只累积新事实而不是整段推理。A-Agent 生成的是"多 RetrieveNode/NodeFeature 调用 + if/for/set/dict + 单 print()"的完整 snippet，把原本 k1 轮 LLM call 压缩到 k2+1 轮。下层 Graph-CoT-aware inference含三件事：(1) vertex chunk 作为 KV cache 的复用单元——把 [Node{attrs}][neighbours(top-k by weight){attrs}] 作为一个 coarse chunk，让不同 query/不同 agent 只要碰到同一个节点就能命中已算好的 KV；(2) 四级优先级驱逐：P-I = 三个 agent 的共享 prompt prefix（永不驱逐）、P-II = 当前会话的 notebook（会话内复用）、P-III = 已完成会话的 notebook（跨 query 可复用）、P-IV = 临时的 missing-info / 原始 question（最先驱逐），每级内部仍用 LRU；(3) pipelined execution：A-Agent 生成的代码第一行几乎总是 RetrieveNode()（向量检索，最贵的一步），系统 streaming 地读 A-Agent 输出，一旦检测到这行就立刻触发检索，让它与后续 token 的 decode 并行，同时用 LRU global cache 把 RetrieveNode(text)→nodeID 映射缓存起来消除重复调用。

结果：GRBench 1040 个问题 × 5 个领域（academia/e-commerce/literature/healthcare/legal）上，相对 Graph-CoT baseline：R-L 0.31–0.46 → 0.55–0.77（up to +38%）；单 query token 22,613–45,490 → 1,538–2,974（↓95.7%，其中 LLM call 数 9–14 → 2–3，每 call token 1,875–4,483 → 769–991）；延迟 11.3–38.6s → 2.8–5.9s（↓74.7–90.3%）；吞吐 0.6–2.2 QPS → 6.8–9.1 QPS（up to 15.1×）。消融：pipelined execution 单独把延迟降 47.8%，vertex-centric reuse 单独把吞吐升 41.6% 且 hit rate +17.7%，priority eviction 再贡献吞吐 +14.3%、miss rate −15.1%。

Key Findings #

• "多 agent 拆解"比"更长的 CoT 链"更能抬 accuracy：把 classify/reason/act 拆开后，每个 agent 的上下文变短变专，不再触发 lost-in-the-middle；加上 code-generation 把"多轮小动作"压成"一轮代码段"，step-limit-exceeded 错误从 37% 掉到 4%、unexpected-agent-output 从 41% 掉到 2%。
• 单纯引入 code-generation 会让错误"搬家"：step-limit 错误从 37%→8% 的代价是 code-execution 错误从 2%→21%，需要 GLM 的 fault-tolerance（捕获 exception → 回喂 LLM 自纠）才收敛。
• Graph-CoT 的 KV cache 复用不是 prefix 匹配问题，而是"检索单元"问题：单个 fact 太碎、排序又不稳定，即使两个 query 内容相似也难命中 prefix；把复用单位从 "fact" 抬升到 "vertex chunk（node + top-k neighbours）"直接把 hit rate 抬 17.7%。
• LRU 在 Graph-CoT 场景是"反向信号"：最近生成的 A-Agent 中间代码片段最不可能复用，但 LRU 恰好会优先保留它们；基于任务语义打优先级（共享 prompt > notebook > 历史 notebook > 临时 missing-info）比单队列 LRU 吞吐高 14.3%。
• retrieval 与 decoding 有天然可 overlap 的结构：RetrieveNode 几乎一定出现在 A-Agent 代码段第一行，系统一旦流式检测到它就触发检索，让检索和后续 decode 并行，把 retrieval 在端到端里的占比从 23% 压到 ~1–9%。
• 准确率最大的增益来自"信息聚合型多跳"而非"单事实查询"：GLM 在 E-commerce 推荐类（R-L 0.39→0.77）、Healthcare 多跳诊断类（0.33→0.62）的提升远大于 Legal 等以单事实 lookup 为主的领域（0.46→0.63）。

Key Figures #

Figure 1: Graph-CoT 框架全景 #

What it shows: baseline Graph-CoT 的"LLM ↔ Graph 迭代闭环"——query 进入 LLM、LLM 发出 RetrieveNode/NodeFeature/... 这样的图调用、从外部图取回节点/属性/邻居/度、再把结果塞回 prompt 继续推理直到 finish。

Why it matters: 这是整个论文攻击的靶子；GLM 第 4 节把闭环里的"reasoning + action + classification"这一团拆开，第 5 节则把"每步 prompt → 全量 KV 重算 + 检索串行"这一瓶颈拆掉。

Detailed description: 左侧是用户 question，进入中央 LLM block；LLM 向右边的 Graph 节点集合发出原语调用（RetrieveNode 做文本→nodeID 的向量检索，其余走 in-memory dict），Graph 返回 node/feature/neighbour/degree，LLM 把返回值拼进上下文进入下一轮。箭头强调"iterative"：没有 Classification 旁路，没有 Action 与 Reasoning 的分离，所有判断压在一个 prompt 里。

Figure 3: GLM 多 agent 推理框架工作流 #

What it shows: GLM 的 4 个组件的调用拓扑——C-Agent 先做 yes/no 路由，deterministic 直通 A-Agent→Retriever 一次出答，non-deterministic 进入 R-Agent↔A-Agent 的 notebook 循环，Retriever 把结果填进 notebook 后 R-Agent 判断是否 finish。

Why it matters: 这是论文的"灵魂图"——把原来一张大 prompt 分解成三类 agent 的 DAG，每个 agent 的 prompt prefix 可以被永久缓存（Priority I），每个 agent 的输出只承担一件事（classify / reason / code-gen），从根源上把 token 成本和 accuracy 同时改善。

Detailed description: 左上 user question 进入 C-Agent（分类判断），输出 deterministic 经下方路径直接到 A-Agent（代码生成）→ Retriever → answer；输出 non-deterministic 进入右侧 R-Agent 与 notebook 的闭环，R-Agent 产出"missing info"喂给 A-Agent，A-Agent 生成 Python 代码段由 Retriever 执行、结果以 vertex chunk 形式进 notebook，R-Agent 下一轮读取扩增后的 notebook；直到 R-Agent 输出 finish。

Figure 4: 单 agent Graph-CoT vs. GLM 多 agent 的 prompt/上下文对比 #

What it shows: 左边 Graph-CoT 的 single agent 每轮都把 (shared prefix + 完整 question + 完整历史 notebook + 完整历史 action trace) 重新灌给 LLM；右边 GLM 三个 agent 各自有 short、任务专属的 prompt（C-Agent 只看 question；R-Agent 只看 notebook+question；A-Agent 只看 missing-info），shared prefix 显著短。

Why it matters: 这张图直接支撑 §4.2 的 cost model $2k_1 T_G$ vs. $(k_2+1) T_G$，也是四级优先级驱逐的依据——只有这种"prefix 稳定、suffix 短"的结构才能让 P-I 永驻、P-IV 快丢。

Detailed description: 上半 Graph-CoT 部分用三个叠加的长方条代表三轮迭代，每条都含重复的 shared prefix（灰色）+ 问题（绿）+ 过往所有中间推理（橙），条越堆越长；下半 GLM 分三列分别画 C/R/A agent，每列顶部是短 prefix，中部是 agent-specific 输入（问题 / notebook / missing-info），尺寸小于单 agent 的一个轮次。论文用这张图来定性论证 token cost 从 $2k_1 T_G$ 压到 $(k_2+1)T_G$。

Figure 7: Vertex-centric KV cache reuse model #

What it shows: 两个 query 都检索到相同的 vertex chunk（"Node n1 + 1-hop 邻居 (n2, n3, …, top-k by weight)"），该 chunk 第一次被 R-Agent 处理时其 KV 被算好并打上"vertex chunk 1"标签，后续同一 query 下一轮、以及完全独立的第二个 query，当 retriever 返回同一 chunk 时不再重算 prefill，而是直接复用这段 KV。

Why it matters: 这是把"fact 级"的琐碎 prefix 命中升级到"chunk 级"持续命中的关键——解释了为什么 vertex-centric 单独就能把 hit rate +17.7%、吞吐 +41.6%。

Detailed description: 图分上下两行。上行是 Query A 的两次 R-Agent 迭代，第一次算出 vertex chunk 1 的 KV（绿色新增），第二次该 chunk 因 notebook 复用被整块命中（蓝色复用），只有 notebook 新增的部分 incremental 计算。下行是独立 Query B 的一次 R-Agent 调用，它恰好也取回 vertex chunk 1——GLM 用同一个缓存的 KV 直接复用，无需再跑 prefill，这正是 "coarse-grained reuse unit" 设计的收益。

Figure 8: Priority-based KV cache scheduling 实例 #

What it shows: 两个并发 query Q1、Q2 在六步内的 cache 状态：gray=shared prefix（P-I 永驻）、green=新加入、blue=仍然有效、red=被驱逐。C→R→A 每次 agent 切换时会驱逐上一个 agent 的 suffix（P-IV），但 notebook 内容（P-II）在同 query 内持续保留，Q2 完成后它的 notebook 降级到 P-III 仍然可被 Q1 接下来的步骤复用。

Why it matters: 把抽象的"四级优先级 + 级内 LRU"落成可视的 6 步时间线，清楚展示 vLLM 朴素 LRU 会把 info1（马上要复用的 notebook 事实）误驱逐、而 GLM 能保住它。

Detailed description: 横轴是时间步 (1)–(6)，每步展示当前缓存中驻留哪些 block：步 (1) 两个 query 都进 C-Agent，shared prefix (gray) + Q1/Q2 (P-IV)；步 (2) 进 R-Agent，Q1/Q2 作为 P-IV 被驱逐，insert 新的 R-Agent prefix；步 (3) 进 A-Agent，R-Agent 的 suffix 被驱逐；步 (4) Retriever 产出 info1、info2 进 notebook（P-II），Q2 session 结束 info2 降为 P-III；步 (5) 只为 Q1 再请求一次 A-Agent 拿 info3，info1 仍然保留在 P-II；步 (6) R-Agent 汇总 notebook（含 info1+info3）给出 Q1 的 finish，info1 直接命中缓存。

Figure 9: Pipelined execution strategy #

What it shows: A-Agent 的一次推理被拆成"前段 = prefill + 解码到 RetrieveNode 行末"（绿+黄）和"后段 = 剩余 decode"（黄延伸），检索进程（粉色）在前段结束的一刻被触发，与后段 decode 并行；虚线表明后段的最后几 token 和 retrieval 的完成点对齐。

Why it matters: 单独把端到端延迟再砍 47.8%（§6.7），因为 RetrieveNode 基本恒为代码段首行，是"可预测的依赖点"，pipelining 不是投机而是确定性 overlap。

Detailed description: 水平时间轴从左至右。最上面是 LLM inference 进度：绿色块代表 prefill，紧跟一段黄色块代表"解码完包含 RetrieveNode() 的那一行"；这条检测信号一产生，下方一行就出现粉色的 Retriever 执行块，它与继续延伸的黄色 decode 块在时间上并行；最右端两条几乎同时结束，拼出"retrieval 被隐藏进 decode"的可视图。附带的 LRU 全局缓存（text→nodeID）进一步让粉条在重复 query 下直接归零。

Figure 11: 端到端延迟按领域拆分 #

What it shows: 五个领域下 Graph-CoT vs GLM 的 end-to-end 延迟柱状图，其中每个柱子进一步拆成 "retrieval time" 与 "LLM inference time"。

Why it matters: 揭示 Graph-CoT 中 retrieval 占 0.2–23.1%（非主导但非小），而 GLM 中 retrieval 被 pipeline 挤到 1.2–9.3% 并且绝对值从 5.5s 级压到 0.6s 级，是 §5.3 pipeline 策略的正面证据。

Detailed description: 横轴是 5 个 GRBench 领域（Academic / E-commerce / Literature / Healthcare / Legal），每个领域两根柱子（Graph-CoT / GLM）；每根柱子用两段色表示 LLM inference 与 retrieval，GLM 的柱子整体矮到 2.8–5.9s，且 retrieval 段几乎隐没；Graph-CoT 在 Healthcare 上冲到 38.6s，是 GLM 的 ~10×。

Figure 15: 三大优化的消融 #

What it shows: 五个子图分别呈现 (a) pipeline 带来的延迟降低、(b)(c) vertex-centric reuse 对 throughput 与 cache hit rate 的影响、(d)(e) priority eviction 对 throughput 与 hit rate 的影响。

Why it matters: 说明三项优化彼此正交贡献——pipeline 专治延迟，vertex-centric 专治 hit-rate，priority eviction 补上高并发下的内存管理缺口，组合起来才吃到 15.1× 吞吐的上限。

Detailed description: (a) 柱状 pipeline vs. non-pipeline 延迟对比，pipeline 降 47.8%；(b)(c) 开/关 vertex-centric 下的 throughput bar / hit rate bar，throughput +41.6%、hit rate +17.7%；(d)(e) 四级优先级 vs. 单队列 LRU 的 throughput bar / miss rate bar，throughput +14.3%、miss rate −15.1%。

Key Tables #

Table 1: Graph-CoT vs. GLM 端到端对比（Cost \$ / R-L / Latency） #

Domain	GC Cost($)	GC R-L	GC Lat(s)	GLM Cost($)	GLM R-L	GLM Lat(s)
Academic	1.9	0.31	27.2	0.1	0.55	3.0
E-commerce	1.9	0.39	17.8	0.1	0.77	3.1
Literature	1.7	0.42	11.3	0.1	0.65	2.8
Healthcare	3.6	0.33	38.6	0.2	0.62	3.4
Legal	2.8	0.46	22.8	0.2	0.63	5.9

Takeaway: 成本从 \$1.7–\$3.6 → \$0.1–\$0.2（~20×）；R-L 全部从 <0.50 跨过 0.50 阈值；延迟从 11.3–38.6s → 2.8–5.9s，全部进入"交互式"区间。

Table 4: 与四类 baseline 的精度对比（R-L / GPTScore） #

Method	Acad R-L	Acad GS	Ecom R-L	Ecom GS	Lit R-L	Lit GS	Heal R-L	Heal GS	Legal R-L	Legal GS
Base	0.09	0.15	0.14	0.20	0.11	0.23	0.06	0.20	0.16	0.26
Text RAG	0.09	0.14	0.25	0.31	0.15	0.28	0.04	0.20	0.21	0.26
Graph RAG	0.28	0.33	0.34	0.37	0.21	0.32	0.11	0.16	0.21	0.24
Graph-CoT	0.31	0.40	0.39	0.44	0.42	0.53	0.33	0.46	0.46	0.53
GLM	0.55	0.55	0.77	0.79	0.65	0.68	0.62	0.70	0.63	0.64

Takeaway: GLM 在全部 5 领域 × 2 指标上是 SOTA；提升最大的是 E-commerce R-L（0.39→0.77）与 Healthcare R-L（0.33→0.62），两者都是典型"多节点信息聚合"任务。

Table 5: 错误类型分布演进 #

Error category	Graph-CoT	Graph-CoT + code-gen	GLM
Unexpected agent output	42 (41%)	49 (51%)	2 (4%)
Retrieval error	20 (19%)	20 (21%)	18 (43%)
Code execution error	2 (2%)	20 (21%)	20 (48%)
Step limit exceeded	38 (37%)	8 (8%)	2 (4%)

Takeaway: 多 agent + code-gen 把 "unexpected output" 和 "step limit" 几乎压平，但把"code execution error"变成主要失败模式——这是论文讲 fault tolerance（捕获 exception → 回喂 LLM 自纠）的原因。

Limitations #

• Accuracy 仍受 backbone 限制：整个 R-L 的天花板由 Qwen3-235B-A22B 决定，论文自认未来需要 distillation/LoRA/结构化 prompt 来解耦。
• Retrieval 仍是剩余瓶颈：大图（Legal, 84M 节点 / 114M 边）上 retrieval 溢出 decode 窗口，pipelining 的收益会衰减。
• Code execution error 成为新主导错误：占比 48%，论文靠 timeout + 自纠 mitigate，但没有系统化的 "code self-verification"。
• 仅在 Qwen3 + vLLM v0.8.5 上验证：priority eviction 与 pipelined streaming 依赖 vLLM 内部 API，迁移到 SGLang/TRT-LLM 需要额外适配。
• Classification 的 deterministic 判定是分布依赖的：训练/提示里若未覆盖的 query 类型会触发误分类，论文未量化 C-Agent 的 FP/FN。
• vertex chunk 的 top-k 邻居裁剪有信息损失风险：在稀疏/多属性节点上 top-k（按 degree 排）可能丢掉与 query 相关但度数不高的邻居。

Infrastructure Impact #

• Algorithm: 为 "结构化 RAG + 多 agent planning" 提供了一个可复用的 classify/reason/act 分解范式；可移植到 KGQA、结构化信息抽取、任务规划。
• Kernel: 不引入新 kernel。对现有 attention/GEMM 没有变动，全部杠杆来自 scheduler 与 cache 管理。
• Framework: 主要落点。给 LLM serving 新增"语义优先级 KV eviction"这一维（取代纯 LRU），以及"把结构化 retrieval 的 hit-point 变成可预测 pipeline 信号"的模式，对 vLLM/SGLang 的 prefix-caching 策略构成直接启示。
• LLM: 对模型无架构修改；对 MoE/GQA 模型中立；长上下文的"lost-in-the-middle" 被 agent 拆解规避，给模型侧留出"不一定非要拉长 context"的空间。
• Agent: 把多 agent 协作从 prompt 工程层面推进到"serving-aware 多 agent"——agent 边界恰是 KV 优先级边界。
• Cluster/Code: 3K 行 Python，基于 vLLM v0.8.5，8×A800 SXM4；其思路可作为 vLLM/SGLang "multi-agent pipeline" 功能的参考 RFC。

---

Deep Analysis (framework) #

0. Review of Phase 2 Quality #

Phase 2 约束推导部分此处再补深：(i) 为什么不能"更大 context window"？—— 论文 Fig.2 直接证伪，9 步时 GPTScore 0.17，lost-in-the-middle 是 LLM 的行为事实而非窗口大小能解决；(ii) 为什么不能仅靠"更好 prefix caching"？—— 单 agent 设计下每步 suffix 都动，prefix 稳定区段短，再好的 hit 也达不到 3× 吞吐；(iii) 为什么不能仅靠"把 graph 变成长 text"？—— §6 Text RAG/Graph RAG 在 Healthcare 上 R-L 仅 0.04–0.11，多跳推理需要 agent 主动发起检索。这三条"为何不可"构成了 GLM 必须 co-design 两层的闭环推导。

1. System Scope #

• 主目标: 对 Graph-CoT 类 agentic RAG 工作负载做 online serving（latency-sensitive）同时保持高 throughput。
• 部署规模: 原型 8×A800 SXM4 单节点 NVLink，vLLM 后端可扩 multi-GPU；未报告跨节点。
• 工作负载: GRBench，1040 QA × 5 领域，图规模 47K–84M 节点、4M–313M 边；query 类型 deterministic（单节点事实）+ non-deterministic（多跳聚合）。
• 适用边界: 当图检索结果可抽象为 "vertex-centric chunk" 时收益最大；pure-text RAG / tool-calling agent / 非结构化 web 检索不直接适用。

2. Architecture & Data Flow #

2a. End-to-End Data Flow #

[NL Query q]
   → [Classify (C-Agent)]        ──(deterministic?)──► yes ──► [A-Agent code-gen] ──► [Retriever.exec()] ──► answer
                                                      no
                                                       ▼
   → [R-Agent (read notebook,q)] ──(finish?)──► yes ──► answer
                                 ──(need more?)─► no
                                                       ▼
                                         [A-Agent code-gen from missing-info]
                                                       ▼
                               ┌─ detect RetrieveNode line (streaming) ─ trigger Retriever concurrently
                                                       ▼
                              [Retriever.exec() → vertex chunk]
                                                       ▼
                              [append chunk to notebook] ──► back to R-Agent

Stage	Input → Output	Location	Latency	Data format & size
C-Agent prefill+decode	q → {deterministic, non-deterministic}	GPU	small (数十 tokens)	short prompt
R-Agent prefill+decode	(notebook, q) → {finish / missing-info}	GPU	dominant decode (≈42% of LLM time)	up to a few k tokens
A-Agent prefill+decode	missing-info → Python snippet	GPU	≈54% of LLM time	code string
RetrieveNode (vector search)	text → nodeID	GPU (FAISS)	0.1–0.6s/round in GLM	embedding query
NodeInfo/NodeFeature/neighbourCheck	nodeID(s) → vertex chunk	CPU in-memory dict	<< 1 ms	vertex chunk string
notebook append	vertex chunk → notebook	CPU	~0	tokens

2b. Data Movement Hotspots #

1. 每轮 R-Agent prefill 读 notebook——这是单 query 内最重的 KV 生成点；vertex-centric reuse 直接命中 P-II，使其主要只做 incremental KV。
2. RetrieveNode 的 embedding 搜索——GPU FAISS 访存密集，单次 0.1–5s；pipelined execution + text→nodeID LRU cache 把它隐藏或消除。
3. 高并发下的 KV eviction 抖动——vLLM LRU 在 concurrent queries 下把马上要复用的 notebook 块驱逐，priority eviction 把它锁在 P-II 里。

3. Design Space & Constraint Analysis #

3a. Alternative Approaches #

Alt	Approach	可行？	理由
A1	更长 context + 更深 CoT	✗	lost-in-the-middle（Fig.2）；token 线性暴涨但准确率下降
A2	单 agent + 更好 prompt engineering	✗	改不动 "prompt 越长越抖" 的模型行为；仍保留重复 prefix 开销
A3	单 agent + vLLM 默认 prefix caching	✗	每步 suffix 变化，稳定 prefix 段短，hit rate ≤61%
A4	Graph → 线性化文本 + 长 context RAG	✗	Text/Graph RAG 在 Healthcare R-L 0.04/0.11，结构化多跳无法靠 retrieval 一次性拉全
A5	Few-shot tool-calling agent（无 cache 优化）	✗	ReAct 式多轮仍然 per-step 重算 KV，与 Graph-CoT 的 serving 问题同源
A6	Multi-agent 但 serving 不改	✗	token 降但吞吐升不上去——三个 agent 的 prefix 都是固定前缀，正好是 prefix caching 的大红利，不改 cache 就浪费
A7 (GLM)	Multi-agent + Graph-CoT-aware KV/pipeline co-design	✓	上层减 token/步数，下层收获稳定 prefix + 可预测 retrieval 调度

3b. Constraint Derivation #

• 为何不可只做"更长 context"？ lost-in-the-middle 是模型级行为，实测 step 从 3→9 GPTScore 0.42→0.17，这是 context 利用率衰减，无法用窗口大小补救。
• 为何不可只做"更好 LRU"？ LRU 由"最近访问"决定，但 Graph-CoT 场景下最新访问的 A-Agent 代码段恰好是最不重要的（one-shot），语义信号与时间信号反向，任何基于时间的策略都次优，必须引入 语义优先级（P-I/II/III/IV）。
• 为何不可只做"更好 retriever"？ retriever 占比 0.2–23%，就算砍一半也只省 10%；主导是 LLM inference 的 k1 轮重复 prefill，必须在 agent 层压缩 k1 → k2+1。
• 为何不可仅靠 multi-agent 而不改 serving？ 三个 agent 的 prefix 可缓存性是 co-design 的关键杠杆；若 serving 层不感知这种结构，多 agent 增加的调度开销可能抵消上层收益。

3c. Assumption Audit #

• A1: "RetrieveNode() 几乎总是 A-Agent 代码段首行" —— 论文观察性陈述，未做分布统计；若 LLM 生成的代码把条件判断放前面，pipeline 触发点会后移，overlap 收益下降。笔者不完全确定该假设在更大 backbone / 更自由 coding style 下的稳定性。
• A2: "C-Agent 二分类可靠" —— 论文未报告 C-Agent 的 FP/FN；若 deterministic 误分为 non-deterministic，回退到 R-Agent 循环不会出错但会损失性能；反向错误会直接降准确率。
• A3: "vertex chunk 在多 query 间有足够重叠" —— 依赖图访问有幂律性（热门节点被反复查）。在长尾查询多的图上（如 Legal 大图），chunk 复用率可能显著下降，Fig.11 Legal 域 GLM 还剩 5.9s 延迟也佐证这点。
• A4: "notebook 只追加不压缩" —— 论文假设 notebook 可以一直增长；极长多跳下 P-II 段会膨胀，P-II 自身需要 LRU 裁剪策略，当前文未充分讨论。

3d. Core Technical Barrier #

核心壁垒: 不是 "四级优先级" 本身（概念简单），而是 把 agent 语义边界精确映射到 KV-cache block 边界 的工程实现。具体地：需要让 vLLM paged attention 的 block 分配器感知"当前这段 token 属于哪个 agent 的哪一级优先级"，在 block allocate/free/evict 三个点上都挂上 priority tag；这要求改 vLLM 的 scheduler 与 block manager 两层（论文点名"modifications to vLLM v0.8.5"），但没公开这份 patch——这是复现最难的部分。配合 pipelined execution 需要让 A-Agent 的输出 流式地暴露给 scheduler 以触发异步 retrieval，这条 streaming hook 也是 vLLM 非标准 API。

3e. Design Binding Critique #

• 绑定 vLLM：priority eviction 与 streaming hook 深度耦合 vLLM v0.8.5；迁移到 SGLang 的 RadixAttention 前缀树需要重写（SGLang 已有 cache-aware scheduling 但粒度不同）。
• 绑定 Graph-RAG 接口：C/R/A agent 的 prompt 都假定能调用 {RetrieveNode, NodeInfo, NodeFeature, NodeDegree, neighbourCheck} 这套原语；换 graph store（如 Neo4j/TigerGraph）需要重写 Python snippet 的 API 层。
• 绑定 Qwen3-235B-A22B 等大模型：code-gen 对模型容量敏感；小模型生成的 Python snippet runtime-error 率会抬高，Fault-tolerance 回路可能指数级放大延迟。
• 绑定 "图结构可抽为 vertex chunk"：多关系类型、超图、hyperedge-heavy 图上，chunk 定义模糊。

4. Key Innovations #

Innovation	Mechanism	Benefit	Cost/Tradeoff
Multi-Agent 分解 (C/R/A)	三个专门 prompt 各自短、prefix 稳定	token -95.7%, R-L +38%	+1 个 C-Agent 调用的固定开销；在 deterministic 分支上是净赚
Code-generation Action	A-Agent 产出可 exec 的 Python snippet	把 k1 轮压到 k2+1	code execution error 2%→21%（需 fault tolerance）
Vertex chunk 作为检索单元	node + top-k neighbour 的结构化串	prefix 稳定、hit rate +17.7%	top-k 裁剪有信息损失
四级优先级 KV eviction	P-I/II/III/IV + 级内 LRU	throughput +14.3%, miss -15.1%	改 vLLM scheduler 多队列；复杂度上升
Pipelined retrieval	流式检测 RetrieveNode 行并触发	latency -47.8%	依赖 RetrieveNode 第一行假设；需要 streaming API
RetrieveNode LRU 缓存	text→nodeID 全局 LRU	消除重复检索	旧 embedding 失效需 invalidate 策略

5. Scheduling & Resource Management #

• Batch 形成: vLLM continuous batching，GLM 在其之上对 prefix 打 priority tag；多 query 的线程池共享 agent/retriever 实例。
• Memory 管理: paged attention + GLM 自定义四级优先级；P-I 锁住共享 prefix，P-II 保 notebook，P-III 跨 query 的旧 notebook 做软缓存，P-IV 最先驱逐。
• GPU 利用率: pipelined execution 让 decode 与 FAISS retrieval 并行；Fault tolerance 里"从 last successful step 用缓存 KV 恢复"降低重算率。
• Multi-tenancy: 未明确隔离保证；按线程共享 model weights，query 级别并行。
• Priority/SLO: KV 层有优先级但请求层无 SLO-aware 调度（未体现 TTFT/TPOT 约束下的抢占）。

6. Target Scenarios & Workload Characterization #

Scenario	Workload Pattern	SLO / Goal	Why existing systems fail
图谱问答 (KGQA)	多跳聚合、中频并发	E2E < 5s, cost < \$0.5/query	Graph-CoT 单 agent token 爆炸
结构化推荐 (E-commerce)	短 query、要节点间共现	TTFT < 500ms, throughput ≥ 5 QPS	vLLM LRU + 单 agent prefix 不稳
医疗多跳推理	长推理链、低并发高准确	R-L > 0.5	lost-in-the-middle 主宰精度

主瓶颈：GLM 解决了 "LLM inference 主导的端到端延迟" 与 "concurrent queries 下 KV eviction 抖动"；剩余瓶颈在大图上回到 retrieval-bound（Legal 域）。

7. Performance Evaluation & Before-After #

7a. Metrics #

Metric	Definition	Unit	Dir
R-L (ROUGE-L)	n-gram overlap w/ gold	[0,1]	↑
GPTScore	GPT-4 judge correctness rate	[0,1]	↑
Cost	$/query on GPT-4.5 pricing	$	↓
Latency	e2e wall time	s	↓
Throughput	QA pairs / s	QPS	↑
Cache hit rate	reused KV / total prefill tokens	%	↑

7b. Before-After #

Optimization	Metric	Baseline	After	Improv	Conditions
Multi-agent + code-gen	Cost / query	\$1.7–\$3.6	\$0.1–\$0.2	~20×	Qwen3-235B-A22B, GRBench
Multi-agent + code-gen	R-L (avg across 5 domain)	0.31–0.46	0.55–0.77	+38% abs on worst	same
Multi-agent + code-gen	LLM calls / query	9–14	2–3	~4–5× fewer	same
Pipelined execution	e2e latency	4.3–10.2 s	2.8–5.3 s	↓47.8%	with vertex-centric already on
Vertex-centric reuse	throughput	baseline	+41.6%	+41.6%	non-deterministic heavy workload
Vertex-centric reuse	hit rate	baseline	+17.7%	+17.7%	same
Priority eviction	throughput	baseline	+14.3%	+14.3%	high concurrency
Priority eviction	miss rate	baseline	−15.1%	−15.1%	same
All combined	throughput	0.6–2.2 QPS	6.8–9.1 QPS	3.2–15.1×	end-to-end

7c. Bottleneck Shift #

Start: lost-in-the-middle + token cost (algorithm-bound)
  → + multi-agent: 转到 scheduling/serving-bound
  → + vertex-centric reuse: 转到 decode-bound
  → + priority eviction: 转到 retrieval tail-bound
  → + pipelined execution: 转到 backbone LLM capacity-bound (论文自承的"accuracy ceiling")

7d. Baselines & Fairness #

• Baselines: Base LLM / Text RAG / Graph RAG / Graph-CoT 都用同 Qwen3-235B-A22B 同硬件（8×A800）；workload 相同 GRBench。
• 可能的不公平：GLM 加入了 "vertex chunk" 这一检索单元改动，其实是同时改了 retriever 和 serving，baseline Graph-CoT 未享受 chunk 化 retriever。严格消融应给 Graph-CoT 也配 vertex chunk 后再比，论文 Fig.15 部分做了但非主表。
• 本质 GLM 赢在何处: 上层 token / 步数削减 × 下层 serving 优化的叠乘，单一改动不够。

8. API & Usability #

• 无官方开源链接被提供；~3K Python + vLLM fork。
• 模型格式: HuggingFace + vLLM 支持的权重。
• 部署: 目前单节点 8×A800；线程池并发。
• 配置: agent prompt 模板可自定义目录替换，priority 级别代码内硬编码。

9. Infrastructure Impact #

Layer	Impact
Algorithm	为 graph-native 多 agent 推理提供新 recipe；可作为 GRPO 等 agentic-RL 的环境模板
Kernel	无直接影响
LLM	无模型改动；长上下文训练的压力被 agent 分解减轻
Agent	把 "serving-aware agent boundaries" 的概念正式化——agent 边界即 cache priority 边界
Ops	需额外监控 priority queue 深度、RetrieveNode cache hit、code-exec 错误率

10. Comparison Matrix #

Feature	GLM	vLLM v0.8.5	SGLang	TRT-LLM	DeepSpeed-MII
Continuous batching	✅ (via vLLM)	✅	✅	✅	✅
Paged attention	✅ (via vLLM)	✅	✅	✅	partial
Prefix caching	✅ (priority-aware)	✅ (LRU)	✅ (RadixAttention)	✅	✅
Multi-agent scheduler	✅ native	✗	partial (sglang.function)	✗	✗
Retrieval-aware pipelining	✅	✗	✗	✗	✗
Semantic priority eviction	✅	✗ (pure LRU)	partial	✗	✗
Code-exec agent fault tolerance	✅	N/A	N/A	N/A	N/A

11. Adoption, Maturity & Ecosystem Influence #

• 阶段: 研究原型（PVLDB 2026 to-appear），无开源地址公开；工业后盾为 Ant Group。
• 复现难度: vLLM fork + 3K Python；但 priority eviction 与 streaming hook 是 vLLM 非标准 API，需要移植。
• 下游: 预计对 SGLang / vLLM 的 prefix caching 策略和 "multi-agent pipeline" 构成直接启示。其"vertex chunk as cache unit"和"semantic priority eviction"思路可被 GraphRAG (Microsoft)、LlamaIndex KG retriever、Neo4j GenAI stack 借鉴到生产级 graph-agent serving。
• 学术血缘: 上承 Graph-CoT (Jin et al., ACL 2024)、Graph-RAG survey (Peng et al., 2024)、vLLM (Kwon et al., SOSP 2023)；下游将成为 "agentic RAG serving"（同时关注 token/latency/throughput 而非仅 accuracy）方向的早期代表。
• 开放问题：多 agent serving 的 SLO-aware 调度、code-exec 错误的 verifier、小模型下 code-gen 的可靠性，都是论文留下的显性 gap。