第六章 工程原语——可执行推理的最小单元
算法执行计算。
原语执行工程含义。
第三章到第五章建立了交通智能体工程的概念基础：责任作为原子计算单元（第三章）、中间表示作为桥梁（第四章）、推理规划作为认知过程（第五章）。但仅有概念并不能产生结果。在某个节点上，抽象推理必须与具体计算相连接。
本章引入工程原语（Engineering Primitive）——TAE 中可复用的最小工程语义单元。原语之于交通工程，犹如指令之于处理器：构成所有工程推理的基本词汇表。理解原语至关重要，因为它们构成了工程思维与计算执行之间的语义边界——意图转化为行动的临界点。
6.1 为什么工程需要原语
交通智能体工程中最根本的问题之一是：
工程推理的最小可执行单元是什么？
传统交通运输软件给出了一个显而易见的答案：算法。这种映射已经深深植根于实践：
| 工程任务 | 传统算法 |
|---|---|
| 信号配时优化 | 韦伯斯特公式、TRANSYT-7F、遗传算法 |
| 交通仿真 | VISSIM（中观）、SUMO（微观）、PARAMICS |
| 通行能力分析 | 《道路通行能力手册》方法体系 |
| 排队估计 | 确定性排队、冲击波理论、元胞传输 |
| 延误计算 | HCM 控制延误公式、韦伯斯特延误、坐标变换法 |
| OD 矩阵估计 | 重力模型、熵最大化、贝叶斯推断 |
从经典软件工程的角度看，这个答案似乎合理。算法定义清晰、可测试、可组合、可实现。还能要求什么呢？
然而，从工程推理的角度看，这个答案从根本上就是错误的。问题不在于算法无用——它们不可或缺。问题在于算法是实现机制，而工程师不以实现机制的方式思考。
当一位经验丰富的工程师调查交叉口拥堵时，她的第一个念头很少是：
“我应该执行韦伯斯特公式。然后运行 CTM。再套用 HCM 延误公式。”
相反，她自然而然地以工程概念进行思考：
| 概念 | 工程含义 | 它所回答的典型问题 |
|---|---|---|
| 排队 | 有多少车在等？ | 是否正在发生溢流？ |
| 延误 | 出行者等待了多久？ | 服务水平是否可接受？ |
| 通行能力 | 设施能处理多少车？ | 需求是否超过供给？ |
| 溢流 | 排队是否阻塞了上游入口？ | 是否存在阻塞？ |
| 存储 | 物理空间是否足以容纳预期排队？ | 排队能否装得下可用长度？ |
| 饱和度 | 通行能力被利用得有多充分？ | 哪些流向是关键流向？ |
| 绿信比 | 周期时间如何在各流向之间分配？ | 分配是否与需求匹配？ |
| 相位差 | 每个信号相对于相邻信号何时变绿？ | 是否实现了协调控制？ |
这些概念既不是算法，也不是软件模块。它们是工程推理的语义构建块——构造工程论证的词汇表。交通智能体工程将这些语义构建块称为工程原语。
6.2 工程原语的正式定义
工程原语的正式定义为：
可复用的最小工程语义执行单元。
三个特征将真正的工程原语与其他计算构件区分开来：
| 特征 | 描述 | 示例 |
|---|---|---|
| 单一概念 | 恰好代表一个连贯的工程概念 | 排队长度——而非”排队分析”或”排队论” |
| 推理独立性 | 可作为独立单元参与推理 | 饱和度可以独立于延误或 LOS 进行评估 |
| 算子可执行 | 可由一种或多种计算机制计算得出 | 通行能力可通过 HCM、CTM、仿真或神经模型来估计 |
因此，工程原语不是：
| 它不是什么 | 为什么不符合定义 |
|---|---|
| API 端点 | API 暴露的是执行接口，而非工程语义 |
| 软件函数 | 函数与技术绑定；原语与技术无关 |
| 工作流节点 | 工作流节点描述流程步骤，而非工程含义 |
| LLM 提示词 | 提示词是自然语言指令，而非结构化能力 |
| 数据库表 | 表存储数据；原语通过计算产生证据 |
相反，原语是一种抽象工程能力，它独立于任何实现技术而存在。这一区别可以可视化为一个分层架构：
┌─────────────────────────────────────────────┐
│ 第一层：工程责任 │
│ "优化交叉口 A 的信号配时" │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 第二层：工程问题 │
│ "东进口排队为什么在增长？" │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 第三层：工程原语 │
│ 排队长度 ◄── 语义构建块 │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 第四层：计算算子 │
│ CTM / SUMO / 神经模型 / 检测器统计 │
└─────────────────────────────────────────────┘
原语充当了工程推理（第一至三层）与计算执行（第四层）之间的语义边界。边界之上，一切用工程语言表达；边界之下，一切用计算术语表达。
6.3 原语是语义的，不是算法的
考虑排队长度这一工程概念——车辆沿道路进口排队的物理范围。排队长度可以用许多不同的计算方法来估计：
| 方法 | 类别 | 数据需求 | 精度特征 |
|---|---|---|---|
| 元胞传输模型（CTM） | 分析/运动学方法 | 流量-密度基本关系、边界条件 | 适用于高速公路，对信号控制有限 |
| 微观仿真（SUMO/VISSIM） | 仿真方法 | 完整路网几何、驾驶行为模型 | 高保真，计算成本高 |
| 视频 AI 分析 | 计算机视觉 | CCTV 视频流、标定好的摄像头 | 直接观测，受天气影响 |
| 环形检测器统计 | 经验方法 | 占有率时间、车辆长度假设 | 近似值，部署广泛 |
| 雷达检测 | 传感方法 | 点测量、分类 | 实时，空间覆盖有限 |
| 神经交通基础模型 | 数据驱动 | 轨迹数据、在大规模语料上训练 | 新兴技术，潜在高精度 |
尽管这些方法采用了完全不同的计算机制，具有不同的数据需求、精度特征和计算成本，它们产生的工程含义完全相同：排队长度。
因此：
- 排队长度是一个工程原语——它代表一个稳定的工程概念。
- CTM、SUMO、视频 AI 等仅仅是能够实现该原语的不同算子。
这种分离使 TAE 能够独立于实现技术而演进。未来还会出现新的算法——神经基础模型、物理信息神经网络、混合仿真学习系统——但排队长度的工程概念将保持不变。改变的只是算子的选择。
6.4 原语规范——交通原语规范（TPS）
每个工程原语必须暴露一个标准的语义接口，完整描述其工程属性。这一规范称为交通原语规范（Traffic Primitive Specification, TPS）。与描述函数签名的 API 规范不同，TPS 描述的是推理接口——该原语建立何种工程含义、在何种条件下、产生何种证据贡献、以及通过哪些执行选项。
一个原语的完整规范包含以下字段：
┌─────────────────────────────────────────────────────────────┐
│ 交 通 原 语 规 范 │
│ │
│ 原语身份 │
│ ├── id: 全局唯一标识符 │
│ ├── name: 人类可读名称 │
│ ├── version: 语义版本号 │
│ └── category: 分类（观测 / 分析 / 评估 / 决策） │
│ │
│ 语义 │
│ ├── meaning: 该原语代表什么工程概念？ │
│ ├── role: 观测 / 诊断 / 评估 / 规范 │
│ ├── dimension: 拥堵 / 安全 / 效率 / ... │
│ └── reasoning_contribution: 如何支持高层推断？ │
│ │
│ 接口 │
│ ├── inputs: 所需的工程实体 │
│ ├── outputs: 产生的工程量 │
│ └── evidence: 可得出什么工程结论？ │
│ │
│ 约束 │
│ ├── preconditions: 执行前必须满足的条件 │
│ ├── applicability: 该原语何时有效？ │
│ └── limitations: 已知的失效模式 │
│ │
│ 执行 │
│ ├── operators: 可用的计算实现 │
│ ├── default_operator: 推荐默认选项 │
│ └── cost_profile: 计算资源需求 │
│ │
│ 质量 │
│ ├── accuracy: 预期误差界 │
│ ├── confidence: 输出不确定性表征 │
│ ├── latency: 执行时间范围 │
│ └── interpretability: 结果是否可解释？ │
│ │
└─────────────────────────────────────────────────────────────┘
规划器不会问：”我应该调用哪个 API？”而是问：”在我当前的约束和质量要求下，哪个工程原语能建立我需要的证据？”
6.5 原语是证据导向的
工程推理从根本上由证据驱动。每个结论都必须由可测量、可验证的数据支撑。因此，每个原语必须明确声明：它能建立哪些工程证据？
这个证据契约可能是 TPS 中最重要的单个字段。考虑常见原语如何映射到它们的证据贡献：
| 原语 | 建立的证据 | 支持哪种推理 |
|---|---|---|
| 排队长度 | 等候车辆的物理范围 | 拥堵诊断、溢流检测、存储风险评估 |
| 延误 | 出行者的时间损失 | LOS 评估、服务质量评价、效率度量 |
| 饱和度（v/c） | 需求与通行能力的比值 | 过饱和识别、瓶颈定位、配时充足性判断 |
| 服务水平（LOS） | 标准化性能等级（A–F） | 性能报告、合规评估、公众沟通 |
| 绿波带宽 | 车队移动的时间窗口 | 协调评价、相位差优化、走廊评估 |
| 停车率 | 必须停车的车辆比例 | 油耗/排放估算、用户体验、干线分类 |
| 事故潜力 | 冲突点实际化的可能性 | 安全评价、对策优先级排序、设计审查 |
一个原语之所以有价值，不是因为它执行了计算，而是因为它为工程推理贡献了证据。同一次排队长度测量在不同推理语境中意味着完全不同的事情：支持拥堵诊断时（排队是否异常？），支持几何 adequacy 判断时（排队能否装得下？），还是支持运营评价时（配时是否有效？）。原语产出数字；推理语境决定其意义。
6.6 原语是可复用的
工程原语最强大的属性之一是跨责任复用。单个原语应当参与许多不同的工程责任，正如单个单词出现在许多不同的句子中。
考虑朴素的排队长度原语。它可以出现在：
| 工程责任 | 排队长度的角色 |
|---|---|
| 诊断拥堵 | 主要指标：排队是否异常偏长？ |
| 优化信号配时 | 优化目标：最小化最大排队 |
| 评估几何 adequacy | 约束检查：排队是否超过存储容量？ |
| 评估安全风险 | 视距和冲突分析的输入 |
| 审查合规性 | LOS 判定和文档编制的证据 |
| 设计施工区 TMP | 排队管理策略的依据 |
| 验证仿真模型 | 校准目标：仿真排队是否与观测一致？ |
底层计算——估计排队长度——在所有这些语境中是完全相同的。唯一变化的是推理语境。 在诊断中，排队长度是假设形成的输入。在优化中，它是待最小化的目标。在合规审查中，它是正式判定的证据。
这种可复用性对系统架构有着深远影响：
| 无原语（传统方式） | 有原语（TAE 方式） |
|---|---|
| 排队逻辑在 7+ 个模块中重复 | 单一排队长度原语，处处复用 |
| 每个模块各自实现排队估计 | 一个原语，多个算子 |
| 各系统间排队定义不一致 | 由 TPS 强制规范的标准语义 |
| 更新排队方法需修改 N 个文件 | 只需更新一次算子绑定 |
工程知识因此通过原语实现复用，而非在软件模块间重复。
6.7 原语是可组合的
单个原语提供孤立的工程证据片段。真实的工程结论需要将多个原语组合成连贯的推断结构。组合因而成为简单原语产生复杂工程智能的机制。
考虑原语如何组合以建立越来越复杂的结论：
简单组合——直接依赖：
需求（辆/小时）
↓ + 通行能力（辆/小时）
饱和度（v/c 比）
中等组合——多步推断：
排队长度（米）
↓ + 存储长度（米）
存储利用率（比值）
↓ + 溢流标志（布尔值）
阻塞判定（结论）
复杂组合——完整的工程论证：
转向运动计数
↓ + 信号配时方案
↓ + 几何数据
↓
[并行:]
├──→ 饱和度 ──→ 是否过饱和？
├──→ 排队长度 ──→ 是否溢流？
├──→ 延误（HCM）──→ LOS 等级？
└──→ 协调分析 ──→ 协调质量如何？
↓
[综合:]
交叉口整体性能评估
↓
建议（附论证依据）
组合结构类似于自然语言：
| 层次 | 类比 | TAE 对应物 |
|---|---|---|
| 单词 | 单一意义单元 | 单个原语（排队、延误、通行能力） |
| 句子 | 按语法组合的单词 | 原语组合链（需求 → v/c → 饱和度） |
| 段落 | 围绕主题组织的句子 | 回答某一问题的推理子图 |
| 文档 | 组成完整工作的段落 | 产出工程产物的完整推理图 |
组合因此成为工程智能的基础。TAE 的表达力并非来自单个原语（它们有意设计得小而简单），而是来自它们几乎无限的组合方式。
6.8 原语是与技术无关的
工程原语或许最具战略重要性的属性是技术存活性——当底层计算技术演进时，原语仍然有效的能力。
考虑一段具体的历史轨迹：
| 年代 | 排队长度的计算方式 | 技术栈 |
|---|---|---|
| 1990 年代 | 人工现场测量 + 电子表格 | 纸质表格、Excel |
| 2000 年代 | 环形检测器占有率 × 有效车辆长度 | 感应线圈、SCADA 系统 |
| 2010 年代 | 微观仿真输出提取 | VISSIM、CORSIM、PARAMICS |
| 2020 年代 | CCTV 视频流的计算机视觉 | 深度学习、GPU 加速 |
| 2025 年以后 | 来自轨迹数据的神经交通基础模型 | Transformer 架构、大规模训练语料 |
在这三十年的演进过程中，排队长度的工程概念完全没有改变。发生变化的只是算子——用于估计它的计算机制。
在 TAE 中，这种演进被透明地处理：
2020 年：
原语：排队长度 → 算子：VideoAI_QueueEstimator(v2.3)
2025 年：
原语：排队长度 → 算子：NeuralTraffic_FoundationModel(v1.0)
发生了什么变化：
✗ 算子：VideoAI → 神经基础模型
✓ 原语：排队长度（不变）
✓ 推理图：不变（仍需要排队长度）
✓ 工程责任：不变（仍在诊断拥堵）
✓ 产物格式：不变（仍以米为单位报告排队）
因此，工程知识独立于计算技术。TAE 明确地将工程语义（”排队长度”的含义）与算法实现（如何计算它）分离开来。这种分离是架构基础，使得 TAE 系统能够随着更好的算法出现而持续改进，且无需修改任何工程规范、推理过程或产物格式。
6.9 原语是工程智能的指令集
工程原语与交通智能体工程之间的关系，类似于机器指令与计算机处理器之间的关系：
| 维度 | 计算机处理器 | 交通智能体运行时 |
|---|---|---|
| 基本单元 | 机器指令（ADD、MOV、JMP） | 工程原语（排队、延误、通行能力） |
| 指令集 | ISA（x86、ARM、RISC-V） | 原语库（TPS 目录） |
| 程序 | 指令序列 | 推理图（组合后的原语） |
| 编译器 | 将高级代码翻译为指令 | 领域推理编译器（IR → 原语图） |
| 执行器 | CPU 流水线 | 交通智能体运行时 |
| 输出 | 计算结果 | 工程产物 |
这个类比揭示了一个重要的设计原则：
处理器不能执行任意的人类语言。它执行的是一个有限的、定义良好的指令集。
同样，推理引擎也不应执行任意的提示词或非结构化查询。它应该执行一个有限的、定义良好的工程原语集合。
这一约束不是局限——它是工程可编程性的赋能者。正如有限指令集通过组合实现任意计算一样，有限的原语库通过组合实现任意工程推理。原语库成为工程智能的指令集架构（ISA）。
原语库的大小因此成为一个关键的设计参数：
| 库规模 | 特征 | 权衡 |
|---|---|---|
| 过小（< 50 个原语） | 表达力不足；许多责任无法表达 | 无法处理复杂工程任务 |
| 最优（~100–300 个原语） | 覆盖核心交通工程领域；可通过组合处理复杂任务 | 覆盖性与可管理性的平衡 |
| 过大（> 1000 个原语） | 冗余、不一致、维护负担 | 收益递减，可能造成混淆 |
基于我们对交通运输工程实践的分析，我们估计完整的交通工程领域大约需要 150–200 个核心原语即可覆盖信号控制、高速公路运营、安全分析、规划及相关学科——这是一个可控的数量，可以被系统地规范化、实现、验证和维护。
6.10 从原语到原语图
工程原语被有意设计得很小。就个体而言，每个原语只提供单一的孤立工程证据片段——一个数字、一个布尔值、一个分类。只有当大量原语通过数据流依赖和逻辑关系相互连接时，真正的工程推理才会涌现。
这些连接的组织形式产生了原语图（Primitive Graph）——一个有向图，其中：
- 节点是绑定了具体输入和算子选择的原语实例。
- 边代表数据流（一个原语的输出作为另一个原语的输入）。
- 结构源自推理规划器产生的推理图（第五章）。
从推理图到原语图的转换由领域推理编译器负责，我们将在第八章详细讨论。目前的关键洞察是：
推理图（抽象） 原语图（具体）
┌─────────────────────┐ ┌─────────────────────┐
│ "验证需求 │ │ ReadDetector() │
│ 是否超过通行能力" │──► 绑定 ►──│ → ComputeVCRatio() │
│ │ │ → CompareToThreshold()│
└─────────────────────┘ └─────────────────────┘
抽象问题 具体的可执行操作
工程师的心智模型 运行时可调用的计算
下一章将介绍原语之间如何连接、依赖如何解析，以及可执行的推理图如何从原语组合中自动构建。
第二部分：交通原语规范（TPS）详解
以下各节（6.11–6.20）对交通原语规范的每个字段进行详细考察，并辅以来自交通工程实践的具体示例。
6.11 概述：TPS 作为语义契约
交通原语规范充当 TAE 架构中两个组件之间的语义契约：
- 推理规划器（消费者）：根据证据需求和推理语境选择原语。
- 交通智能体运行时（提供者）：通过选择适当的算子和管理计算来执行原语。
这份契约必须足够精确，使规划器能够对使用哪些原语做出明智决策；同时又要足够灵活，使运行时能够在不违反工程语义的前提下优化执行。
6.12 原语身份
每个原语必须拥有一个全局唯一标识符，该标识符编码其工程含义——而非其实现技术。我们采用层次化命名约定：
| 标识符 | 含义 | 类别 |
|---|---|---|
traffic.queue.length | 交通流的物理排队长度 | 观测 |
traffic.delay.hcm | HCM 方法的控制延误 | 评估 |
traffic.capacity.lane | 车道级通行能力估计 | 分析 |
traffic.signal.split | 各流向的绿信比分配 | 参数 |
traffic.offset.greenband | 绿波带宽 / 相位差 | 协调 |
traffic.storage.available | 有效存储长度 vs 排队 | 几何 |
traffic.saturation.degree | 流量通行能力比（v/c） | 诊断 |
traffic.los.grade | 服务水平分类（A–F） | 评估 |
traffic.crash.conflict | 冲突点分析结果 | 安全 |
traffic.emission.factor | 单车排放率 | 环境 |
标识符使用工程术语，而非实现名称。标识符 CTMQueueCalculator 是不恰当的，因为 CTM 仅仅是估计排队长度的一种可能的算子。无论运行时选择 CTM、SUMO、视频 AI、检测器统计还是某种尚未发明的未来量子计算算子，标识符 traffic.queue.length 始终有效。
6.13 原语语义
每个原语必须回答一个根本性问题：该原语建立什么工程含义？ 语义部分通过四个字段来捕捉这一点：
示例：traffic.queue.length
| 字段 | 值 | 说明 |
|---|---|---|
| meaning | 估计指定时间段内某交通流的物理排队长度（米或辆），从停车线到最后一辆排队车辆的位置 | 该原语实际上测量什么？ |
| role | 观测型原语 | 它是观察现实、诊断问题、评估性能还是规定行动？ |
| dimension | 拥堵 / 空间 | 它涉及哪个工程维度？ |
| reasoning_contribution | 为排队范围提供定量证据，支持溢流检测、存储利用率评估和拥堵严重程度量化 | 它如何支持更高层次的推断？ |
请注意，语义中没有任何内容提及 CTM、SUMO、环形检测器或任何具体实现。语义始终与技术无关。 原语定义建立了什么工程含义；算子定义如何计算它。
6.14 原语输入和输出
与描述软件对象（JSON 载荷、数据库记录、类实例）的 API 规范不同，原语 I/O 描述的是工程实体：
traffic.queue.length 的示例输入：
| 输入实体 | 类型 | 描述 |
|---|---|---|
| LaneState | 结构化 | 当前车道配置（车道数、车道类型、几何） |
| SignalTiming | 结构化 | 当前信号配时方案（周期、绿信比、相位差） |
| ArrivalFlow | 时间序列 | 车辆到达模式（每时间间隔车辆数） |
| TurningRatio | 分布 | 直行/左转/右转比例 |
示例输出：
| 输出实体 | 类型 | 单位 |
|---|---|---|
| QueueLength | 标量 | 米或辆 |
| QueueGrowthRate | 标量 | 米/分钟 或 辆/小时 |
| StorageUtilization | 比值 | queue_length / storage_length（0–1+） |
规划器完全以工程概念进行推理——车道状态、到达流量、转向比——而不是 HTTP 端点或函数签名之类的编程接口。这种以工程为中心的词汇确保推理过程扎根于领域概念，而非实现细节。
6.15 原语证据契约
证据契约声明一个原语可以支持哪些工程结论。这是推理规划器在确定给定推理步骤调用哪些原语时所查阅的字段。
示例证据契约：
| 原语 | 支持的证据结论 |
|---|---|
traffic.queue.length | 是否存在拥堵？是否发生溢流？是否超过存储容量？排队是在增长还是在消散？ |
traffic.delay.hcm | 服务是否可接受？能否确定 LOS 等级？用户体验是否下降？能否进行效率比较？ |
traffic.capacity.lane | 需求与供给是否平衡？是否发生过饱和？配时是否充足？是否存在储备通行能力？ |
traffic.saturation.degree | 哪些流向是关键流向？瓶颈在哪里？需求是否接近通行能力？ |
traffic.los.grade | 性能是否可报告？标准是否达标？是否适合公众沟通？合规性是否已记录？ |
该契约使得证据驱动的原语搜索成为可能：给定一个推理目标（”我需要判断是否发生了溢流”），规划器在原语库中搜索证据契约包含溢流检测的原语，而不是搜索名为”溢流检测器”的算法。
6.16 原语约束
工程计算从来不是无条件的。每个原语都在一个有限的有效性区域内运作。约束字段规定：
| 约束类型 | 排队长度的示例 | 目的 |
|---|---|---|
| 前置条件 | 检测器覆盖 > 进口长度 80%；有效的车道拓扑数据可用 | 确保有意义的计算可行 |
| 适用性 | 信号控制交叉口进口；不适用于环岛或无信号交叉口 | 定义有效性域 |
| 局限性 | 排队 < 15m 时精度下降（检测器分辨率限制）；无法检测超出最下游检测器的排队 | 记录已知失效模式 |
| 数据时效性 | 实时场景需最近 15 分钟内的检测器数据；离线分析可接受历史计数 | 确保时间相关性 |
这些约束成为推理图的组成部分。如果某个约束无法满足（例如目标进口没有检测器覆盖），规划器必须要么选择替代原语，要么请求补充数据采集，要么在最终产物中标注该局限性。
6.17 原语算子
每个原语可以暴露多个算子——实现相同工程语义但具有不同权衡的替代计算实现：
traffic.queue.length 的算子示例：
| 算子 | 类型 | 数据需求 | 精度 | 延迟 | 成本 |
|---|---|---|---|---|---|
CTM_QueueOperator | 分析/运动学 | 流量-密度基本关系、边界条件 | 中等 | 低 | 很低 |
SUMO_QueueOperator | 仿真 | 完整路网几何、跟驰参数 | 高 | 高 | 高 |
NeuralQueueOperator | 数据驱动/ML | 轨迹数据或检测器历史 | 高（若经过良好训练） | 中等 | 中等 |
VideoAI_QueueOperator | 计算机视觉 | CCTV 视频流、摄像头标定 | 高 | 中等 | 中等 |
DetectorStats_Operator | 经验 | 环形检测器占有率、车辆长度 | 低–中等 | 很低 | 很低 |
关键设计原则：规划器永远不选择算子。运行时来做。
规划器规定需要什么工程含义（即原语）。运行时根据数据可用性、计算预算、精度要求和实时约束来确定如何计算它（即算子选择）。这种分离确保即使执行策略不断演变，推理仍保持稳定。
6.18 原语质量
并非每个算子都产生相同质量的输出。质量字段从多个维度刻画每个算子的预期表现：
| 质量维度 | 描述 | 对调度的影响 |
|---|---|---|
| 精度 | 预期误差界（±米、±秒、±%） | 决定是否适用于高风险决策 |
| 置信度 | 不确定性表征（点估计 vs 分布 vs 区间） | 决定是否需要额外验证 |
| 延迟 | 执行时间（毫秒到小时） | 决定实时应用的可行性 |
| 可解释性 | 结果能否用工程术语解释？ | 决定监管产物的可接受性 |
| 计算成本 | CPU、内存、GPU 需求 | 决定资源分配策略 |
运行时调度因此成为一个多目标优化问题：给定一个含多个节点的原语图，每个节点提供多种算子选择，在时间、资源和精度的约束下，选择使整体质量最大化的组合。这与传统的函数调用有着本质区别——后者只是以固定参数调用单一实现。
6.19 完整原语示例
排队长度原语的完整 TPS 规范展示了所有字段如何协同工作：
Primitive:
id: traffic.queue.length
version: "1.0"
category: Observation
Semantics:
meaning: >
估计指定分析时段内某交通流的物理排队长度（米或辆），
测量范围为从停车线到最后一辆排队车辆的位置。
role: Observation Primitive
dimension: [Congestion, Spatial]
reasoning_contribution: >
为拥堵诊断、溢流检测、存储利用率评估和配时
效果评价提供主要的定量证据。
Interface:
inputs:
- entity: LaneState
description: 进口车道配置和几何
- entity: SignalTiming
description: 当前信号配时参数
- entity: ArrivalFlow
description: 车辆到达时间序列
outputs:
- entity: QueueLength
unit: meters
- entity: StorageUtilization
unit: ratio (0.0–∞)
evidence:
- CongestionSeverity
- SpillbackOccurrence
- StorageRisk
- QueueTrend
Constraints:
preconditions:
- 检测器覆盖 >= 进口长度 80%
- 世界上下文中存在有效的车道拓扑
applicability:
- 信号控制交叉口进口
- 不适用于环岛或无信号交叉路口
limitations:
- 最小可检测排队：约 15 米（检测器分辨率）
- 无法检测延伸至最下游检测器之外的排队
Operators:
- name: CTM_QueueOperator
type: analytical
default: true
- name: SUMO_QueueOperator
type: simulation
- name: NeuralQueueOperator
type: ml
- name: VideoAI_QueueOperator
type: vision
- name: DetectorStats_Operator
type: empirical
Quality:
accuracy:
CTM: ±10-20%
SUMO: ±5-10%
Neural: ±3-8%（校准良好时）
confidence: dynamic（取决于数据质量）
latency:
CTM: <100ms
SUMO: 30min-2hours
Neural: <1s
interpretability: high（所有算子产生可解释指标）
请注意关键属性：整个规范中没有出现任何实现代码。 TPS 描述的是工程含义，而非软件实现。每个算子的实际代码驻留在运行时的原语库中，与语义规范分离。
6.20 原语是工程智能的词汇
人类工程师通过工程术语彼此交流——一套由精确定义的概念（LOS、v/c、周期、相位差、协调、饱和度）构成的共享词汇表。当一位工程师说“东进口左转的 v/c 比超过了 0.95”时，另一位工程师立刻理解其中的工程意义。
推理规划器通过工程原语与运行时交流——一套由精确定义的、可执行的概念构成的共享词汇表。当规划器请求 traffic.saturation.degree 时，运行时立即理解必须产出什么工程含义。
类比自然延伸：
| 人类交流 | TAE 交流 |
|---|---|
| 单词 = 工程术语 | 原语 = 可执行的工程概念 |
| 句子 = 有据陈述 | 组合 = 产生证据的原语链 |
| 段落 = 连贯论证 | 子图 = 回答某一问题的推理簇 |
| 文档 = 完整工程工作 | 推理图 = 产出产物的完整过程 |
| 语言 = 共享词汇 | 原语库 = 共享指令集 |
交通智能体工程因此引入了一种新的编程抽象：
与其编程算法，不如编程工程语义。
原语规范成为可执行工程智能的词汇表——一个有限的、定义良好的、可组合的概念集合，任何交通工程推理任务均可从中构建。下一章将介绍这些原语如何连接形成可执行的推理图——原语图——以及领域推理编译器如何自动化从抽象工程问题到具体原语组合的转化。
本章小结
第六章介绍了工程原语——TAE 中可执行工程含义的最小单元。主要贡献包括：
- 为什么原语很重要：工程师以概念思考（排队、延误、通行能力），而非算法（韦伯斯特、CTM、SUMO）。原语捕捉了概念词汇表。
- 正式定义：原语是可复用的最小工程语义执行单元——单一概念、推理独立、算子可执行。
- 语义 ≠ 算法：排队长度是原语；CTM/SUMO/视频 AI 只是实现它的算子。同一含义，不同计算。
- TPS 规范：涵盖身份、语义、接口、约束、执行和质量的九字段规范。
- 证据导向：每个原语声明它能建立哪些工程证据——规划器的主要搜索准则。
- 可复用 & 可组合：一个原语服务多项责任（复用）；原语组合成复杂推理链（组合）。
- 与技术无关：原语在算法演进中存活——1990 年、2020 年和 2030 年的排队长度含义相同。
- 指令集类比：原语之于 TAE 犹如机器指令之于 CPU——工程智能的 ISA（全领域覆盖约 150–200 个原语）。
- 完整示例：
traffic.queue.length的完整 TPS 规范展示所有字段。 - 词汇隐喻：原语是单词；组合是句子；推理图是段落；产物是文档。
- 下一步：原语连接形成原语图（第七章）——通过组合的原语依赖实现可执行推理。