在上一篇文章中，我们已经提出了一个颠覆性的观点：
通信协议不应该写在代码里，它应该是可以执行的 YAML 流程。
那么问题来了：
一个 YAML 文件，真的可以驱动串口/TCP、执行协议逻辑、完成复杂通信握手吗？ 它是怎么变成一个可运行的状态机，而不是普通的配置文件？
今天，我们就把 ToolOfCOM 的底层原理彻底讲清楚。
🧭 在深入原理之前：什么是 DSL 和 AST？
ToolOfCOM 的实现基于两个关键概念：
- DSL —— 让人类描述通信流程
- AST —— 让机器理解并执行这些流程
如果不了解这两者，你会误以为 ToolOfCOM 只是“增强版串口助手”。 而实际上，它是一套通信运行时系统。
🧠 DSL（Domain Specific Language）是什么？
DSL 是领域特定语言，不是通用编程语言，而是专门为某类问题设计的表达方式。
在 ToolOfCOM 中，DSL 的目标是：
用文本描述通信协议的执行流程
例如：
send: "AT+LOGIN"
expect: "OK"
goto: next
DSL 关心的是 “做什么”：
- 发什么指令
- 收到什么算成功
- 超时怎么办
- 下一步跳到哪里
因此它改变了传统思维：
| 传统模式 | ToolOfCOM DSL 模式 |
|---|---|
| 写代码表达逻辑 | 写文本表达流程 |
| 协议绑定程序 | 协议独立于设备 |
DSL 让通信逻辑第一次可以被描述、共享、版本化和资产化。
🛰️ AST（Abstract Syntax Tree）是什么？
DSL 是给人看的，机器不能直接执行。
AST 是：
把 DSL 转成可执行语义结构的抽象语法树
你可以这样理解：
DSL = 菜谱
AST = 已拆解好的烹饪步骤
执行器 = 厨师
例如，下面的 DSL：
state: login
send: "AT"
expect: "OK"
会变成 AST 节点：
StateNode(
name="login",
action=Send("AT"),
on_event={"OK": "next"},
)
AST 的作用包括：
| 能力 | 意义 |
|---|---|
| 消除歧义 | 把“意图”变成确定执行语义 |
| 可遍历 | 执行器能逐节点运行 |
| 可分析 | 检查非法跳转、缺失状态 |
| 可扩展 | 可复用于 UART / TCP / Modbus 等后端 |
AST 是 DSL 变成程序的关键台阶。
📌 DSL 与 AST 的关系
DSL —— 人类语言（定义流程）
↓
AST —— 机器语义（可执行模型）
↓
Runtime —— 执行行为（驱动协议）
一条线总结：
DSL 说要做什么，AST 说明这意味着什么，Runtime 负责真的做出来。
🧩 总览：不是加载 YAML，而是执行“编译后的通信程序”
ToolOfCOM 的执行链路如下：
DSL（YAML） → AST（语义树）
→ Runtime（状态机执行器）
→ Action + Driver + Channel
这是一条类似编译器/浏览器/SQL 引擎的完整链路，它不是脚本解释器。
📜 第一阶段：DSL —— 声明式通信逻辑
用户写下的 YAML 实际上是在描述一个通信流程状态机：
state_machine:
initial: start
states:
start:
do: [ - action: send("AT") ]
on_event: { "OK": done }
DSL 不关心底层 UART/TCP 怎么发，它定义的是协议行为。
DSL = 意图层
🌳 第二阶段：Parser —— 把 DSL 编译成 AST
解析器承担三件事：
- 解析 YAML
- 校验语义合法性（状态、条件、跳转）
- 构造 AST 节点
最终 AST 变成这样的结构：
StateNode(
name="start",
actions=[Send("AT")],
transitions={"OK": "done"},
)
这一步让 DSL 从“文本”变成“程序”。
⚙️ 第三阶段：Runtime —— 通信的 CPU
执行器是系统真正的灵魂，它是一个事件驱动状态机：
进入状态
↓
执行动作(do)
↓
等待事件/超时
↓
根据 AST 跳转下一状态
你写的 YAML 不是被解释，而是被执行。
🔌 第四阶段：Action / Driver / Channel 解耦体系
Runtime 不负责具体发包，它只负责调度。
1️⃣ Channel（介质）
UART / TCP / BLE / Mock / File
统一 send / recv 接口
2️⃣ Driver（协议栈）
XMODEM / YMODEM / Modbus RTU / Modbus TCP / 自定义协议
构建与解析帧，不关心通道
3️⃣ Action（动作）
由 DSL 触发，调用 Driver + Channel：
DSL → AST → Runtime → Driver → Channel
协议逻辑首次可组合、可扩展、可复用。
🔁 整体链路回顾
upgrade.yaml
↓
DSL Parser
↓
AST（状态节点 + 条件 + 跳转）
↓
Runtime Engine
↓
Action 调用 Driver 打包数据 → Channel 发送
↓
Driver 解析回包 → Runtime 状态跳转
通信第一次从“代码逻辑”变成了“可执行流程”。
🧭 一句话总结原理
DSL 负责表达意图
AST 负责表达语义
Runtime 负责行为执行
Driver / Channel 负责协议落地
ToolOfCOM 把通信流程从程序中抽离出来，变成一门可以执行的语言。
