为什么我把 JSON‑LD “编译成 DAG” 后，整个 Agent 平台立刻聪明了
我写的Gliding Horse（流马）是一个用 Rust 从零构建的 AI Agent 操作系统。如果你问我：整个系统里最“魔法”的一个设计是什么？
我会毫不犹豫地回答：把 JSON‑LD 直接编译成 DAG。
这个 DAG 不是普通的流程图，它是可验证的、可溯源的、语义化的任务执行蓝图。
这件事做完之后，SA 调度器不再是一个“猜谜游戏”，PA 计划者不再是一个“凭感觉写步骤”的实习生，整个平台第一次真正拥有了可计算的任务结构。
今天就来聊聊这个设计背后的逻辑。
一、先看问题：Agent 的“计划”为什么总是不靠谱？
不管是给 AI 一个 prompt 让它写计划，还是用 Skill 图去规划步骤，传统方案都会碰到三个顽固问题：
1. 计划与知识割裂
PA 生成的计划是自然语言，DA 要去执行，但 DA 不知道“步骤 2 为什么需要调用那个工具”。知识图谱里的依赖关系、前置条件，PA 知道，但 PA 只是用文字写出来，DA 只能用概率去理解。
2. 步骤间的关系是“隐式”的
PA 写“先做 A，再做 B”，CA 想校验“做完 A 真的能满足 B 的前置条件吗？”——没有结构化数据可以验证。
3. 计划无法被增量修正
上游 PRD 改了，PA 改几个字。但哪些步骤受到了影响？不知道，只能全量重新规划，浪费 Token。
根本原因：计划是“文本”，不是“数据”。
二、JSON‑LD 编译成 DAG：让计划变成“可计算的数据”
在流马里，任务、技能、依赖关系都是用 JSON‑LD 表达的。JSON‑LD 天生就是图——
@id是图的节点skill:requires、task:dependsOn等是图的边@type是节点的类型，可以多态继承
编译成 DAG 的关键思路：
不要等 PA 去写自然语言计划。而是直接从 JSON‑LD 构建的语义网络中，用 SPARQL 提取一条可执行的、无环的有向图。这条图就是 DAG。
2.1 编译流程
2.2 一个具体例子
假设任务描述是：
{"@id":"task:jwt-refactor","@type":"task:ImplementationTask","task:what":"重构认证模块为 JWT","task:how":[{"@id":"skill:rust-jwt-auth"},{"@id":"skill:token-security"}]}SPARQL 引擎可以立刻查询：
CONSTRUCT { ?skill skill:requires ?dep . ?dep skill:requires ?transitive . } WHERE { BIND (skill:rust-jwt-auth AS ?skill) ?skill skill:requires* ?dep . }结果得到依赖链：
skill:rust-jwt-auth → skill:rust-basics → skill:cargo-setup skill:token-security → skill:hash-algorithmsDAG 生成器把这些依赖链拼成一张有向无环图，每个节点是一个具体的 Skill 调用。节点之间用exec:then、exec:parallel、exec:conditional等边标记执行关系。
最后，这张 DAG 被序列化成一个 JSON‑LD 节点（plan:task-tree/jwt-refactor），存入 L2 黑板。PA 不再需要“写计划”，PA 的职责变成了审查并修正这张 DAG。
三、JSON‑LD 编译成 DAG 的四大优势
优势一：计划变成“数据”，而非“文本”
PA 生成的 DAG 是 RDF 三元组，不是自然语言段落。CA 可以用 SPARQL 或 SHACL 直接查询：
- 所有叶子节点是否都有
exec:assignedTo？ - 是否存在循环依赖？
- 某 Skill 的输入是否满足了前置 Skill 的输出 schema？
这些检查是确定性算法，不需要依赖 LLM 的“自觉”。
优势二：增量更新，Token 成本骤降
上游需求改了，只修改了一个参数。传统方式要重新生成整个计划。
而在流马里，因为 DAG 是数据，系统只需：
- 定位到变更的 IRI。
- 重新查询受影响的子图。
- 局部重建 DAG 的受影响分支。
Token 消耗从 O(n) 变成了 O(Δ)。
优势三：SA 动态调度有了“地图”
有了 DAG，SA 不再是凭空决策，而是在地图上导航：
- 哪些分支可以并行？看 DAG 的并行边。
- 哪个任务处于阻塞状态？看 DAG 的前置节点是否全部完成。
- 出错后怎么回滚？沿 DAG 反向遍历受影响节点。
优势四：跨阶段传递“可计算契约”
需求阶段的产出是一个 IRI，指向的是结构化的设计 DAG。
设计阶段接手时，不是读一份“需求文档.txt”，而是加载一个 DAG，并拿到所有前置约束。
下游设计 SA 可以直接用 SPARQL 查询：“这个 DAG 的叶子节点有哪些？它们需要什么输入？”
这比任何自然语言交接都精准。
四、与 Gliding Horse 架构的匹配性
Gliding Horse 的架构核心是“编排引擎 + 上下文管理”，JSON‑LD 编译成 DAG 完美地嵌入了这两个核心。
- 编排引擎：SA 直接读取编译出的 DAG，决定执行拓扑和资源分配。
- 上下文引擎：把 DAG 的当前状态（哪些节点已完成、哪些阻塞）以及相关 IRI 注入给每个 Agent，而不是注入冗长的计划文本。
这种设计让计划和执行彻底分离，计划是“图数据”，执行是“状态机”。
五、总结
把 JSON‑LD 编译成 DAG，本质上是在 Agent OS 里装了一个“编译器”。
它把人类意图（5W2H）和技能网络（Skill Graph）编译成可以被 Agent 直接执行的字节码（DAG）。
这带来了几个关键飞跃：
- 计划从“自然语言”变成“结构化数据”，可验证、可增量、可追溯。
- 调度器有了精确的执行地图，而不是盲猜。
- 上下文只存 DAG 的摘要和 IRI，Token 成本降到极致。
- 跨阶段协作传递的是结构化契约，而不是文本文档。
如果你也在构建复杂的 Agent 系统，我强烈建议：不要让 Agent 输出“计划文档”，让它输出“DAG”。
这是让你的平台从“聪明但不可靠”走向“可依赖工程”的关键一步。
我这套系统叫Gliding Horse（流马），所有代码都在 GitHub 上：https://github.com/doiito/gliding_horse
欢迎来 star、提 issue、一起把 Agent OS 的理念推得更远。
摘要：本文深入解析了如何将 JSON‑LD 语义网络编译成 DAG（有向无环图），从而让 AI Agent 平台拥有可计算、可验证、可增量更新的任务执行蓝图。基于 Gliding Horse（流马）Rust Agent OS 的实战经验，展示了从 SPARQL 图遍历到 DAG 拓扑排序的完整编译流程，以及四大核心优势：计划结构化、Token 成本骤降、动态调度地图化、跨阶段契约传递。适合 AI 架构师、Agent 系统开发者、知识图谱工程师阅读。
关键词：JSON‑LD 编译 DAG、Agent 操作系统、AI Agent 计划编排、语义网络 DAG、Gliding Horse 流马、SPARQL 图遍历、Rust Agent OS、任务 DAG 生成、Token 优化、可计算任务结构