第十八章：交通智能体运行时——执行工程推理
18.1 从编译到执行
领域推理编译器（第十一章和第十六章）将工程责任转化为原语依赖图。领域原语库（第十七章）提供构建模块。但编译后的 PDG 只是一个计划——关于应该计算什么、以什么顺序、具有什么依赖关系的静态规范。
交通智能体运行时（Traffic Agent Runtime, TAR）是执行该计划的引擎。它接收 DRC 产生的 PDG 并运行它：按正确顺序调用原语、在它们之间传递数据、处理错误、管理状态、收集证据并产生交付物。
如果 DRC 是编译器，那么 TAR 就是虚拟机——赋予编译后的工程推理生命的运行时环境。
TAR 本身不进行任何计算。它编排计算。每一项工程计算都在原语内部发生（第十七章）。TAR 的任务是确保这些原语正确执行，以正确的顺序、使用正确的数据，并产生可审计的结果。
本章详细阐述交通智能体运行时的架构、机制和操作特征。
18.2 运行时架构概览
18.2.1 分层架构
TAR 实现分层架构，在每一层分离关注点：
┌─────────────────────────────────────────────┐
│ 应用层 │
│ （用户界面 / API 网关） │
├─────────────────────────────────────────────┤
│ 编排层 │
│ （执行引擎 / 调度器 / 监控器） │
├───────────────────┬─────────────────────────┤
│ 原语 │ 验证 │
│ 执行 │ 引擎 │
│ 容器 │ │
├───────────────────┴─────────────────────────┤
│ 状态管理层 │
│ （工作内存 / 证据存储 / 缓存） │
├─────────────────────────────────────────────┤
│ 集成层 │
│ （数据源 / 模拟器 / 外部 API） │
└─────────────────────────────────────────────┘
每层具有不同的职责：
| 层 | 职责 | 关键组件 |
|---|---|---|
| 应用层 | 接收请求、返回结果 | REST API、WebSocket、CLI |
| 编排层 | 执行 PDG、管理工作流 | 调度器、执行器、监控器 |
| 原语执行层 | 运行单个原语 | 容器、沙箱、资源管理器 |
| 验证层 | 强制执行验证规则 | 前检器、后检器、交叉验证器 |
| 状态管理层 | 维护执行状态 | 工作内存、证据存储、缓存 |
| 集成层 | 连接外部系统 | 数据适配器、模拟器封装、API 客户端 |
18.2.2 核心组件
TAR 由六个协同工作的核心组件组成：
| 组件 | 角色 | 接口 |
|---|---|---|
| 图执行器 | 遍历 PDG 并分派原语调用 | execute(PDG) -> ExecutionResult |
| 原语调用器 | 调用单个原语实现 | invoke(PrimitiveSpec, Inputs) -> Output |
| 数据管理器 | 在原语之间路由数据、管理类型 | get(node_id) -> TypedValue、put(node_id, value) |
| 验证引擎 | 对原语结果运行前/后验证检查 | validate(primitive, result) -> ValidationResult |
| 证据收集器 | 在整个执行过程中捕获来源元数据 | record(event) -> EvidenceEntry |
| 错误处理器 | 检测、分类并从错误中恢复 | handle(error) -> RecoveryAction |
这些组件通过明确定义的接口交互，使每个组件能够独立测试、替换和演进。
18.3 执行模型
18.3.1 依赖驱动的遍历
TAR 按依赖而非按顺序执行 PDG：一个节点只要它所依赖的东西都产出了值，它就可以运行。没有一份主调度表要遵循，也没有固定次序被焊死在图里。
因此执行是一个形状很简单的循环：
- 播种就绪集。 没有任何未满足依赖的节点，一开始就是可运行的。
- 派发。 每个可运行节点从工作状态中汇齐输入，调用它的原语，产出要么是一个值，要么是一次失败。
- 记录。 成功的结果写入该节点并记入证据日志；它的下游被重新检查，可能随之变为可运行。
- 就地处理失败。 失败的节点按其类别被重试、跳过或上报——能被一个有据可依的默认值满足的节点不会让整张图停下，而交付物确实倚重的节点会让它停下。
- 组装。 当再没有可运行的节点时，从已完成的节点组装出交付物，并封存证据日志。
对工程师有意义的几条性质，是这个形状的推论，而不是外挂上去的功能：
- 数据驱动。 节点在输入就绪时运行，而不是在调度器轮到它时运行。
- 可并行。 就绪集中的每个节点都可以并发执行。
- 容错。 失败被限制在出错的节点上；图是继续还是停下，是刻意的结果，不是碰巧。
- 可追溯。 每一次操作都落在证据日志里，并按发生的先后排列。
18.3.2 执行策略
TAR 根据 PDG 的性质支持多种执行策略：
| 策略 | 使用时机 | 特征 |
|---|---|---|
| 顺序执行 | 小型图（<10 个节点）、需要严格排序 | 简单、可预测、易于调试 |
| 并行执行 | 具有多个独立子图的大型图 | 更快利用率、需要线程安全的状态管理 |
| 流式处理 | 持续/实时任务伴随持续数据到达 | 数据到达即处理、无界执行时间 |
| 增量执行 | 部分输入变更后的重新执行 | 仅重新执行受影响的子图、缓存未变更的结果 |
策略选择可以是自动的（基于图的规模和结构）或显式的（由工程师或系统配置指定）。
18.3.3 调度与优先级
当多个节点同时就绪时，调度器基于以下因素决定执行顺序：
| 优先级因素 | 理由 | 示例 |
|---|---|---|
| 关键路径长度 | 最长路径上的节点应先开始 | 延误计算前先算饱和流率 |
| 下游扇出数 | 高扇出节点馈送更多依赖者 | 流量提取优先于其他一切 |
| 资源需求 | 重计算安排在低负载期间 | 模拟运行安排在夜间 |
| 用户优先级 | 工程师标记的关键步骤 | 关键分析的手动覆盖 |
| 历史持续时间 | 过去执行时间预测未来需求 | 已知慢速原语获得更早时段 |
调度器使用这些因素的加权组合生成优先化执行顺序，在尊重所有依赖的同时最小化总完成时间。
18.4 原语调用机制
18.4.1 调用生命周期
每个原语调用遵循严格的生命周期：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 解析 │ → │ 准备 │ → │ 执行 │ → │ 验证 │ → │ 存储 │
│ │ │ │ │ │ │ │ │ │
│ 查找实现 │ │ 收集输入 │ │ 运行算法 │ │ 检查结果 │ │ 缓存输出 │
│ 加载代码 │ │ 类型检查 │ │ 计算 │ │ │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
实现查找 类型强制转换 沙箱执行 错误/警告生成 来源元数据附加
18.4.2 解析：找到正确的实现
单个原语规范可能有多种实现：
primitive: CalculateSaturationFlowRate
implementations:
- id: hcm_default
type: builtin
language: python
source: "tae_primitives/hcm/saturation_flow.py"
priority: 100
- id: field_measurement
type: external
language: python
source: "agency_modules/field_sfr.py"
trigger: "sufficient_detector_data"
priority: 90
- id: local_regression
type: external
language: R
source: "agency_models/sfr_regression.R"
trigger: "local_calibration_available"
priority: 80
解析器基于以下因素选择最佳实现：
- 触发条件：所需的数据/方法是否可用？
- 优先级排名：当多个符合条件时，选择最高优先级
- 用户偏好：显式选择覆盖自动解析
- 历史性能：历史成功率影响未来选择
18.4.3 准备：输入收集与类型检查
执行前，TAR 执行以下操作：
准备清单：
□ 所有必需输入是否存在？→ 缺失则报错
□ 可选输入是否已应用默认值？→ 应用指定的默认值
□ 类型是否匹配规范？→ 若兼容则尝试强制转换
□ 假设是否满足？→ 若违反则标记警告
□ 约束是否已传播？→ 将下游约束传递给输入验证器
□ 资源是否可用？→ 检查内存、许可证、外部服务可用性
此处的任何失败都会产生预执行错误，阻止原语使用错误的输入运行——这与”垃圾进，垃圾出”的方法有根本区别。
18.4.4 执行：沙箱计算
原语在沙箱环境中执行，提供以下功能：
| 沙箱功能 | 目的 | 实现 |
|---|---|---|
| 资源限制 | 防止失控计算 | CPU 时间限制、内存上限 |
| 网络隔离 | 控制外部访问 | 仅允许白名单端点 |
| 文件系统隔离 | 保护主机系统 | 仅限临时目录 |
| 超时强制执行 | 保证响应性 | 每个原语超时（可配置） |
| 日志捕获 | 确保完整审计轨迹 | stdout/stderr 捕获至证据存储 |
沙箱确保有缺陷或恶意的原语无法危及 TAR 或主机系统——当原语由第三方贡献时（第 17.9.3 节），这是一个关键属性。
18.4.5 后执行：验证与存储
执行完成后：
- 验证引擎运行原语规范中定义的所有后检（范围检查、合理性检查、一致性检查）
- 结果被类型化，按照输出规范（
Derived(T)、Estimated(T)等） - 附加来源元数据（时间戳、使用的实现、输入哈希、持续时间、资源使用情况）
- 结果存储在工作内存中，按节点 ID 索引供下游消费
- 通知依赖方其输入已就绪
18.5 状态管理
18.5.1 工作内存模型
TAR 维护一个工作内存，保存执行过程中的所有中间和最终结果：
WorkingMemory {
nodes: Map<NodeID, TypedValue>,
metadata: Map<NodeID, ProvenanceRecord>,
status: Map<NodeID, NodeStatus>, // pending/running/completed/failed/skipped
dependencies: DependencyGraph,
execution_log: EventLog[]
}
关键设计决策：
| 决策 | 理由 |
|---|---|
| 不可变结果 | 一旦节点完成，其输出不可修改（防止微妙 bug） |
| 类型化存储 | 值在整个执行过程中携带类型；类型不匹配在消费时捕获 |
| 惰性求值 | 结果仅在首次被依赖方请求时计算（适用于昂贵操作） |
| 急切缓存 | 常用值在首次计算后缓存 |
| 自动清理 | 不再需要的中间值释放（内存管理） |
18.5.2 证据收集
执行期间的每个事件都记录在证据存储中：
| 事件类型 | 记录的数据 | 保留策略 |
|---|---|---|
PRIMITIVE_INVOKED | 节点 ID、输入哈希、时间戳、实现 ID | 完整保留 |
PRIMITIVE_COMPLETED | 输出、持续时间、资源使用、验证结果 | 完整保留 |
PRIMITIVE_FAILED | 错误类型、消息、部分输出（如有）、堆栈跟踪 | 完整保留 |
VALIDATION_CHECK | 检查名称、条件、结果（通过/失败/警告/错误） | 完整保留 |
DATA_ACCESSED | 来源、查询、返回记录、时间戳 | 摘要（按需完整保留） |
DECISION_MADE | 决策点、考虑的选项、做出的选择、理由 | 完整保留 |
STATE_SNAPSHOT | 检查点的完整工作内存 | 可配置（默认仅里程碑） |
该证据存储是以下功能的基础：
- 可解释性：”我们为什么得到这个答案？”→ 通过证据追踪
- 可审计性：”这个分析做得正确吗？”→ 审查证据链
- 可复现性：”我们能再次得到相同结果吗？”→ 从证据日志回放
- 调试：”哪里出了问题？”→ 检查失败事件
18.5.3 检查点与恢复
对于长时间运行的执行（大型网络研究、重度模拟分析），TAR 支持检查点机制：
检查点触发条件：
✓ 每 N 个原语完成后（默认：N=10）
✓ 昂贵操作之前（模拟运行、外部 API 调用）
✓ 用户显式请求时
✓ 在预定义里程碑节点处（例如：LOS 评估之后）
检查点内容：
✓ 完整的工作内存快照
✓ PDG 中的执行位置（哪些节点已完成、哪些待处理）
✓ 至检查点时间的证据日志
✓ 系统状态（资源使用、时间戳）
恢复过程：
1. 加载最近的检查点
2. 验证完整性（哈希比较）
3. 从检查点位置恢复执行
4. 将新事件追加到现有证据日志
检查点机制实现了对系统故障的韧性，使长时间运行的任务能够在崩溃、更新和维护窗口中幸存而不丢失工作成果。
18.6 错误处理与容错
18.6.1 错误分类
TAR 区分几类错误，每类有不同的处理策略：
| 错误类别 | 示例 | 严重程度 | 默认处理 |
|---|---|---|---|
| 输入缺失 | 所需流量数据不可用 | 错误 | 向用户请求；阻塞依赖节点 |
| 类型不匹配 | 期望数字却传入字符串 | 错误 | 尝试强制转换；若不可能则失败 |
| 约束违反 | 计算的周期时长超过最大值 | 警告 + 标记 | 记录违反；带警告继续 |
| 资源耗尽 | 模拟期间内存不足 | 错误 | 释放资源；缩小范围重试 |
| 外部故障 | 模拟器服务不可用 | 可重试 | 指数退避；回退方法 |
| 超时 | 原语超过时间限制 | 错误 | 终止；报告部分结果 |
| 验证失败 | 后检检测到无效输出 | 错误 | 不传播；标记节点失败 |
| 断言失败 | 内部不变量被违反 | 致命 | 中止整个执行 |
18.6.2 恢复策略
当错误发生时，错误处理器选择恢复策略：
| 策略 | 适用场景 | 效果 |
|---|---|---|
| 重试 | 瞬时故障（网络超时、暂时过载） | 用相同输入重新调用同一原语 |
| 回退 | 主实现不可用 | 切换到替代实现 |
| 替代 | 输入数据缺失但可估计 | 使用估计/默认值并附加警告标志 |
| 降级 | 无法达到全精度 | 以降低精度继续；记录局限性 |
| 跳过 | 非关键原语失败 | 标记为跳过；对依赖方使用默认/空值 |
| 中止 | 关键原语失败；无法恢复 | 停止执行；产生带错误报告的部分交付物 |
| 升级 | 需要人工判断 | 暂停执行；通知工程师决策 |
恢复策略可以在原语规范中预配置（例如”若外部模拟器失败，回退至 HCM 近似”）或由错误处理器根据错误类型和上下文动态确定。
18.6.3 优雅降级
一个关键设计原则：部分结果胜于无结果。如果非关键原语失败，TAR 继续执行而非中止：
场景：排队估计原语失败（检测器故障）
无优雅降级：
整个分析中止 → 无交付物产生 → 工程师一无所获
有优雅降级：
排队估计跳过 → 使用历史排队数据（标记为估计）
↓
延误计算继续（不确定性增加）
↓
LOS 评估继续（附带排队数据质量说明）
↓
产生交付物，附带有关于降级组件的警告
最终交付物明确标记哪些部分使用了降级或估计数据，使工程师能够评估尽管存在不完美但结果是否仍适用。
18.7 并行与分布式执行
18.7.1 图内并行
在单个 PDG 内，TAR 自动识别并利用并行性：
原始顺序执行：
[ExtractVolumes] → [CalculateSFR] → [CalculateCapacity] → [CalculateXc]
[ExtractGeometry] ────────────────────────────────────────────────┘
[ExtractTiming] ─────────────────────────────────────────────────→ [AllocateGreen]
[GetConstraints] ────────────────────────────────────────────────→ [EvaluateLOS]
并行执行（同一 PDG）：
线程 1: [ExtractVolumes] ──→ [CalculateSFR] ─┐
线程 2: [ExtractGeometry] ────────────────────┤──→ [CalculateCapacity]
线程 3: [ExtractTiming] ─────────────────────┤ │
线程 4: [GetConstraints] ────────────────────┘ │
↓
[CalculateXc] → [AllocateGreen] → [EvaluateLOS]
加速比取决于图结构：
- 高度并行的图（许多独立分支）：随核心数接近线性加速
- 顺序链（长关键路径）：无论核心数多少加速有限
- 典型交通工程任务：8 核硬件上 2-4 倍加速
18.7.2 图间并行：多责任执行
TAR 可以同时执行多个独立的责任：
| 场景 | 示例 | 并行收益 |
|---|---|---|
| 多交叉口研究 | 优化 10 个交叉口的配时 | 每个交叉口独立分析 |
| 多策略分析 | 诊断并评估同一路廊 | 不同策略共享观测层 |
| 方案比较 | 评估 5 种替代设计方案 | 相同基础数据、不同参数 |
| 批处理 | 为 50 个信号生周报 | 相同模板、不同数据 |
TAR 在并发执行之间协调共享资源（数据连接、模拟许可证、缓存），同时保持它们之间的隔离。
18.7.3 分布式执行
对于极大规模分析（数百个交叉口的区域网络优化），TAR 支持跨多台机器的分布式执行：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 工作节点 1 │ │ 工作节点 2 │ │ 工作节点 3 │
│ 交叉口 │ │ 交叉口 │ │ 交叉口 │
│ A1-A20 │ │ A21-A40 │ │ A41-A60 │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────┼────────────────┘
│
┌────────▼────────┐
│ 协调器 │
│ （聚合结果、 │
│ 管理依赖） │
└─────────────────┘
分布对工程师是透明的——TAR 自动处理分区、通信、容错和结果聚合。
18.8 交互模式
18.8.1 同步请求-响应
最简单的交互模式：发送责任，接收交付物。
工程师 → TAR："优化交叉口 A 的配时"
TAR：[编译 → 执行 → 验证 → 组装]
TAR → 工程师：配时方案文档（附完整证据链）
延迟：秒到分钟（取决于复杂度）。适合交互式使用。
18.8.2 异步长时任务
对于耗时较长的复杂分析：
工程师 → TAR："评估走廊范围信号协调（15 个交叉口）"
TAR → 工程师：任务ID：task-abc123，状态：排队中
...
TAR → 工程师（回调）：状态：进行中，完成：8/15，预计：12 分钟
...
TAR → 工程师（回调）：状态：已完成
工程师 → TAR：GET /tasks/task-abc123/result
TAR → 工程师：走廊评估报告
支持进度跟踪、取消和方便时的结果获取。
18.8.3 流式模式
用于持续监控和实时响应：
工程师 → TAR："监控交叉口 A 的过饱和状态"
TAR：[建立持续观测循环]
[态势评估流...]
TAE → 工程师：态势=正常（14:00）
TAE → 工程师：态势=拥堵（14:23）⚠️
TAE → 工程师：态势=过饱和（14:47）🔴
TAE → 工程师：建议：周期增加 10 秒（自动生成）
工程师 → TAR：确认 / 修改 / 覆盖
流式模式将 TAR 直接连接到实时数据源，产生持续的工程智能而非一次性分析。
18.8.4 交互协作模式
对于需要人机协同判断的场景：
TAR → 工程师："证据冲突：检测器数据显示 v/c=0.95，
但观测排队表明 v/c > 1.1。
您更信任哪个来源？"
工程师 → TAR："信任观测排队；检测器可能标定不准"
TAR：[调整推理、重新运行受影响分支]
TAR → 工程师：修订分析使用基于排队的 v/c=1.15，
建议立即提升容量
交互模式在决策点暂停执行（由 dec: 原语标记，第 17.3.1 节），收到人工输入后恢复。
18.9 性能特征
18.9.1 延迟基准
| 任务类型 | 典型节点数 | 中位延迟 | P99 延迟 |
|---|---|---|---|
| 单交叉口诊断 | 12-18 | 3-8 秒 | 15 秒 |
| 单交叉口优化 | 22-35 | 10-30 秒 | 60 秒 |
| 走廊分析（10 个交叉口） | 80-150 | 2-5 分钟 | 10 分钟 |
| 全网研究（50+ 个交叉口） | 300-800 | 15-45 分钟 | 90 分钟 |
| 实时流式更新 | 5-10 | < 500 ms | < 2 秒 |
由于并行化和共享计算的缓存，延迟随问题规模亚线性增长。
18.9.2 资源利用
| 资源 | 典型消耗 | 扩展行为 |
|---|---|---|
| 内存 | 每次 50-500 MB | 随图规模线性增长 |
| CPU | 利用 1-8 核 | 受图结构限制的并行性 |
| I/O | 数据库查询、文件读取 | 由数据访问模式主导 |
| 外部服务 | 模拟器调用、API 请求 | 因任务类型而异 |
| 存储 | 证据日志（每任务 10-100 MB） | 随执行持续时间线性增长 |
18.9.3 优化技术
TAR 采用多种优化技术以保持响应性能：
| 技术 | 描述 | 影响 |
|---|---|---|
| 结果缓存 | 按输入哈希键缓存原语输出 | 重复分析 30-50% 缓存命中率 |
| 增量执行 | 输入变更时仅重新执行受影响的子图 | 比全量重执行快 70-90% |
| 惰性求值 | 延迟计算直到输出实际需要 | 减少不必要工作 |
| 预取 | 空闲期预取可能需要的数据 | 掩盖 I/O 延迟 |
| 并行 | 并发执行独立节点 | 典型 2-4 倍加速 |
| 近似层级 | 提供快速近似 vs 慢速精确选项 | 用户可控的延迟/精度权衡 |
18.10 与外部系统集成
18.10.1 数据源适配器
TAR 通过标准化适配器连接到多样化的数据源：
| 数据源 | 适配器协议 | 数据格式 | 刷新率 |
|---|---|---|---|
| 交通检测器系统 | MQTT / REST API | 时间序列计数 | 实时（1-5 分钟） |
| 视频分析 | RTSP / 文件导入 | 事件、分类 | 近实时 |
| GIS / CAD 系统 | WFS / 文件导入 | 几何、拓扑 | 按需 |
| 历史数据库 | SQL / Parquet | 归档观测 | 批量 |
| 天气服务 | REST API | 条件、预报 | 每小时 |
| 事件管理 | REST / Webhook | 事件、持续时间 | 事件驱动 |
适配器将异构数据规范化为原语所期望的类型化观测格式（Observation(T)）（第十七章）。
18.10.2 模拟器封装
外部交通模拟器被封装为原语实现：
| 模拟器 | 封装类型 | 通信方式 | 典型用途 |
|---|---|---|---|
| Synchro Studio | COM API / 文件 I/O | 本地进程 | 信号配时优化 |
| VISSIM | COM API / DLL | 本地进程 | 微观分析 |
| Paramics | API / 建模器 | 本地/远程 | 全网模拟 |
| AIMSUN | API / Python | 本地/远程 | 中观/微观 |
| 自定义机构模型 | 直接集成 | 库调用 | 专有方法 |
封装接口抽象模拟器特定细节，向 TAR 呈现统一的 sim:*Run* 原语接口。
18.10.3 交付渠道
完成的交付物通过适当渠道路由：
| 渠道 | 交付物类型 | 触发条件 |
|---|---|---|
| 文件系统 | 报告、文档、数据导出 | 完成时自动 |
| 邮件 | 摘要报告、警报 | 可配置订阅 |
| API 回调 | 程序化消费者 | Webhook 注册 |
| 仪表盘 | 实时指标、KPI | 流式模式 |
| CMS / 文档管理 | 正式记录 | 机构政策要求 |
交付路由按交付物类型配置，确保结果通过正确渠道到达正确的利益相关者。
18.11 监控与可观测性
18.11.1 运行时指标
TAR 暴露全面的运行时指标：
| 指标类别 | 示例 | 粒度 |
|---|---|---|
| 吞吐量 | 任务/分钟、原语/秒 | 每任务、滚动平均 |
| 延迟 | P50/P95/P99 执行时间 | 每任务类型直方图 |
| 错误 | 按类别的错误率、重试次数 | 滚动窗口 |
| 资源 | CPU%、内存、打开的连接 | 实时仪表盘 |
| 队列深度 | 待处理任务、等待中的原语 | 实时计数器 |
| 缓存性能 | 命中率、淘汰率、大小 | 滚动平均 |
指标通过 Prometheus 格式暴露，以便与标准监控栈（Grafana、Alertmanager）集成。
18.11.2 分布式追踪
每次执行获得唯一的追踪 ID，该 ID 传播到所有原语调用中，支持端到端请求追踪：
Trace: exec-a1b2c3d4
├── Span: DRC.compile (duration: 85ms)
├── Span: TAR.execute (duration: 23.4s)
│ ├── Span: obs:ExtractVolumes (duration: 1.2s)
│ │ └── Span: DB.query_detector_data (duration: 900ms)
│ ├── Span: drv:CalculateSaturationFlow (duration: 45ms)
│ ├── Span: drv:CalculateCapacity (duration: 32ms)
│ ├── Span: drv:AllocateGreenTimes (duration: 180ms)
│ │ └── Span: webster_optimize (duration: 150ms)
│ ├── Span: val:ValidateTimingPlan (duration: 88ms)
│ └── Span: del:GenerateTimingReport (duration: 340ms)
│ └── Span: template_render (duration: 280ms)
└── Span: delivery.route (duration: 120ms)
追踪与 OpenTelemetry 标准集成，支持与基础设施级可观测性的关联。
18.11.3 健康检查
TAR 暴露健康端点用于运维监控：
| 端点 | 用途 | 响应 |
|---|---|---|
/health/live | 存活探针 | 进程运行时返回 200 |
/health/ready | 就绪探针 | 接受任务时返回 200 |
/health/components | 组件级状态 | 每组件健康/降级/停用 |
/health/version | 版本信息 | 构建、注册表版本、最后更新时间 |
这些支持标准 Kubernetes 存活/就绪探针模式，用于容器化部署。
18.12 总结：使 TAE 活起来的运行时
交通智能体运行时是 TAE 的运营核心。没有它，DRC 编译的 PDG 将只是惰性规范；原语库的知识将保持休眠；精心设计的验证规则永远不会触发。
本章的关键原则：
- 分层架构分离编排、执行、验证、状态和集成关注点。
- 依赖驱动遍历正确高效地执行 PDG，处理任意图结构。
- 原语调用生命周期（解析 → 准备 → 执行 → 验证 → 存储）确保每一步的正确性。
- 沙箱执行隔离原语以确保安全和可靠。
- 全面状态管理包括类型化工作内存、证据收集和检查点机制。
- 优雅降级产生有用的部分结果而非完全失败。
- 并行和分布式执行从单交叉口扩展到区域网络。
- 多种交互模式服务同步、异步、流式和协作用例。
- 丰富可观测性通过指标、追踪和健康检查实现卓越运维。
- 标准集成连接数据源、模拟器和交付渠道。
TAE 将 TAE 从一个有趣的理论框架转变为实用的、可部署的、可操作系统——一个能够真正协助交通工程师日常工作的系统，而非仅在受控环境中展示 AI 能力。
本章表格索引
| # | 表格名称 | 所在节 |
|---|---|---|
| 1 | TAR 分层架构 | 18.2.1 |
| 2 | 核心组件 | 18.2.2 |
| 3 | 执行策略 | 18.3.2 |
| 4 | 调度优先级因素 | 18.3.3 |
| 5 | 调用生命周期阶段 | 18.4.1 |
| 6 | 沙箱功能 | 18.4.4 |
| 7 | 错误分类 | 18.6.1 |
| 8 | 恢复策略 | 18.6.2 |
| 9 | 并行执行加速比 | 18.7.1 |
| 10 | 交互模式 | 18.8 |
| 11 | 延迟基准 | 18.9.1 |
| 12 | 优化技术 | 18.9.3 |
| 13 | 数据源适配器 | 18.10.1 |
| 14 | 模拟器封装 | 18.10.2 |
| 15 | 运行时指标类别 | 18.11.1 |
| 16 | 分布式追踪示例 | 18.11.2 |