4.4 塔台频道：人机交互与协作行动

4.4 塔台频道：人机交互与协作行动

本节摘要：人不是旁观者，是飞行器的塔台。本节设计接管等级（全程监督、关键点确认、异常接管、人工主飞），定义交接协议——"谁在飞"永远有唯一答案、切换时状态无损，讲意图共享与可解释性怎么复用状态板与任务单，最后谈信任校准：既不过度放权，也不事事插手。

地面站的屏幕上弹出黄色提示："前方区域置信度不足，请求人工确认绕飞方案。"值班员点开一看，屏幕上不是一串吓人的报错，而是飞行器当前的信念、两条候选航线和各自的代价——他圈了一条，点下确认，飞行器继续飞。这则提示能弹得这么恰到好处，背后是一整套协议在工作：什么时候该叫人、叫人时给人看什么、人接手后机器记不记得自己刚才在干什么。行动舱的前面三节解决了机器自己飞的问题，本节解决人机共飞的问题。

飞行问题：两个主角，一根操纵杆

人机协作的根本难点在操纵权的唯一性：一根操纵杆，两个人同时握，就是事故剧本。要么抢——人的修正与机器的自动控制在打架，舵面抖成筛子；要么真空——人以为机器在飞，机器以为人已接管，飞行器进入无人驾驶状态。历史上多起自动化事故的调研报告都用几乎相同的措辞描述根因：模式混淆——机组不知道当前处于哪种自动化模式。解法在工程上早已收敛：把"谁在飞"做成严格唯一的状态，把切换做成正式的协议动作，而不是随手点击的副产品。

舱段设计：接管等级与触发

接管不是一档，是按风险与机器自信度分档的滑条：

触发要主动且克制：机器该叫人时果断叫（置信度不足、动作不可逆、阶梯到顶），不该叫时保持安静（事事请示与从不请示一样危险——前者把人训练成橡皮图章，后者把人排除在回路外）。判断的锚点是动作的可逆性与置信度：可逆且高置信的自动做，不可逆或低置信的必须过人。

算法实现：交接协议

交接协议的核心承诺：任何时刻"谁在飞"有唯一答案，切换时状态无损、责任清晰。实现上把接管做成一个显式的状态机事务，而不是一个隐式的输入焦点：

from enum import Enum
import time

class Pilot(Enum):
    AGENT = "机器在飞"
    HUMAN = "人工在飞"
    PENDING = "交接中"          # 短暂且必须超时回落

class TowerChannel:
    """塔台频道：接管与交还的正式协议。"""

    def __init__(self, board):
        self.pilot = Pilot.AGENT
        self.board = board       # 单一事实源再次发力
        self._pending_deadline = None

    def request_takeover(self, failure_context, timeout_s=10.0):
        """机器请求人工接管：进入交接态并打包现场。"""
        assert self.pilot is Pilot.AGENT
        self.pilot = Pilot.PENDING
        self._pending_deadline = time.monotonic() + timeout_s
        handover_pack = {        # 交接包：人接手所需的最小全套
            "belief": self.board.snapshot_belief(),
            "goal_stack": self.board.read("goal_stack"),
            "route": self.board.read("route"),
            "failure": failure_context,
            "options": self.board.propose_options(),
        }
        self.board.write("pilot", Pilot.PENDING.value, writer="tower")
        return handover_pack

    def confirm_takeover(self):
        self.pilot = Pilot.HUMAN
        self.board.write("pilot", Pilot.HUMAN.value, writer="tower")
        self.executor.standby()          # 机器操纵面退到待命

    def release_control(self, resume_note):
        """人交还：机器从交接包原地恢复，不重演历史。"""
        assert self.pilot is Pilot.HUMAN
        self.pilot = Pilot.AGENT
        self.board.write("pilot", Pilot.AGENT.value, writer="tower")
        self.executor.resume(resume_note)   # 人附注意图，机器续飞

    def tick(self):
        # 交接超时保护：请求无人应答则回安全态，绝不能悬空
        if self.pilot is Pilot.PENDING and \
           time.monotonic() > self._pending_deadline:
            self.executor.enter_safe_state()
            self.pilot = Pilot.AGENT
​

协议里两处设计最见功夫。交接包把人需要的现场打包成最小全套——信念、目标栈、航线、失败上下文、候选项——人接手不必从原始日志里考古；候选项让确认变成选择题而不是问答题，响应速度与质量都高一截。交接超时堵住真空缝隙：请求发出没人应答，机器自己进安全态，"没人管"永远落不到"没人管还继续飞"。

信任校准的可视化数据由建议通道持续供给，骨架如下：

class SuggestionChannel:
    """建议通道：机器只建议，裁量权归当前在飞的一方。"""

    def __init__(self, board, audit):
        self.board = board
        self.audit = audit

    def propose(self, suggestion):
        # 建议带置信度与理由，供监督者校准对机器的信任
        self.board.write("suggestion",
                         {"what": suggestion.action,
                          "why": suggestion.reason,
                          "conf": suggestion.confidence},
                         writer="agent")
        self.audit.append("suggestion", suggestion.name)

    def calibrate_report(self, window):
        """校准报表：建议被采纳率与正确率，信任的数字画像。"""
        stats = self.audit.query("suggestion", since=window)
        return {"adopted": stats.adopted_ratio(),
                "correct": stats.correct_ratio()}
​

意图共享与可解释性

叫人之前让人看得懂，靠的是意图共享：机器的计划、进展与顾虑对人透明。好消息是不必另起炉灶——第 1 章的状态板与第 3 章的任务单就是现成的解释素材：行为名与目标栈回答"在干什么、为什么"，任务单的步骤与验收谓词回答"还差几步、按什么标准算成"，2.4 节语义层的标签让人话直通机器的航图。可解释性的工程判据是回答三类追问：为什么这么做（引用目标与约束）、为什么现在做（引用触发与时机）、为什么不那样做（引用被否决的候选项及原因）。三问都能从结构化数据里答出来，就不需要事后编故事。

协作行动更进一步：人机同时在线、能力互补——机器出候选与执行精度，人出判断与例外处置。共享控制的关键仍是那根唯一的操纵杆：任何时刻只有一方拥有最终裁量权，另一方的输入以建议形式进入（机器的建议显示给人，人的建议标注给机器），建议可以有多个，裁量权只有一个。

信任校准：放权与插手的配平

信任错配有两种病：过度信任（人不再核对，机器错了人也跟着错到底）与过度插手（人频繁打断，机器的闭环被打成碎片段）。校准的抓手是透明的不确定性——置信度、回执统计、故障史对监督者可见且被要求看：置信度高的画面淡呈现，低的重呈现；再配定期的接管演练，让监督者的手感与机器的真实水平对表。信任不是建出来的，是校准出来的——校准的依据是双方持续暴露的真实成绩单。

图：接管等级滑条——按可逆性与置信度定位当下档位

联调测试与故障排查

塔台频道的联调主打交接演练：正常交接、交接中超时、人在飞时机器故障、机器在飞时人突然介入——四种剧本各跑一遍，核对操纵权状态的唯一性与现场的无损性。接管延迟也要测：从请求到人工应答的耗时分布，直接决定哪些场景敢放"异常接管"档。

按症状排查：模式混淆复发（日志里出现双方同时下指令）是交接协议被旁路——有人绕过接口直接驱动执行器，与第 1 章的状态板直写同罪，白名单与断言根治；请求疲劳（人开始无脑点确认）查触发阈值是否过敏感，用误报率回推；交还后行为怪异（机器恢复后重复已做过的步骤）查交接包是否缺字段——恢复要基于完整快照，不是从头重放。

💡 关键直觉：好的自动化不追求"人少管"，追求"人在对的时刻管对的量"。叫人叫得准，比飞得稳更能决定一套系统的口碑。

本节要点回顾

• 操纵权唯一：一根杆两个人握就是事故；"谁在飞"是严格唯一的状态，切换必须是协议事务。
• 接管分档：全程监督、关键点确认、异常接管、人工主飞；锚点是动作可逆性与置信度。
• 交接包与超时：人接手要有最小全套现场；请求无人应答自动落安全态，真空缝隙不容存在。
• 意图共享用现成数据：状态板、任务单、语义标签回答三类追问，可解释性不靠事后编故事。
• 信任靠校准：透明的不确定性加定期演练，防过度信任也防过度插手。

至此行动舱交舱，主回路全线贯通。下一章转进机腹的黑匣子舱：这些环节产生的记录怎么分层保管、飞行状态怎么记账、断电重启后怎么原地复活。