recommended_action 接口与仲裁器：统一干预层如何真正落地

发布时间： 2026-03-26
主题： intervention layer / recommended_action / 仲裁器 / HMI / ADAS
关键词： recommended_action、arbiter、driver capability、action policy、trace_id

---

一句话结论

统一干预层如果没有标准接口，最终还是会退化回“每个 feature 自己发警报”。

真正让它落地的关键有两个：

• recommended_action 接口
• 动作仲裁器（arbiter）

前者负责把复杂状态转成统一动作语义，
后者负责在多风险并存时做最终决策。

---

1. 为什么只讲 capability score 不够

因为 capability score 只能回答“危险不危险”，
却不能直接告诉系统：

• HMI 现在该怎么提示
• ADAS 是否该进入 assist-ready
• 是否要缩短确认窗口
• 是否该进入 safety action

所以一定要有更接近执行层的接口。

---

2. recommended_action 应长什么样

建议输出至少包含：

{
  "risk_level": 0.82,
  "dominant_factors": ["fatigue", "response_delay"],
  "recommended_action": "escalate",
  "escalation_policy": "short_window",
  "assist_ready": true,
  "time_budget_ms": 2200,
  "trace_id": "evt_123"
}

这里最关键的不是字段多少，而是把“状态”转成“动作语义”。

---

3. 为什么必须有仲裁器

现实系统里常见场景不是单风险，而是：

• 疲劳 + 认知负荷
• 分心 + phone use
• impairment suspicion + response delay

如果没有仲裁器，不同 feature 会：

• 竞争 HMI
• 输出相互矛盾动作
• 重复记录和升级

仲裁器的职责就是：

• 合并多个 recommended_action
• 选出最终动作
• 决定升级顺序和优先级
• 保留 trace_id 方便回放

---

4. 一个实用的动作等级

A0 Observe

• 仅记录
• 不打扰用户

A1 Prompt

• 标准提醒
• 常规 HMI 提示

A2 Escalate

• 增强提醒
• 缩短容忍时间窗

A3 Assist-ready

• ADAS/HMI 提前进入高敏感状态
• 准备更强响应

A4 Safety-action

• 进入最小风险动作或 emergency path

只要动作语义足够稳定，后面加新 feature 的成本就会大幅下降。

---

5. 仲裁规则怎么设计

建议最少考虑四个维度：

• severity：风险强度
• urgency：时间预算有多紧
• confidence：证据是否可靠
• persistence：风险是否持续存在

仲裁器不是简单取最大值，
而要综合：

• 是否升级过快
• 是否会造成过度骚扰
• 是否已有更高动作在执行
• 是否应等待更多证据

---

6. trace_id 为什么重要

统一干预层如果没有 trace_id，后面几乎无法调试：

• 为什么这次 HMI 提示出现？
• 为什么 ADAS 提前介入？
• 为什么这条风险没升级？

trace_id 可以把：

• evidence
• capability state
• recommended_action
• arbiter decision
• HMI/ADAS outcome

串成一条完整时间线。

---

7. 验证应该怎么做

不要只测 feature accuracy。

更应该测：

• 多风险同时出现时，最终动作是否正确
• escalation timing 是否过早/过晚
• HMI 与 ADAS 是否一致执行
• trace_id 是否能完整追溯

也就是：

从 feature test 升级到 action test。

---

8. 研发优先级建议

P0：先定义 recommended_action schema

P0：搭建 arbiter，而不是让 feature 直接碰 HMI

P1：把 trace_id 接进日志和回放工具

P1：建立 multi-risk action regression cases

---

结语

统一干预层真正落地，不靠一句“我们有 capability model”，
而靠两件很工程化的事：

统一动作接口，和统一动作仲裁器。

把这两个东西做出来，driver capability 才真正从概念变成系统。