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

我为什么把整个Agent系统的“语言”从Markdown换成了JSON-LD很多同学问我“为啥非要用JSON-LD啊Markdown不香吗”今天就来聊聊我在写Gliding Horse流马这个Agent操作系统时做的一个最“偏执”但最不后悔的技术选型。一、先说结论Markdown是给人看的JSON-LD是给机器“理解”的如果你只是想让AI读一段指令然后执行Markdown完全够用。但我要的是200多个Skill能互相对话、Agent间能共享记忆、LLM能随时查到任意历史细节、整个系统能像拼乐高一样组装——而且还要安全要能校验数据靠不靠谱。这时候Markdown就顶不住了。JSON-LD不是另一种Markdown它是让数据变成图的技术。二、举个栗子三个SkillMarkdown的灾难想象一下团队里三个小伙伴写了三个Skill小明的Skill参数叫input_file小红的Skill参数叫source_url小黑的Skill参数叫data_path表面上看这是三个不同的名字。但业务上它们都指向同一个概念——“数据来源的地址”。如果用MarkdownAI调用时必须记住“哦小明那个得传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系统里统统映射成同一个IRIskill:sourceDataURI。这就是鸭子类型走起来像鸭子、叫起来像鸭子那你就是鸭子。系统不关心你怎么命名只关心你语义上是不是同一个东西。这叫“语义互操作”——听起来很学术用起来就是“名称冲突不存在的。”三、再举个栗子多轮对话Markdown的Token黑洞AI对话最大的痛是什么上下文窗口贵得要死。你用GPT-4每1000个Token就是钱。你每次把完整的对话历史丢回去Token数指数级爆炸。但你不给完整历史AI就“失忆”——“啊刚才我们聊啥来着”我的做法让LLM只记“摘要”不记“全文”。每次LLM回答系统强制要求它同时输出三样东西{thought:详细推理过程……存进数据库不占上下文,content:正式回答……也存进数据库,summary:我们决定了用JWT做认证有效期24小时}关键来了thought和content→ 存进Oxigraph图数据库并分配一个唯一的id例如memory:session-042/block-017summary→ 塞进LLM的上下文历史效果聊了50轮LLM上下文里只有50条摘要每条十几个Token而完整的50轮对话细节全在图数据库里。某天LLM突然想“诶我们第三轮时那个JWT密钥长度是多少来着”它不需要在上下文里翻——直接查memory:session-042/block-003图数据库瞬间返回那轮的完整记录。Token消耗从O(n)变成O(1)。这就是JSON-LD作为“数据地址总线”和Oxigraph作为“高速查询引擎”结合后最朴实无华的威力。四、Markdown vs JSON-LD 全面对比场景MarkdownJSON-LD多Skill协作名字满天飞容易撞车context映射到统一IRI天然不冲突上下文管理全量历史塞进PromptToken爆炸摘要 IRI引用按需查图Token恒定数据校验靠人工审查AI可能瞎编JSON Schema 数字签名代码层硬拦截知识追溯“这结论哪来的”——翻聊天记录去吧每个结论都有id顺着图一查到底Agent间共享靠传文件、复制粘贴同一id在图里自动合并天然去重人类阅读极其友好需要工具辅助或者看摘要学习成本零门槛需要理解context、id、RDF这些概念工具生态到处都是Rust有json-ldcrate但总体小众五、坦诚聊聊JSON-LD的坑1. 学习曲线陡峭第一次看到context、id、type、graph、RDF、SPARQL…… 我脑子也嗡嗡的。但好消息是你不需要让LLM理解这些。在我的系统里LLM只输出普通JSON它最擅长的由Rust引擎自动加上context和id。LLM完全不知道自己在玩JSON-LD。2. 工具链不如Markdown成熟在Rust生态里json-ldcrate已经很能打支持展开、压缩、Framing、RDF转换但和遍地都是的Markdown解析器比确实小众。3. 人类直读不友好给一个JSON-LD文件让你看绝对没有Markdown舒服。解决方案对外展示时渲染成好看的HTML或Markdown摘要内部处理时用JSON-LD。4. 社区惯性“Markdown都够用了搞那么复杂干嘛” —— 我认同。如果你的系统永远不超过10个Skill、5轮对话、单AgentMarkdown绝对是更优解。但当你像我一样想让200个Skill互相对话、Agent跑上几周不丢上下文、多Agent共享记忆不出错的时候…… JSON-LD就是救命的。六、这套设计给我的系统带来了什么装X环节1. 统一数据模型系统中没有任何东西是“字符串”——全是带id的图节点。提示词、Skill、记忆、设计文档、审计日志…… 格式完全统一。这意味着任何组件都能通过SPARQL查询任何数据。2. 自动去重与关联两个Agent写了同一个实体的信息同一个id在图里自动合并连MERGE语句都不用写。这是RDF图数据库自带的光环。3. 按需加载Token精确控制LLM上下文里全是摘要和IRI引用。想查细节沿着IRI在图里一拉就行。Token预算从“尽力压缩”变成了“精确控制”。4. 内核级安全Skill的定义必须经过JSON Schema校验 Ed25519数字签名验证才能被系统调用门放行。Markdown做不到这种硬拦截。5. 知识可审计“我们当时为什么选JWT而不是Session” —— 查一下决策节点的IRI顺着图能看到当时的讨论摘要、相关Skill、甚至CA的审计结果。整个系统的决策链路完全透明。七、到底该不该用JSON-LD如果你的场景是3-5个简单Skill对话不超过10轮单Agent执行不需要多Agent协作不需要长期记忆→用Markdown别折腾。如果你的场景是几十上百个Skill且不断增长Agent需要跑几小时甚至几天多Agent并发共享状态需要精确的上下文预算控制需要安全校验和知识追溯→JSON-LD 图数据库是真的香。八、最后说句人话我当时选JSON-LD不是因为它“新潮”或者“听起来牛X”。是因为我受够了Token费用飞涨Agent突然失忆Skill名字打架查历史靠“感觉”数据到底可不可信不知道JSON-LD没能解决所有问题但它至少给我提供了一套可寻址、可校验、可追溯、可演化的统一数据协议——这已经比Markdown能提供的多了一个维度。对Agent系统来说数据不是文件是图引用不是链接是语义校验不是审查是数学。这就是我选JSON-LD的原因。如果你也在做Agent系统或者对Rust知识图谱感兴趣欢迎来GitHub围观https://github.com/doiito/gliding_horse关于这个项目我之前还写过一篇更硬核的技术介绍感兴趣可以去翻翻。今天这篇主要是想用人话把JSON-LD的价值讲清楚——毕竟再好的技术讲不明白也没人用。