论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-10-15 |
| 论文 | Knowledge Graphs as Files: An Agent Harness Where Tool Creation and Tool Use Co-Evolve |
| 作者 | Yuyang Bai, Yu Wang, Yu Zhang |
| 机构 | Texas A&M University / University of Oregon |
| 链接 | https://arxiv.org/abs/2610.18616 |
| 代码 | https://github.com/leopoldwhite/DKGI |
一句话总结
把知识图谱完整导出为普通文件，让Agent自己写Python代码做图检索，工具创造与工具使用共同进化，免训练即刷新STaRK基准。
解决什么问题
在文本丰富的知识图谱（产品页、论文摘要、药物说明等半结构化数据）上做检索，查询往往同时包含关系约束和文本约束（“找X的合著者写过关于Y的论文”）。现有方法都通过预定义接口访问图谱——查询语言、子图检索器、或实体搜索/邻居扩展等固定工具。这些接口限制了Agent能看到的证据范围：论文中的例子是，一个neighbors调用只返回某大学66位合作者中的20位，Agent永远遇不到正确答案。即使Agent写代码批量组合这些API调用，每次调用仍继承API的截断限制。
核心方法
DKGI（Direct Knowledge Graph Interaction）的核心设计极其朴素：
- 图谱即文件：把KG导出为纯文本文件——节点文件（每节点一行JSON，含ID/类型/属性）、每种关系一个TSV边表、外加一份schema说明。保留全部节点和边，不做任何预检索。
- Agent写访问代码：Agent在ReAct循环中自由编写Python代码，直接读文件实现图操作：全表扫描选择σφ(N)、按ID查找、一跳遍历Nr(U)及其反向、多跳组合、集合交并差、打分排序。例如"X合著者关于Y的论文"可直接编码为 N_w(N_w⁻¹(N_w({X}))∖{X}) ∩ N_h⁻¹({Y})。
- 大输出落盘：每次执行的完整输出保存为文件ℓt，模型只看到head+tail截断视图及文件路径；后续代码可以grep、过滤、复用这些输出文件，避免撑爆上下文又不丢证据。
- 工具创造与使用共同进化：执行反馈（候选ID、空结果、报错）指导Agent修订/扩展代码，新代码又决定下一步收集什么证据——写代码即造工具，跑代码即用工具，二者在任务内互相驱动，无需任何训练。
实验结果
- STaRK基准三个图谱（Amazon/MAG/Prime），免训练DKGI即使用极简的Pi harness，也在每个数据集上超过最强已发表基线至少6.7 Hit@1。
- 受控消融（固定模型/环境/预算）：仅shell访问不如预定义图工具；允许写Python代码后整体Hit@1提升6.9点并反超；单次执行恢复的增益很小，证明多轮交互的价值。
- 轨迹分析显示Agent确实利用执行反馈创建和修订图访问代码。
深层洞察
这篇论文代表了一个正在成型的趋势：与其精心设计工具接口，不如把原始数据和执行环境直接交给Agent。传统KGQA工程大量投入在"给Agent暴露哪些API"上，而这篇工作证明预定义接口本身就是瓶颈——任何截断、任何固定返回格式都在替Agent做它本可以自己做的决策。这与"direct corpus interaction"一脉相承：当代码模型足够强时，文件系统+Python就是最通用的检索接口。更微妙的是"工具创造与工具使用共同进化"的表述——它把agent写代码从"调用手段"提升为"探索策略本身"。
局限性
- 要求图谱能完整装进本地文件，对超大规模或动态更新的图（工业级图谱动辄数十亿边）不直接适用。
- 多轮代码执行意味着高延迟和高token成本，不适合在线低延迟检索场景。
- 依赖强代码模型；弱模型写不出可靠的遍历代码时，“工具创造"优势可能消失。
- 仅在STaRK三个中等规模图谱上验证，泛化性待考。
工程实践启示
- 做RAG/图检索系统时，认真考虑"导出原始文件+让Agent写代码"这条路线，尤其是查询模式多样、难以预先枚举接口的场景。
- 大输出落盘+head/tail截断视图是处理执行输出的优雅模式，可直接借鉴到自己的agent框架。
- 不要急着封装API：暴露数据和schema本身，往往比封装工具更能释放agent能力。