第二十章：WayMind——交通智能体工程的参考实现

20.1 理论与实现：双重必要性

贯穿本书第一卷和第二卷发展的交通智能体工程，根本上是一个理论框架——一套用于组织交通运输系统工程智能的原则、架构和方法论。但没有实现的理论仍然是抽象。

每一个持久的工程学科都通过双轨发展而来：解释事物为何运作的理论基础，和展示其如何运作的参考实现。 牛顿定律解释了天体力学；太阳系仪演示了它。香农信息论定义了信道容量；调制解调器实现了它。HCM 定义了容量分析；Synchro 实现了它。

TAE 解释工程智能应如何结构化。WayMind 展示了一种在运营性交通工程平台内实现该结构的可能方式。

本章呈现 WayMind 并非作为产品广告，而是作为具体示例——说明前述各章描述的抽象组件——工程责任（第1-2章）、推理规划器（第3章）、原语系统（第7、17章）、依赖图（第7、16章）、编译器（第11、16章）、运行时（第18章）、验证引擎（第13章）和交付系统（第12、19章）——如何组合成一个可运行的系统。

20.2 设计哲学：以责任为中心的架构

20.2.1 架构差异

当代大多数面向交通工程的 AI 系统围绕三种架构范式之一构建：

范式	核心抽象	示例系统
对话式 AI	对话轮次 / 消息交换	基于 ChatGPT 的助手、交通聊天机器人
仪表盘/可视化	数据展示 / 图表	ATMS 仪表盘、实时监控器
以模型为中心	预测 / 优化模型	自适应控制系统、模拟工具

WayMind 与三者均不同。它的核心抽象是工程责任：

┌─────────────────────────────────────────────────────┐
│                   WAYMIND 架构                       │
│                                                     │
│                    ┌──────────┐                      │
│                    │ 工程师    │                      │
│                    │ 请求     │                      │
│                    └────┬─────┘                      │
│                         │                            │
│                         ▼                            │
│              ┌──────────────────────┐                │
│              │ 责任               │                │
│              │ 解析器             │                │
│              │ (自然语言 →        │                │
│              │  结构化工程对象)   │                │
│              └──────────┬───────────┘                │
│                         │                            │
│                         ▼                            │
│         ┌──────────────────────────────────┐        │
│         │     领域推理编译器 (DRC)         │        │
│         │   (责任 → PDG)                   │        │
│         └─────────────────┬────────────────┘        │
│                           │                            │
│                           ▼                            │
│         ┌──────────────────────────────────┐        │
│         │      交通智能体运行时 (TAR)       │        │
│         │   (执行 PDG → 类型化结果)        │        │
│         └─────────────────┬────────────────┘        │
│                           │                            │
│                           ▼                            │
│         ┌──────────────────────────────────┐        │
│         │   工程交付系统 (EDS)             │        │
│         │   (结果 → 结构化交付物)          │        │
│         └─────────────────┬────────────────┘        │
│                           │                            │
│                           ▼                            │
│              ┌──────────────────────┐                │
│              │ 工程交付物           │                │
│              │ + 记忆存储           │                │
│              └──────────────────────┘                │
│                                                     │
│  对话是 ONE 接口，而非 THE 架构                     │
└─────────────────────────────────────────────────────┘

在 WayMind 中，对话仅仅是工程师发起责任的一个接口。系统的核心逻辑操作的是结构化工程对象，而非对话历史。

20.2.2 为何这很重要

以责任为中心的架构提供对话式或以模型为中心的方法无法具备的特性：

特性	对话式 AI	以模型为中心	WayMind (TAE)
可追溯性	有限（对话上下文）	低（黑箱）	完整（PDG + 证据）
可复现性	否（随机生成）	部分（固定模型）	是（确定性 PDG）
可验证性	表层检查	输出验证	多层级（L1-L5）
可组合性	无（单体）	有限（流水线）	完整（原语图）
可解释性	事后合理化	特征归因	固有（图结构）
问责性	不清楚	依赖供应商	清晰（工程师在环）

20.3 TAE 组件到 WayMind 模块的映射

20.3.1 组件对应

每个主要 TAE 概念都映射到具体的 WayMind 模块：

TAE 概念（理论）	WayMind 模块（实现）	参考章节
工程责任	`ResponsibilityInterpreter` 服务	第 1-2、10 章
态势评估	`SituationAssessor` 带 12 类分类器	第 14 章
策略选择	`StrategySelector`（6 策略路由器）	第 10、15 章
领域推理编译器	`DRC` 微服务（6 遍流水线）	第 11、16 章
原语依赖图	`PDG` 数据结构 + 序列化器	第 7、16 章
领域原语库	`PrimitiveRegistry` 数据库（~255 个原语）	第 17 章
类型系统	`TypeChecker` 中间件	第 16 章
交通智能体运行时	`TAR` 执行引擎（Go 实现）	第 18 章
验证引擎	`Validator`（5 层金字塔）	第 13 章
交付系统	`EDS` 流水线（模板驱动）	第 12、19 章
工程记忆	`MemoryStore`（PostgreSQL + 向量索引）	第 12、19 章

20.3.2 技术栈

WayMind 使用现代化的云原生技术栈实现：

层	技术	理由
API 网关	Kong / Envoy	限流、认证、路由
核心服务	Go (gRPC)	性能、并发、类型安全
DRC 服务	Python (FastAPI)	ML/NLP 生态访问
原语执行	Python + R 沙箱化	领域库兼容性
数据存储	PostgreSQL + Redis	可靠性 + 缓存
向量搜索	pgvector / Qdrant	记忆相似度搜索
消息队列	NATS JetStream	异步任务编排
可观测性	OpenTelemetry + Prometheus + Grafana	分布式追踪、指标
前端	React + TypeScript	工程师 Web UI
部署	Kubernetes + Helm	可扩展、声明式基础设施

多语言方法（Go 用于性能关键路径、Python 用于 ML/DRC、TypeScript 用于 UI）反映了不同组件具有不同最优实现语言的现实。

20.4 完整演练：信号配时优化

20.4.1 请求

工程师通过 WayMind 的 Web 界面与之交互：

工程师： “第五大道的主路似乎每天傍晚 5:30 左右都会堵车。你能调查一下并建议配时调整吗？”

20.4.2 逐步处理

以下是 WayMind 内部逐组件发生的过程：

═══ 步骤 1：责任解析 ═══

输入："第五大道与主路交叉口似乎每天傍晚 ~5:30 堵车，
        建议调整配时"

ResponsibilityInterpreter 输出：
{
  location: { intersection: "5th Ave & Main St", ... },
  situation_symptom: "排队/拥堵",
  temporal_pattern: "规律性，晚高峰 (~17:30)",
  implied_strategy: "先诊断 → 后设计",
  scope: "单交叉口信号配时",
  deliverable_expectation: "配时建议"
}

═══ 步骤 2：态势评估 ═══

SituationAssessor 查询观测层：
  - 检测器数据：可用（最近 30 天）
  - 视频：可用（2 台摄像机）
  - 历史：可用（3 年）

评估结果：
  - 态势类型：规律性拥堵（晚高峰）
  - 置信度：高（20+ 天一致模式）
  - 关键指标：排队平均=45m，最大=82m，高峰 v/c=1.08
  - 根因假设：协调绿波窗口期间容量不足

═══ 步骤 3：策略选择 ═══

StrategySelector 确定：
  主策略：诊断（先确认根因）
  辅策略：设计（产生配时建议）

理由：不确认问题是容量、协调还是两者兼有，
      无法设计有效的配时方案。

═══ 步骤 4：DRC 编译 ═══

DRC 接收结构化责任 + 策略 → 编译 PDG：

PDG 统计：
  节点：28 个原语
  边：37 条依赖
  预计执行时间：45-90 秒
  并行组：4 组（最大并行度：6 个节点）

关键子图：
  [诊断子图]
    obs:ExtractVolumes → drv:CalculateCapacity → drv:CalculateXc
                        → drv:CalculateDelay → drv:EvaluateLOS
    val:CrossValidate(观测 vs 模拟排队)

  [设计子图]（依赖于诊断确认）
    drv:AllocateGreenTimes(webster) → val:CheckConstraints
    → drv:EvaluateLOS(拟定) → del:GenerateTimingReport

═══ 步骤 5：TAR 执行 ═══

TAR 执行 PDG：

[14:32:01] 开始执行（追踪：exec-7f3a9b2c）
[14:32:03] ✓ obs:ExtractVolumes (1.8s) → 提取 4 个进口道流量
[14:32:04] ✓ obs:ExtractGeometry (0.9s) → 车道配置已加载
[14:32:04] ✓ obs:ExtractCurrentTiming (0.5s) → 当前方案已获取
[14:32:05] ✓ drv:CalculateSaturationFlow (0.04s) → SFR: [1850, 1720, 1600, 1550]
[14:32:05] ✓ drv:CalculateCapacity (0.02s) → 容量：1680 veh/h
[14:32:06] ✓ drv:CalculateXc (0.01s) → Xc_高峰: 1.08（过饱和）
[14:32:06] ✓ drv:CalculateDelay (0.03s) → 延误：58.2 s/veh（LOS D）
[14:32:07] ✓ drv:EvaluateLOS (0.02s) → 当前 LOS：D
[14:32:08] ✓ val:ValidateDiagnosis (0.9s) → 通过（证据一致）
[14:32:09] ✓ dec:ConfirmRootCause (0.1s) → 容量不足确认
[14:32:10] → 转入设计阶段...
[14:32:11] ✓ drv:AllocateGreenTimes (0.15s) → 拟定：C=95s, 绿信比=[45,35,15]
[14:32:11] ✓ val:CheckConstraints (0.08s) → 所有约束满足
[14:32:12] ✓ drv:EvaluateLOS_proposed (0.02s) → 拟定 LOS：C（改善）
[14:32:13] ✓ sim:QuickValidation (8.2s) → 模拟确认约 22% 延误降低
[14:32:14] ✓ del:GenerateTimingReport (0.3s) → 报告已组装
[14:32:14] 完成（总计：13 秒，28/28 节点成功）

═══ 步骤 6：验证 ═══

Validator 运行 5 层检查：

  L1 语法：✓ 报告结构完整（11/11 章节）
  L2 约束：✓ 所有约束满足（最小绿灯、行人清空、周期范围）
  L3 计算：✓ 计算可复现（中间值已记录）
  L4 模拟：✓ 快速模拟验证分析结果（Δ < 5%）
  L5 审核：⚠ 标记待工程师审核（建议超出当前政策周期上限 5 秒）

总体验证状态：有条件通过（周期增加需工程师批准）

═══ 步骤 7：交付 ═══

EDS 生成交付物：

  生成文件：
    [1] Timing_Optimization_5thAve_MainSt_20250803.pdf（24 页）
    [2] Timing_Optimization_5thAve_MainSt_20250803.docx（可编辑）
    [3] Executive_Summary_5thAve_MainSt.pdf（1 页）
    [4] Operations_WorkOrder_5thAve_MainSt.pdf（2 页）
    [5] Data_Package_5thAve_MainSt.json（机器可读）

  交付渠道：
    → 邮件发送给请求工程师
    → 归档至工程记忆
    → 向主管发送仪表盘通知

═══ 步骤 8：工程记忆更新 ═══

MemoryStore 记录：
  - 新交付物已索引（位置、策略、日期、成果）
  - 模式更新："规律性晚高峰拥堵 → 以容量为焦点的配时优化"
  - 标定数据点：预测 22% 延误降低 → 待实施后验证

20.4.3 工程师收到什么

提交初始请求后约 90 秒内，工程师收到：

一份完整技术报告（24 页），包含完整方法论、证据和分析
一份执行摘要（1 页），适合管理层简报
一份运营工单，包含信号技术员所需的精确参数
一份数据包，用于下游系统集成

所有内容源自同一底层执行，全部内部一致，完全可追溯。

20.5 运营中的 WayMind：部署模式

20.5.1 部署架构

WayMind 支持多种部署模式，适应不同机构规模和需求：

模式	描述	适用场景
单节点	所有服务在一台服务器上	小型机构（<50 个信号）
集群	Kubernetes 集群上的微服务	中型机构（50-500 个信号）
分布式	区域节点加中央协调	大型机构/都市区（500+ 个信号）
混合云	本地核心，重计算时云端扩展	工作负载变化的机构
边缘部署	场地设备上的轻量级 TAR 用于实时响应	车联网 / 边缘计算场景

20.5.2 集成模式

WayMind 与现有交通工程生态系统集成：

集成点	协议	典型连接
ATMS/ATMCS	REST / NTcip	双向：接收警报、发送建议
信号控制器	SS125 / 专有协议	读取当前配时、写入拟定配时
检测器系统	MQTT / REST	实时数据流
GIS / CAD	WFS / 文件导入	几何和网络拓扑
模拟工具	COM API / CLI	Synchro、VISSIM、Paramics 集成
文档管理	CMIS / REST	交付物归档和检索
机构 ERP	REST / SOAP	工单生成、资源跟踪

集成通过适配器实现，将外部系统的数据格式规范化为 WayMind 的内部类型化表示——观测值、参考值、派生量与估计量等。

20.6 实践中的持续学习

20.6.1 学习循环实现

WayMind 实现本书通篇描述的闭环学习机制：

                    ┌──────────────────┐
                    │   新的工程       │
                    │   责任           │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  执行 (TAR)       │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  交付 (EDS)       │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  实施             │◄────── （现场）
                    │  (工程师/团队)    │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  实施后数据收集   │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  成果分析         │
                    │  (预测 vs 实际)  │
                    └────────┬─────────┘
                             │
                ┌────────────┴────────────┐
                │                         │
                ▼                         ▼
    ┌──────────────────┐      ┌──────────────────┐
    │ 成功              │      │ 差异              │
    │ 强化方法          │      │ 调查原因          │
    │ 添加至模式库      │      │ 更新标定          │
    │ 提升置信度        │      │ 精炼原语          │
    └────────┬─────────┘      └────────┬─────────┘
             │                         │
             └──────────┬──────────────┘
                        │
                        ▼
               ┌──────────────────┐
               │ 更新后的系统      │
               │ （下次更好）      │
               └──────────────────┘

20.6.2 追踪的学习指标

WayMind 追踪具体的学习指标：

指标	定义	目标趋势
预测准确性	预测成果与实际成果的相关性	随时间改善
方法成功率	推荐方法达到目标的百分比	按方法追踪
标定漂移	默认值偏离本地现实的程度	随系统学习而下降
模式识别率	新态势匹配已知模式的百分比	上升（更多态势变为”已知”）
工程师覆盖率	工程师修改建议的百分比	下降（系统与专业知识对齐）
重新执行频率	与类似过往任务重复的分析的百分比	上升（记忆复用）

这些指标显示在系统学习仪表盘上，供系统管理员和领域专家查看。

20.7 人机协同：WayMind 如何尊重工程判断

20.7.1 人工干预点

WayMind 明确设计干预点，在这些点上人工判断是必需或有价值的：

干预点	触发条件	人工角色	自动化程度
责任澄清	模糊请求	细化范围、添加上下文	必需
策略确认	多种策略合理	批准或重定向	默认：确认
决策原语	到达 `dec:` 节点	做出工程选择	必需
验证例外	L5 审核标记	批准/拒绝/修改	有条件
政策覆盖	建议与政策冲突	授权例外	必需
交付物审核	最终发布前	质量批准	可配置
实施决策	呈现多种选项	选择方案	推荐

20.7.2 增强原则

WayMind 基于一个根本原则运作：

目标不是自动化工程师。目标是增强他们——处理工程工作中例行、重复和计算密集的方面，使人类能够专注于判断、创造力和问责。

这一原则在实践中体现为：

活动	WayMind 处理	工程师处理
从 30 天检测器日志中提取数据	✅ 自动化	—
按 HCM 方法计算饱和流率	✅ 自动化	—
Webster 配时优化	✅ 自动化	—
对照机构政策进行约束检查	✅ 自动化	—
生成格式正确的报告	✅ 自动化	—
确定哪个问题需要解决	—	🔵 工程师
解释模糊的利益相关者需求	—	🔵 工程师
决定何时覆盖标准方法	—	🔵 工程师
对成果承担专业责任	—	🔵 工程师
向非技术受众传达发现	🔄 辅助	🔵 工程师主导

劳动分工不是静态的——它随系统学习和信任建立而变化。但问责边界保持固定：合格的人类工程师始终对工程决策承担最终责任。

20.8 超越 WayMind：TAE 作为开放方法论

20.8.1 非专有、非产品锁定

WayMind 是一个参考实现，而非唯一实现。交通智能体工程的原则刻意独立于任何特定技术栈、供应商或产品：

TAE 原则	实现无关声明
以责任为中心	任何以工程责任（而非查询、而非仪表盘）为主要对象的系统
编译推理	任何在执行前将请求转化为显式、可验证推理计划的系统
类型化原语	任何将工程方法表示为类型化的、规范的、可组合单元的系统
依赖感知	任何追踪和强制执行工程计算间依赖关系的系统
多级验证	任何在语法、约束、计算、模拟和审核层面进行验证的系统
结构化交付	任何产生规范的、可追溯的、可操作的工程交付物的系统
记忆赋能	任何从既往工程工作中学习并复用的系统
人类问责	任何在自动化辅助与人类责任之间维持清晰边界的系统

机构可以使用完全不同的技术实现 TAE 原则——基于 Java 的 DRC、基于 Rust 的 TAR、自定义前端——而仍然是在实现交通智能体工程。

20.8.2 生态系统愿景

TAE 的长期愿景是一个开放生态系统：

┌─────────────────────────────────────────────────────┐
│            交通智能体工程生态系统                     │
│                                                     │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐             │
│  │ WayMind │  │ 机构    │  │ 研究    │             │
│  │(参考    │  │ 自定义  │  │ 原型    │             │
│  │ 实现)   │  │ 实现    │  │ 实现    │             │
│  └────┬────┘  └────┬────┘  └────┬────┘             │
│       │            │            │                    │
│       └────────────┼────────────┘                    │
│                    │                                 │
│          ┌─────────▼─────────┐                       │
│          │  TAE 规范          │                       │
│          │  （开放标准）      │                       │
│          └─────────┬─────────┘                       │
│                    │                                 │
│    ┌───────────────┼───────────────┐                 │
│    │               │               │                 │
│    ▼               ▼               ▼                 │
│ ┌────────┐  ┌──────────┐  ┌────────────┐            │
│ │原语库  │  │ 模板     │  │ 验证规则   │            │
│ │(共享)  │  │ 交换     │  │ (共享)     │            │
│ └────────┘  └──────────┘  └────────────┘            │
│                                                     │
│  共享资产：原语、模板、验证规则、最佳实践 —— 社区贡献  │
└─────────────────────────────────────────────────────┘

在这个生态系统中，实现在质量、性能和易用性上竞争，同时共享基础资产（原语库、模板、验证规则）。工程师从实现竞争中受益，同时通过共享标准享受互操作性。

20.9 衡量成功：TAE 系统的关键绩效指标

20.9.1 工程效能指标

我们如何知道像 WayMind 这样的 TAE 系统是否真正有效？以下指标提供证据：

指标类别	具体 KPI	目标	测量方法
吞吐量	每工程师月完成的责任数	> 3× 基线	系统日志 vs 历史基线
质量	通过完整验证（L1-L5）的交付物	> 95%	验证器通过率
及时性	从请求到交付物的平均时间	< 2 小时（标准任务）	时间戳分析
可操作性	30 天内实施的建议	> 70%	后续调查 / 系统跟踪
成果准确性	预测 vs 实际改善相关性	r > 0.8	实施后评估
工程师满意度	用户满意度评分	> 4.0/5.0	定期调查
学习率	重复性态势的解决时间改善	> 15% 同比	同比比较
成本效率	每个交付物成本 vs 传统方法	< 基线的 60%	财务分析

20.9.2 反指标：应避免的行为

同样重要的是反指标——表明系统被误用的行为：

反指标	警示信号	纠正动作
橡皮图章	工程师 >95% 无修改即批准	审查自动化水平是否适当
过度依赖	工程师无法在没有系统的情况下进行分析	确保技能维护、避免技能退化
模板思维	无论态势如何所有交付物看起来相同	审查模板灵活性、鼓励定制
指标博弈	系统针对 KPI 而非成果优化	将指标与真正的工程价值对齐
范围蔓延	系统用于非工程目的	维护清晰的范围边界

20.10 总结：从理论到影响

WayMind 证明交通智能体工程不仅是一个学术框架——它是构建交通运输系统工程智能系统的实用的、可实施的、可运营的方法。

本章的关键要点：

理论需要实现。 WayMind 提供使 TAE 抽象概念具体化的具体参考。
以责任为中心的架构从根本上区别于对话式和以模型为中心的范式。
完整的组件映射展示每个 TAE 概念如何映射到可运行的软件模块。
端到端演练（信号配时优化）展示了从自然语言请求到多格式交付物的完整流水线，耗时不到 90 秒。
多种部署模式服务于各种规模的机构，从单节点到分布式边缘部署。
持续学习循环确保系统从现实世界成果中改进，而不仅是从训练数据。
人机协同设计尊重工程判断，同时最大化例行工作的自动化。
开放方法论意味着 TAE 不绑定于 WayMind——任何合规的实现都符合资格。
明确的成功指标（及反指标）提供系统有效性的客观证据。

WayMind 只是一种实现。它体现的原则——以责任为中心的设计、编译推理、类型化原语、验证交付、持续学习——是普遍的。它们代表了一条从交通工程现状（主要是手工的、工具辅助的、依赖专业知识的）向未来状态的道路，在那里工程知识是可执行的、工程推理是可验证的、工程交付在大规模上是可靠的。

这一未来不是推测性的。它是可实现的。而 WayMind 证明了这一点。

后记：工程交通的未来

交通始终是一门关于工程责任的学科。

从 20 世纪初最早的手动交通信号，到 20 世纪 70 年代的计算机化感应控制，再到今天的自适应系统和数字孪生——每一代都在扩展我们观察、理解、分析和改进交通系统的能力。然而在整个演进过程中，有一个恒定的不变量：交通工程归根结底是做出影响人们生活的决策——他们的安全、他们的时间、他们的社区、他们的环境。

人工智能革命为交通带来了前所未有的计算能力。大语言模型可以超人类规模地处理和生成文本。机器学习可以检测数据中任何人都无法感知的模式。优化算法可以探索天文数字大小的解空间。

但能力不是智能。计算不是工程。而生成看似合理的文本并不等同于产生可信的工程成果。

交通智能体工程代表了一种不同类型的里程碑——不是 AI 能力的又一次渐进式改进，而是对构建工程智能系统意味着什么的根本重新构想。其核心洞察简单得令人误解：

不要为交通工程师构建更聪明的聊天机器人。构建一个能做交通工程的系统。

这意味着：

责任优于查询：系统的原子单位不是问题，而是一项工程任务。
推理优于生成：系统构建论证，而不只是答案。
验证优于貌似合理：系统在多个层面验证正确性，而不只是表层连贯。
交付优于响应：系统产生工程制品，而非对话轮次。
学习优于训练：系统从工程成果中改进，而不只是从训练语料。
问责优于自主：系统增强人类判断，而非替代它。

从这些原则到运营系统的旅程才刚刚开始。WayMind 证明的是可行性而非成熟度。原语库将增长。验证规则将更精准。交付模板将演进。学习循环将积累智慧。而贡献于这个生态系统的从业者、研究者和机构社区将扩展。

交通未来的定义不会仅由更大的模型、更多的数据或更快的计算决定——尽管这些都发挥作用。它将由我们能否将交通工程积累的知识转化为可执行的、可验证的、持续改进的工程智能来定义。

本书提出了对该挑战的一种可能答案。答案并不完整。实现并不完美。方法论无疑将被采用它的社区精炼、挑战和改进。

但方向是清晰的。机会是真实的。而工作紧迫——对于每个仍在按过时配时方案运行的交叉口，对于每条因诊断耗时太长而拥堵的走廊，对于每个基于不完整分析做出的工程决策，对于每个被本应自动化的例行计算压得喘不过气的交通工程师。

交通的未来是工程化的。让我们把它工程好。

— 第二卷完 —

本章表格索引

#	表格名称	所在节
1	AI 范式比较	20.2.2
2	TAE 组件 → WayMind 模块映射	20.3.1
3	WayMind 技术栈	20.3.2
4	信号优化演练时间线	20.4.2
5	部署模式	20.5.1
6	集成模式	20.5.2
7	学习指标	20.6.2
8	人工干预点	20.7.1
9	增强分工	20.7.2
10	TAE 原则（实现无关）	20.8.1
11	成功 KPI	20.9.1
12	反指标	20.9.2