LLM 指令门控（FunctionCall）：结构化解析 + fail-closed 拦截

01问题引入：LLM 的嘴，门控的手

如果没有门控，用户随口一句"把那个红色的追一下"，0.8B 的小模型可能幻觉出一个根本不存在的 id99；一句"你好"也可能被误吐成 track_ids 而当成追踪指令执行。需求 R7 要求指令理解可控、可拦截，R5 要求误触发为零。所以架构把职责劈成两半——嘴与手分开：

02原理通俗讲解：机场安检的"拿不准就不放行"

把 LLM 想成 热心的前台接待：语法再好也只是复述请求；放行进闸机的是安检员（_native_gate），前台说的不算数。安检员按 固定顺序核验（对应讲义 5.6 路由图）：

类比消防门——正常状态锁着（默认关闭），只有确认是自己人才推开；绝不会因为"识别不出"就敞开门。锁车是危险副作用（锁定后即便目标消失也不跟别的车），误锁成本远高于不动作，这是 fail-closed 成为安全核心的原因。

03关联知识点

# config/track_config.yaml L76 起（interaction 词表，讲义 5.6 JSON）
interaction:
  clear_words:   [清除, 解除, 取消, 停, 不追, 恢复全, 不跟]
  track_words:   [追踪, 追, 锁定, 识别, 找, 看, 跟, 停]
  instruct_words:[追踪, 追, 停, 取消, 解除, 不追, 恢复全, 不跟, 清除]
  color_words:   [红, 蓝, 白, 黑, 绿, 黄, 灰, 粉, 紫]
  desc_words:    [红, 黄, 蓝, 白, 黑, 绿, 灰, 粉, 紫, 卡车, 轿车, suv, 大, 小, 新, 旧]

• _rule_fallback（track_app.py L618-626）：LLM 失败 → parse_instruction → 执行或回"没听懂"；只支持追踪/清除/列目标，不支持闲聊（test_chat_reply_clean.py L206-217 断言闲聊无规则可匹配）。
• 行为基线：tests/test_native_wiring.py L18-113 覆盖门控 id 对齐/不对齐/清除强制/描述走 VLM/闲聊回落五类断言。
• 安全依据：rkllm 原生工具调用（llm_server.py set_function_tools）与 OpenAI function calling 同构——但执行权始终在本地 registry。

04实验目标

• 掌握 CommandWorker 门控路由（_native_gate L320-366 顺序）与 fail-closed 语义。
• 理解清除语义强制 clear_track（分支①短路）与闲聊回落（分支②不执行工具）的本质差异。
• 掌握 LLM 子进程常驻管理（server_manager，端口 8080）与 parse_instruction 规则兜底。
• 独立完成文本全链路验证：track_app.py --text --mjpeg 交互，先输入「小飞小飞」唤醒，再「追踪 id3 的车」锁定，然后清除、闲聊。
• 会读日志分岔：[cmd] = 门控放行指令、[LLM] = 闲聊回落、[track_vlm] = 转视觉选目标——三种前缀对应三条路由。
• 迁移：理解大模型 FunctionCall 在机器人指令场景的门控安全设计（模型可幻觉、代码可兜底）。

05实验环境与准备

# ① 快速回归（跳过真模型用例，x86 可跑）
cd ~/ros2_ws/src/xflz_eai_car1/app/object_tracking
python3 -m pytest tests/ -q -k "not test_real"

# ② 查看门控与兜底的源码锚点
grep -n "NATIVE_TOOLS\|_native_gate\|_rule_fallback" apps/track_app.py
grep -n "clear_words" config/track_config.yaml   # L76 词表

06动画讲解：门控路由与 fail-closed 出口

一条 FunctionCall 进门后按路由图顺序核验。看三条彩带走哪条路——青色合法指令五步放行；琥珀话语含清除词在①短路强制 clear_track；红色幻觉 ID 在③"数值不对齐"被拦下坠入⑤拒绝口。

07互动讲解：门控判定输入实验台

点预设句或自由输入，模拟它经 FunctionCall 解析后落在门控哪条路由（判定逻辑按 L320-366 路由顺序的讲义语义推演；示例检测池：id2、id3、id7）。

试着输入「停」「不追了」——它们都在 clear_words 里，会走分支①短路；再输入「追高架」——有追踪词却解不出数字与描述，应停在"请提供目标 id"的引导，绝不空 submit。这就是 L67 特判在替你把关。

08实操步骤：追踪 / 清除 / 闲聊三连

# 工作目录（object_tracking 模块）
cd ~/ros2_ws/src/xflz_eai_car1/app/object_tracking

# 1. 纯逻辑门控用例（x86，无真实 LLM）
python3 -m pytest tests/ -q -k "not test_real"   # 覆盖 _native_gate/test_native_wiring/闲聊

# 2. 文本全链路（LLM FunctionCall + 门控）——依次在提示符输入三句
python3 apps/track_app.py --video /home/iflytek/ros2_ws/src/xflz_eai_car1/vision/07_multi_object_tracking/test.mp4 --text --mjpeg
小飞小飞
追踪id3
# 期望：[cmd] track_ids {3} → 播报「好的，只追踪 id3」
清除
# 期望：[cmd] 清除语义指令，执行 clear_track → 播报「好的，已解除全部锁定」
你好
# 期望：[LLM] 自然回复，[cmd] 不存在——闲聊回落干净请求，无工具执行

# 3. 规则兜底演练：杀 LLM 后重跑第 2 条命令
pkill -f llm_server
# 「追踪 id3」→ parse_instruction L45-68 接管照常锁定；「你好」→ _rule_fallback 回「没听懂」（设计预期）

# 4. 实验收尾：清理常驻子进程
pkill -f llm_server

09重点与易错点

• 路由顺序即安全：清除 > 非指令回落 > ID 对齐 > 描述转 VLM > 执行。清除必须放最前——它是安全操作且模型可能误吐，短路保证"说了解就一定解"。
• 验证顺序：pytest（-k "not test_real"）→ 三连文本 → 宕机演练，三步都要留日志证据。
• 实验后 pkill -f llm_server 清理常驻子进程（track_app finally 也会调 stop，但手工跑测试时容易漏）。
• 不要自行放宽门控：fail-closed 是安全核心，任何"不确定锁谁"都不执行工具。

10总结与思考