tok：面向人类与AI的BPMN/DMN文本语法

业务流程建模长期依赖图形化工具，BPMN 和 DMN 的 XML 存储格式对机器友好，对人和大模型却相当笨重。一篇新论文提出的 tok 试图改变这一点：它用纯文本表达 BPMN 2.0.2 流程模型和 DMN 1.5 决策模型，一套引擎同时完成标准校验、编译为带自动图表的 XML，并通过 Model Context Protocol 为语言模型应用提供服务。

tok 是什么：BPMN/DMN 的另一种具体语法

论文把 tok 归类为 BPMN 和 DMN 元模型的一种替代具体语法（alternative concrete syntax）。这个定位很关键——tok 不是新标准，也不是私有 DSL，而是同一套元模型之上的文本化表达。这意味着 tok 文档可以被严格校验是否符合 BPMN 2.0.2 与 DMN 1.5，而不是停留在"看起来像"的层面。

工程上的取舍也很清晰：一份 tok 文档交由单个引擎处理，校验、编译、图表生成在一条流水线内完成。对习惯用 Git 管理流程资产的团队来说，纯文本意味着可 diff、可 review、可合并；对语言模型来说，纯文本意味着更少的 token 和更低的出错面。

具体语法与抽象语法是建模语言领域的核心区分。抽象语法（如 BPMN 元模型）定义模型可以包含哪些元素、元素之间允许什么关系，与具体怎么写、怎么画无关；具体语法则是这套抽象结构在某种媒介上的实际呈现方式。BPMN 常见的具体语法是框图，DMN 是决策表与表达式，二者的 XML 序列化也可视作一种面向机器的具体语法。同一抽象语法可以有多种具体语法，彼此可无损互转。tok 的定位正是新增一种面向文本与语言模型的具体语法，因此它不必重新定义语义，只需保证与元模型严格对齐，校验也就能直接对照 BPMN 2.0.2 与 DMN 1.5 的规范约束进行。

Model Context Protocol（MCP） 是 Anthropic 于 2024 年底提出并开源的协议，用于在语言模型应用与外部工具、数据源之间建立标准化的调用接口。它把能力提供方抽象为 server，把宿主应用（如 IDE 插件、桌面客户端、agent 框架）抽象为 client，双方通过声明式的工具列表和结构化的请求响应交互，从而避免为每个模型应用单独写集成代码。对 tok 而言，通过 MCP 暴露校验与编译能力意味着任何支持该协议的 agent 都能直接调用 tok 引擎，无需自己实现 BPMN/DMN 解析，这也是论文中“单一检查器工具”实验能够成立的基础设施前提。

实测数据：token 更少，查错更准

论文给出的对比数字值得逐条看。在 37 个工具导出的 893 个 BPMN XML 文件上，tok 模型所需的 token 数比其中最小的 XML 还少 2.2 倍，比文件原始导出形式少 7.7 倍。这个差距不是微调级别的，而是直接改变了长流程模型能否塞进上下文窗口的问题。

校验能力上，针对注入的 1,411 个故障，tok 检查器能识别出 98.2%，而 XML Schema 配合 bpmnlint 的组合为 85.8%。这说明文本语法并没有以牺牲严谨性为代价换取简洁，反而在故障检出上更占优。

XML Schema 与 bpmnlint 代表两类不同的校验思路。 XML Schema（XSD）是 W3C 标准，依据 BPMN 2.0.2 提供的 XSD 约束 XML 文档的元素结构、顺序、类型与基数，属于语法层校验，能抓出结构错误，却不理解语义规则，例如某个网关是否缺少分支条件、流程是否有不可达节点。bpmnlint 则是社区维护的 BPMN 静态规则检查器，以可配置规则集覆盖命名规范、连接合法性等语义与风格问题，但规则覆盖有限、扩展依赖插件。两者组合是当前实践中的常见做法，其 85.8% 的检出率反映的正是“结构校验 + 有限规则”这一组合的天花板，而 tok 在单一引擎内把元模型约束与语义规则统一检查，是它检出率更高的结构性原因。

语言模型能否直接写 tok

论文设计了两组实验。第一组让四个此前从未接触 tok 的语言模型，仅凭一页参考文档来写 tok：在来自两个数据集的 87 条流程描述上，有效 tok 的生成率为 85.7% 到 100%，而对应的 BPMN XML 则是每条描述都能写出来。最强模型写 tok 比写 BPMN XML 少用 25% 和 19% 的 token。

第二组把模型配置为带精简技能和一个检查器工具的 agent：有效 tok 生成率提升到 97.6% 到 100%，最强模型的 token 节省为 21% 和 14%。这里有个容易被忽略的细节——如果技能设计成让模型通过工具去读参考文档，token 开销是精简技能的 1.7 到 2.8 倍。换句话说，把参考资料放进上下文比让模型反复调用工具去查更划算，这对 agent 的提示工程有直接参考价值。

从日志回到模型：闭环验证

论文还做了一项往返测试：从公开模型模拟出 47 份事件日志，其中 44 份能拟合回其来源模型，且 tok 能导入从这些日志中发现的每一个模型。这项测试的意义在于确认 tok 不只是"能写"，还能在流程挖掘与模型重建的链路上站得住。

几点判断

tok 的价值不在于替代图形化建模，而在于为流程资产提供一种更适合版本控制和大模型读写的底层表示。2.2 倍到 7.7 倍的 token 差距、98.2% 对 85.8% 的故障检出率，加上 MCP 的原生支持，构成了一条从人工建模到 agent 自动处理的连贯路径。需要留意的是，目前的验证集中在论文自建的两组数据集和公开模型上，tok 在大型企业级流程库中的表现、以及多工具生态的采纳意愿，还有待观察。

对正在把流程建模接入 AI 工作流的团队，tok 提出的"精简技能 + 单一检查器工具"模式，可能比语法本身更值得借鉴。