EP03 · 架构：动态环境里怎么做到实时决策
一句话概要：动态环境的实时决策，赢家是「跟着感知滚动」的架构——从预测控制到 gRPC，从硬件抽象层到四个九，所有选择服从同一条判据。 时长见文末声明 ｜ 素材锚点：单1、单7、单21、单29、单47、问5 ｜ 所属：第一季·核心范式
一、知识框架
本集回答一个问题：环境是动的，系统怎么跟得上？ 六个锚点题覆盖架构选型的四个层级：
- 决策架构层（单1）：动态环境实时决策选「基于模型的预测控制」。判据只有一条——环境是动的，决策就得是滚动的；静态规则、批处理、离线模型都输在「决策与感知不同步」。
- 通信协议层（单7）：毫秒级工业控制选 gRPC。HTTP/2 长连接省握手 + Protobuf 二进制压报文，延迟是选型定死的，不是优化出来的。
- 跨平台 SDK 层（单21）：核心要求是硬件抽象层。跨平台的真正矛盾是硬件异构；语言可绑定、协议可约定，唯独硬件差异没有中间层跨不过去。
- 接口与可用性（单29 + 单47）：RESTful 的优势是标准化接口交互（不承诺低延迟、不提精度、不自动出文档）；高可用黄金标准是 99.99%，承认故障必然、把恢复做到分钟级，而不是追 100%。
- 跨端交互设计（问5）：四条原则——上下文同步、自适应界面、隐私分级控制、离线基础功能；一句话：体验连续、能力裁剪、底线不塌。
二、题面锚点
单选 1：智能体在动态环境中实时决策时，最可能采用的架构是()
A. 静态规则引擎 B. 基于模型的预测控制 C. 批处理机器学习流水线 D. 离线强化学习模型
单选 7：工业控制智能体需毫秒级响应，最合适的通信协议是()
A. HTTP/1.1 B. MQTT C. gRPC D. WebSocket
单选 21：构建跨平台智能体 SDK 时，核心要求是()
A. 统一编程语言 B. 标准化通信协议 C. 硬件抽象层 D. 预训练模型内置
单选 29：智能体 API 设计遵循 RESTful 原则的优势是()
A. 减少网络延迟 B. 提升模型精度 C. 标准化接口交互 D. 自动生成文档
单选 47：保障智能体系统高可用的黄金标准是()
A. 99% 正常运行时间 B. 99.9% 正常运行时间 C. 99.99% 正常运行时间 D. 100% 无故障运行
问答 5：列举跨平台智能体(如手机/车载/loT)的统一交互设计原则
三、答案要点讲透
单选 1 答案：B（基于模型的预测控制）
- 为什么是它：「基于模型」指系统心里有对世界的简化描述（车怎么走、油门方向盘怎么影响轨迹）；「预测控制」指每个时刻都拿模型往前推演一小段，比较几种动作的后果，挑当下最优执行。关键在滚动：窗口很短，执行完立刻拿最新观测重推，上一轮结论作数。决策与感知锁在同一个循环里，时刻同步。
- A 静态规则引擎为什么错：规则是人穷举的，动态环境情况组合无穷多，写不死；没写进规则的它就不会，不会应变。
- C 批处理机器学习流水线为什么错：数据攒一批、算一波、出一批，天生慢半拍，实时场景等于看后视镜开车。
- D 离线强化学习模型为什么错：训练时能学到策略，但部署后环境一变策略就过时，没有在线重算机制。
单选 7 答案：C（gRPC）
- 为什么是它：毫秒级的刚需是单次往返又快又稳。gRPC 跑在 HTTP/2 上，一条长连接多路复用，省掉反复握手；用 Protobuf 二进制序列化，报文小、解析快，同样信息体积只有文本格式零头。长连接 + 二进制，把延迟和抖动都压到很低。
- A HTTP/1.1 为什么错：每次请求基本新建连接、握手、传大摞冗余头部，慢且浪费。
- B MQTT 为什么错：为海量设备、弱网、低功耗设计，强项是省流量与带动海量连接，不是压榨延迟极限；毫秒级控制要确定性低延迟，它不够锐利。
- D WebSocket 为什么错：只打通一条全双工双向管道，不管数据格式与调用语义，序列化和调用规范还要自己在上面搭，等于只给毛坯房。
单选 21 答案：C（硬件抽象层）
- 为什么是它：手机、车载、IoT 三端硬件异构（摄像头型号、算力差数量级、传感器配置、网络连通性），硬件抽象层把硬件差异收进统一接口后面，上层业务代码只面对抽象设备说话，换平台不必重写业务。
- A 统一编程语言为什么错：拿生态换统一，绑定单一语言把其他语言开发者关在门外；主流跨端 SDK 靠多语言绑定，不靠强制统一。
- B 标准化通信协议为什么错：是对外的接口约定，必要不充分——约定了怎么说话，硬件对不上仍说不上话。
- D 预训练模型内置为什么错：把迭代最快的部分焊死，模型几个月一换代，内置即过时；且模型从来不是跨平台的主要障碍。
单选 29 答案：C（标准化接口交互）
- 为什么是它：RESTful 三句话——资源用名词表达、动作交给 HTTP 方法、服务器不记客户端状态。价值在标准二字：接口长什么样、出错怎么报、语义怎么读，全行业一套读法；客户端服务端解耦，协作、对接、自动化测试成本都下来。智能体组件最多（感知、决策、记忆、工具调用），接口不标准，集成就是灾难。
- A 减少网络延迟为什么错：RESTful 不承诺低延迟；无状态意味着每次请求都要重传上下文，省不掉。
- B 提升模型精度为什么错：接口规范管交互，模型精度是另一条战线，互不相干。
- D 自动生成文档为什么错：是周边生态的衍生便利，不是 RESTful 原则本身的优势。
单选 47 答案：C（99.99% 正常运行时间）
- 为什么是它：工程上不存在 100% 无故障，只有把故障影响压多小的区别。按 365 天折算年停机：99% 约 87.6 小时（将近四天）、99.9% 约 8.76 小时、99.99% 约 52 分钟。四个九意味着年停机压在五十分钟量级，靠冗余、快速故障切换、降级预案实现——承认故障必然发生，同时把恢复做到分钟级。
- A 99% 为什么错：一年躺平将近四天，工业场景不可接受。
- B 99.9% 为什么错：年停机 8.76 小时，仍超出分钟级恢复的目标一个量级。
- D 100% 为什么错：只存在于汇报材料里；追 100% 是把资源耗在不可能上，还掩盖真问题。
问答 5 答案要点（与题库一致）：上下文同步（如任务续接）；自适应界面（屏幕尺寸兼容）；隐私分级控制（车内禁用敏感操作）；离线基础功能。
- 上下文同步：上下文跟着人走，不跟着设备走——手机上规划的路线，上车接着聊。背后是统一账号体系 + 状态云端同步。
- 自适应界面：同一能力不同屏幕不同长相——车机屏大、手表屏小，布局随输入输出能力变形，任务流不变。
- 隐私分级控制：按场景给能力分级——车内有乘客同行，支付、改密码、看病历等敏感操作在车机上禁用或要求二次确认。
- 离线基础功能：断网能力不归零——导航、本地控制、缓存日程可离线跑；架构的终极目标不是永远在线，是降级可用。
四、延伸思考
- 「决策与感知同频」是架构第一性原理：本集六个锚点看似分散，判据归一。预测控制把决策锁进感知循环；gRPC 把指令往返压到毫秒；硬件抽象层让上层能力不因平台抖机；99.99% 让故障恢复跑在分钟级；离线兜底让断网不归零。任何一层不同频，实时性就断在那一层。
- 协议选型的「补洞效应」：先用 HTTP/1.1 顶毫秒级需求，再上连接池、压缩、缓存、预连接——每一步都在补选型欠的账。选型阶段多算一遍账，胜过后期三个月的优化。
- 可用性的「四个九」怎么落地：52 分钟的年停机预算，靠的不是单点更可靠，而是冗余（多副本、多活）、快速切换（故障检测 + 自动转移）与降级预案（核心功能保底）。与问 5 的「离线基础功能」同源：承认会出问题，设计好在出问题时剩什么。
- 与语音链路测试的连接（作者实践注脚）：gRPC 的长连接与 Protobuf 序列化直接影响 ASR 服务的接口延迟测量口径；99.99% 的分钟级恢复目标，对应测试体系里的故障演练与恢复时长统计——架构题背后都是可量化的工程指标。
五、术语表
| 白话 | 术语 | 一句话解释 |
|---|---|---|
| 边看边修 | 基于模型的预测控制 | 每时刻用模型推演一小段未来，选当下最优，感知更新后立刻重推 |
| 一条管道多路送货 | gRPC | 基于 HTTP/2 长连接 + Protobuf 二进制的远程调用，低延迟高吞吐 |
| 把硬件差异藏起来 | 硬件抽象层 | 统一接口屏蔽传感器/算力/网络差异，上层业务不重写 |
| 全行业一套读法 | RESTful | 资源用名词、动作用 HTTP 方法、服务端无状态的接口约定 |
| 四个九 | 99.99% 可用性 | 年停机约 52 分钟，靠冗余与分钟级恢复，不靠运气 |
| 断网不归零 | 离线基础功能 | 网络不可用时核心能力降级可用，而非整体失效 |
*本集音频：ep03-动态环境实时决策.mp3 ｜ 下一集：EP04 感知层：多模态与传感器融合*