【Agent Harness】给模型厂商的一封信：求求你们，教教AI说“JSON-LD”吧

给模型厂商的一封信：求求你们，教教AI说“JSON-LD”吧

前几篇和大家聊了为什么我选择用JSON-LD做数据总线、为什么抄CPU缓存架构做记忆系统，以及Oxigraph和Qdrant这对黄金搭档。

评论区里有小伙伴问：“既然JSON-LD这么好，为啥不直接让LLM生成JSON-LD呢？”

这个问题戳到了我的痛点——因为现在的LLM，压根不认识JSON-LD。

今天就来聊聊：为什么模型厂商应该把JSON-LD塞进训练数据，以及如果LLM能像写JSON一样写JSON-LD，我的流马平台会变成什么样。

---

一、现在的LLM，看JSON-LD就跟我看甲骨文一样

做过测试，我让好几个主流模型写一个带@context、@id、@type的JSON-LD文档。

结果惨不忍睹：

• @context 经常被写成 @context（注意那个诡异的引号）
• @id 要么重复，要么缺失，要么写了个根本没意义的字符串
• @type 时而有时而没有，类型名还经常拼错
• 最绝的一次，模型直接给我一个普通JSON，上面加了个注释：“这是JSON-LD”

原因很简单：它们在训练时，几乎没见过JSON-LD。

你想想，训练数据里有什么？API文档（JSON）、配置文件（JSON）、网页数据（HTML）、代码（各种语言）、维基百科（Markdown/文本）……

JSON-LD？那是W3C那群搞语义网的老学究才会用的，根本进不了主流通用训练集。

于是LLM对JSON-LD的理解，基本停留在“好像是一种以@开头的奇怪JSON”这种水平。

---

二、因为这个“文盲”，我被迫在系统里塞了一个“翻译官”

我的流马平台，JSON-LD是绝对核心。所有数据——Skill定义、任务元数据、对话记忆、设计文档——全是JSON-LD节点，存在Oxigraph图数据库里。

但因为LLM不认识JSON-LD，我不得不在LLM和图数据库之间，加了一层“翻译引擎”。

流程是这样的：

LLM想读数据 → Rust引擎从Oxigraph取JSON-LD → 剥掉@context和@id 
→ 转成“技能：Python数据分析（IRI: skill:python-analysis）”这种纯文本 
→ 喂给LLM

LLM想写数据 → 输出普通JSON → Rust引擎解析 → 加上@context和@id 
→ 转成JSON-LD → 存入Oxigraph

这就像你家请了个外国保姆，但她只会说英语，你不得不在她和家人之间配个翻译。翻译很累，你也心累。

这套翻译层带来的代价很实在：

• 几百行Rust代码，全在做“转换”这种没技术含量的事
• 每次转换都有信息损失——图里的语义关系，到了LLM眼里就是一堆“相关技能：xxx”的文本
• Token白白浪费在自然语言描述上，而不是直接的IRI引用

---

三、如果LLM能原生支持JSON-LD，流马会变成什么样？

畅想开始。

1. 那个翻译层，直接删掉

LLM直接读JSON-LD，直接输出JSON-LD。中间那几百行转换代码，全部扔进垃圾箱。

系统架构瞬间清爽。

2. LLM自己能“逛”知识图谱了

现在，LLM要查“skill:rust-jwt-auth 需要什么前置技能”，必须等我喂给它。

未来，LLM可以直接在推理中规划：“我看到 task:how 里引用了 skill:rust-jwt-auth，让我查一下它的 skill:requiresDirect……” 然后触发一次内部工具调用，返回相关子图，继续推理。

LLM从一个被动的“信息接收者”，变成主动的“知识探索者”。

3. Token消耗再砍一刀

现在为了安全，我得把IRI翻译成自然语言：“技能：Rust JWT认证实现（IRI: skill:rust-jwt-auth）”。

如果LLM认识IRI，我直接给 skill:rust-jwt-auth 一个字符串就够了。上下文里全是紧凑的IRI引用，没有冗余的自然语言解释。

4. Skill共享变成“复制粘贴IRI就行”

现在，两个Skill之间要共享参数，我得在@context里做映射，LLM完全不知道这回事。

如果LLM懂JSON-LD，它自己就能理解：“哦，skill:sourceDataURI 在A里叫 input_file，在B里叫 data_path，但它们语义相同。”

鸭子类型真正发挥威力——不再依赖Harness翻译，LLM自己就能做语义匹配。

5. 多Agent协作，直接用图通信

现在，Agent A完成了一个任务，Agent B要知道这个状态，得等Harness把图变化翻译成文本告诉B。

如果LLM懂JSON-LD，Agent A写完 task:001 exec:status "completed" 后，Agent B直接在对话中接收这个三元组更新，立刻、自动、无歧义地调整自己的计划。

---

四、给模型厂商的具体建议

我知道，让你们在训练数据里加JSON-LD，听起来像个很小的需求。但这事其实没那么复杂：

1. 在代码生成数据集里混入JSON-LD

现在很多训练数据里有“生成JSON”的任务。把其中一小部分替换成JSON-LD就行。让模型知道世界上还有@context、@id、@type这些关键字。

2. 在RDF/知识图谱数据上做指令微调

Wikidata、DBpedia都有海量的JSON-LD格式数据。拿来做指令微调——“请把这段自然语言描述转换成JSON-LD格式”、“请根据这个JSON-LD文档回答问题”。

3. 在Agent相关数据里用JSON-LD做工具定义

现在大多数Agent框架用JSON Schema定义工具。其实JSON Schema很容易嵌进JSON-LD。训练模型时，让它学会理解和生成带@context的工具定义。

4. 就这么简单

不需要专门为JSON-LD训练一个新模型。只需要在现有的训练管线里，让JSON-LD的占比从“接近0%”提升到“能看到几次”，LLM对它的适应能力就会有质的飞跃。

---

五、最后说句掏心窝子的话

我知道模型厂商们的优先级列表很长——多模态、更长上下文、更快推理、更低成本…… “支持JSON-LD”可能排在一千名开外。

但我真的相信，JSON-LD是AI Agent走向真正智能的关键基础设施。

它不是另一种数据格式，它是让数据变成图、让Agent能互相理解、让记忆能跨会话持久化的语义总线。

现在的LLM，就像一个聪明绝顶但只会说英语的人。你让它处理全球业务，它很强，但一旦碰到西班牙语、中文、阿拉伯语，就得上翻译。

JSON-LD，就是AI世界的“通用语”。

所以，模型厂商们，求求你们，教教LLM说“JSON-LD”吧。

流马平台在线等，挺急的。

---

我这套系统叫 Gliding Horse（流马），所有代码都在 GitHub 上：https://github.com/doiito/gliding_horse

之前还写过为什么选 JSON-LD、为什么抄 CPU 缓存架构、Oxigraph 和 Qdrant 怎么配合，感兴趣可以去翻翻。今天这篇是“求模型厂商教AI说JSON-LD的请愿书”，希望有一天，这篇文章能彻底过时。