【Agent Harness】我为什么把整个Agent系统的“语言”从Markdown换成了JSON-LD

doiito（Do It Together） · 2026-06-06 18:28:42 发布

我为什么把整个Agent系统的“语言”从Markdown换成了JSON-LD

很多同学问我：“为啥非要用JSON-LD啊？Markdown不香吗？”

今天就来聊聊，我在写Gliding Horse（流马）这个Agent操作系统时，做的一个最“偏执”但最不后悔的技术选型。

如果你只是想让AI读一段指令然后执行，Markdown完全够用。

但我要的是：200多个Skill能互相对话、Agent间能共享记忆、LLM能随时查到任意历史细节、整个系统能像拼乐高一样组装——而且还要安全，要能校验数据靠不靠谱。

这时候Markdown就顶不住了。

JSON-LD不是另一种Markdown，它是让数据变成图的技术。

想象一下，团队里三个小伙伴写了三个Skill：

表面上看，这是三个不同的名字。但业务上，它们都指向同一个概念——“数据来源的地址”。

如果用Markdown： AI调用时，必须记住：“哦，小明那个得传 input_file，小红那个得传 source_url……” 一旦记错，整个流程炸掉。这种“名字爆炸”的破事，干过集成的同学应该都懂。

如果用JSON-LD： 我在三个Skill里加一个 @context：

{
  "@context": {
    "skill:sourceDataURI": "https://my-agent-os.com/skill#sourceDataURI"
  },
  "input_file": { "@id": "skill:sourceDataURI" }
}

现在，无论你叫 input_file、source_url 还是 data_path，系统里统统映射成同一个IRI：skill:sourceDataURI。

这就是鸭子类型：走起来像鸭子、叫起来像鸭子，那你就是鸭子。 系统不关心你怎么命名，只关心你语义上是不是同一个东西。

这叫 “语义互操作”——听起来很学术，用起来就是：“名称冲突？不存在的。”

AI对话最大的痛是什么？上下文窗口贵得要死。

我的做法：让LLM只记“摘要”，不记“全文”。

每次LLM回答，系统强制要求它同时输出三样东西：

{
  "thought": "详细推理过程……（存进数据库，不占上下文）",
  "content": "正式回答……（也存进数据库）",
  "summary": "我们决定了用JWT做认证，有效期24小时"
}

关键来了：

thought 和 content → 存进 Oxigraph图数据库，并分配一个唯一的 @id（例如 memory:session-042/block-017）
summary → 塞进LLM的上下文历史

效果： 聊了50轮，LLM上下文里只有50条摘要（每条十几个Token），而完整的50轮对话细节全在图数据库里。

某天LLM突然想：“诶？我们第三轮时那个JWT密钥长度是多少来着？”

它不需要在上下文里翻——直接查 memory:session-042/block-003，图数据库瞬间返回那轮的完整记录。

Token消耗从O(n)变成O(1)。 这就是JSON-LD作为“数据地址总线”和Oxigraph作为“高速查询引擎”结合后，最朴实无华的威力。