> ## Documentation Index
> Fetch the complete documentation index at: https://all.mimedal.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 语言引擎概述

> 从实验目标到对象状态、可检查程序和真实执行结果。

ALL 语言引擎先从 FSP 服务获取设备能力、使用边界和约束，再通过智能体（Agent）根据实验目的生成任务流程。编译/解释器整理流程，仿真器计算预测结果并检查约束；有问题就反馈给 Agent 修订，直到通过检查或达到修订上限。执行器接收通过仿真的流程，解析任务，在下发前向 FSP 查询最新状态，确认设备和对象可用，再交给 FSP 执行。

整个流程围绕同一批样品和容器展开：它们现在在哪里、处于什么状态、操作之后应发生什么变化，以及这些变化由什么证据确认。

## 从 FSP 获取规划依据

语言引擎通过 FSP 查询设备已实现的动作、参数单位和范围、适用对象、前置条件、完成证据、资源限制及能力版本。FSP 根据动作契约、设备实现和部署配置提供这些信息；语言引擎保留来源、版本和未知项，供 Agent 生成流程和仿真器校验使用。

Agent 的输入包括实验目的、成功条件、对象初态以及这些能力和约束。输出应说明步骤、参数、对象、先后依赖和判断条件。Agent 提出的流程经过编译/解释与仿真后才能进入执行阶段。

## 核心原理：带条件的状态转换

用 `S` 表示当前对象状态，用 `θ` 表示操作参数，用 `P(S, θ)` 表示操作必须满足的条件。只有条件成立，仿真才能应用操作的状态效果：

```text theme={null}
P(S, θ) 成立：S_next = apply_effect(S, θ)
P(S, θ) 不成立：保留 S，返回定位到步骤的诊断
```

例如加液要同时检查来源余量、目标剩余容量、容器状态、参数单位和设备能力。通过后，仿真更新来源和目标的预测体积。实际执行时还要读取设备和对象证据，不能把预测体积直接作为测量值。

对象状态至少区分身份、样品、容器、位置、证据和来源。每项操作只读取它声明需要的字段。多个对象参与同一动作时，检查和更新必须覆盖整个对象集合。

## 三部分怎样配合

| 部分     | 负责什么                                    | 交付什么                   |
| ------ | --------------------------------------- | ---------------------- |
| 编译/解释器 | 整理 FSP 能力与 Agent 候选流程，检查调用和依赖，并根据证据推进路径 | 能力注册表、程序结构、实际路径与控制状态   |
| 仿真器    | 按模型计算预测变化，检查使用边界与约束，把诊断反馈给 Agent        | 计算结果、诊断、预测状态、仍需现场确认的条件 |
| 执行器    | 解析已验证流程，下发前查询 FSP 并确认可用设备，提交任务、跟踪真实反馈   | 任务结果、实际对象变化和完成证据       |

编译/解释器确定步骤、参数和执行条件，仿真器计算预测变化并检查这些条件是否满足。

```mermaid theme={null}
flowchart TD
    A[FSP 提供能力、使用边界与约束] --> B[语言引擎整理能力]
    C[实验目的、成功条件与对象初态] --> D[Agent 生成候选流程]
    B --> D
    D --> E[检查流程结构、动作与参数]
    E --> F[解释控制结构]
    F --> G[仿真计算与约束校验]
    G --> H{必检项通过?}
    H -->|否| I[向 Agent 反馈步骤、原因和计算结果]
    I --> D
    H -->|是| J[保存验证记录与待现场确认项]
    J --> K[执行器解析任务]
    K --> L[向 FSP 查询最新能力与状态]
    L --> N{设备可用且条件满足?}
    N -->|否| O[等待或返回诊断]
    O -->|需要修订| D
    O -->|重新查询| L
    N -->|是| M[下发 FSP：再次门控并执行]
    M --> P[实际结果返回执行器]
    P --> V{还有未完成任务?}
    V -->|是：以实际结果推进剩余步骤| F
    V -->|否| Z[保存实验结果与完成证据]
```

## 五种组合策略

下面的循环表达实验流程内部的重复处理；前述“生成—仿真—修订”循环用于检查和完善整个流程，两者分别记录次数和结束条件。

| 结构   | 表达的实验逻辑     | 必须检查                  |
| ---- | ----------- | --------------------- |
| 顺序   | 前一步产物进入下一步  | 对象类型、状态与位置能够衔接        |
| 有界循环 | 重复处理直到达标    | 最大次数；到达上限仍不满足时报告未收敛   |
| 条件   | 根据检测结果选择路径  | 证据有效；只能选择允许的一条分支      |
| 并行汇合 | 独立样品分别处理后汇总 | 分支写集合不冲突；共享资源可用；结果可合并 |
| 保护区间 | 一组操作保持连续    | 声明资源与顺序；不得被冲突操作穿插     |

这些结构可以嵌套。实现应声明支持的结构，对不支持的结构返回明确诊断。并行任务必须满足设备和资源互斥要求；保护区间结束或中断时，应根据设备实际状态释放资源。

继续阅读：[编译/解释器](/docs/specification/engine/compiler)、[仿真器](/docs/specification/engine/simulator)、[执行器](/docs/specification/engine/executor)。